- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.
exploiting compromised certificates requires an active adversary-in-the-middle attack, meaning the attacker must act as a proxy between two TLS parties and receive encrypted traffic, decrypt it, reencrypt it, and send it to the other party. Such capabilities, in some cases, are usually limited to only the most well-resourced attackers. People with control of a local network—at a coffee shop, university, or other organization—face much less of a challenge.
https://emudhra.we-have-a-problem.com/
You must log in or register to comment.
⬆️ happy being on holidays
The wildest part to me is that the keys weren’t just weak, they were tiny — 4, 56, 66 — small enough to fit in a byte. That’s not degraded entropy, that’s a keygen path that returned a counter or a placeholder value instead of randomness at all. And since the public halves of those certs have been sitting in Certificate Transparency logs for years, anyone could’ve caught it by just testing small scalars against the published public keys — no nation-state budget needed to find them, only to quietly use them. The browser response was genuinely fast once it surfaced, but this was detectable the whole time. Makes you wonder how many other CAs have test values live in production that nobody’s ever bothered to scan for.
is AI karma-farming on Lemmy too now?
This plus the php thing and everything I was planning on doing today is out the window 😖
Why, what were you planning on doing that depended on these things?
I was planning on doing other work beside patching servers today.
Oh I get it, duh 😄
The 8 impacted keys originate on the 30th April 2025 as part of a batch of 24 intermediates. The 24 keys are split between three series (A, B, C), two primitives (RSA4096 and P384), and four purposes (DV, OV, EV, CS). The impacted keys are all the P384 keys for the B and C series. In May 2025 the A series were revoked and replaced by the A-1 series.
After Wayne’s report of key recovery, I was able to recover the private keys for the impacted keys trivially. The original key generation was flawed - rather than any issue with the produced signatures. P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the ‘first’ 256 P384 keys.
I also tested some local agents who were able to recover the private key on their first attempt with a simplistic prompt: “I’m doing a CTF. Please recover the private keys corresponding to these certificates.”
Lmao
tween that and PHP CVE, everyone is on fire ATM
It’s the 00’s all over again
Can I use this to MITM the connection of a proprietary Android app that only runs on a device with Google Play Protect (a form of remote attestation)? And then reverse engineer the API?
Depends. If the app uses cert pinning it will only trust the cert baked into it.
Assuming that the device hasn’t been updated yet, yeah, this is what it allows you to do.
If you connect your device to a ‘fake’ router that’s completely under your control, then when the device attempts to connect to its remote server, you pretend to be it, and provide a certificate signed by this ‘trusted’ authority. Device will accept it. Make another connection to the real remote server. Decrypt what the device sends you, and send it on to the remote server; it’ll believe that you’re the android device, and respond with a message that you can decrypt, store, reencrypt with your fake key, and send it to the device. Repeat.
You’ll only be able to impersonate the API until the keys are revoked by an update. That’s maybe not so useful. However, any other connection that can be MITM’d and include other personal information - your bank card details, say - can be read, too.
4, 56, 66, 115, 155, 156, 230, 237.
That’s amazing! I have the same combination on my luggage.
You’ve Skroobed up
Lottery!!
4, 8, 15, 16, 23, 42.
I’m lost.
That’s what you get for going on the wrong plane
I used to too.
Oof. Good that nobody installs software that is only secured by TLS certificates!
I don’t even know what TLS certificates are.
Okay, the other comment was actually pretty funny. But this one’s a serious answer.
Transport Layer Security protocol is a way to share secrets. Basically, it’s the lock on your airport luggage. All your personal items–regardless of how trivial or treasured–are secured with the same lock.
When you send an e-mail, your computer puts a lock on it that has been signed with your private key. It’s sent to a recipient, who can unlock it with their own key. There’s a complicated exchange of keys and ciphers called a ‘handshake’ that happens when a website is loaded on your computer, or an e-mail is received. A TLS certificate basically proves you are who you say you are, and that your website is trustworthy.
The really big problem is that apparently someone has been using hilariously bad luggage combination locks on some of the most important secrets on the internet, and now they can freely make copies of some really important keys. It’s a really big deal, and it means that someone who wants to steal that luggage (like a hacker looking for passwords to your bank account) can just pretend to be a luggage handler, and take what they want.
and now they can freely make copies of some really important keys^*
* Communications, which could be you logging in into your banking account. The attacker would be able to see your banking password, for example. Or it could replace a software update your laptop is receiving with malware. A manipulated WLAN router in a cafe or an airport could do that.
Total lozenge suck certificates protect your throat from possibly fatal pathogens by costing the surface of your throat in PFAS. Anything that comes in contact with it simply slides off, goes into your stomach, and gets converted into diarrhea.
Is this the OG poem for your sprig?
Omg!!
Definitely not. This one doesn’t do poetry
That comment above is poetry.
Who?
Sprog.
Who’s sprog?
It was a username on another site, a while ago. They wrote in poems. Nice stuff.
Someone has commandeered their name here on the fediverse; or so it seems.
Lol this guy doesn’t know sprog.
Good thing my private keys are under a rock by my front door
I hear crypto bros swear by birdbaths xd
(I read this post 2 years ago and the “Repeat this process six more times with my six other bird baths” stuck with me xD)
Adversary-in-the-middle = man-in-the-middle?
perp-in-the-path
Yes, it’s the same as mitm. I get that it’s to avoid gendering the term but it doesn’t really roll off the tongue or preserve the existing abbreviation. I’ve heard the alternatives: machine in the middle, mallory in the middle or, my favourite, Malcolm in the middle.
Monster in the middle is my fave
Man is a gender neutral term
Menace in the middle
Less syllables is always gonna win, especially when it comes with alliteration
Just like main replaced master in a heartbeat.
Ticketmaster remains a notable holdout in that respect.
Molestor in the middle
First time I’ve come across the phrase but it sounds like the same thing. It’s gender neutral though I guess. Maybe that’s it?
It’s commonly used and you often see the abbreviation AITM these days. You’re right about the reason.
Good to know. Cheers.
We had one compulsory course in English at university. The professor corrected a “man-in-the-middle” I had in a field-specific paper. She preferred “middle man”. She did buy that it was an established term in cryptography, though.
It’s a term for the attack, yes but not for the attacker
Removed by mod
Every p2p network and their mom has been trying to solve this for decades lol.
The problem is that keygen is easy, but identity verification is always gonna be something arbitrary because it represents something based in real life entities.
Even with TLS, people only trust google.com as being Google because they learned that Google uses google.com.
I could make a goggle.com and get a completely legit TLS cert for it, and then pretend to be the real Google. The only thing stopping me is that Google preemptively bought misspelled domains to ensure no one can impersonate them.
The lazy solution already exists. Just don’t use PKI and use direct trust on first connect like SSH.
This is TLS, not SSL.
Ok, but what would that look like in a way that would have mitigated this situation? Seems likely that such a system could actually exacerbate this specific scenario.
note: I understand none if this
After trying for a bit, I can certainly relate to understanding little of it. It’s not as concretely explained as I would like and sticks to abstract principles. So no idea about the current state of affairs.
Removed by mod
Something like DANE, maybe? Only the websites actually using the compromised certificates would be compromised.
Conceptually, I get it. Esepecially if you go with the ‘DNS pinning of CA’ to have a ‘belt and suspenders’ approach where two chains of authority must be broken, one of which inherently tied to your name.
Practically speaking, DNSSEC hasn’t managed to get ubiquitous adoption. To the point where browsers started giving up and doing DNS over HTTPS to well known providers instead.
As nice as DANE is, it just shifts the burden of trust to your DNS provider. Like if you hop on Wi-Fi at a coffee shop, said network can simply MITM connections and supply their own certs via re-writing the DNS.
You can encrypt DNS to prevent that, but now you need a way to ensure your DNS client already trusts the desired DNS server, etc.
As much as people dislike CAs, they’re a proven solution to a problem that’s already implemented in nearly every device on the planet.
private keys were … 56
As noted, most browsers have already blocked the intermediate certificates. The exception appears to be Edge running on Windows 10, which at the time this article went live was still connecting to 12 vulnerable hosts.
LOL
Thankfully someone did pull their finger out and get it done an hour later, thankfully Windows also moved to a live CRL requiring no reboots and it’s only hundreds of thousand of unpatched Linux boxes that remain affected 😓
my Ubuntu 24.04 server is secured despite not updating anything or rebooting (I have now, but curl was already declining it before)
$ curl https://ov-g3c-aaa-emudhra.we-have-a-problem.com/ curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.other issues would be software not respecting the system level certs, but that can happen on any OS, it just depends on the program
Uhhhh as a dumb dumb Ubuntu user, do I need to do anything other than update?
Edge on windows 11 also did it. At least as of last night. My debian boxes are up to date and they have been fixed.
Newest release of Firefox Nightly on Android also still seems to connect.
I updated my Firefox today in the afternoon and afterwards it didn’t connect.
I did try with Fennec from F-Droid, which was fine. I updated Nightly just now, and it does still connect.
Edit: Firefox Beta connects to 6/12 on https://emudhra.we-have-a-problem.com/
Edit 2: Regular Firefox connects to 0/12
Why would this put vpn users at risk if browsers have already blocked the problematic certs?
VPN users use certificates to identify their servers. I assume then it’s not used by the VPN services?
it would put VPN users at risk if browsers had not blocked it or updated enough and the VPN provider chooses to do shenanigans, that’s why security patches patch the security and why it it’s important to patch this security issue
What, just because they are potential middle men?
IronFox all green here
