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

1356711

Comments

  • @MikePT said:

    @Prime404 said:

    @MikePT said:
    This time it happened to be VestaCP. And gosh if that really correlates to API running as root then... Definitely start using something else.

    As far as I know that's the cause here, as there is no other logical explanation to how a process would get elevated rights otherwise. As far as I know, basically the entire API and all commands in the background run on the user "admin", that have sudo rights and thus root permissions on the system.

    Yep. Hence why I mentioned that I don't think it was even secure to start with. That makes no sense. Also seems that it wont sanitize properly from some posts I read in their forums.

    The main developer said they found an issue and will be issuing an update today. I would recommend and give it some time. An issue isnt exactly THE ISSUE.

    API should be disabled until its rewritten as well IMHO.

    I think this particular issue is only the tip of the iceberg and there is more to come.That is till they fix the real problem, which will most likely take a few years looking at their development phase .. if ever.

    I've seen the downward spiral of the project over the past 2 years and it's not looking all that bright, considering that the development is almost dead and there is only 1 person that can push to the main update server. Due to this problem I'll most likely migrate over my existing server and users to Plesk - even if it's just a lab server and the license costs a bit.

  • DylanDylan Member

    Yikes - DigitalOcean's been having network issues in all their NYC regions since earlier this morning and now they're saying it's because of this
    https://status.digitalocean.com/incidents/jzszyktwsrss

  • @Dylan said:
    Yikes - DigitalOcean's been having network issues in all their NYC regions since earlier this morning and now they're saying it's because of this
    https://status.digitalocean.com/incidents/jzszyktwsrss

    It doesn't surprise me.. I wonder how many hosts that are infected with this.

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

    @Dylan said:
    Yikes - DigitalOcean's been having network issues in all their NYC regions since earlier this morning and now they're saying it's because of this
    https://status.digitalocean.com/incidents/jzszyktwsrss

    Everything seems to add up to it being the most likely cause.

    MikePT said: API is the biggest concern I have seen in VestaCP

    It's easy to throw a jab at anything running as root or as a user with sudo, because it's sometimes an easy thing to not do. But running as root or sudo user is not in itself necessarily bad. Many things do, many things have to by design/function. If everything running as root or sudo user is bad, then everything running as root or sudo user is bad. The fact is it's not always that simple. It's just an easy thing to take a jab at and receive common agreement for having done so. Maybe it's the right thing to take a jab at, maybe it's not. Just remember: OpenSSH has had vulnerabilities and runs as root, and no one really felt the need to take that jab then. Why? Because they can't imagine it not. But it's public facing and running as root, no? Things aren't always so black and white.

  • MikePTMikePT Moderator, Patron Provider, Veteran

    @Prime404 said:

    @MikePT said:

    @Prime404 said:

    @MikePT said:
    This time it happened to be VestaCP. And gosh if that really correlates to API running as root then... Definitely start using something else.

    As far as I know that's the cause here, as there is no other logical explanation to how a process would get elevated rights otherwise. As far as I know, basically the entire API and all commands in the background run on the user "admin", that have sudo rights and thus root permissions on the system.

    Yep. Hence why I mentioned that I don't think it was even secure to start with. That makes no sense. Also seems that it wont sanitize properly from some posts I read in their forums.

    The main developer said they found an issue and will be issuing an update today. I would recommend and give it some time. An issue isnt exactly THE ISSUE.

    API should be disabled until its rewritten as well IMHO.

    I think this particular issue is only the tip of the iceberg and there is more to come.That is till they fix the real problem, which will most likely take a few years looking at their development phase .. if ever.

    I've seen the downward spiral of the project over the past 2 years and it's not looking all that bright, considering that the development is almost dead and there is only 1 person that can push to the main update server. Due to this problem I'll most likely migrate over my existing server and users to Plesk - even if it's just a lab server and the license costs a bit.

    Might be too much for only two or three guys. I do understand @jarland when he says that a vulnerability shouldnt stop you from using it. I just dont think they have the resources to fully inspect the code and secure it, nor if they have knowledge to. I don't know who they are and what they do, or what their skills are. I do know that many people rely on VestaCP and I stopped using it quite a long time ago because I too felt it stalled a bit. I was having multiple issues with it as well. As much as I love FOSS projects, I tend to rely on projects that are willing to accept pulls from other contributors and preferably projectsbeith many contributors that can audit it properly. Thinking of the API issue and not escaping the password properly just got me to conclude that it was only a matter of time until this happened. Granted that I am no developer and am probably biased on the API surroundings we can read there but I am well aware that is not how APIs should run. Thats a very vulnerable point of entry to the servers running VestaCP.

  • MikePTMikePT Moderator, Patron Provider, Veteran

    @jarland said:

    @Dylan said:
    Yikes - DigitalOcean's been having network issues in all their NYC regions since earlier this morning and now they're saying it's because of this
    https://status.digitalocean.com/incidents/jzszyktwsrss

    Everything seems to add up to it being the most likely cause.

    MikePT said: API is the biggest concern I have seen in VestaCP

    It's easy to throw a jab at anything running as root or as a user with sudo, because it's sometimes an easy thing to not do. But running as root or sudo user is not in itself necessarily bad. Many things do, many things have to by design/function. If everything running as root or sudo user is bad, then everything running as root or sudo user is bad. The fact is it's not always that simple. It's just an easy thing to take a jab at and receive common agreement for having done so. Maybe it's the right thing to take a jab at, maybe it's not. Just remember: OpenSSH has had vulnerabilities and runs as root, and no one really felt the need to take that jab then. Why? Because they can't imagine it not. But it's public facing and running as root, no? Things aren't always so black and white.

    It's too early to take any conclusions. To be honest and as mentioned above, I never felt VestaCP to be secure enough to host any production websites. Its no issue running the API with sudo rights as long as it is secured. Which doesn't seem to be the case. If they conclude that it was the issue here you can only assume that a vital point of your server could be used to hack it entirelly for no proper sanitization. That is what I am referring to. API has root rights? Secure is properly. Being an API acting as so would allow you to compromise a big amount of servers pretty easy.

  • TomTom Member

    Blanket blocking port 8083 is a bit eh, though

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

    @Tom said:

    Blanket blocking port 8083 is a bit eh, though

    Actually I think its the right way to do it for now.

  • angstromangstrom Moderator
    edited April 2018

    @MikePT said: It's too early to take any conclusions.

    But, dear @MikePT, above you seem to be one of the most eager to draw conclusions.

    Thanked by 3Tom mikho iKeyZ
  • angstromangstrom Moderator

    @jarland: You use Vesta on the classic plans at mxroute.com, don't you?

  • jarjar Patron Provider, Top Host, Veteran

    @angstrom said:
    @jarland: You use Vesta on the classic plans at mxroute.com, don't you?

    I do. I've openly stated in the past that I'm not as confident in it's long term security as cPanel, thus one major reason for the switch. But demand was high, so I let those that want it continue to have it. I'm pretty satisfied with it thus far, tbh. Though last night I definitely shut off the panels thanks to our glorious OP here :)

  • MikePTMikePT Moderator, Patron Provider, Veteran

    @angstrom said:

    @MikePT said: It's too early to take any conclusions.

    But, dear @MikePT, above you seem to be one of the most eager to draw conclusions.

    My conclusion about the API stands. We just dont know if that was the attack vector.

  • doughmanesdoughmanes Member
    edited April 2018

    Blocking the port on their network temporarily works to keep the problem down. Other providers did it during amplification attacks on NTP plus I think Kloxo was the shit panel that had DNS open to an amplification attack in the past also

    Thanked by 2MikePT Aidan
  • I also can't get over their response on their forum..

  • CloudconeCloudcone Member, Patron Provider

    Infected, we've already sent an email to clients. What a weekend, next weekend comes bandwidth bills

  • apt update
    apt install clamav clamav-daemon -y
    
    service clamav-freshclam stop
    
    freshclam
    
    service clamav-freshclam start
    
    clamscan -r --infected /
    

    If you are running vestacp you should probably do a full system scan after turning off your vesta service just to verify the exploit isn't installed.

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

    @Prime404 said:
    I also can't get over their response on their forum..

    I don't see the issue there. Most of the users posting on their forum are not capable of performing their own investigation, and the fastest path to identification is to investigate a system that has been compromised.

    Surely you don't want their reaction to be "We don't know the attack vector and will therefore be auditing every line of code and reworking the entire application prior to addressing the specific cause."

  • MasonRMasonR Community Contributor

    @jarland said:

    @Prime404 said:
    I also can't get over their response on their forum..

    I don't see the issue there. Most of the users posting on their forum are not capable of performing their own investigation, and the fastest path to identification is to investigate a system that has been compromised.

    Surely you don't want their reaction to be "We don't know the attack vector and will therefore be auditing every line of code and reworking the entire application prior to addressing the specific cause."

    Also tacking on to this, if you're using their software on your system that runs at root privilege, then there's already some implied trust there. If you don't trust the developers poking around in your compromised system, then you shouldn't have installed their software in the first place.

    Thanked by 1Shazan
  • jarjar Patron Provider, Top Host, Veteran

    @MasonR said:

    @jarland said:

    @Prime404 said:
    I also can't get over their response on their forum..

    I don't see the issue there. Most of the users posting on their forum are not capable of performing their own investigation, and the fastest path to identification is to investigate a system that has been compromised.

    Surely you don't want their reaction to be "We don't know the attack vector and will therefore be auditing every line of code and reworking the entire application prior to addressing the specific cause."

    Also tacking on to this, if you're using their software on your system that runs at root privilege, then there's already some implied trust there. If you don't trust the developers poking around in your compromised system, then you shouldn't have installed their software in the first place.

    On top of that add-on, you've already been rooted by a compromise so you're not worried about security ;)

    Thanked by 2MasonR netomx
  • sinsin Member

    I don't use any panels but if I did I would personally stick with Webmin/Virtualmin (mainly because they've been around for a long time and regularly update/maintain the project). It sucks to see so many people getting hacked because of this though :(

    Thanked by 1vimalware
  • HBAndreiHBAndrei Member, Top Host, Host Rep

    @Prime404 said:
    I also can't get over their response on their forum..

    Well, in all honesty, if your server got hacked you can already say goodbye to the privacy, security and integrity of the data stored on said server...

  • Free hosting I offer to friends is using vestacp. Maybe this is a good reason to buy an life time directadmin.

  • v3ngv3ng Member, Patron Provider

    I have used VestaCP some years ago but switched to Froxlor.
    The team behind VestaCP doesn't care about bugs, I made several bug reports and even push requests but they got mostly ignored.

  • HxxxHxxx Member

    Time for Vesta to start paying security researchers to inspect that code.

  • Now blame is put on Roundcube again it seems.. is this a never ending story?
    https://forum.vestacp.com/viewtopic.php?f=10&t=16556&start=210#p68798

  • LeeLee Veteran

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

    Time for users to start paying for the panel then.

  • @v3ng said:
    I have used VestaCP some years ago butd switched to Froxlor.
    The team behind VestaCP doesn't care about bugs, I made several bug reports and even push requests but they got mostly ignored.

    I liked Froxlor when I tried it some years ago. At the time you couldn't have subaccounts with permissions to add additional domains. Is this feature release by now? This panel looks good as well, bit bloated compared to VCP but clean.

  • ClouviderClouvider Member, Patron Provider

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

    With what money ?

    Thanked by 4Lee Wolveix kkrajk lazyt
  • YmpkerYmpker Member
    edited April 2018

    Unfortunate events indeed :/ Good luck to everyone who is affected by this! I for one, will be moving everything that was on Vesta to ispConfig now. Of course there is bo guarantee for it always being flawless either.

    Thanked by 1kkrajk
Sign In or Register to comment.