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.

53 comments

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

    Why don't they study this just a bit?

    1. Re:key management by Anonymous Coward · · Score: 0

      because that exceeds point-and-click and javascript skillsets.

    2. 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 Anonymous Coward · · Score: 0

      That's why you give them a script to double click.

    8. Re:The thought process behind this... by Anonymous Coward · · Score: 0

      Yes, it would have improved security immeasurably. A self-signed certificate for ciscodrm.local could have been added to the certificate store at software installation time. Instead they chose to distribute the private key for drmlocal.cisco.com and compromised security (cookie, XSS, other) for the entire cisco.com domain.

    9. 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 Anonymous Coward · · Score: 0

      You should always encrypt the key.

    2. 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?

    3. Re:Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

      There is no reason for a home install of their application to require the private key of their internet based site. If the program at home needs to communicate with xxx.cisco.com, it only needs the public key to do so. If the program is running a local web server to provide, for example, a web GUI for interacting with the program then that program should generate a unique local key for use only on that machine.

      Whatever manager allowed a private key to a cisco server to end up in this program needs to be fired, and all engineers/high-school-compsci-students involved need to be re-educated.

    4. Re:Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

      The Web isn't the right solution for every Internet use case. It's just easier to leverage all the existing tools.
      Also, this wouldn't happen if companies didn't think video needs to be DRMed.

    5. 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?

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

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

    9. 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
    10. 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?

    11. Re:Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

      Note the use-case, a local drm provider.

      The remote site needs to know that the local software is what it says it is such that legal intellectual property agreements can be maintained.

      This implementation is good enough for that until someone notices.

      For proper security a private key does not necessarily need to be local, but there is a hangup about that. A Certificate and sending a hash along would do. That way the remote site can check the cert and the hash to determine authenticity and know whether or not the local software is authentic. Encryption by this method is not really necessary, any would do.

      Back to the local private key. It's fine if you need to trust that end explicitly anyway. This is mass-downloaded software. If they implemented PKI properly, someone could just as easily copy the cert anyway given the implementation and use.

      This story is "much ado about nothing" but gives 95% of slashdot the opportunity to bitch about fellow developers, the state of security, and general work related venting whether or not they have the expertise needed to understand the underlying problem.

      A story perfect for clicks.

    12. Re:Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

      Key embedded in a SIM so that the application contains no key and is only usable with a valid physical SIM. While not impossible to break into a SIM it's orders of magnitude harder. The application can use it to authenticate itself using a per-device key and negotiate a one time key for the session that are managed individually and can be revoked specific to a device. It's good enough for authentication in mobile phones, which is one place they're used and the user has physical access to the device.

    13. Re:Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

      pointing and clicking our way across the information superhighway!

    14. Re: Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

      Except that all this is FOR a DRM service. Look at the subdomain. It has the acronym drm right in it.

    15. Re: Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

      drmlocal.cisco.com

    16. Re:Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

      If you want that, then why does the private key need to be in the executable and not created at install time from a local seed? That way someone can only pretend to be some random joe rather than CISCO, who carry rather more trust in web connections than Joe Shmoe.

    17. 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
    18. 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

    19. 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
    20. 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.

    21. 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......)

    22. Re:Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

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

      This is DRM we're talking about, even if that creates the same effective result, the small hands that mandate this crap can't deal with the idea of a portion of the encryption key being generated on the client system. After all, they can't revoke a key that they didn't sign*.

      I say check the DRM implementation. There's probably some part that depends on the installed CA cert being revokable to "maintain" the "security" of the player and the content. (Check the player too. If they implemented it correctly, the DRM probably checks the revocation / validity status on the installed cert as a counter to someone using OpenSSL to generate a fake cert with the same domain.)

      *Before anyone says: "What about the generated key being submitted for signing?", remember if you control the private key, you can set it up so that it's effective key length is compromised, or insert known constants to reduce the encryption's effectiveness in a way that the users of that keypair cannot detect easily. (Just ask the NSA....) The media cartels wouldn't dare sign a key from just anyone. Especially if that key was sent to them for the purpose of content protection.

    23. Re:Okay, so how SHOULD this be done? by Anonymous Coward · · Score: 0

      Firstly, they should register a separate top-level domain that is only used for this purpose. Then at least the vulnerability is confined to the product they are shipping, not their entire *.cisco.com web presence.

    24. 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. This is the problem with infosec people by Anonymous Coward · · Score: 0

    You guys think you know everything and run around like Chicken Little screaming bloody murder about every little security "mistake" that you see, claiming it's the end of the Internet as we know it.

    Meanwhile if this "trusted https site" was running on localhost aliased to a cisco subdomain, it would have to have an entry in /etc/hosts to 127.0.0.1; ergo... the rest of your security nightmare that you describe means.... fuck-all.

    Also if your local system is compromised such that someone is running an http proxy - you are already fucked.

    So yes, nothing to see here.

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

      Because the scenario is total bollocks and would be extremely difficult, if not impossible, to carry out in a real world scenario outside of a controlled environment. If this subdomain is used only locally, on a specific application, MITMing DNS does fuck-all because /etc/hosts overrides.

      If this was a wildcard certificate I'd be concerned but it's not so carry on.

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

    3. 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???

  8. 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?

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