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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
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.
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.
Everything seems to add up to it being the most likely cause.
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.
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.
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.
DO is doing their bit: https://status.digitalocean.com/incidents/jzszyktwsrss
Blanket blocking port 8083 is a bit eh, though
Actually I think its the right way to do it for now.
But, dear @MikePT, above you seem to be one of the most eager to draw conclusions.
@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
My conclusion about the API stands. We just dont know if that was the attack vector.
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
I also can't get over their response on their forum..
Infected, we've already sent an email to clients. What a weekend, next weekend comes bandwidth bills
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.
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
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
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.
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.
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
Time for users to start paying for the panel then.
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.
With what money ?
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.