We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
Got 10 VestaCP servers exploited
Re: Got 10 VestaCP servers exploited
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.
Re: Got 10 VestaCP servers exploited
There 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/
Re: Got 10 VestaCP servers exploited
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/
Firewall!
Sorry to be persistent but a firewall is included with vestacp, use it. White listing hosts is very common and good practice in cybersecurity. It is also a very simple solution.
Re: Got 10 VestaCP servers exploited
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
I suppose we'll have to wait on that, obviously I'd rather someone be deep in coding a fix than here explaining it.
Re: Got 10 VestaCP servers exploited
I've already provided FTP access to OVH files. Haven't got any response on mail though. I was unable to get in touch with OVH to enable SSH rescue access. Anyway I noticed malicious files in /etc/rc.d/init.d/ those files are also symliked in all rc0.d, rc1.d .... rc6.d
Re: Got 10 VestaCP servers exploited
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.
Re: Got 10 VestaCP servers exploited
The best way to secure just about any web application is to use a firewall. White list the hosts that are necessary.