Re: Got 10 VestaCP servers exploited
Posted: Tue Apr 10, 2018 4:40 pm
Already enabled for new installationsThe most thing that I am concerned about the future is that updating Vesta wont enable access logs
Community Forum
https://forum.vestacp.com/
Already enabled for new installationsThe most thing that I am concerned about the future is that updating Vesta wont enable access logs
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.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.
So the exploit is still present :(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
Can 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
You 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
Thanks for the breakdown of the patch.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.
If no POST data was collected from the attacker and it hasn't been able to be reproduced, this doesn't inspire much confidence in being a proper patch to the exploit used.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.
Code: Select all
2018/04/09 03:52:05 [error] 8641#0: *32 "/usr/local/vesta/web/_asterisk/index.php" is not found (2: No such file or directory), client: 46.161.55.106, server: _, request: "GET /_asterisk/ HTTP/1.1", host: "myip:8083"