Cisco subdomain private key found in embedded executable

https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/T6emeoE-lCU

by janvdberg • 9 years ago

141 62 9 years ago

groups.google.com

adrianN• 9 years ago

I wonder how many people had to approve the decision to send publicly trusted private keys to users. It seems like such an obvious security mistake that I didn't think people would make it.

tehlike2• 9 years ago

I am more interested in how does an embedded app get the cert in the first place. That cert should be accessed by automation and restricted to a set of people only.

pm90• 9 years ago

I can easily see it as being a "stop gap" solution to get a deadlined proof of concept working, and then some other team getting assigned to take the POC to production and not being smart enough to remedy a very obvious security hole.

rrobukef• 9 years ago

It's automatically embedded by the build script ;)

noahdesu• 9 years ago

How do security procedures for handling, distributing, and revoking keys work in practice, especially at big companies that release a lot of software? For some companies getting this right would have to be critical, but I would be nervous if everything hinged on keeping a small 4K private key file secure.

theossuary• 9 years ago

Well then you should be very nervous, most of the internet's security is centered around keeping 4kb files secure.

icedchai• 9 years ago

If you read that thread or do a DNS lookup, it turns out drmlocal.cisco.com points to 127.0.0.1.

I wonder what they're actually using it for...

stereo3• 9 years ago

Probably communication with the browser over a kind of web API.

peterwwillis• 9 years ago

IIRC, with many CAs all you have to do to generate a trusted certificate is show you control a subdomain. Once you control the subdomain, you get your cert signed by a CA, and then you can send keys anywhere you want.

In terms of who was _supposed_ to approve the decision, there is a policy in place for that. Did they get that approval? Who knows, but I think in theory there isn't a mechanism to enforce it once you control the subdomain.

Never underestimate the potential to make security mistakes.

HCIdivision17• 9 years ago

What impact does this sort of compromise cause? In context, it seems to be a poorly architected loopback to make an appliance gizmo work. So on the face of it, it sorta seems a bit harmless (well, as much as any internet appliance is harmless...)

I'd imagine that could allow an adversary to compromise DRM for the SKY perhaps? (Based on the domain name.) But there seemed to also be concern that improperly set up cookies for other cisco.com domains may allow this to compromise them; do Cisco devices put sensitive things in cookies where that could happen?

EDIT: I am not in any way, shape, or form a network or security 'guy'. I just read the thread and wasn't horribly alarmed by the discussion; seems like a reasonable but bad exposure on the device.

Retr0spectrum• 9 years ago

At a glance, cisco.com has an SSO cookie set for .cisco.com, so given an attacker is on your LAN, they could have used this cert to MITM your connection to drmlocal.cisco.com and insert a script to steal your cisco SSO cookie. That would give the attacker to your cisco account (I have no idea what a cisco account actually entails).

throwawaysec0xf• 9 years ago

For whatever it's worth, the team behind this stupidity has been let go a while back...

Throwaway account for obvious reasons.

sofaofthedamned• 9 years ago

Used to work for CSCO myself. Was amazed they (internally) didn't have centralised PKI, so we rolled our own as an acquisition.

This is the Sky UK middleware project isn't it? I know a couple of people who work there who said it's a bit of a clusterfuck. There were some good things at CSCO when I was there, but loads of WTF moments.

anothertemp398• 9 years ago

I certainly hope damage control does a better job than throwing another team under the bus whether or not they were let go. This speaks to systemic issues in my opinion.

pilif8• 9 years ago

The domain in question (drmlocal.cisco.com) resolves to 127.0.0.1. This is a handy and above all cross-platform/cross browser way for a website to talk to a locally installed application (that's running a web server, bound to the loopback interface) by using CORS and/or jsonp.

If the site that wants to make use of this is using SSL, then the locally running web browser also needs to be using SSL and it needs to have a publicly trusted cert.

The other alternative (installing a local CA) seems to be worse.

An option would be for the locally installed app to ask a server for a cert to use while it's running, but that means that the app needs to phone home which it otherwise would not have to.

So I guess we're back to proprietary browser extensions if this technique is frowned upon.

Nullabillity2• 9 years ago

This technique is already the equivalent of a proprietary browser plugin, except for that it's running completely outside of the browser sandbox.

The proper fix here is to stop with the DRM bullshit and just use HTML5 <video> like everyone else.

notyourwork• 9 years ago

Can you elaborate on use html5 <video> like everyone else? I am not familiar with this technique.

pilif8• 9 years ago

In my case I’m using this to allow people to read data from a locally connected (via USB) barcode scanner.

Remind me again how <video> would be of help there?

euroclydon2• 9 years ago

I actually need to do this. Is there a best practice for handling the certificate? It needs to be installed on the machine for the browser to trust it. All I can think of is to make a new certificate for every machine at install time and binding an obscure domain name to the loopback interface, so it would be highly unlikely to overlap with a real site.

ploxiln• 9 years ago

You can do what Cisco did with the domain name. Just don't create a CA-trusted cert for it. Instead, as you suppose, generate a unique cert on each machine and install it to the appropriate/needed trust stores on that machine.

justinclift• 9 years ago

The Plex approach, pointed out above by diafygi above might suit you.

  https://news.ycombinator.com/item?id=14595269

You need a wildcard cert (not hard), and a DNS resolver (daemon) to respond back with custom IP address. Sounds pretty simple in concept. :)

asdfaoeu3• 9 years ago

It looks like browsers will allow you to talk to localhost from a secure page without SSL https://bugzilla.mozilla.org/show_bug.cgi?id=903966. The other way assuming you don't need to transfer much is you can reverse proxy it out to your own server and back to your application. (Where the SSL decoding is done by the remote server)

stereo3• 9 years ago

Chrome doesn’t.

stereo3• 9 years ago

JOSM, an editor for OpenStreetMap, installs its own certificate, which is limited to https://localhost:8112. This seems pretty safe to me - if someone can MITM that, you already have bigger problems.

ryanlol2• 9 years ago

Presumably that certificate isn't actually signed by any relevant CA, right? If so it seems rather irrelevant in the context.

Kenji• 9 years ago

If somebody MitMs your connection to 127.0.0.1, you're hopelessly lost anyway. I don't really see a reason to protect requests that do not leave your machine.

asdfaoeu3• 9 years ago

The issue is remote sites that are using SSL and want to do an Ajax request to a local site.

ejcx• 9 years ago

If it is local and communication never leaves the machine, why use TLS?

1Password got heat for the opposite in the past (use of ws:// between the browser extension and the Mac Client). 1Password correctly pointed out that there isn't really a point to "secure communications" if the webserver and the web client are on the same machine.

If you can't trust your own machine to intercept your connection then TLS is not going to save you. What I bet happened was some project manager said "There needs to be a green check" or some security person said "You NEED TLS" and nobody spoke up that it didn't make sense.

edit: I'm not a deleter, but I misunderstood your post and I realized it right after I pressed enter.

Did not realize you were talking about being on a remote webpage and being connected locally.

pilif8• 9 years ago

Yeah. The webpage is remote and using ssl and now wants to talk to the locally installed app.

I agree that SSL doesn’t make sense there and honestly, in my opinion it would make sense for browsers to treat localhost as a secure origin.

But they don’t and so we’re back to square one which is that a secured origin can’t make requests to a non secured origin.

Update: newer browsers do in-fact do this. It’s also part of the WHATWG spec: https://github.com/w3c/webappsec-mixed-content/commit/349501...

Of course there’s still IE and Edge that are of different minds, but it’s nice to see movement

diafygi• 9 years ago

Plex does this by generating a private key at install then issuing a real ssl cert for it. That way the private key never is seen by Plex or anyone else. Really cool technique.

https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

pilif8• 9 years ago

Yes. But it requires them to have a CA certificate which requires special contracts with a CA.

Now, Cisco could certainly do that, but for smaller companies, that‘s probably not feasible

Azeralthefallen2• 9 years ago

The company i used to work for wanted to basically replicate what plex does with their certs for our IoT devices. Unfortunately the price implied by Digicert was far too high for a startup.

The other solutions proposed like abusing Lets Encrypt, etc never really seemed right. I am still not sure really what the best solution is for IoT devices that doesn't have an astronomical cost.

ryanlol2• 9 years ago

So I guess we're back to proprietary browser extensions if this technique is frowned upon.

It's not. You just need to not fuck it up.

drmlocal.cisco.com isn't really an acceptable way of doing that because it's in the cisco.com scope, why not just have drmlocalcisco.com instead?

vbezhenar3• 9 years ago

If private key is accessible to the wide public, it's considered compromised and CA must revoke the certificate. Domain doesn't matter.

0xfeba• 9 years ago

Microsoft was proposing to prohibit localhost connections in a new version of Edge. They, rightly, were shouted down from that position.

duskwuff• 9 years ago

Another option that comes to mind is a keyless SSL configuration, similar to what Cloudflare does:

https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...

vardump• 9 years ago

The domain in question (drmlocal.cisco.com) resolves to 127.0.0.1.

So if someone just MITMs your clear text DNS to make drmlocal.cisco.com resolve to something else, they get your cisco.com cookies and plausible chance to impersonate Cisco?

Think targeted attacks.

saurik3• 9 years ago

Back in 2011, the HBO Go application on iOS contained a similar certificate for 127.0.0.1; I believe in that case a certificate for the bare IP address or just "localhost" that they got from Verisign. It was noticed by jan0 from the iOS jailbreak community, who had written isslfix, with the goal of hacking in a fix to a bug found in Apple's SSL certificate verification. He had some logging and noticed this extremely weird certificate get checked.

https://github.com/jan0/isslfix

The file was embedded in the binary as a base64-encoded PKCS12, but was encrypted with a password. They thought they were clever and used a format string to cobble together multiple parts that they then ran through a base64 decide to get the password. When jan0 told me about it, I spent a couple hours reversing the logic until I worked out the password... only for jan0 to tell me after that he had simply used one of my tools to hook the decryption itself and it only took him a few minutes ;P.

(I scavenged my stuff and found a copy!) The password to this file--which is the one directly taken from the binary, and so this is the original password (!!)--is "AmsterdamIsC0ld". (I have given talks about "the fallacy of trying to secure content inside of a binary you give to your attacker", and this password with that 0 for the O always manages to get some laughs ;P.)

http://test.saurik.com/hackernews/localhost.der

As for why this absolutely should be frowned upon: this doesn't provide any actual security... if everyone has the private key then anyone on your computer can man in the middle attack this connection. This is no better than just using HTTP to connect to this local service: the only reason you are even using SSL here is to bypass a security check in the browser (that an SSL website can't access a non-SSL website).

And if you want to argue "it is a local computer, why is a man in the middle attack relevant", you need only see the work people in jailbreak communities for random devices do to escalate privileges through various otherwise protected and sandboxed applications... made all the more obvious in your own description as it is the security of this website that is being undermined now (as maybe returning weird stuff from its API will mess with the user's site account or network settings or just break the website and give you arbitrary JavaScript execution).

I mean, in this case, you can't even guarantee the connect is to localhost! You start by swapping out the DNS to redirect drmlocal.cisco.com to some other IP address, and now you can get that website running on one computer--which you might not even have physical access to!--to talk to your forged copy, and trick the user into interacting with it, possibly letting you steal authorization keys or doing any of the other aforementioned described "bad stuff".

I will argue a local CA is absolutely "better", even if the optics are worse: you can generate the key for the CA, use that key to generate a key for just the one host, destroy the private key for the CA, and then install the public key. You now have a CA installed that can effectively only ever be used for the one host.

Of course, that causes a problem that you are training users to install CAs. If you dislike that, you can either use a proprietary browser or lobby browsers and OS developers to provide support for installing a CA limited to a hostname pattern: the fact that these do not exist is the real problem here and is downright criminal, as we know people want to do stuff like this, and it isn't even a ludicrous concept.

tinus_hn• 9 years ago

If that is true Verisign should be blacklisted for signing a certificate for localhost or an IP address. Both of these things are not allowed.

mook• 9 years ago

As for why this absolutely should be frowned upon: this doesn't provide any actual security...

I was under the impression that some of the newer APIs only work under SSL (e.g. geolocation, https://developers.google.com/web/updates/2016/04/geolocatio... ). This would mean they'd need this even if they were not requiring security. The specific instance is probably to tick a checklist for the content provider though.

YCode• 9 years ago

Odd that they requested a new cert after theirs was revoked... As if to say "Eh, we'll hide it better next time."

hannob2• 9 years ago

Seems Spotify did the same: https://groups.google.com/forum/#!msg/mozilla.dev.security.p...

0x0• 9 years ago

I'm curious, what is the current best practise for shipping LAN-only type embedded devices that needs to be configurable from a browser now that everyone is pushing for https only and marking http not safe?

Some may not even have a local DNS name but only use an RFC 1918 ip address. I don't think the current CA system can accomodate that? Obviously you don't want to hand anyone who asks for it a cert and a private key for "10.0.0.1".

Cisco subdomain private key found in embedded executable

Related Stories