We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on Vesta 2.0 and expect to release it by the end of 2024. Read more about it: https://vestacp.com/docs/vesta-2-development
Got 10 VestaCP servers exploited
Re: Got 10 VestaCP servers exploited
Interesting.
But I never updated since January or February, so it means the virus was inside our servers this whole time waiting to be activated.
But I never updated since January or February, so it means the virus was inside our servers this whole time waiting to be activated.
-
- Posts: 92
- Joined: Sat Aug 02, 2014 6:50 pm
- Os: CentOS 6x
- Web: nginx + php-fpm
Re: Got 10 VestaCP servers exploited
The problem was a security fault on Vesta that was explored, this doesn't mean that you have a virus inative on your system.
I think the Vesta team should tell us what they know about this problem and what have they made to solve it, probably some people that really understand from security will help to check if everything is fixed now.
Re: Got 10 VestaCP servers exploited
The Vespa team does not need and should not report anything. Anyone who understands the subject and wants to help can study the changes made in the login script and argue with the developers on the subject if necessary.
Spreading what happened would only help the unemployed learn more of a way to hack into servers.
Re: Got 10 VestaCP servers exploited
Err, yes they should. Vesta needs to provide a full explanation as to how the hack happened, and what steps they've done to fix this as a fatal flaw in their product has led to the compromisation of thousands of servers.
Unfortunately without a detailed explanation it doesn't supply serious users of VestaCP with the confidence required to continue using their product.
Instead of shutting down any speculation as to how it happened with a quick message of reassurance, there's been a simple fix delivered with no actual confirmation or details to the POC as to how the hack occurred. The boards are overrun with rumors without any staff to confirm otherwise.
In my opinion, this will be the deathknell for the VestaCP project. I cannot see how any serious user or developer will have any confidence in using this anymore.
Re: Got 10 VestaCP servers exploited
the core of what you are saying is true!fuzeweb wrote: ↑Tue Apr 10, 2018 2:25 pmErr, yes they should. Vesta needs to provide a full explanation as to how the hack happened, and what steps they've done to fix this as a fatal flaw in their product has led to the compromisation of thousands of servers.
Unfortunately without a detailed explanation it doesn't supply serious users of VestaCP with the confidence required to continue using their product.
Instead of shutting down any speculation as to how it happened with a quick message of reassurance, there's been a simple fix delivered with no actual confirmation or details to the POC as to how the hack occurred. The boards are overrun with rumors without any staff to confirm otherwise.
In my opinion, this will be the deathknell for the VestaCP project. I cannot see how any serious user or developer will have any confidence in using this anymore.
without a clue and no definitive assurance or understanding, i cant see me using this product with the same confidence as i did.
i might as well look for alternatives. i enjoyed the last 4 years with vestacp, but communication is everything.
you dont need to give complete fine details with line of codes or a proove of example.
but theres a thing inbetween. between nothing and everything.
-
- Posts: 73
- Joined: Sun Dec 03, 2017 6:30 pm
Re: Got 10 VestaCP servers exploited
I agree with you.
The fix was based on one user enabling log and reporting /API/ requests
But he didn't enable post logging. And we never got post data.
And the only flaw that could be the possible reason is patched even though many tried exploiting older version and didn't succeed. So noone knows what's going on.
Therefore we are all keeping Vesta service disabled
The fix was based on one user enabling log and reporting /API/ requests
But he didn't enable post logging. And we never got post data.
And the only flaw that could be the possible reason is patched even though many tried exploiting older version and didn't succeed. So noone knows what's going on.
Therefore we are all keeping Vesta service disabled
Re: Got 10 VestaCP servers exploited
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.
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.
Re: Got 10 VestaCP servers exploited
The most thing that I am concerned about the future is that updating Vesta wont enable access logs since config files are not getting update. Only way to enable them is by manually editing config files by user. So every Vesta installaton which is currenly running will still not make access logs and if something similar happens in future we wont have logs again