⬆️ happy being on holidays
post
This plus the php thing and everything I was planning on doing today is out the window 😖
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
4, 56, 66, 115, 155, 156, 230, 237.
That's amazing! I have the same combination on my luggage.
4, 8, 15, 16, 23, 42.
tween that and PHP CVE, everyone is on fire ATM
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?
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.
Depends. If the app uses cert pinning it will only trust the cert baked into it.
Oof. Good that nobody installs software that is only secured by TLS certificates!
Good thing my private keys are under a rock by my front door
I think that this isn't really getting the right attention, about what a massive WTF situation this is...
its a 384 bit certificate and this is the private key
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:04
that is just fucking NUTS
And 8 of them no less. The guess of this being test code leaking into prod is likely, but security focused companies need consequences for stuff like this. That being said:


top 50 comments