04-09-2018, 11:38 PM
@Monad of FreeVPS reported a serious security issue with VestaCP:
https://freevps.us/thread-22032-post-244426.html
I'm a very enthusiastic user of VestaCP so have been studying the VestaCP discussion thread about the issue.
In summary what happened was a wave of Servers were infected with /etc/cron.hourly/gcc.sh on 4th of April. It was an automated hack. The infection was platform independent meaning that all of the OSs were affected. On April 7th the infected servers started to DDoS remote hosts using /usr/lib/libudev.so. The logical consequence was a large scale suspension of those VPSs. All of it happened very fast. Those affected included smart users. In other words geeks who were using all of the standard precautions, security measures, keyless entries etc. So there is a theory that the issue could have originated with the VestaCP installation script. That theory hasn't been proven yet. However, until it does either way, those of us who are using VestaCP need to be careful with using it.
In the meanwhile there is a patch available from VestaCP that users can use. I'm on automatic updates with VestaCP and I always thought every one else was by default, so for those with automatic updates this patch should already have been loaded during 8th of April. Here is a copy of the post about the patch:
https://forum.vestacp.com/viewtopic.php?p=68893#p68893
https://freevps.us/thread-22032-post-244426.html
I'm a very enthusiastic user of VestaCP so have been studying the VestaCP discussion thread about the issue.
In summary what happened was a wave of Servers were infected with /etc/cron.hourly/gcc.sh on 4th of April. It was an automated hack. The infection was platform independent meaning that all of the OSs were affected. On April 7th the infected servers started to DDoS remote hosts using /usr/lib/libudev.so. The logical consequence was a large scale suspension of those VPSs. All of it happened very fast. Those affected included smart users. In other words geeks who were using all of the standard precautions, security measures, keyless entries etc. So there is a theory that the issue could have originated with the VestaCP installation script. That theory hasn't been proven yet. However, until it does either way, those of us who are using VestaCP need to be careful with using it.
In the meanwhile there is a patch available from VestaCP that users can use. I'm on automatic updates with VestaCP and I always thought every one else was by default, so for those with automatic updates this patch should already have been loaded during 8th of April. Here is a copy of the post about the patch:
https://forum.vestacp.com/viewtopic.php?p=68893#p68893
Quote:The fix has been released just now!
As usually there are 3 ways to update your server:
1. Via web interface
- Login as admin
- Go to updates tab
- Click un update button under vesta package
2. Via package manager
- SSH as root to your server
- yum update / apt-get update && apt-get upgrade
3. Via GitHub
- SSH as root
- Install git / yum install git /apt-get install git
- Then run following commands
Code: (Select All)cd $(mktemp -d)
git clone git://github.com/serghey-rodin/vesta.git
/bin/cp -rf vesta/* /usr/local/vesta/
Some information about this indecent. We still don't have working exploit for previous version. But we know for sure that the vector of attack was through a potentially unsecure password check method. Therefore we have completely rewrite password auth function. It's bullet proof now!
Please upgrade your servers as soon as possible.