We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
Got 10 VestaCP servers exploited
Re: Got 10 VestaCP servers exploited
Already enabled for new installationsThe most thing that I am concerned about the future is that updating Vesta wont enable access logs
Re: Got 10 VestaCP servers exploited
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
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
Re: Got 10 VestaCP servers exploited
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=''
~
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=''
~
Re: Got 10 VestaCP servers exploited
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.
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
Re: Got 10 VestaCP servers exploited
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
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
Re: Got 10 VestaCP servers exploited
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
Re: Got 10 VestaCP servers exploited
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.
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.
-
- Posts: 92
- Joined: Sat Aug 02, 2014 6:50 pm
- Os: CentOS 6x
- Web: nginx + php-fpm
Re: Got 10 VestaCP servers exploited
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
You probably already did have your server compromised before installing the updates.
Re: Got 10 VestaCP servers exploited
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.
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.
Re: Got 10 VestaCP servers exploited
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"