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

13468911

Comments

  • Temporarily restarted one instance of vesta. It's at 0.9.8 20. vesta-php and vesta-nginx at 0.9.8 19.

    The vesta site shows 0.9.8 19 as the latest release (Jan 22). Further down it says
    "FINALLY, VESTA 0.9.8-18 IS HERE!"

    The roadmap says about 0.9.8-20 "The release is scheduled on end March 2018".
    I'm guessing the features for 20 are pushed out to 21, and 20 is basically 19 but with the fix?

    I'm still not 100% clear that I have the fix on my system.
    ¯_(ツ)_/¯

  • WorkingDudeWorkingDude Member
    edited April 2018

    What I don't get is why they removed packages from their repo... how exactly are you supposed to get said x.20 patch? :)

    (Debian 8)

    Update: actually, it seems they did not push the x.20 installer to their site, they just have it in their GitHub repo.

  • HxxxHxxx Member

    I mean open source and they don't accept commits from other people? Damn sounds like a cluster fuck.

    @MikePT said:

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

    Thanked by 1MikePT
  • @WorkingDude said:
    What I don't get is why they removed packages from their repo... how exactly are you supposed to get said x.20 patch? :)

    (Debian 8)

    Update: actually, it seems they did not push the x.20 installer to their site, they just have it in their GitHub repo.

    I guess the updater runs even with the vesta service stopped?

  • finally, patch released.

  • MikePTMikePT Moderator, Patron Provider, Veteran
    edited April 2018

    @Hxxx said:
    I mean open source and they don't accept commits from other people? Damn sounds like a cluster fuck.

    @MikePT said:

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

    Seems to be the case if you look at their Github. I have seen a few guys saying that their pull requests were ignored, completely.

  • MikePTMikePT Moderator, Patron Provider, Veteran

    @squibs said:

    @WorkingDude said:
    What I don't get is why they removed packages from their repo... how exactly are you supposed to get said x.20 patch? :)

    (Debian 8)

    Update: actually, it seems they did not push the x.20 installer to their site, they just have it in their GitHub repo.

    I guess the updater runs even with the vesta service stopped?

    Correct. Run apt-get and the VestaCP update command.

  • ElmoElmo Member
    edited April 2018

    I have some VESTA servers. Since I've applied my config management config to all of them, they have +90% similar configurations (for same OS). In all of them I have the following

    1. Password login in SSH = Disabled
    2. Default port for VESTA + Enabled
    3. Services: nginx, apache2, bind, exim4, dovecot, vsftpd
    4. Firewall = Enabled
    5. All of them had VESTA v0.9.8-19

    Most of them were setup some years ago. Three of them were setup within 2018 (can't remember exact dates). Only 2 out of 3 that were recently setup were compromised.The rest are fine (ofc I shutdown Vesta in all of them just to make sure they stay fine).

    By my results I'm not sure if the theory "recently setup servers = hack" is right. Neither the theory about roundcube (or other service apart from VESTA) being the culprit. Neither about OS. I do believe though the theory about internet subnets being scanned/attacked, which correlates with my results.

    Thanked by 1Falzo
  • HarambeHarambe Member, Host Rep

    https://forum.vestacp.com/viewtopic.php?f=25&p=69296#p69296

    Just want to confirm that we have checked our infrastructure. It is secured and wasn't affeceted in any way. The was some problems deb repos because we did initial push in a hurry. It is now fixed.


    I'm trying to push for some details/confirmation on the attack vector, if they even actually collected solid evidence of how the attackers got in...

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

  • HarambeHarambe Member, Host Rep
    edited April 2018

    Only official response to my question so far.

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

    Can't copy/paste much because stupid Cloudlare errors, but:

    We think that this part could allow for arbitrary code execution. Theoretically you could send something like
    ...
    However we weren't able to bypass auth protection ourselves

    Doesn't instill much confidence in me personally... sigh

  • HBAndreiHBAndrei Member, Top Host, Host Rep

    Harambe said: Doesn't instill much confidence in me personally... sigh

    >

    Not sure how they can claim the vulnerability was patched if they weren't able to reproduce the exploit themselves. Just because you find an odd looking part of your code that may represent an entry point, but you can't manage to exploit it, doesn't mean it's your entry point.

    Thanked by 2Aidan Harambe
  • @HBAndrei said:

    Harambe said: Doesn't instill much confidence in me personally... sigh

    >

    Not sure how they can claim the vulnerability was patched if they weren't able to reproduce the exploit themselves. Just because you find an odd looking part of your code that may represent an entry point, but you can't manage to exploit it, doesn't mean it's your entry point.

    I do not think they were able to get clear data on the exploit in action.

  • FalzoFalzo Member

    @AlyssaD said:

    @HBAndrei said:

    Harambe said: Doesn't instill much confidence in me personally... sigh

    >

    Not sure how they can claim the vulnerability was patched if they weren't able to reproduce the exploit themselves. Just because you find an odd looking part of your code that may represent an entry point, but you can't manage to exploit it, doesn't mean it's your entry point.

    I do not think they were able to get clear data on the exploit in action.

    +1

    that's what they should clearly communicate then.

  • AlyssaDAlyssaD Member
    edited April 2018

    Most recent posts are still suggestion VestaCP is compromised:

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

    Context though is they updated to update 20 on the 9th, but the virus was installed on the 9th. It might be they were vulnerable pre-update, but no one knows.

  • @AlyssaD said:
    Most recent posts are still suggestion VestaCP is compromised:

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

    Context though is they updated to update 20 on the 9th, but the virus was installed on the 9th. It might be they were vulnerable pre-update, but no one knows.

    Possibly they just released patch for another bug and not this security issue

  • ClouviderClouvider Member, Patron Provider

    @Falzo said:

    @AlyssaD said:

    @HBAndrei said:

    Harambe said: Doesn't instill much confidence in me personally... sigh

    >

    Not sure how they can claim the vulnerability was patched if they weren't able to reproduce the exploit themselves. Just because you find an odd looking part of your code that may represent an entry point, but you can't manage to exploit it, doesn't mean it's your entry point.

    I do not think they were able to get clear data on the exploit in action.

    +1

    that's what they should clearly communicate then.

    Yep. Not much more they can do when they were running access log to /dev/null, until Honeypot is attacked, but now since they have made it public they are hunting the attacker... I seriously doubt it.

  • FalzoFalzo Member

    Clouvider said: Yep. Not much more they can do when they were running access log to /dev/null, until Honeypot is attacked, but now since they have made it public they are hunting the attacker... I seriously doubt it.

    agreed, next attack only in a few weeks, after everything calmed down :(

    there are still pointers that leave a bad taste about the API not being the only vulnerable point here, though I really like to believe in simplicity of powerful attacks.

  • HarambeHarambe Member, Host Rep

    @MasonR Can I get another title/post update.


    Title edit: [Patch Released, Unclear If Patch Fixed Exploit]

    Addition to body (at top):

    April 10 Update: Unclear if patch resolved the exploit. VestaCP team has not produced confirmed details on the attack vector and have not been able to reproduce the attack. Harden your VestaCP installs by keeping the vesta service offline and/or locking down admin ports in firewall.


    Definitely editorializing this incident at this point with the above edit, but I don't feel comfortable saying "all good" - nor do any of the other security-conscious members in this thread.

    The fact that hosts like DigitalOcean have not changed their position on network-wide port blocks also reaffirms my position that this isn't 'all good' and 'bullet proof' as one of the VestaCP devs has said.

    Thanked by 2scorcher9 Falzo
  • MasonRMasonR Community Contributor

    @Harambe, you got it boss! Look good?

    Thanked by 1Harambe
  • HarambeHarambe Member, Host Rep

    @MasonR said:
    @Harambe, you got it boss! Look good?

    Looks good, thanks man. Might be time to drop 'possibly' from the title as well, lol.

    Thanked by 1MasonR
  • MasonRMasonR Community Contributor

    @Harambe said:

    @MasonR said:
    @Harambe, you got it boss! Look good?

    Looks good, thanks man. Might be time to drop 'possibly' from the title as well, lol.

    No problem. I was thinking the same thing and forgot to do it when I edited. Just took it out now :)

    Thanked by 1Harambe
  • jarjar Patron Provider, Top Host, Veteran
    edited April 2018

    My own webmail installed instead of the default (over cautious bordering on paranoid, I can't even construct the scenario where it benefits me), panels down. Confirmed no sudo access for webmail user. Smooth sailing. Ain't in a hurry for the next part with that setup.

  • It's reasons like this why I love my simplistic nginx, php-fpm, and mariadb setup lol.

  • I like VestaCP. I think it's come a long way since 2014 when I first started using it. I particularly like it because it is so light weight and fast because of nginx and one can easily run it on a 512 MB VPS. Webmin takes more resources to run as it obviously has more to offer for server admin from a systems point of view. I only use a minimal version of VestaCP - like I deliberately exclude e-mail and FTP as I think those two are the vulnerable targets in the best of Control Panels, including cPanel. That may be the reason that my VestaCP was not infected, although who knows maybe I was just lucky.

    What is interesting to me, if one checks the VestaCP Forum discussion about the issue, those affected included savvy geeks who knew their stuff and had done all the usual stuff to harden their VPSs. Some were convinced that the infection could only have come through the installation script. Although that hasn't been proven. So I'd probably wait a while before I use the installation script again. I haven't turned my VestaCP off. I'm on automatic updates so the security patch was automatically loaded on 8th of April.

    I'm still following the discussions at VestaCP and once I have a good feeling the installation script is OK, I'll start using it again. What gives me confidence is that the Admin at VestaCP have been around the script for many years - guys like Imperio and Skurudo have been there for ages - in my experience they don't move very fast, but they eventually get whatever is needed right. One should be patient and give them a chance to sort it out. Great opportunity to learn about security as well. Like that discussion thread at VestaCP is a How To tutorial in how to check for infections and harden one's VPS.

  • Mark_O_PoloMark_O_Polo Member
    edited April 2018

    @deanhills said:

    I haven't turned my VestaCP off. I'm on automatic updates so the security patch was automatically loaded on 8th of April.

    Based on the scenario at hand, it is safer turning off the control panel, all of the other components will just keep running on their own. With a yet to be replicated understanding of the failure point, the risk doesn't out-way the benefits.

    It's a 5 second turn off thing. (can always restart it at any point down the road).

    Thanked by 1deanhills
  • jarjar Patron Provider, Top Host, Veteran
    edited April 2018

    @Mark_O_Polo said:

    @deanhills said:

    I haven't turned my VestaCP off. I'm on automatic updates so the security patch was automatically loaded on 8th of April.

    Based on the scenario at hand, it is safer turning off the control panel, all of the other components will just keep running on their own. With a yet to be replicated understanding of the failure point, the risk doesn't out-way the benefits.

    It's a 5 second turn off thing. (can always restart it at any point down the road).

    This can't be overstated. The attack vector has not been identified, this patch was a best effort to address potential security issues and hope that the attack vector simply happened to be found in them. Serghey is working his ass off on this and it is to be admired, he's a great guy, but unless a compromise doesn't matter to you (and hey, we all have a few servers like that tbh) or you're running a honeypot, keeping the panel off is the most logical step right now.

    The repos, roundcube, exim/dovecot, those are all less likely based on circumstantial evidence (I'm not sharing my evidence as it's larger than just me, just telling you I have it, trusting me is a choice you can make or not make).

    One other thing to note: The reports of compromises continuing after disabling the panel I would take with a grain of salt right now. There are a lot of people out there getting rooted every day, and a lot of them may even be migrating an infection to new servers from old ones. There will also be a hefty amount of people being compromised at the user level due to vulnerable PHP scripts on a daily basis. We just don't know, but with the panel disabled VestaCP's stack isn't quite unique or custom enough to have me highly convinced that it's something else other than the panel.

  • @jarland @Mark_O_Polo
    Thank you for the feedback and the note about the infection migrating. I'm worried that if I should use SSH when I access my system to shut the panel down, I may trigger an infection that is already there but dormant, waiting for me to access the system at the root level. Is that logically possible? If it is as serious as you say it is, wouldn't it be better to reload the OS and start from scratch without VestaCP?

  • donlidonli Member

    @deanhills said:

    If it is as serious as you say it is, wouldn't it be better to reload the OS and start from scratch without VestaCP?

    There's always the possibility the expolit has been used to install a backdoor into your system (like modifying login code) so it's always best to do a fresh install if there's a possibility your system might have been compromised.

    Thanked by 2deanhills sarah
  • FalzoFalzo Member

    jarland said: The repos, roundcube, exim/dovecot, those are all less likely based on circumstantial evidence (I'm not sharing my evidence as it's larger than just me, just telling you I have it, trusting me is a choice you can make or not make).

    thanks for stating this, gives me much more confidence in my own believings than what anyone else would say. I very much trust you in this, as I am sure you looked yourself into it as good as possible and in addition might have access to DOs flow of information around it.

    One other thing to note: The reports of compromises continuing after disabling the panel I would take with a grain of salt right now. There are a lot of people out there getting rooted every day, and a lot of them may even be migrating an infection to new servers from old ones. There will also be a hefty amount of people being compromised at the user level due to vulnerable PHP scripts on a daily basis.

    totally agree with that too, probably a lot of mixup happening, people will quickly jump on blaming the next best thing even if there are reasons for their problems.

    We just don't know, but with the panel disabled VestaCP's stack isn't quite unique or custom enough to have me highly convinced that it's something else other than the panel.

    this! but I still can't get it out of my head, that some malicious files had gid 1002 or maybe even other groups instead of belonging to 1001/admin. this simply should not happen, while accessing through vesta-nginx.
    so at some point of the way in, there still could be an (additional) vector missing which involves apache2 and a customers domain to have that group set on the files (not neccessarily on purpose)...

    however all we got left is hoping that patching the best guess will help, even if that also has been done in a somewhat weird way, which doesn't look so promising security-wise at all.

    For now I am proxying the panel through the general apache2 and restrict 8083 to localhost. In addition restricting API-access with additional http auth and may be blocking IPs instantly that try to access port 8083 directly (dangerous though, because clients may use old links and block themselves out for a while).
    so far this is all doable outside the scope of files that could potentially be overwritten with any future vesta update.

    Thanked by 1jar
  • akbakb Member

    sin said: I would personally stick with Webmin/Virtualmin (mainly because they've been around for a long time and regularly update/maintain the project).

    Is it just a coincidence that two of the most stable panels, one free (webmin/virtualmin) and other commercial (cpanel) are both perl based? :-)

    Thanked by 1uptime
Sign In or Register to comment.