DEF CON 31 - Private Keys in Public Places - Tom Pohl

DEFCONConference
DEFCONConference
50,726
0
Publicado 2023-09-15
Firmware and software binaries are littered with private keys, legitimate CA-blessed certificates, and encryption keys—but hardly anyone notices. These secrets are often obfuscated or otherwise hidden in ways that weren’t intended to be found. I’ll show three real-world examples from popular manufacturers (Netgear, Fortinet and Dell), and demonstrate techniques for uncovering them. In the most extreme example, an adversary can use an obfuscated key to gain access to any customer’s vCenter environment.

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.
Todos los comentarios (21)
  • @micahnightwolf
    These manufacturers will never learn to stop leaving their private keys under the proverbial doormat.
  • @cardude1957
    This has not gotten enough views for the amount of great content that was in this presentation. Great job, Tom.
  • @drakas110
    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"
  • @akmadsen
    I'm not even 3 minutes in and I already love Tom. This is going to be great!
  • @ryanwolfe2219
    Wonderful talk, wonderful presenter! Tom seems like a great guy
  • @DeetexSeraphine
    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.
  • @mo3k
    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!
  • @ICountFrom0
    Sings, "You've got key in wrong places, and your IT crew keeps making faces, it pains the crew, you know it's true"
  • @stubstunner
    Another excellent talk. I’ve been in this field for a little over 10 years and I love talks like these.
  • @aaronr.9644
    sad state of affairs :( the hardcoded AES key with IV of zeroes is just crazy!!!
  • @Dwonis
    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.
  • @shelvacu
    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"?
  • @HenryLoenwind
    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...