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/

Xkcd 221: int getRandomNumber() { return 4; // chosen by fair dice roll. guaranteed to be random. }

  • superglue@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    38
    ·
    1 day ago

    So if my understanding is correct, to be exploited the attacker would already need to be in a position to intercept your traffic, but this means when they do they can effectively impersonate anyone.

    This could actually be an interesting attack vector for hacking IOT devices. If you control the DNS server the device connects to you can get it to trust literally anything.

    • Badabinski@kbin.earth
      link
      fedilink
      arrow-up
      14
      ·
      1 day ago

      MITM HTTPS traffic without a key doesn’t really let you do much of anything, especially with stuff like HSTS. You can mess with DNS, but the whole certificate authority thing is meant to make it so you can’t redirect someone’s traffic to a malicious server.

      This leaked private key completely destroys that guarantee, making it extremely scary. ~Plus, saved traffic for any site signed by this key which didn’t use PFS will be subject to post-facto decryption.~

      edit: I don’t know wtf I was thinking, the decryption thing is nonsense.

      • BlueKey@fedia.io
        link
        fedilink
        arrow-up
        8
        ·
        1 day ago

        I don’t think so about the post-facto decrypt. Keyexchange runs with the certs of the destination server. The cerst affected by the leak are intermediate certs which give trust to a cert chain AFAIK.

        • Badabinski@kbin.earth
          link
          fedilink
          arrow-up
          8
          ·
          1 day ago

          You’re absolutely right, I had shit all mixed up in my head. Oops 😅 thank you for the correction.

    • hirihit640@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 day ago

      Wasn’t the Gamer’s Nexus video on LG spy TVs, saying that the telemetry traffic is protected by SSL and thus they couldn’t figure out exactly what was sent? Would they be able to use the leaked keys to decrypt the traffic?

      • x00z@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 day ago

        That should be possible yes, depending on how those TVs handle their cert stores.

        • hirihit640@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          1
          ·
          23 hours ago

          Thanks, I wasn’t sure if it mattered that the leaked keys in this case were for intermediate certs and not root certs (afaik)

    • frongt@lemmy.zip
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 day ago

      Yup.

      These days, a lot of firmware blobs are also signed with the vendor’s key, so you’d still need to get past that hurdle.