Vesta Control Panel - Forum

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.

pipoy wrote: ↑

Tue Apr 10, 2018 12:28 pm

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.

What makes you say that?

pipoy wrote: ↑

Tue Apr 10, 2018 12:28 pm

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.

pipoy, stop misinforming

imperio wrote: ↑

Tue Apr 10, 2018 12:37 pm

pipoy wrote: ↑

Tue Apr 10, 2018 12:28 pm

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.

pipoy, stop misinforming

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.

kandalf wrote: ↑

Tue Apr 10, 2018 1:21 pm

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.

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.

dsystem wrote: ↑

Tue Apr 10, 2018 1:55 pm

The Vespa team does not need and should not report anything.
Spreading what happened would only help the unemployed learn more of a way to hack into servers.

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.

fuzeweb wrote: ↑

Tue Apr 10, 2018 2:25 pm

dsystem wrote: ↑

Tue Apr 10, 2018 1:55 pm

The Vespa team does not need and should not report anything.
Spreading what happened would only help the unemployed learn more of a way to hack into servers.

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.

the core of what you are saying is true!
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.

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

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.

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