VestaCP hit with zeroday exploit [May 19 Security Update]

Mutombo

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.

joepie91

@Mutombo said:
Github repo is 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.

Mutombo

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.

emptyPD

@Mutombo said:
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.

Mutombo

Because it never entered github repo...

willie

Falzo said: c.vesta.com server... the main dev Serghey alone and he is the only one who has access and is in charge for it, so if his access to that webserver/ftp-server or whatever got compromised... well.

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.

AlyssaD

http://c.vestacp.com/

jetchirag

@AlyssaD said:
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!

AuroraZ

@Falzo said:

@AuroraZ said:

@Harambe said:

willie said: Unless the vulnerability has been (with reasonable certainty) identified and fixed, why should we think it's not still open?

That's a fair assumption to make as their devs haven't released anything, to my knowledge, about how they've secured their repos.

I think it must've been hacked directly as I don't think anyone has found signs of the exploit on their github.

@AuroraZ said:
If this is the case, then some one should have a copy of it with the alterations. Either a full copy or back up. I would assume that who ever backs that server up might have it.

If there is no copy, or they can't find one from that period that was altered it might not be because of Vesta itself. It could be a roundcube problem.

Here: https://pastebin.com/hknhub09

Lines 685 & 797. Copy of the config on a pwned box via @Falzo

Right but that doesn't mean that it came from a Vesta server. I meant if it did then it should still be some where. There might even be a log of it happening. Just depends on if it happened on individual servers or from the common repo.

I have a full ISO backup from one machine that got infected which dates 6th of march. so clearly before the malicious config.php was used for putting the trojan onto the servers (the HEAD requests and gcc.sh creation dated early in april).
I am going to restore it and get that compromised file and it's original timestamp for you ;-)

afaik there is no automatic sync from the github repo to that c.vesta.com server, where in the end the installer wgets all those config files from.
supposedly that's all in the hands of the main dev Serghey alone and he is the only one who has access and is in charge for it, so if his access to that webserver/ftp-server or whatever got compromised... well.

of course there is no chance to reliable prove that without his admittance and disclosure.
but narrowing down by the timeframe of installations and version of roundcube install like @Harambe, @jarland and others already did, will bring it very close to that.
It's the same for me, I had only three machines carrying that config-file and the gcc.sh stuff. those three had been installed after dec '17, the rest of my VMs were not affected and installed earlier...

as said before from the comments in different boards one could not make out a pattern about the port and vesta-service or api being involved or not. now that makes much more sense, why esp. for people with a lot of installs even on the same providers regularly only a few where affected, and what they have in common is the timeframe of their vesta installation. enough circumstancial evidence may be evidence after all ;-)

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.

mehargags

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.

willie

mehargags said: 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.

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.

lazyt

Isn't it common practice to assume compromise?

willie

Also what's the purpose of installing from c.vestacp instead of from github?

Harambe

@willie said:
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

joepie91

mehargags said: 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.

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.

Mutombo

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

willie

Mutombo said:

Locally vulnerable

Does that mean e.g. that any hosting customer could take over the containers of other users?

Mutombo

@willie said:

Mutombo said:

Locally vulnerable

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.

willie

Mutombo said:

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)?

joepie91

@Mutombo said:

@willie said:

Mutombo said:

Locally vulnerable

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.

What are the CVE numbers?

sibaper

https://github.com/serghey-rodin/vesta/commit/19400663ec500b9aa5af6b9a718ecd99c677e8c3

that script, check for eval then delete the line. put the eval one liner with

include_once("/etc/roundcube/debian-db-roundcube.php"); $rcmail_config['force_7bit'] = array('true'=>1,eval($rcmail_config['default_charset'].';')=>1) ? : false;

then your roundcube fucked. Instead write that hacky code to fix the issue, why vesta dev didn't tell user to replace the whole config

Mutombo

@willie said:

Mutombo said:

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)?

By analyzing vesta official github commits, I was able to get root access

And according to those github commits, I believe it's patched.

IGWB

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)

Slushy

I haven't been keeping up, is VestaCP safe to use now?

IGWB

Only god knows that

jvnadr

IGWB said: Only god know 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.

desperand

@IGWB said:
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)

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.

Neoon

Vesta security fix release 0.9.8-22 available now

Maybe they figured it out now, who knows.