Update your stuff, folks. I've had a fun day at work.

IT department told us to not use any browser until further notice lol

Jfc it’s patched in just about all of them now.

Unless for some reason they’ve overridden that capability while being unable to issue patches in a timely manner due to process overhead, but nobody would be that stupid right?

Currently having a very fun day at work.

Fortunately our own certificates are unaffected, but it's the autumn break and most of the staff are absent and incommunicado.

The certificates were determined by fair die roll

I can’t believe the private key was 4.

I wonder if they didn't read this section:

There are no entries in the certificate transparency logs for these intermediates in that period, indicating that CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked.

or if they did read it, but don't trust it.

I dont know whats more emberassing, the fact a CA fucked up this baddly. Or that the private keys look like they were actually someones lottery numbers from that morning.

ELI5?

Random website: your password must include lower and upper case characters, numbers, special characters, emojis, invisible UTF-16 characters, be at least 32 digits long, contain no repeating sequences, mathematical sequences, musical sequences, a random episode number of Friends, parts of your username, email, mother's name, father's name, address, social security number, childhood address street name, first pet's name, any date between 32 March 1928 and 1 Feb 2077, or the special character ë̷̡̡̨̡̬̜̲̫̼̠̙̱̝̖̝̞͕͉͎̿́̂͗͂̉͐͑͐̀͗̔̊̈́̅̑͘͠ͅ.

CA private key security: "Pick a number between 0 and 10443888814131525066917527107166243825799642490473837803842334832839539079715574568488268119349975583408901067144392628379875734381857936072632360
8785136527794595697654370999834036159013438371831442807001185594622637631883939771274567233468434458661749680790870580370407128404874011860911446797778359802900668693897688178778594690563019026094059957945343282346930302669644305902501597239986771421554169383555988529148631823791443449673408781187263949647510018904134900841706167509366833385055103297208826955076998361636941193301521379682583718809183365675122131849284636812555022599830041234478486259567449219461702380650591324561082573183538008760862210283427019769820231316901767800667519548507992163641937028537512478401490715913545998279051339961155179427110683113409058427288427979155484978295432353451706522326906139490598769300212296339568778287894844061600741294567491
9823050571642377154816321380631045902916136926708342856440730447899971901781465763473223850267253059899795996090799469201774624817718449867455659250178329070473119433165550807568221846571746373296884912819520317457002440926616910874148385078411929804522981857338977648103126085903001302413467189726673216491511131602920781738033436090243804708340403154190335"

User: guess 4 will do

Not possible.

The encryption that SSL/TLS provides (that puts the "secure" in HTTPS) uses a public--private key pair and a specific mathematical function. Generating the key pair requires a cryptographically secure random number that is impossible or very difficult to guess, which must be kept secret at all times. If this random number is leaked or guessed by a malicious actor, the private key can be reconstructed and used to impersonate a website or break the encryption.

The security of the encryption comes from the fact that the function is easy to calculate one way, but difficult to calculate its inverse. To demonstrate: multiplying the prime numbers 88117 and 44543 is easy, but the inverse, factorizing the semiprime 3924995531, is extremely lengthy in comparison.

One of the factors that determine the security of the key is the size of the number, i.e. the number of digits. In this case, a proper key should've had a length of 384 bits (or 116 decimal digits). In reality, the keys that eMudhra used had eight bits, which can only represent 256 possible values, and can be easily guessed even by brute force. The specific private keys were the numbers 4, 56, 66, 115, 155, 156, 230, and 237.

They can’t check if it’s patched because they can’t use their browsers

... Eight? Eight???

I immediately thought of Hurley from lost when I saw them

Four... Fucking... Pixels?

The working hypothesis is that this was some sort of debug or test key that was never meant to be used in production, being used in production.

https://www.youtube.com/watch?v=87H6m2v4zNs

I'm honestly skeptical about even this. I tried to generate an 8 bit key and got rsa_gen_set_params:key size too small.

And like, you need to go deliberately out of your way to not use OpenSSL.

Little eMudhra was asked to write down his a secret and hand it in to the teacher. He accidently gave the teacher the wrong paper.

It's also worth mentioning that these very poorly secured certificates were intermediate certificates. These are not used directly by websites to assure the end user that the communication with the website is secure - it's even worse than that.

Intermediate certificates are used to sign the website certificates, so that the end user's browser can look up the server certificates that websites give them, to determine if the certificate is genuine (and not, say, a man-in-the-middle that is intercepting the communication and merely pretending to be the real website).

Since anybody can easily just create a certificate, there has to be a way that an end user can be confident that the website they are visiting is actually the one they intend to visit. The way the current system works is that there is a curated list of CA (certificate authority) certificates that have been thoroughly vetted by multiple security organizations. These are used to "sign" server certificates. Every browser has a copy of the corresponding public CA certificate. The private certificates are kept very securely offline. There's no easy way for anyone to create a certificate that "claims" to be (but actually isn't) signed by one of these trusted CA certificates. This way, when a website provides its certificate, the browser can look at the signing key and know with a high degree of certainty that the website is what it says it is.

An intermediate certificate is a "delegate" subsidiary of a CA cert. It can be used as a proxy to its parent CA cert to sign other generated certs. So even if a website (or a man-in-the-middle) provides what appears to be a very secure cert with strong encryption, it may have been signed by a "broken" insecure intermediate cert. The browser, of course, doesn't know - or care - about how insecure the the intermediate cert is - the browser has already implicitly trusted it. There fore, the browser has no way of knowing or alerting the user that their communication with the website has been compromised by someone pretending to be another website.

They were proper 384bit certs, just the upper 376 bits were 0 in all the listed certs. So it's different to setting the key size in OpenSSL, and they were most likely rolling their own crypto.

Naughty boy

It's back to curl, bois

This is great news to get mitmproxy (which has been updated with a specific --emudra flag) to intercept your iot widgets that you couldn't install a custom ca on.

Oh SHIT yes, I hadn't even considered using this for my own purposes.