Got 10 VestaCP servers exploited

[Prime]

Hi, I've two vps on ovh with attack, I downloaded the three last backups of vesta from /backup and was reinstalled the S.O. (Debian 9) with vestacp. I was restore the backup on new installation and change port of vestacp. At the moment, i monitoring and don't see anything wrong. On my VPSs, the archives of /backup don't they affected (at the moment).

The problem isn't fixed and therefore it's a not a good idea to leave it open.. you'll just end up with another infected machine.

[damian]

Experienced the same hack on my VestaCP server (CentOS 7.x) earlier today, came across this thread only now. Deleting the malicious script only caused gcc.sh to reinstall it. Followed the steps outlined here: https://superuser.com/a/1004724 to change /lib/ folder permissions, secure cron permissions, delete the initial scripts, and afterwards deleted the libudev.so file.

Note that a cron is added to both the cron.hourly file as well as the cron.hourly/ folder

Hope this helps someone!

[soguor]

Hi, I've two vps on ovh with attack, I downloaded the three last backups of vesta from /backup and was reinstalled the S.O. (Debian 9) with vestacp. I was restore the backup on new installation and change port of vestacp. At the moment, i monitoring and don't see anything wrong. On my VPSs, the archives of /backup don't they affected (at the moment).

The problem isn't fixed and therefore it's a not a good idea to leave it open.. you'll just end up with another infected machine.

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

[Prime]

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.

[DarthVader]

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.

What if add die() to /usr/local/vesta/web/api/index.php
This could resolve problem?

[igorus]

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

I have many servers with VestaCP. The only one without IP restriction for VestaCP got this infection.
So, protect port 8083 and you will be fine, I think.

[sandy]

so it isn't roundcube issue rather vulnerability is in vesta core files and vesta team assured security patch tomorrow. Wait for it.

[vesta_mtl]

Thanks for sharing this link. I cannot access Vesta GUI today on my DigialOcean servers. This DigitalOcean message saying they have blocked inbound traffic to 8083 seems to explain it (I have other servers on Vultr which still work). Once DigitalOcean re-opens the access to 8083, what is recommended so that I can protect my Vesta GUI?

Wonder how many hosts that are infected, considering this...

Code: Select all

Our engineering team continues to work to resolve the networking issue impacting our NYC regions. We believe a previously undisclosed vulnerability in software by some customers on their Droplets is allowing for denial of service (DoS) attacks against targets outside of DigitalOcean. Our Trust & Safety team is also engaged to resolve this incident; in an effort to protect unaffected Droplets, we will block inbound traffic to TCP/8083. 

We will continue to post updates here as more information becomes available, and we will provide additional guidance for customers to determine whether their Droplets are impacted, and how to work around the block to continue to safely access their software.

https://status.digitalocean.com/incidents/jzszyktwsrss

[sandy]

Thanks for sharing this link. I cannot access Vesta GUI today on my DigialOcean servers. This DigitalOcean message saying they have blocked inbound traffic to 8083 seems to explain it (I have other servers on Vultr which still work). Once DigitalOcean re-opens the access to 8083, what is recommended so that I can protect my Vesta GUI?

Wonder how many hosts that are infected, considering this...

Code: Select all

Our engineering team continues to work to resolve the networking issue impacting our NYC regions. We believe a previously undisclosed vulnerability in software by some customers on their Droplets is allowing for denial of service (DoS) attacks against targets outside of DigitalOcean. Our Trust & Safety team is also engaged to resolve this incident; in an effort to protect unaffected Droplets, we will block inbound traffic to TCP/8083. 

We will continue to post updates here as more information becomes available, and we will provide additional guidance for customers to determine whether their Droplets are impacted, and how to work around the block to continue to safely access their software.

https://status.digitalocean.com/incidents/jzszyktwsrss

they can only blocks ports during attacks the main issue is the CP script we're using. As DDOS attack are not allowed on 99% of hosts.

[Trentor]

Once DigitalOcean re-opens the access to 8083, what is recommended so that I can protect my Vesta GUI?

If you can access to your server via SSH, you are able to change the port of VestaCP right now.

• Choose a new port

• If it's neccesary, open the new port in your firewall

• Edit your VestaCP nginx config

Code: Select all

/usr/local/vesta/nginx/conf/nginx.conf

• Search for this line and modify 8083 with your new port

Code: Select all

server {
        listen          8083;

• Restart your server or, at least VestaCP and your firewall

• Then, you can close 8083 in your firewall if you want

• Check if you are able to connect to your VestaCP installation in the new port