Got 10 VestaCP servers exploited

[imperio]

The most thing that I am concerned about the future is that updating Vesta wont enable access logs

Already enabled for new installations

[ivcha92]

But what for those installations which were not affected. How many users are going to read forum and update their configs? Many of us did not reinstall systems completely. Just cleared the virus and got the servers runnign.

I just think it might a be a good ide to implemnt some differential scripts on update which will run on update from specific version

[sukh0v]

hi,

facing this error when try to update VestaCP:

[root@teampower /]# /usr/local/vesta/bin/v-update-sys-vesta-all
/usr/local/vesta/conf/vesta.conf: line 1: WEB_SYSTEM=httpd: command not found
/usr/local/vesta/conf/vesta.conf: line 1: WEB_SYSTEM=httpd: command not found
/usr/local/vesta/conf/vesta.conf: line 1: WEB_SYSTEM=httpd: command not found
/usr/local/vesta/conf/vesta.conf: line 1: WEB_SYSTEM=httpd: command not found
/usr/local/vesta/conf/vesta.conf: line 1: WEB_SYSTEM=httpd: command not found


And no any clue why this not works.
vesta.conf:

WEB_SYSTEM='httpd'
WEB_RGROUPS='apache'
WEB_PORT='8080'
WEB_SSL_PORT='8443'
WEB_SSL='mod_ssl'
PROXY_SYSTEM='nginx'
PROXY_PORT='80'
PROXY_SSL_PORT='443'
STATS_SYSTEM='webalizer,awstats'
FTP_SYSTEM='vsftpd'
DNS_SYSTEM='named'
MAIL_SYSTEM='exim'
ANTIVIRUS_SYSTEM=''
ANTISPAM_SYSTEM=''
IMAP_SYSTEM='dovecot'
CRON_SYSTEM='crond'
FIREWALL_SYSTEM='iptables'
FIREWALL_EXTENSION='fail2ban'
BACKUP_SYSTEM='local'
LANGUAGE='en'
VERSION='0.9.8'
DB_SYSTEM='mysql'
DISK_QUOTA='no'
FILEMANAGER_KEY=''
~

[Nipsey]

First 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.

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

[ivcha92]

First 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.

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

So the exploit is still present :(

Do you have now log at /usr/local/vesta/log/nginx-access.log to get more detail what is going on. I am sill keeping vesta service off since I need websites on the server working

[mxroute]

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

Can you confirm that this was a root level infection and did it appear just the same as the majority of the reports here?

[n0x]

Just had a message from Digital Ocean that I had an outbound DDoS originating from a clean OS install after the Saturday problems.

This was a clean 0.9.8-19 install that I updated to 0.9.8-20.

Looks like my clean 0.9.8-20 installation hasn't been compromised. I'll be back at a PC in half an hour and will post some more details.

[RevengeFNF]

First 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.

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.

You probably already did have your server compromised before installing the updates.

[Harambe]

First 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.

Thanks for the breakdown of the patch.

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.

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.

Among the seasoned sysadmins I know, a response of "install this patch, everything's good now" without firm details of the attack is more disconcerting than it is reassuring.

This attack trashed the networks of big providers, I don't know if the patch and explanation given is enough for them to let down their network-wide port bans - or the scanning of their network for VestaCP and then disabling networking on machines found running it.

[efinstorm]

Found this in my nginx-error.log

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"