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
That is absolutely not what you wrote.
You stated categorically that Virtualizor was not the exploit vector. And standard English usage "as per" would mean that Ouiheberg had provided details that confirmed your claim, when in fact, they still maintained the complete opposite position.
The phrase you should have used is "contrary to".
Shoutout to OuiHeberg! The only provider status page that's actually working. https://status.ouiheberg.com/
Last update (Gemini translated):
at this point I feel like any host who uses virtualizor is just an instant no buy, way too many issues with that platform to ever feel remotely safe.
We are still awaiting the details from them
We routinely audit Virtualizor for security flaws, so this is news to us.
While we recognize that no product will ever be 100% secure, and we make that very clear to every company that works with us, I can tell you that every time a hosting company approaches Virtualizor about being hacked, the issue has always been related to password reuse or compromised staff machines, etc. (The live-chat compromise incident aside, of course...)
Don’t take their word for it. We are the ones who handle incident response for them. We log into the customer's infrastructure, review the logs, gather evidence, and provide clear, indisputable proof to the affected parties that the incident was not caused by the Virtualizor platform itself.
Additionally, we maintain honeypots in North America and Europe, wide open for all intents and purposes, to catch any zero-day exploits in the wild. We also work with large hosting partners in our threat intelligence program, who operate significant Virtualizor clusters and keep us updated on increases in attack attempts or unusual behaviour.
The individual who contacted Virtualizor claimed to have a working exploit related to a module for a popular billing platform, but offered no factual information or proof-of-concept. They referenced specific lines of code that make no sense in terms of being exploitable in real-world scenarios, nor do they represent any meaningful attack vector from what we can see...
I strongly suspect they ran the code through ChatGPT or some other SAST (Static Application Security Testing) tool that produces a large number of false positives, or flags code that, while insecure, cannot actually be exploited to escalate privileges or perform malicious actions in the real world.
With all that said, we are not seeing any credible information indicating that an exploit exists in the wild, and no one has provided actual proof to suggest otherwise.
As mentioned above, no software will ever be 100% secure, and an exploit may very well be buried deep within. But at the moment, we have nothing to go on, and I wouldn't stress if you're using Virtualizor.
We actually find more security flaws in other hosting software these days than in Virtualizor itself, we just no longer publish public advisories, and companies often patch quietly so no one knows what's going on.
If anyone has credible information regarding an exploit, please reach out to Virtualizor and it will be forwarded to us. We're committed to keeping the hosting community safe and take these things extremely serious.
https://lowendtalk.com/discussion/205968/colocrossing-database-breach/p1
https://colocrossingbreach.com/
Wasn't that a result of Virtualizor's live chat system being "compromised", where a lot of credentials were exposed by providers who shared root passwords and such?
Per: https://lowendtalk.com/discussion/202897/virtualizor-live-chat-compromised
I mean, it was more than likely an ex-Virtualizor-employee who still had access to the live chat system after being let go or who just logged credentials as they were shared.
Not defending Colocrossing or Virtualizor, but if someone gets your login credentials from a separate 3rd party chat service and uses it to login to your server, it doesn't mean that the software on your server is inherently insecure.
Quoting myself and others to add additional details.
I now always pay our licenses manually, after having a big issue where for several months we were overpaying by hundreds due to automated PayPal agreements that I foolishly didn't cancel, but that we could never get refunded by Virtualizor, after we had migrated VMs to larger nodes and consolidated things, reducing the number of nodes we had in operation and the number of licenses we needed. This was probably back in 2021 or 2022.
So, out of habit, I am often in the account once a week or so to pay licenses manually and have had to do this for at least a couple of years now.
In February of this year I notice new licenses in the account, ones I did not order, and ones that did not belong to IPs we even own or on our network.
I don't usually use live chat, but for this instance, I did. Live chat basically just tried to tell me the only way they could be in my account is if I added them myself. I didn't add them.
Posted in their Discord and saw someone else report the same:
So, it's clear they've had some issues for some time now, whether these are software related or just issues with internal control and bad staff.
In any case, we've since moved (mostly) away from Virtualizor with only old legacy VMs still using it. Every time one of these threads are created we do the whole, "just in case" procedure of rotating API keys and resetting all credentials and double checking things like the authorized_keys file to make sure nothing unexpected has occurred.
I don't remember ever getting clear answers and there were lots of reports after/during about vms getting wiped.. Frankly because of the way CC handled it I chose to assume the fault was on CC's end alone.
*not that they should give a shit about my opinion, obviously.
There must be no Product Owner or Q/A.
Worst experience ever from the point of the end user.
Not familiar with that specific incident, but I would guess it's related to the live chat hack, unrelated to any security flaws in the Virtualizor software itself. We did a bunch of incident responses afterwards that were traced back to the live chat hack.
From our end, we did tell Virtualizor that they should develop a function to securely enable/disable access to nodes that can only be enabled by the end-user to allow temporary access for support issues. I do believe that is in the works, similar to what cPanel and Plesk have available.
Without knowing the specifics, I would assume ColoCrossing gave their credentials to live chat and never changed them afterwards, then the hack happened, and the credential reuse allowed access later on. A simple policy of changing passwords and keys every X date would have prevented them from being compromised months later.
You would be terrified to find out how many "big name" hosting providers reuse passwords, freely hand them out to random support agents and don't change them afterwards...
I wish you the best, I hope your PTSD will eventually heal off.
That and -- as you may be familiar with, judging by your handle/sig -- how many enterprise firewall users in the F500 (
) are cavalier about things like leaving random support techs more or less unattended at the root prompt of their gateway over a remote session, or giving them credentials to log themselves back in to the box during long operations, or scrolling through sensitive network info on remote session, or . . .
The public-sector customers were usually better about it at least (the military wouldn't even let us remote in, they just got documentation and left to do it themselves). And not everyone was like this. But a concerning chunk of them seemed to think we had, like, security clearances, or super intensive vetting, or strict monitoring, or something, I guess.
Sometimes it wasn't just the customers. I'll just say I was once browsing through the KB and I ended up in possession of a PGP secret key+pass that, to be fair, was apparently for the use of my department/team, but in my opinion, should not have been accessible in such a trivial and uncontrolled way due to its potential for exploiting customers' trust.
Update : We have not yet received any further details / PoC / substantive proof of Virtualizor being vulnerable.
Then you shouldn't have claimed that Virtualizor was the problem!
I can't help but conclude that the following statement was a lie: “Our internal teams have successfully reproduced the attack by executing a payload via their WHMCS add-on in communication with their API.”
In the meantime, there would have been more than enough time to provide proof if the vulnerability had actually already been known.
We're still waiting for the full public statement from @ouiheberg I guess. It's said that the Virtualizor servers were brought back after migrations to new servers.
Which would lead some to believe the issue was a result of a physical fault and not a software exploit.
I still hold the benefit of doubt and willing to be proven wrong, so perhaps @ouiheberg should also address how a physical hardware change solved a problem that reportedly stemmed from a software bug.
To be clear, this (and the rest of my post) is about something that happened at my old job, not about anything/anyone in this thread
What I find interesting is that how members that write as "members" can so easily pass as accounts affiliated with companies as important as Virtualizor. There's no title to distinguish them and explicitly identify them here for security purposes - why? Doesn't make sense.
Anyone can create an account tomorrow, do a user as "VirtualizorIN" and pass as if it was Virtualizor. Seems insecure, to say the least. Odd considering we are talking about security here.
Regarding this issue. OuiHeberg may be at this moment stopped and prevented of actually being able to show the issue if Virtualizor, in some way (e.g. licensing or other internal API validations) are actually stopping them of providing proof of evidence adequately. I'm not saying that is what is happenning here, but it could occur.
For what it's worth, it seems to me there is a very high pressure from Virtualizor (if this account is Virtualizor's company/team) to pass things as if they are entirely right, shown by the multiple messages on this thread between November 15th and today (so, 4 days). That may be open to multiple interpretations.
However, since the provider usually is at the other end of the spectrum and has solely the control over the software infra that Virtualizor allows them through their design, I'd very much assume some wouldn't want to get their neck out that way without being explicitly sure it really is from Virtualizor. Especially because they are a newer presence here at LET.
And since the Virtualizor's team has all the bread and butter, they are the main interested ones in either solving this issue, hiding this issue (avoiding brand tarnishing or by closing tools/ports/etc) or having it dealt privately (and this third one has gone out of the window for the most part, at this point).
We'll just have to wait and see, but it's pivotal that @ouiheberg stands by their own word, if this really is an issue, and lets us know in a credible way.
As a security auditing company that claims to work closely with Virtualizor I find it very interesting you have no knowledge of a large breach event that was blamed solely on Virtualizor by Colocrossing earlier in the year.
https://haveibeenpwned.com/Breach/ColoCrossing
Mods can see registration emails. In this case, I can confirm that @virtualizor has a virtualizor.com email address.
I probably read about it at that time on here or WHT, but the specifics of the hack are drawing a blank in my head at the moment...
Looking at our inbox, there was nothing communicated around that time for any sort of large-scale incident response. I would have to talk to the Virtualizor team to see if ColoCrossing reached out to them and offered any details back then.
As I said above, this happens fairly frequently, where a provider claims they have been hacked due to Virtualizor and reaches out to their team. In most cases, the affected company is more than willing to let us log into their infrastructure and perform an audit to get to the bottom of how the attacker(s) gained access.
You know, it's easy for people to blame a company and say they were hacked by some random zero-day exploit. Companies want to blame someone other than themselves, especially when customer data has been accessed. It's also possible that those companies truly do believe they were hacked by a zero-day exploit, even when they weren't.
But getting back to the specifics of this alleged hack... if the company in question is aware of a working exploit, why have they not responsibly disclosed the details to the Virtualizor team? I just don't understand.
Why are you passing yourself off as someone who works for Alfa Romeo? It makes no sense.
Update : Multiple reminders have been sent to @ouiheberg . We have not yet received any further details / PoC / substantive proof of Virtualizor being vulnerable.
And effectively, radio silence in 12 days, which should have been plenty to do a video or to bring more details about the issue.
They've possibly found something of their own setup that caused the issue at this point, I'd believe.
No further communication from @ouiheberg . For now we will conclude that this security issue was not caused by Virtualizor !
I'm happy for you, but I still don't trust your product and will actively avoid providers who use it!
Interesting take. I'll admit I'm a bit biased since I use a lot of Softaculous products, but I've never doubted Virtualizor's confidence or innocence here. Softaculous, in my view, are remarkably transparent in this regard. They will however tell you - somewhat rightly - to eat dirt if you've done something wrong, complained, and deserve it.
I'll put my hands up and say I doubted it.
Clearly as they're both accusing each other of being the problem, only one can be right (or both part of the problem, who knows). But just seeing the speed by which he declared that his software couldn't possibly be responsible in the first instance, with absolutely no evidence to back up his confidence, made me not trust him at all. Maybe he's right and his software wasn't to blame in this case, but the attitude of "deny first, investigate later" just doesn't sit right with me.
I've no knowledge of virtualizor. How can I infer who is using it?
I don't think OuiHeberg giving up trying to convey an issue to Virtualizor necessarily means that there isn't an issue with the product. It's more likely that OuiHeberg just couldn't be bothered to continue the communication when they have absolutely nothing to gain from their effort, especially if the vendor is being obstructive.
OuiHeberg's disclosure of their incident was professional from start to finish, so I don't see any reason why they'd publicly claim to have reproduced the issue if they hadn't.
On the other hand, the responses from Virtualizor in this thread indicate they're more interested in appearances than resolving issues, (something OuiHeberg also claimed), so their instant denials and their latest victory lap suggests to me that they're not a serious vendor and it's best to swerve their products.