Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


VestaCP hit with zeroday exploit [May 19 Security Update] - Page 11
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.

VestaCP hit with zeroday exploit [May 19 Security Update]

15678911»

Comments

  • MutomboMutombo Member
    edited May 2018

    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.

  • joepie91joepie91 Member, Patron Provider

    @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.

  • MutomboMutombo Member
    edited May 2018

    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.

  • emptyPDemptyPD Member

    @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.

  • MutomboMutombo Member

    Because it never entered github repo...

  • williewillie Member

    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.

  • 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!

    Thanked by 1Aidan
  • AuroraZAuroraZ Barred

    @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.

    Thanked by 1Falzo
  • 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.

  • williewillie Member
    edited May 2018

    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.

  • lazytlazyt Member

    Isn't it common practice to assume compromise?

  • williewillie Member

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

  • HarambeHarambe Member, Host Rep

    @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

    Thanked by 1willie
  • joepie91joepie91 Member, Patron Provider
    edited May 2018

    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.

    Thanked by 1inthecloudblog
  • MutomboMutombo Member
    edited May 2018

    Locally vulnerable :D
    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 :) :) :)

  • williewillie Member

    Mutombo said:

    Locally vulnerable :D

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

  • MutomboMutombo Member
    edited May 2018

    @willie said:

    Mutombo said:

    Locally vulnerable :D

    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.

  • williewillie Member

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

  • joepie91joepie91 Member, Patron Provider

    @Mutombo said:

    @willie said:

    Mutombo said:

    Locally vulnerable :D

    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?

  • sibapersibaper Member
    edited May 2018

    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

  • MutomboMutombo Member
    edited May 2018

    @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.

  • IGWBIGWB Member

    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)

  • SlushySlushy Member

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

  • IGWBIGWB Member
    edited June 2018

    Only god knows that :)

  • jvnadrjvnadr Member

    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.

  • @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.

  • NeoonNeoon Community Contributor, Veteran

    Vesta security fix release 0.9.8-22 available now

    Maybe they figured it out now, who knows.

Sign In or Register to comment.