Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cisco Subdomain Private Key Found in Embedded Executable (google.com)

Posted by msmash on from the catch-me-if-you-can dept.

Earlier this month, a developer accidentally discovered the private key of a Cisco subdomain. An anonymous reader shares the post: Last weekend, in an attempt to get Sky's NOW TV video player (for Mac) to work on my machine, I noticed that one of the Cisco executables contains a private key that is associated with the public key in a trusted certificate for a cisco.com sub domain. This certificate is used in a local WebSocket server, presumably to allow secure Sky/NOW TV origins to communicate with the video player on the users' local machines. I read the Baseline Requirements document (version 1.4.5, section 4.9.1.1), but I wasn't entirely sure whether this is considered a key compromise. I asked Hanno Bock on Twitter, and he advised me to post the matter to this mailing list. The executable containing the private key is named 'CiscoVideoGuardMonitor', and is shipped as part of the NOW TV video player. In case you are interested, the installer can be found here (SHA-256: 56feeef4c3d141562900f9f0339b120d4db07ae2777cc73a31e3b830022241e6). I would recommend to run this installer in a virtual machine, because it drops files all over the place, and installs a few launch items (agents/daemons). The executable 'CiscoVideoGuardMonitor' can be found at '$HOME/Library/Cisco/VideoGuardPlayer/VideoGuardMonitor/ VideoGuardMonitor.bundle/Contents/MacOS/CiscoVideoGuardMonitor'. Certificate details: Serial number: 66170CE2EC8B7D88B4E2EB732E738FE3A67CF672, DNS names: drmlocal.cisco.com, Issued by: HydrantID SSL ICA G2. The issuer HydrantID has since communicated with the certificate holder Cisco, and the certificate has been revoked.

10 of 53 comments (clear)

  1. key management by charliemerritt03 · · Score: 4, Funny

    Why don't they study this just a bit?

  2. The thought process behind this... by __aaclcg7560 · · Score: 5, Funny

    "Which one is the public key and the private key? Oh, screw it. I'll include both."

    1. Re:The thought process behind this... by ebrandsberg · · Score: 2

      This domain resolves to 127.0.0.1 and was likely a use-case where a self-signed key would have done just as well is my guess, i.e. nothing to see here.

    2. Re:The thought process behind this... by XanC · · Score: 2

      I agree about nothing to see here in that the "vulnerability" is minimal.

      But a self-signed certificate wouldn't have worked. The browser would complain and/or refuse to connect.

    3. Re:The thought process behind this... by The+MAZZTer · · Score: 2

      Not if you add the cert to your PC's certificate store as a root certificate. This works fine if you have control over all PCs that will be using the site.

    4. Re:The thought process behind this... by jaymemaurice · · Score: 5, Interesting

      Uhhh sorry but you are wrong about this being a "nothing to see here". You can use this private key to run a "trusted https site" on local host that is capable of stealing cookies set for cisco.com. If you can man in the middle http traffic and DNS you can redirect the http traffic to this "site" on another system which includes content from cisco.com and steals cookies or does cross site scripting. Does Cisco have cloud services? Where are the session authentication cookies set and what other parameters invalidate them that can't be spoofed using data obtained by the web browser in the initial request...

      --
      120 characters ought to be enough for anyone
  3. Re:Have it generate a private key and CSR by XanC · · Score: 2

    But the local HTTPS server only listens on localhost. It doesn't *need* to be secure at all, really. The only reason it needs HTTPS at all is because the browser will scream bloody murder if you try to make a WebSocket connection to a non-HTTPS WebSocket server (even if it's running on the local machine) when viewing an HTTPS site.

    So in addition to all the problems you raised with getting a unique certificate for each, there's the additional problem of the HTTPS server not being reachable from the outside at all.

    It would seem that in order to make things "secure", these internal-only HTTPS servers, which don't really need to be secure in the first place because it really is a local service, must be published online!

  4. Re:Okay, so how SHOULD this be done? by houghi · · Score: 2

    ROT26.

    --
    Don't fight for your country, if your country does not fight for you.
  5. The DNS challenge by tepples · · Score: 2

    there's the additional problem of the HTTPS server not being reachable from the outside at all.

    ACME as implemented by Let's Encrypt supports a cleartext HTTP challenge and a DNS challenge. A user obtaining a certificate can use either of these to prove domain control. Only the cleartext HTTP challenge requires the server to be "reachable from the outside". The DNS challenge requires that the device requesting the certificate have control over TXT records associated with the requested hostname, which is true of any dynamic DNS implementation.

  6. Re:Okay, so how SHOULD this be done? by jaymemaurice · · Score: 2

    Same as the typical Cisco/Nortel/Dell product "This product is unsupported in the current browser" right in the browser when you manually accept the certificate warning. At the end of the day this is a stupid problem. There should not be a valid signed certificate and private key required for a local service. Other than DRM there is no point in the encryption with localhost communication for a video player app. There should be no DNS request required to make this work.

    --
    120 characters ought to be enough for anyone