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
Softaculous also got new SSL certs at the exact same time as this happened. All of these products received new SAN certs around the same time that don't match the previous issuance patterns:
https://www.certkit.io/tools/ct-logs/?query=softaculous.com
https://www.certkit.io/tools/ct-logs/?query=webuzo.com
https://www.certkit.io/tools/ct-logs/?query=virtualizor.com
So my worry is that other services were impacted.
This is why it takes time to thoroughly test each step, ensuring perfection without any hanging tasks like Virtualizor does.
Looking Glass? Speed test files?
(emphasis mine)
Yeah, sakkurity at work:
host -t caa virtualizor.comResult:
virtualizor.com has no CAA recordIf that was just a BGP hijack and not a total data breach, then I wonder: how could someone log in into their softaculous.com/clients zone; provided your panel/database is not available to a 3rd party that could spin up a fake client zone?
To be able to replicate your client zone, a BGP hijack is not enough.
@Andreix As I understand, the login form was there, but the panel itself wasn't.
We are generally focusing on Virtualizor, but the main issue for me is that is possible to hijack Hetzner's IP addressing without much trouble...
You probably have not had too much to work with T1 providers.
They simply don't give a f*ck most of them. Since 2019 till today, I still have issues for my customers with T1s or providers with immediate T1 access, that simply accept stuff from downstream, with no IRR or ROA check.
And once a T1 accepts such a prefix (and believe me, it's not so rare), it doesnt matter if it's Hetzner, OVH, ServerSpan or any other. It will propagate to all it's downstreams (or a majority of them) and create a beautiful hijack.
After this happens, you basically try to find every connection you have, that may have a connection who may have a connection that may know someone from that T1 NOC. Because mails and tickets are basically "we're T1, f*ck off!". And most of the time, even if the request was clearly a malicious one, T1s accept a simple: sorry, we made a mistake from their clients.
So, yeah, internet as it is today, is one small T1 ignorance away.
If the user tried to login, they put their password on the malicious site. No DB was leaked.
So was basically a pishing to store user password...
Agreed. @DP what do you think?
With AI auto-feed fetched from known blackhat forums or CVE DBs?
Since working with lots of hypervisor.io users, I can tell that it has "Native virtualizor Importer", its supported from hypervisor beta 2.2.6 release, you may consider peeking into that and give your views.
It sounds stupid, but It seems the solution to hijack is to hijack the hijack?
Incident Response over at https://www.virtualizor.com/blog/security-incident-bgp-hijacking/
I had the same reply along with their bash script which I compared to the one I shared.
First thing I noticed was their script fixed 1 file (globals.php) while the one that I shared targets the 3 changed php files.
Not really. It comes to ASN authority and BGP way-of-work afterall.
If AS174 (Cogent) starts leaking a hijack, it will be preferred in 99.9% of cases over a hijack I do from AS3280 (for example).
Why? Because most of the internet is Cogent's client and will automatically accept all routes received from Cogent => will accept a hijacked prefix with no question asked.
AS3280 (or even Hetzner's AS... which I do not now know) would have to pass multiple hops until AS174 and even then, it will get rejected because of BGP.bestpath features, which says "hey AS174 AS12345 (bad customer) is shorter path than AS174 AS6939 AS3280, we'll prefer that."
Keep in mind that my example can be applied to FULLY AUTHENTICATED ROUTE OBJECTS!
I could even hijack a prefix by appending a fake AS Path. Let's say 10.0.0.0/24 is authorized to be used by AS123. I could send to Cogent the prefix 10.0.0.0/24 via BGP and instruct my router to add a new (fictive, non-existent) hop to the path. So, instead of path being AS174 AS3280 (unauthorized), it will become AS174 AS3280 AS123 (injected via route-map). Legit as f*ck. Will pass most of simple filters.
It will also tend to prefer a more specific hijacked prefix, than a broader legit prefix (which was the exact case virtualizor experienced now). Aka a hijacked 10.0.0.0/24 will win over a legit 10.0.0.0/22 (in the examples above).
Now, imagine a prefix is not fully authenticated in DFZ.
And I kid you not, most providers do not do proper IRR filters; what to say about ROA which is a little bit more advanced?! Most providers are simply used per-client generated templates which filter bogons and MAYBE checks if AS is in AS_SET.
An outdated or even hijacked AS_SET is another nice story...