DEF CON 31 - Private Keys in Public Places - Tom Pohl
50,726
Published 2023-09-15
I’ll start with a straightforward look at Netgear firmware and show methods for discovering private keys in PEM-encoded text files. We’ll dig into the Fortinet firmware, which contained custom obfuscated archive files, and show how to extract Apple and Google issued certificates and I will also show that 3 year awaited “fix” did not adequately solve the issue.
Finally, I’ll dig into the worst case: a static AES encryption key within Dell software used to connect to vCenter. I'll demonstrate how retrieve, decompile and use a static AES key which will decrypt vCenter credentials. The key is the same for EVERY customer. This has not been talked about anywhere publicly.
I’ll conclude by discussing the importance of developer training, proper key management, and (above all), identifying and eliminating this systemic practice.
All Comments (21)
-
These manufacturers will never learn to stop leaving their private keys under the proverbial doormat.
-
This has not gotten enough views for the amount of great content that was in this presentation. Great job, Tom.
-
i do hope he turned around and said at the "only guy at a hacker convention you use their real name" "its a hacker convetion you think that would stop them"
-
I'm not even 3 minutes in and I already love Tom. This is going to be great!
-
Wonderful talk, wonderful presenter! Tom seems like a great guy
-
Wait... this is still relevant. sharp inhale Ima thinkin I'm gonna take a peek and maybe give a poke at my company's server cabinet.
-
Great presentation and super entertaining and well-presenting presenter! Understood all his methods and even yelled out the answer to most of his questions lol. Thank you DefCON and Tom!
-
Sings, "You've got key in wrong places, and your IT crew keeps making faces, it pains the crew, you know it's true"
-
Another excellent talk. I’ve been in this field for a little over 10 years and I love talks like these.
-
Great man, great talk ! cheers
-
What a great talk. Thanks
-
sad state of affairs :( the hardcoded AES key with IV of zeroes is just crazy!!!
-
i love him
-
When did "responsible disclosure" come to mean not publicly disclosing things yourself after a period of time? There's supposed to be an implied "public disclosure" in these terms---"full disclosure" doesn't mean just fully disclosing to the vendor, it means full public disclosure. How did "responsible disclosure" get warped to omit the public disclosure at some point? I've been out of the loop from the security industry for some time, but when I first learned the term, it didn't mean vendors could hide problems. You just gave them some reasonable time to patch things before you went public.
-
the netgear story seems unfair, routerlogin is what they use for, well, router login. Including the private key in the binary is no less secure then every other router which must either do that or have no SSL at all. What was the "fix"?
-
I use XZ, just about everyone does right?
-
25:44 - oooh someone de-mosaic that plz :P
-
And I'm still waiting for the talk that explains how a program can authenticate itself to another service in a way, that a human who can log into the same account the program runs under cannot. The only halfway working way I've seen so far is using a tamper-protected SOC with the data in its read-only storage that only runs signed code (and isn't controlled by software running outside the SOC). The second best solution is using a hardware encryption module, as this requires the attacker to funnel their attack through that module. Also, I blame web browser manufacturers for not having come up with a method a browser can pair with a device on the local network to replace the need to ship that device with an SSL cert to avoid the browser trying its best to prevent the user from accessing that "insecure" device...
-
0039 1:10
-
Boring!!!