Re: Got 10 VestaCP servers exploited
Posted: Tue Apr 10, 2018 7:37 pm
sending email from my webserver (as always) but nothing , only can receive
Community Forum
https://forum.vestacp.com/
nextgi wrote: ↑Tue Apr 10, 2018 5:11 amHi Everyone,
We have put together a survey to help us better understand the general configuration in relation to some of the working theories. If you have suggestions to broaden the survey, please let us know.
https://goo.gl/forms/qXtzd6nZFrKNw7DN2
We greatly appreciate any input.
Didn't see that - Have completed it with info from the first time and today.kobo1d wrote: ↑Tue Apr 10, 2018 7:47 pmn0x, if you havent so yet, you can check out this poll and fill in your infos there:
nextgi wrote: ↑Tue Apr 10, 2018 5:11 amHi Everyone,
We have put together a survey to help us better understand the general configuration in relation to some of the working theories. If you have suggestions to broaden the survey, please let us know.
https://goo.gl/forms/qXtzd6nZFrKNw7DN2
We greatly appreciate any input.
Code: Select all
v-backup-user admin
Code: Select all
apt-get update && apt-get upgrade
v-update-sys-vesta-all
Code: Select all
scp /backup/admin.date.tar new-server:/backup/
Code: Select all
v-restore-user admin admin.date.tar
Yes it wasmxroute wrote: ↑Tue Apr 10, 2018 5:33 pmCan you confirm that this was a root level infection and did it appear just the same as the majority of the reports here?Nipsey wrote: ↑Tue Apr 10, 2018 4:57 pm
Yesterday I installed 0.9.8-20 on a fresh vultr centos 7.4 everything was fine the whole day until I ran yum update today, centos and vesta had updates so I accepted them and then the server was infected. Now I am afraid to run yum update after installing vesta. So I guess 0.9.8-20 is affected as well.
You can try this yourself, I don't know why yum update had vesta updates when I was already running version 0.9.8-20
How?. There was no /etc/cron.hourly/gcc.shRevengeFNF wrote: ↑Tue Apr 10, 2018 5:56 pmYou did have Vesta at version 0.9.8-20. Now you received the update to vesta-nginx and vesta-php to those versions.Nipsey wrote: ↑Tue Apr 10, 2018 4:57 pmYesterday I installed 0.9.8-20 on a fresh vultr centos 7.4 everything was fine the whole day until I ran yum update today, centos and vesta had updates so I accepted them and then the server was infected. Now I am afraid to run yum update after installing vesta. So I guess 0.9.8-20 is affected as well.skid wrote: ↑Tue Apr 10, 2018 3:42 pmFirst of all, there was no reports about hacks on 0.9.8-20.
Please update your servers as soon as possible.
For those who are interested in technical details here is how authentication model looked like in previous releases:
- PHP script /api/index.php receives user password via POST request
- then this script writes user password to a tmp file (for example /tmp/tmp.cWdkwNbBrR)
This operation was needed to protect password from being hijacked via "ps auxf" command.
- Path to the file was then passed to the shell script v-check-user-password:
(v-check-user-password admin /tmp/tmp.cWdkwNbBrR)
- The script reads the content of /tmp/tmp.cWdkwNbBrR and calls sub process in order to generate hash based on the file content
hash=$($BIN/v-generate-password-hash $method $salt <<< $password)
We think that this part could allow for arbitrary code execution. Theoretically you could send something like
"password; cat /etc/passwd" to get the content of /etc/passwd. However we weren't able to bypass auth protection ourselves.
Here is what we did in the new release.
- The PHP process still receives unescaped password via POST
- Then instead of transmitting this password to the script it is now creates hash
- Then this hash is written into the tmp
This way code injected string like "password; cat /etc/passwd" converts to a harmless "7v8FlZefN7aQ9OoxGkR8lFHKejCxH9g64TQVVoRUuAObszO2hJy.CAs8ZG3JUtDKYQZNIZS61" sequence of characters which makes it impossible to inject anything.
You can try this yourself, I don't know why yum update had vesta updates when I was already running version 0.9.8-20
You probably already did have your server compromised before installing the updates.