Got 10 VestaCP servers exploited

[sandy]

we don't have log nothing during the attack, after attack we've some hacked OS files with root permission and with outbound ddos

[StudioMaX]

https://www.virustotal.com/#/file/48343 ... /detection

This is for libudev.so, the infected version.

We all know this and discussed it on the first pages of this topic. Also, many of us has given access to infected servers to developers, and they know it all. The only thing we can do now is wait until someone provides the web server's logs from Vesta service, with the enabled logging of POST requests. But since logging has been disabled at all by default, we can only wait when the bots will exploit the honeypots (as we still don't know whether the developers actually found the reason of the hack).

[sandy]

https://www.virustotal.com/#/file/48343 ... /detection

This is for libudev.so, the infected version.

We all know this and discussed it on the first pages of this topic. Also, many of us has given access to infected servers to developers, and they know it all. The only thing we can do now is wait until someone provides the web server's logs from Vesta service, with the enabled logging of POST requests. But since logging has been disabled at all, we can only wait when the bots will exploit the honeypots (as we still don't know whether the developers actually found the reason of the hack).

patience at bottleneck lol

[Falzo]

We just want logs and as much information as possible.

that's what we all are here for, you're obviously just some hours behind ;-)

and no worries, I perfectly understand, that you won't run off guesses from an internet board...
sadly there are no logs to share - unless you get lucky and find someone who changed the logging config for the vesta-nginx before all of this started :/

of course I am willing to share whatever I find if I can manage to log further informations to help narrow down the problem.

[nextgi]

https://www.virustotal.com/#/file/48343 ... /detection

This is for libudev.so, the infected version.

We all know this and discussed it on the first pages of this topic. Also, many of us has given access to infected servers to developers, and they know it all. The only thing we can do now is wait until someone provides the web server's logs from Vesta service, with the enabled logging of POST requests. But since logging has been disabled at all by default, we can only wait when the bots will exploit the honeypots (as we still don't know whether the developers actually found the reason of the hack).

Im glad,

Simply providing more information. I

Is there any guess or evidence of which methods are exploited? I forgot that releasing information on the fly brings the wolves out to play. Anyway, we will keep our trap shut as to what we find until we find a solution. A good solution for all of you is to simply use a gosh darn firewall lol. Sorry, but for you, StudioMax to be pointing what is odvious, there is absolutly no need to disable VestaCP, simple enable the firewall and white list necessary hosts for the moment. In addition change the ports to which the service is listening on.

All vulnerabilities can be prevented and solved with diligence, not anger.

[nextgi]

We just want logs and as much information as possible.

that's what we all are here for, you're obviously just some hours behind ;-)

and no worries, I perfectly understand, that you won't run off guesses from an internet board...
sadly there are no logs to share - unless you get lucky and find someone who changed the logging config for the vesta-nginx before all of this started :/

of course I am willing to share whatever I find if I can manage to log further informations to help narrow down the problem.

Falzo,

Thank you much. I do appreciate your candidness. I completely understand, this is one of the problems with bleeding edge discoveries.

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

[nextgi]

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.

[StudioMaX]

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

[Falzo]

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.