Patch was released, but it’s unclear if this fixed the exploit. No confirmed details on how the hack was performed are available, no official statements from VestaCP team on the issue, just a security patch that fixed some issues.
Personal opinion: Assume VestaCP is still pwned, do not run the vesta service unless you’re a gambler.
April 8 Update:
Patch Released, please update your VestaCP installs ASAP.
Lots of users reporting their boxes have been pwned. Vesta dev team members suggesting users disable the vesta service on your machine (admin panel) until they can figure out what’s going on and release a patch.
Likewise. Considering the value of what’s behind mine (MX1 and Galaxy MXroute servers) old/classic customers may have to bite the bullet on having no panel for a while though. Ain’t gonna play games with that data, one mild scare and I’ll wall up like Trump visiting Mexico.
The first wave happened on April 4. Servers were infected with /etc/cron.hourly/gcc.sh
It was an automated hack
CentOS, Debian, Ubuntu all distros are affected it’s platform independent
We didn’t find any traces in vesta and system logs yet
On April 7 infected servers started to DDoS remote hosts using /usr/lib/libudev.so.
What you can do:
The best way to stay safe is to temporary disable vesta web service
service vesta stop
systemctl disable vesta
or limit access to port 8083 using firewall
What we are doing:
Few users provided us with root access to their servers. We are investigating what happened. We also launched a couple honeypots in order to get full picture of the hack.
Might be the VestaCP API. I recommend the providers to issue a security advisor. Users are reporting DDoS and spam activity occurring in their servers.
They have to. In the past (and to some extent, to this day), they used to be extremely criticized and called out as #1 attack source on the whole internet.
Remember the recent memcached fiasco (memcached as a DDoS Amp)? Many people on NANOG mailing list were openly hating on OVH and suggesting everyone to de-peer them, block all their ranges (and it seems quite a few netops do block OVH ranges) etc