Cisco Subdomain Private Key Found in Embedded Executable (google.com) 53
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.
key management (Score:4, Funny)
Re: (Score:2)
The thought process behind this... (Score:5, Funny)
"Which one is the public key and the private key? Oh, screw it. I'll include both."
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:3)
Re: (Score:2)
Hardly improves security, though, does it?
Re: (Score:2)
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.
Re: (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.
You or I know how to do this. The average person on the street? not so much.
Re:The thought process behind this... (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...
Re: (Score:2)
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..
Re: (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. /etc/hosts
I would then setup my own
Okay, so how SHOULD this be done? (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:3)
Re: (Score:2)
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...
Re: (Score:2)
or use localhost as the domain and install the certificate into the trusted keystore
"the trusted keystore" of which browsers on which devices?
Re: (Score:2)
the device the software service is being installed on, and all browsers present...
Re: (Score:2)
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
Re: (Score:3)
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.
Mixed active content blocking (Score:2)
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 [mozilla.org] 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?
Re: (Score:2)
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 implem
Re: Okay, so how SHOULD this be done? (Score:2)
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 ...
Have it generate a private key and CSR (Score:2)
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 suppo
Re: (Score:3)
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
The DNS challenge (Score:3)
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.
Re: The DNS challenge (Score:2)
"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
Dynamic DNS (Score:2)
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 dev
Re: (Score:2)
LE rate override vs. PSL add is probably a wash (Score:2)
"It takes a few weeks to process requests" according to Rate Limits [letsencrypt.org]. So I don't see how it'd necessarily be faster than a PSL addition.
Re: (Score:2)
Exactly how would the local key for use on that machine be accepted by a browser?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Generate a locally-significant self-signed certificate and install it into the Trusted Certificate storage.