8 ms·
Cisco subdomain private key found in embedded executable
- adrianN 9y agoI 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 9y agoI 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 9y agoI 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 9y agoIt's automatically embedded by the build script ;)
- tehlike 9y agolol, yes, except the acl is wrong :)
- noahdesu 9y agoHow 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 9y agoWell then you should be very nervous, most of the internet's security is centered around keeping 4kb files secure.
- icedchai 9y agoIf 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...
- stereo 9y agoProbably communication with the browser over a kind of web API.
- peterwwillis 9y agoIIRC, 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 9y agoWhat 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 9y agoAt 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).
- deleted 9y ago[deleted]
- throwawaysec0xf 9y agoFor whatever it's worth, the team behind this stupidity has been let go a while back... Throwaway account for obvious reasons.
- sofaofthedamned 9y agoUsed 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 9y agoI 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.
- pilif 9y agoThe 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.
- Nullabillity 9y agoThis 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 9y agoCan you elaborate on use html5 <video> like everyone else? I am not familiar with this technique.
- pilif 9y agoIn 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?
- Nullabillity 9y agoIf you already need a native driver then you might as well make the whole thing native.
- euroclydon 9y agoI 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.
- YCode 9y agoOdd that they requested a new cert after theirs was revoked... As if to say "Eh, we'll hide it better next time."
- hannob 9y agoSeems Spotify did the same: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/eV89JXcsBC0/hKPv7lXfAQAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p...
- 0x0 9y agoI'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".