We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on Vesta 2.0 and expect to release it by the end of 2024. Read more about it: https://vestacp.com/docs/vesta-2-development
Got 10 VestaCP servers exploited
Re: Got 10 VestaCP servers exploited
we don't have log nothing during the attack, after attack we've some hacked OS files with root permission and with outbound ddos
Re: Got 10 VestaCP servers exploited
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).nextgi wrote: ↑Sun Apr 08, 2018 6:37 pmhttps://www.virustotal.com/#/file/48343 ... /detection
This is for libudev.so, the infected version.
Re: Got 10 VestaCP servers exploited
patience at bottleneck lolStudioMaX wrote: ↑Sun Apr 08, 2018 6:47 pmWe 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).nextgi wrote: ↑Sun Apr 08, 2018 6:37 pmhttps://www.virustotal.com/#/file/48343 ... /detection
This is for libudev.so, the infected version.
Re: Got 10 VestaCP servers exploited
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.
Re: Got 10 VestaCP servers exploited
StudioMaX wrote: ↑Sun Apr 08, 2018 6:47 pmWe 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).nextgi wrote: ↑Sun Apr 08, 2018 6:37 pmhttps://www.virustotal.com/#/file/48343 ... /detection
This is for libudev.so, the infected version.
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.
Re: Got 10 VestaCP servers exploited
Falzo,Falzo wrote: ↑Sun Apr 08, 2018 6:57 pmthat'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.
Thank you much. I do appreciate your candidness. I completely understand, this is one of the problems with bleeding edge discoveries.
Re: Got 10 VestaCP servers exploited
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.
Re: Got 10 VestaCP servers exploited
So,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.
Last edited by nextgi on Sun Apr 08, 2018 7:13 pm, edited 1 time in total.
Re: Got 10 VestaCP servers exploited
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.