
Cisco subdomain private key found in embedded executable - janvdberg
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/T6emeoE-lCU
======
pilif
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.

~~~
saurik
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](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](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
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.

~~~
saurik
FWIW, my post provides the certificate _and private key_ for anyone to verify
themselves; the certificate is definitely made out to "localhost" ;P.

subject=/C=US/ST=Florida/L=Melbourne/O=AuthenTec/OU=Terms of use at
www.verisign.com/rpa (c)05/CN=localhost

issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at
[https://www.verisign.com/rpa](https://www.verisign.com/rpa) (c)10/CN=VeriSign
Class 3 Secure Server CA - G3

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

Throwaway account for obvious reasons.

~~~
sofaofthedamned
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.

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

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

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

~~~
tehlike
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.

~~~
rrobukef
It's automatically embedded by the build script ;)

~~~
tehlike
lol, yes, except the acl is wrong :)

------
hannob
Seems Spotify did the same:
[https://groups.google.com/forum/#!msg/mozilla.dev.security.p...](https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/eV89JXcsBC0/hKPv7lXfAQAJ)

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

