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.

34 of 53 comments (clear)

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

    Why don't they study this just a bit?

    1. Re:key management by arglebargle_xiv · · Score: 1

      Key management, motherfucker, do you speak it? Say 'embedded private key' again. Say 'embedded private key' again, I dare you, I double dare you motherfucker, say embedded private key one more Goddamn time!

  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 XanC · · Score: 1

      Hardly improves security, though, does it?

    5. 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
    6. Re:The thought process behind this... by Strider- · · Score: 1

      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.

      You or I know how to do this. The average person on the street? not so much.

      --
      ...si hoc legere nimium eruditionis habes...
    7. Re:The thought process behind this... by Maritz · · Score: 1

      Looks like the subject/DN is drmlocal.cisco.com - how would this affect the whole cisco domain? Not saying it wouldn't, I don't pretend to know everything about PKI.

      --
      I do not want your cheap brainburning drugs. They are useless for work. And I am a working man today.
  3. Okay, so how SHOULD this be done? by XanC · · Score: 1

    If they want an HTTPS website to be able to access a local service I've installed via WebSocket, then what other option is there?

    Also, this only theoretically allows an attacker to steal cookies if they're based off the company's root domain. Doesn't seem so bad.

    1. Re:Okay, so how SHOULD this be done? by XanC · · Score: 1

      Decrypting it by what mechanism such that it's useful? I suppose the WebSockets app could include both the private key and the encryption key that was used to encrypt it, but is that really any better?

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

      Exactly how would the local key for use on that machine be accepted by a browser?

    3. Re:Okay, so how SHOULD this be done? by XanC · · Score: 1

      It's not a DRM issue.

      Cisco runs some web service, over HTTPS as is (of course) best practice. It has a local component, provided by a WebSocket server running on the local machine. The WebSocket server must also be HTTPS or the browser will complain. That's why a private key is needed locally; nothing to do with DRM.

    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. Re:Okay, so how SHOULD this be done? by tepples · · Score: 1

      The installer for the application would install the corresponding root certificate into the root certificate store of all major web browsers currently installed on the same machine.

      But this wouldn't work so well for allowing access by other machines on the same LAN. This requires operating a dynamic DNS server that issues subdomains of a domain on the Public Suffix List and then obtaining a certificate from Let's Encrypt through the DNS challenge.

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

      If it has to be decrypted to be used it's still compromised when you don't control the system doing the decryption...

      I think the correct answer is don't use x.cisco.com use localhost.ciscovideoguardmonitor.com...
      or use localhost as the domain and install the certificate into the trusted keystore...
      or don't expect the browser to not prompt with an untrusted certificate warning...

      --
      120 characters ought to be enough for anyone
    7. Re:Okay, so how SHOULD this be done? by tepples · · Score: 1

      or use localhost as the domain and install the certificate into the trusted keystore

      "the trusted keystore" of which browsers on which devices?

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

      the device the software service is being installed on, and all browsers present...

      --
      120 characters ought to be enough for anyone
    9. Re:Okay, so how SHOULD this be done? by tepples · · Score: 1

      What steps should be taken to field customer support requests related to these?

      A. Browsers other than the pack-in, Chrome, or Firefox
      B. Browsers installed after the certificate was installed

    10. 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
    11. Re:Okay, so how SHOULD this be done? by mysidia · · Score: 1

      Generate a locally-significant self-signed certificate and install it into the Trusted Certificate storage.

    12. Re:Okay, so how SHOULD this be done? by mysidia · · Score: 1

      There should not be a valid signed certificate and private key required for a local service.

      Well... another user on the multi-user computer could have a malicious program running first and bound to the port.

      What should happen is the Installer or Admin should have a way of installing a Locally-trusted signifier of authorization or registration to
      use a hostname with a particular keypair.

      AND all Web browsers ought to be designed to learn about this registration mechanism for the OS they run on and implement it.

      If ONLY major OSes would provide a standard certificate trust store, huh? (Hint: They Do. Even Linux has trusted root certs in some standard well-known paths. It's broken browser software that ignores admin settings......)

    13. Re: Okay, so how SHOULD this be done? by buchanmilne · · Score: 1

      Except if you want to get the app into the Apple App Store, they are requiring *ALL* HTTP to use HTTPS now?

      Because HTTPS Everywhere, even when the end result is less secure for the user ...

  4. Have it generate a private key and CSR by tepples · · Score: 1

    If they want an HTTPS website to be able to access a local service I've installed via WebSocket, then what other option is there?

    Have the local HTTPS server generate its own private key and then send a certificate signing request (CSR) with the public key and hostname to a certificate authority (CA).

    But this in turn raises two questions: which CA, and which hostname? Let's Encrypt is limited to 20 certificates per registrable domain per week, and if all devices are on the same domain, it'll hit that rate limit fairly quickly. Is every end user supposed to pay for his own domain and pay to keep it renewed? Or is the manufacturer supposed to register a domain, run its own dynamic DNS server, give each end user a subdomain, and submit it to Mozilla's Public Suffix List (PSL) so that subdomains are considered registrable? Last I heard, the PSL had such a backlog that adding a domain took months.

    Also, this only theoretically allows an attacker to steal cookies if they're based off the company's root domain.

    Then the domain used for the dynamic DNS service should differ from the domain used for the company's customer service web application. It's why Google serves works uploaded by users from the domain googleusercontent.com.

    1. 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!

    2. Re:Have it generate a private key and CSR by bobbutts · · Score: 1

      Let's Encrypt will raise the limitation if you ask nicely. https://docs.google.com/forms/...

  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.

    1. Re: The DNS challenge by buchanmilne · · Score: 1

      "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."

      Are you saying devices in the world have access to send dynamic DNS updates for a domain, of which they have a record pointing to an address that reaches the device?

      I don't know that many people who habe domains just for their own devices at home ...

      Sure, it's technically possible, but it's also possible for the user to operate their own CA, but neithet are going to result in most users getting the app to work.

  6. LE rate override vs. PSL add is probably a wash by tepples · · Score: 1

    "It takes a few weeks to process requests" according to Rate Limits. So I don't see how it'd necessarily be faster than a PSL addition.

  7. Mixed active content blocking by tepples · · Score: 1

    Other than DRM there is no point in the encryption with localhost communication for a video player app.

    The other point is to satisfy the mixed active content blocking policy of major web browsers. If the outer page is HTTPS, all requests it makes must also be HTTPS. Or do you consider the mixed active content blocking policy itself pointless?

  8. Re:This is the problem with infosec people by mysidia · · Score: 1

    The DNS lookup is insecure and can be easily hijacked on the network. The SSL Certificate and its corresponding Keypair is what controls access of HTTPS connections to be associated with a given hostname..

  9. Re:This is the problem with infosec people by Anonymous Coward · · Score: 1

    Your ramblings have nothing to do with how this certificate would actually be used in the real world.

    drmlocal.cisco.com is what hands out the permissions to view (or not view) videos this app streams.

    It would be the computer and network owner setting up the proxy, so whatever you're going on about as some local insecurity has what to do with that again?
    The security problem is with cisco, not the user!

    I would setup my own proxy, on my own network, using my own credentials.
    I would then setup my own /etc/hosts equivalent redirect for cisco's domain on my own computer to point to my own proxy.

    With this private key, the application will now trust any response my own server sends the app.

    It will of course be configured to always say "Yes that person has permission to stream whatever video it was you mentioned"

    If cisco has specified I do not have permission to stream a video on their servers, because you know, I don't have permission and didn't buy it, this setup will allow me to stream and watch it.

    How on earth do you figure that isn't a security compromise from cisco's point of view???

  10. Dynamic DNS by tepples · · Score: 1

    I don't know that many people who habe domains just for their own devices at home ...

    The manufacturer of such a device is expected to follow the following steps:

    1. Register a domain for devices to use.
    2. Submit this domain to Mozilla's Public Suffix List so that cookies and certificates from one device don't leak to others.
    3. Issue a subdomain of this domain to each device.
    4. Operate a dynamic DNS service so that devices can set their AAAA and TXT records.

    The cost of steps 1 and 4 would be rolled into the price of each device.

    Sure, it's technically possible, but it's also possible for the user to operate their own CA

    It may not be possible for the user to configure a particular device to trust his own CA's root certificate. For example, under Android 7 "Nougat", an application will not trust user-added root certificates unless the application's developer has opted in, and there's no rule that all web browser developers must opt in. See "Changes to Trusted Certificate Authorities in Android Nougat" by Chad Brubaker