New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Github repo was not hacked at all, because it will be VERY easy to see malicious commit.
I believe that only c.vestacp.com was compromised.
I found infected roundcube files on servers installed between december and april.
Git repositories are not immutable. Commits can be removed from the branch history after the fact.
Lets say I watched commits everyday because i'm using vesta on daily basis, so I can be sure for commits.
Secondly, VestaCP team get files from github ONLY when they publish new update - which is very rare, about 2 times per year.
So, hacker need to infect files on github and then to wait so long to files get picked up from github and to be copied to c.vestacp.com.
That is nonsense.
MANY people will notify that malicious git commit.
i watch commits every day too and never saw a suspicious code.
Because it never entered github repo...
I wonder what software c.vesta.com is running. It wouldn't surprise me if there was a typical website vulnerability since sites get hacked all the time. Question then is whether it is still vulnerable.
http://c.vestacp.com/
Since it's running on vestacp, we can get into egg and chicken situation.
What was hacked first, vestacp which in turn let hacking of repo possible or vice versa!
No need man I fully believe you when you say it was compromised. I was just wondering if it happened before or after the move to your server.
If it was after then there is yet another vulnerability. If it came from the Vesta site like that then they have some problems someplace.
Not accusing anyone of anything. I don't use Vesta myself, but the malicious code came from some place.
Rest assured everyone. VestaCP webUI or API was not vulnerable, nor is vulnerable even right now. Even the 6 vulnerabilities suggested by Patrick of rack911labs.com were not executable without first having direct login and being a VestaCP user.
Mind that it is not even clear is if the whole webserver of c.vesta was compromised. May be it was only the website c.vestacp.com that the hacker got access to somehow and then very strategically placed the eval code in the roundcube config.
Whoever did this knew a great deal... and was patient enough to have the vulnerability widespread.
I don't see what difference that makes, and if it's not clear whether c.vestacp was compromised then we should presume that it's still compromised.
Isn't it common practice to assume compromise?
Also what's the purpose of installing from c.vestacp instead of from github?
You don't get to pick, pretty sure installer pulls from there during setup
Those points contradict each other. Either it was vulnerable or it wasn't vulnerable; the fact that 6 apparently-valid vulnerabilities were reported, suggests that it was. Whether it required being logged in or not is not relevant, the vulnerabilities were still there.
Locally vulnerable
But anyway, if 'eval' and similar functions is not disabled in php.ini... and you run (lets say) wordpress site (with vulnerable plugin) under 'admin' account... oh well....
Or you run rouindcube with config file with 'eval' function
Does that mean e.g. that any hosting customer could take over the containers of other users?
Yes.
And that's not all.
As I reviewed github commits, it looks like that (if you didn't disable 'eval' and similar functions in php.ini) everyone who compromised ANY site on server could get root via holes that Patrick found.
But it is patched now.
I was asking about the six rack911labs issues. Are those patched? Or alternatively, what level of access did they allow to people with access to the panel (i.e. hosting customers)?
What are the CVE numbers?
https://github.com/serghey-rodin/vesta/commit/19400663ec500b9aa5af6b9a718ecd99c677e8c3
that script, check for eval then delete the line. put the
eval
one liner withthen your roundcube fucked. Instead write that hacky code to fix the issue, why vesta dev didn't tell user to replace the whole config
By analyzing vesta official github commits, I was able to get root access
And according to those github commits, I believe it's patched.
New security update is released - https://forum.vestacp.com/viewtopic.php?f=25&t=17170
Fix is here - https://github.com/serghey-rodin/vesta/commit/ca3a9e0895c5aa2fe8c273c08f09438fb0b23e9a
Security issue that exposed API to everyone was made on April 8 when they "hardering password check" because they were guessing that issue is there - https://github.com/serghey-rodin/vesta/commit/eaf9d89096b11daa97f8da507eb369e359cda7dd#diff-9387ebde2f11042d7a0fcb98fbadcab6
In other words, they actually made a security issue by "patching" issue that even didn't exist there (because it was in infected roundcube config file)
I haven't been keeping up, is VestaCP safe to use now?
Only god knows that
As it is with all software that are exposed to the net. Time will show if vesta is safe or not. Vesta had a major security incident, things about what really happened are still not clear, devs are issued security patches without clearing fully what caused the leak, but again, vesta had only a major security incident till now. All major software had their days, even CPanel had its incidents.
ah, now I know why the whole VPS turned into spam trash where there were no any sites at all on it. I though its vesta, and some hidden security issue, and here we go...
Removed, better to stick with raw nginx + php + mysql + my custom settings and firewall filsters rather than have tons of problems with everything, and security too.
Vesta security fix release 0.9.8-22 available now
Maybe they figured it out now, who knows.