Re: Got 10 VestaCP servers exploited
Posted: Sun Apr 08, 2018 7:23 pm
Community Forum
https://forum.vestacp.com/
Generally speaking the internal VestaCP commands are the ones executed over API at least. These are log censored entries from API automation:nextgi wrote: ↑Sun Apr 08, 2018 7:12 pmSo,mxroute wrote: ↑Sun Apr 08, 2018 6:59 pmWhat are you doing to your installs? All of my API access is logged to /usr/local/vesta/log/system.log.
Also auth for API is logged to /usr/local/vesta/log/auth.log.
If the logging mechanism functions and this is the exploit point, you'll get more logging than you would in standard Nginx logs. Theoretically, at least. It's not going to log the contents of a POST request by any application's default.
As for logging, system.log does not contain entries for API based commands, only internal VestaCP commands. At least as we can tell. Auth.log however does show our authentication via API. We are testing a few exploit ideas now to see what nginx is truly logging.
We are noticing that if you send API requests without any username or password, nothing is logged.
Code: Select all
2018-04-07 01:00:54 admin {ip of other server} successfully logged in
2018-03-31 11:14:50 v-add-user 'username' '******' '[email protected]' 'PackageName' 'FirstName' 'LastName'
Aye I suppose so, fair point. My setup isn't really much different, most of my customization are to the bin scripts themselves, and to the template.Falzo wrote: ↑Sun Apr 08, 2018 7:14 pmif it is calling regular vesta-commands that might be the case, afaik those are the ones that log their actions to system.log themselves.
but probably there will be no entry for some foreign shell commands injected through unescaped POST vars...
at least I can't find anything in system.log - I was more about access-logs from the vesta nginx, which are redirect to /dev/null in /usr/local/vesta/nginx/conf/nginx.conf
honestly can't tell if that's been the default only lately or for a long time. so far I haven't come across the need for it, obviously my own fault to not check properly beforehand.
if you can share more insight because you use a different config/setup that would be ofc appreciated.
This in addition to a....ivcha92 wrote: ↑Sun Apr 08, 2018 7:34 pmThere might be an easier way to prevent attack and keep vesta running just by configuring http auth in /usr/local/vesta/nginx/conf/nginx.conf here is how it can be done https://docs.nginx.com/nginx/admin-guid ... ntication/
I'm interested to see whether these commits are known to be related to the issue or just things discussed in the thread and taken as likely candidates. Whether this is patching the hole or just boarding up a few windows that might possibly have been opened.StudioMaX wrote: ↑Sun Apr 08, 2018 7:13 pmNew commits here: https://github.com/serghey-rodin/vesta/commits/master
sadly that's very true. so even with being able to see that vesta or it's api was accessed via the nginx there would not have been any POST data anyway. it would only have helped to narrow it down more quickly ;-)
same as me then, I also usually put vesta behind a proxy to get rid of the port, but without additional auth set up, that's just obfuscation, same as changing the port... not really fixing the problem.My setup isn't really much different, most of my customization are to the bin scripts themselves, and to the template.