Got 10 VestaCP servers exploited

[soguor]

I kown the risk, but can't have this servers stopped.

Kill the vesta service at least if you want to keep the machine running.

I had already done it when I reinstalled vesta. I had not commented. Thank you! :)

[mxroute]

while only you could not see the api of vesta to be accessed (because all vesta access logging goes to /dev/null per default)

What 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.

So,

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.

Generally speaking the internal VestaCP commands are the ones executed over API at least. These are log censored entries from API automation:

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'

But as you noted I guess it's not going to log something that didn't call one of these commands. Whether the attack vector, if using the API at all, would have run the attack through one of the vesta scripts or merely injected it directly from the available PHP script to run the API I suppose would be the determining factor.

while only you could not see the api of vesta to be accessed (because all vesta access logging goes to /dev/null per default)

What are you doing to your installs? All of my API access is logged to /var/log/vesta/system.log.

Also auth for API is logged to /usr/local/vesta/log/auth.log.

if 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.

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.

[ivcha92]

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/

[nextgi]

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/

This in addition to a....
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.

[mxroute]

New commits here: https://github.com/serghey-rodin/vesta/commits/master

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.

I suppose we'll have to wait on that, obviously I'd rather someone be deep in coding a fix than here explaining it.

[ivcha92]

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

[sandy]

Update

Read it
https://servercheap.net/crm/index.php?r ... isory.html

[Falzo]

Theoretically, at least. It's not going to log the contents of a POST request by any application's default.

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 ;-)

My setup isn't really much different, most of my customization are to the bin scripts themselves, and to the template.

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.

[nextgi]

The best way to secure just about any web application is to use a firewall. White list the hosts that are necessary.

[mxroute]

The best way to secure just about any web application is to use a firewall. White list the hosts that are necessary.

Doesn't cut down the support tickets much though ;)