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 4
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]

1246711

Comments

  • FalzoFalzo Member

    as the nginx that's used for accessing the control panel itself and the API does not log access at all but instead sends those data to /dev/null you won't be able to find the needed information on system that has been compromised before the issue become known anyway.

    luckily some people already were able to set up honeypots with logging and one even managed to confirm that there are accesses to the API, though sadly the POST data wasn't logged and it has not been revealed yet, what injection exactly happened.

    so far I'd assume that deactivating/removing the api folder/php script might be the easiest way to disable any new attacks while keeping the main interface up and usable for the clients. no guarantue though, waiting for more input on the possible POST calls. set up a honeypot myself, maybe I get lucky to catch something ;-)

  • MikePTMikePT Moderator, Patron Provider, Veteran

    @Falzo said:
    as the nginx that's used for accessing the control panel itself and the API does not log access at all but instead sends those data to /dev/null you won't be able to find the needed information on system that has been compromised before the issue become known anyway.

    luckily some people already were able to set up honeypots with logging and one even managed to confirm that there are accesses to the API, though sadly the POST data wasn't logged and it has not been revealed yet, what injection exactly happened.

    so far I'd assume that deactivating/removing the api folder/php script might be the easiest way to disable any new attacks while keeping the main interface up and usable for the clients. no guarantue though, waiting for more input on the possible POST calls. set up a honeypot myself, maybe I get lucky to catch something ;-)

    Yeah that one is pretty hilarious, no logs for the API, at all. lol

    Thanked by 1netomx
  • HxxxHxxx Member

    OMEGALOL

    @MikePT said:

    @Falzo said:
    as the nginx that's used for accessing the control panel itself and the API does not log access at all but instead sends those data to /dev/null you won't be able to find the needed information on system that has been compromised before the issue become known anyway.

    luckily some people already were able to set up honeypots with logging and one even managed to confirm that there are accesses to the API, though sadly the POST data wasn't logged and it has not been revealed yet, what injection exactly happened.

    so far I'd assume that deactivating/removing the api folder/php script might be the easiest way to disable any new attacks while keeping the main interface up and usable for the clients. no guarantue though, waiting for more input on the possible POST calls. set up a honeypot myself, maybe I get lucky to catch something ;-)

    Yeah that one is pretty hilarious, no logs for the API, at all. lol

  • ahmiqahmiq Member

    Pheww. just saw the post here.. Luckily i had changed vesta's API port and it was behind a firewall too.. didnt find any gcc.sh yet.

    but turned it off as a pre caution. Thanks for sharing.

  • jarjar Patron Provider, Top Host, Veteran

    MikePT said: no logs for the API, at all. lol

    That's not true. Logs of expected actions for the API, actions taken as intended through the API, are extensively logged.

    What wasn't logged there was what might be unexpected, the overflow.

  • MikePTMikePT Moderator, Patron Provider, Veteran

    @jarland said:

    MikePT said: no logs for the API, at all. lol

    That's not true. Logs of expected actions for the API, actions taken as intended through the API, are extensively logged.

    What wasn't logged there was what might be unexpected, the overflow.

    If you read, the necessary logs weren't being recorded, at all, therefore it's much harder to trace the attack vector.

  • oof

  • jarjar Patron Provider, Top Host, Veteran

    MikePT said: If you read, the necessary logs weren't being recorded, at all

    If you read, there is no confirmation as to what logs are necessary :P

  • I removed VestaCP somewhat years ago already. My provider at that time, Swiftway just banned the use of it after my server was compromised. Bought a DirectAdmin license. I liked it, so after some months I bought two life time licenses. All fine. :)

  • LeeLee Veteran

    Won't stop using it, still a nice enough panel, shit happens. I mean, it's worth what I pay for it.

  • HarambeHarambe Member, Host Rep

    @Lee said:
    Won't stop using it, still a nice enough panel, shit happens. I mean, it's worth what I pay for it.

    Limit access to admin panel via IP, reverse proxy admin panel with nginx and another layer of password auth, etc.

    It's a great panel, so hopefully some users smarter than myself can pick apart the security and help lock it down.

    Thanked by 3Lee Wolveix Ympker
  • FalzoFalzo Member
    edited April 2018

    @jarland said:

    MikePT said: If you read, the necessary logs weren't being recorded, at all

    If you read, there is no confirmation as to what logs are necessary :P

    @jarland is right, as he already pointed out API auth should be logged and every vesta command that's called will add an entry into the syslog.
    most likely the (hacking) api request didn't need to auth at all, but was able to inject the malicious code at such an early stage that nothing made it into those logs.

    sadly if it is an code injection via vulnerable POST vars, even with access-logs available all you'll see is the request to the API itself - just like it would be with such attacks vs any other PHP script. apache or nginx won't log the content of the POST request anyway...

    seems like still no one really knows the content of those POST calls yet, so the new commit they released might not be an exact fix. hardening should never be wrong though.

    I am going to monitor closely and probably take on the risk to bring back the interfaces only slowly with deactivated API tomorrow.

    as @Lee said, still good for what one has to pay for it :-D

    most panels do cost money or offer tons of complicated features only a handful of people really make use of. I wouldn't even need a panel myself for personal stuff, but for clients Vesta provides an easy and clean way to give access e.g. to set up a mail-address or database by themselves without to much hassle.

    Thanked by 4Harambe Lee netomx mikho
  • HarambeHarambe Member, Host Rep
    edited April 2018

    Patch was just released, hard to tell if this is the final fix though:

    https://forum.vestacp.com/viewtopic.php?f=10&t=16556&start=260#p68893

    The fix has been released just now!
    As usually there are 3 ways to update your server:

    1 Via web interface

    • Login as admin
    • Go to updates tab
    • Click un update button under vesta package

    2 Via package manager

    • SSH as root to your server
    • yum update / apt-get update && apt-get upgrade

    3 Via GitHub

    • SSH as root
    • Install git / yum install git /apt-get install git
    • Then run following commands

    >

    cd $(mktemp -d)
    git clone git://github.com/serghey-rodin/vesta.git
    /bin/cp -rf vesta/* /usr/local/vesta/

    Some information about this indecent. We still don't have working exploit for previous version. But we know for sure that the vector of attack was through a potentially unsecure password check method. Therefore we have completely rewrite password auth function. It's bullet proof now!

    Please upgrade your servers as soon as possible.

    Thanked by 1scorcher9
  • HarambeHarambe Member, Host Rep

    Also:

    It's bullet proof now!

    Famous last words there Vesta team...

  • HarambeHarambe Member, Host Rep

    @MasonR (or another mod), could you give me edit privs on the OP again? Want to update to include the patch info. Or if you could just drop that block + link to VestaCP forum I posted 2 comments ago into the bottom of my post, and maybe update thread title with [Patch Released], would be appreciated!

  • MasonRMasonR Community Contributor

    @Harambe said:
    @MasonR (or another mod), could you give me edit privs on the OP again? Want to update to include the patch info. Or if you could just drop that block + link to VestaCP forum I posted 2 comments ago into the bottom of my post, and maybe update thread title with [Patch Released], would be appreciated!

    Unfortunately Vanilla doesn't give us many options regarding permissions, so I updated the OP and title. Give me a shout if you'd like anything changed/added.

    Thanked by 1Harambe
  • HarambeHarambe Member, Host Rep

    @MasonR Nope, that's perfect, thanks dude. Just didn't want the update buried on page 3.

    Thanked by 1MasonR
  • MikePTMikePT Moderator, Patron Provider, Veteran

    @Harambe said:
    Also:

    It's bullet proof now!

    Famous last words there Vesta team...

    Really. Like tmobileat?

  • MikePTMikePT Moderator, Patron Provider, Veteran
    edited April 2018

    @Falzo said:

    @jarland said:

    MikePT said: If you read, the necessary logs weren't being recorded, at all

    If you read, there is no confirmation as to what logs are necessary :P

    @jarland is right, as he already pointed out API auth should be logged and every vesta command that's called will add an entry into the syslog.
    most likely the (hacking) api request didn't need to auth at all, but was able to inject the malicious code at such an early stage that nothing made it into those logs.

    sadly if it is an code injection via vulnerable POST vars, even with access-logs available all you'll see is the request to the API itself - just like it would be with such attacks vs any other PHP script. apache or nginx won't log the content of the POST request anyway...

    seems like still no one really knows the content of those POST calls yet, so the new commit they released might not be an exact fix. hardening should never be wrong though.

    I am going to monitor closely and probably take on the risk to bring back the interfaces only slowly with deactivated API tomorrow.

    as @Lee said, still good for what one has to pay for it :-D

    most panels do cost money or offer tons of complicated features only a handful of people really make use of. I wouldn't even need a panel myself for personal stuff, but for clients Vesta provides an easy and clean way to give access e.g. to set up a mail-address or database by themselves without to much hassle.

    Fair enough. Nevertheless its design doesn't seem to be right.
    Note that access log isn't everything. There should be an extra logging mechanism/verbose, eg WHMCS module logs.

  • I am going to err on the side of caution and upgrade, but keep the vesta panel down. It might be suggestible for you all to follow as well.

    Thanked by 1Harambe
  • DylanDylan Member
    edited April 2018

    @Clouvider said:

    @Hxxx said:
    Time for Vesta to start paying security researchers to inspect that code.

    With what money ?

    I'm sure they're not making cPanel money but they do sell commercial addons and support packages. Plus they have a few corporate sponsors.

    Thanked by 1doughmanes
  • MikePTMikePT Moderator, Patron Provider, Veteran
    edited April 2018

    @Dylan said:

    @Clouvider said:

    @Hxxx said:
    Time for Vesta to start paying security researchers to inspect that code.

    With what money ?

    I'm sure they're not making cPanel money but they do sell commercial addons and support packages.

    I have no idea but got a feeling that such income is far from enough to cover a proper security firm to review the whole code. Plus, its open source so anyone can review it and contribute. Maybe this time they will allow other people to contribute to their code.

  • jarjar Patron Provider, Top Host, Veteran
    edited April 2018

    I can't escape the feeling that this patch addressed security complaints that resulted from the compromises and not the actual attack vector. It seems odd that the community so quickly jumped to conclusions that matched the cause when no one could confirm the cause.

    Perhaps I'm wrong. But I'd like to know the cause and how the patch addressed it, someone knows the cause enough so that no one is safe so it's not important that it remain hidden.

    Thanked by 3Harambe MasonR netomx
  • HarambeHarambe Member, Host Rep

    @AlyssaD said:
    I am going to err on the side of caution and upgrade, but keep the vesta panel down. It might be suggestible for you all to follow as well.

    Yeah, I did the same thing. I don't know if the patch actually addressed the issue or was just another security-related patch, I don't think anyone can know until a honeypot intercepts it.

  • @Harambe said:

    @AlyssaD said:
    I am going to err on the side of caution and upgrade, but keep the vesta panel down. It might be suggestible for you all to follow as well.

    Yeah, I did the same thing. I don't know if the patch actually addressed the issue or was just another security-related patch, I don't think anyone can know until a honeypot intercepts it.

    Exactly, and from what I gathered no one caught those actions from what I saw on the forum.

  • Thanks for this topic

  • MikePTMikePT Moderator, Patron Provider, Veteran

    @jarland said:
    I can't escape the feeling that this patch addressed security complaints that resulted from the compromises and not the actual attack vector. It seems odd that the community so quickly jumped to conclusions that matched the cause when no one could confirm the cause.

    Perhaps I'm wrong. But I'd like to know the cause and how the patch addressed it, someone knows the cause enough so that no one is safe so it's not important that it remain hidden.

    100% agreed.

  • HarambeHarambe Member, Host Rep

    Interesting..

    https://forum.vestacp.com/viewtopic.php?f=10&t=16556&start=280#p68923

    in my case :
    all vesta which are not install exim and dovecot are safe
    --exim no --dovecot no (while install)

    but some of my vesta which install exim and dovecot were infected with gcc.sh

  • jarjar Patron Provider, Top Host, Veteran

    Harambe said: Interesting..

    Yeah that's coincidence for sure. Exim and Dovecot do not run as any account that has those kind of privileges.

Sign In or Register to comment.