Potential VestaCP zeroday exploit [May 19 Security Update Pushed]

#1

April 10 Update:

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.

https://forum.vestacp.com/viewtopic.php?f=10&t=16556&start=260#p68893

=======================

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.

Full thread: Got 10 VestaCP servers exploited - Vesta Control Panel - Forum

Edit:

Look for a gcc.sh file in your /etc/cron.hourly (and other cron.* folders). If you find it, you’ve been pwned.

Definitely disable the vesta service though ASAP. service vesta stop // systemctl stop vesta

7 Likes
#2

This is gonna be fun…

#3

Done. Interesting.

#4

Same. None of my boxes appear to have been impacted, apparently it’s showing itself as a gcc.sh file in /etc/cron.hourly/

Running an extra round of backups though right now, just in case.

#5

I blame Mike.

#6

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.

3 Likes
#7

[root@hostballs cd /etc/cron.hourly
[root@hostballs cron.hourly]# ls
0anacron awstats gcc.sh

1 Like
#8

RIP

2 Likes
#9

Yeah, rip. Will wait for their team to post an update and reinstall the server. Nothing important just yet!

#10

Now I’m lost, you joking with the @hostballs in there? Or was that just a hostname swap to post on the forum?

1 Like
#11

These are not the hostballs you are looking for.

#12

Joke is on you, HostBalls is running under a very secure copy of kloxo, and not that “kloxo-mr” fork. Ligesh is supposed to update it any day now.

4 Likes
#13

Wait, isn’t MXRoute Classic using Vesta?

#14

Sounds like good old XoR.DDoS?

RIP

#15

Yup, right here:

https://galaxy.mxroute.com:8083/

:slight_smile:

#16

Vesta team member posted an update Got 10 VestaCP servers exploited - Page 7 - Vesta Control Panel - Forum

Here is what we know so far:

  1. The first wave happened on April 4. Servers were infected with /etc/cron.hourly/gcc.sh
  2. It was an automated hack
  3. CentOS, Debian, Ubuntu all distros are affected it’s platform independent
  4. We didn’t find any traces in vesta and system logs yet
  5. 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.

1 Like
#17

Reading through that vestacp forum thread, it’s scarry how OVH will just drop your server off the face of the earth, like it’s nothing.

1 Like
#18

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.

#19

This has been a thing for ages now. It’s always been one of the biggest issues that presents itself working with OVH.

#20

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

// EDIT example: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks