Yesterday Apple released iOS 7.06, an important security update you have probably seen blasted across many other sites. A couple points:
- Apple normally doesn’t issue single-bug out-of-cycle security patches for non-public vulnerabilities. They especially don’t release a patch when the same vulnerability may be present on OS X but there isn’t an OS X patch yet. I hate speculating, especially where Apple is concerned, but Apple has some reason for handling this bug this way. Active exploitation is one possibility, and expectations of a public full disclosure is another.
- The bug makes SSL worthless if an attacker is on the same network as you.
- OS X appears vulnerable (10.9 for sure). There is no public patch yet. This will very likely be remediated very quickly.
- A lot of bad things can be done with this, but it isn’t a remotely exploitable malware kind of bug (yes, you might be able to use it locally to mess with updates – researchers will probably check that before the weekend is out). It is bad for Man in the Middle (MitM) attacks, but it isn’t like someone can push a button and get malware on all our iOS devices.
- It will be interesting to see whether news outlets understand this.
The best security pro article is over at ThreatPost.
The best technical post is at ImperialViolet. They also have a test page.
If you are in an enterprise, either push the update with MDM as soon as possible, or email employees with instructions to update all their devices.
Posted at Saturday 22nd February 2014 6:11 pm
(4) Comments •
I was talking to yet another contact today who reinforced that almost no one is sniffing SSL traffic when they deploy DLP.
- No monitoring of most major webmail providers.
- No monitoring of many social networks.
- No monitoring of Dropbox or other cloud storage services.
- No monitoring of connections to any site that requires a login.
Don’t waste your money. If you aren’t going to use DLP to monitor SSL/TLS encrypted web traffic you might as well stick to email, endpoint, or other channels. I’m sure no one will siphon off sensitive stuff to Gmail. Nope, never happens. Especially not after you block USB drives.
Posted at Monday 24th June 2013 7:38 pm
(7) Comments •
Major Update: I got a core fact incorrect, in a big way. Thanks to @ivanristic for catching it. It’s an obvious error and I wasn’t thinking things through. ECC is used at a different point than RC4 in establishing a connection, so this doesn’t necessarily affect the use of RC4. David Mortman seems to think it may be more about mobile support and speeding up SSL/TLS on smaller devices. My apologies, and I will leave the initial post up as a record of my error.
In a rambling press release that buries far too much interesting stuff, Symantec announced the release of both ECC and DSA digital certificates for SSL/TLS. On the surface this looks like merely an attempt to speed things up with ECC, and hit government requirements for DSA, but that’s not the entire story.
As some of you might remember, a total d*ck of a patent troll operating under the name of TQP Development has been suing everyone they can get their hands on for using the RC4 cipher in TLS/SSL. We know of small businesses, not merely big guys, getting hit with these suits. This is important because RC4 was the best way to get around certain attacks against SSL/TLS.
Which brings us back to ECC. I wouldn’t bet my personal fortune on it, but I suspect it avoided both the security and legal issues in question. Pretty interesting, but I suppose the Symantec lawyers wouldn’t let them put that in a release.
Posted at Wednesday 13th February 2013 4:54 pm
(0) Comments •
Most security professionals have long understood at least some of the risks of the current ‘web’ or ‘chain’ of trust model for SSL security. To quickly recap for those of you who aren’t hip-deep in this day to day:
- Your browser knows to trust a digital certificate because it’s signed by a root certificate, generated by a certificate authority, which was included in your browser or operating system. You are trusting that your browser manufacturer properly vetted the organizations which own the roots and sign downstream certificates, and that none of them will issue ‘bad’ certificates. This is not a safe assumption. A new Mac trusts about 175 root certificates, and Apple hasn’t audited any of them.
- The root certificates are also used to sign certain intermediary certificates, which can then be used to sign other downstream certificates. It’s a chain of trust. You trust the roots, along with every certificate they tell you to trust – both directly and indirectly.
- There is nothing to stop any trusted (root) certificate authority from issuing a certificate for any domain it chooses. It all comes down to their business practices. To detect a rogue certificate authority, someone who receives a bogus certificate must notice that the certificate they issued is different than the real certificate somehow.
- If a certificate isn’t signed by a trusted root or intermediary, all browsers warn the user, but they also provide an option to accept the suspicious certificate anyway. That’s because many people issue their own certificates to save money – particularly for internal and private systems.
There is a great deal more to SSL security, but this is the core of the problem: we cannot personally evaluate every SSL cert we encounter, so we must trust a core set of root providers to identify (sign) legitimate certs. But the system isn’t centralized, so there are hundreds of root authorities and intermediaries, each with its own business practices and security policies. More than once, we have seen certs fraudulently issued for major brands such as Google and Microsoft, and now we see attackers targeting certificate authorities.
We’ve seen two roots hacked this year – Comodo and DigiNotar – and both times the hackers issued themselves fraudulent certs that your browser would accept as valid. There are mechanisms to revoke these things but none of them work well – which is why after major hacks the browser manufactures such as Microsoft, Mozilla, and Apple have to issue software updates. Research in this area has been extensive, with a variety of exploits demonstrated at recent Black Hat/Defcon conferences.
I highly recommend you read the EFF’s just-published summary of the DigiNotar issue.
It’s a mess. One that’s very hard to fix because:
- Add-on models, such as Moxie Marlinspike’s Convergence add-on and the Perspectives project are a definite improvement, but only help those educated enough to use them (for the record, I think they are both awesome). The EFF’s SSL Observatory project helps identify the practices of the certificate authorities, but doesn’t attempt to identify breaches or misuse of certificates in real time. DNSSec with DANE could be a big help, but is still nascent and requires fundamental infrastructure changes.
- Google’s DNS pinning in Chrome is excellent for those using that browser (I don’t – it leaks too much back to Google). I do think this could be a foundation for what I suggest below, but right now it only protects individual users accessing particular sites – for now, only Google. The Google Certificate Catalog is another great endeavor that’s still self-limiting – but again, I think it’s a big piece of what we need.
- The CA market is big business. There is a very large amount of money involved in keeping the system running (I won’t say working) as it currently does.
- The browser manufacturers (at least the 3 main ones and maybe Google) would all have to agree to any changes to the core model, which is very deeply embedded into how we use the Internet today. The costs of change would not fall only on evil businesses and browser developers, but would be shared among everyone who uses digital certs today – pretty much every website with users.
- We don’t even have a way to measure how bad the problem is. DigiNotar knew they had been hacked and had issued bad certs for at least more than a month before telling anyone, and reports claim that these certs were used to sniff traffic in Iran. How many other evil certs are out there? We only notice them when they are presented to someone knowledgeable and paranoid enough to notice, who then reports it.
Dan Kaminsky’s post shows just a small slice of how complex this all is.
To summarize: We don’t yet have consensus on an alternate system, there are many strong motivations to keep the current system even despite its flaws, and we don’t know how bad the problem is – how many bogus certs have been created, by how many attackers, or how often they are used in real attacks. Imagine how much more confusing this would all be if the DigiNotar hacker had signed certificates in the names of many other certificate authorities.
Internally, long before the current hacks, our former intern proposed this as a research area. The consensus was “Yes, it’s a problem and we are &^(%) if a CA issues bad certs”. The problem was that neither he nor we had a solution to propose.
But I have an idea that could help us scope out the problem. I call it a ‘transitional’ proposal because it doesn’t solve the problem, but could help identify the issues and raise awareness. Call it an “Early Warning System for SSL” (I’d call it “IDS for SSL”, but you all would burn my house down). The canary in the SSL mine.
Conceptually we could build a browser feature or plugin that serves as a sensor. It would need a local list of known certificate signatures for major sites – perhaps derived from the Perspectives notaries or the Google Certificate Catalog. When it detected a mis-matched certificate it would report it up to the central registry, which could perform an analysis to detect bad certs. The registry would also tracks update origins in an attempt to detect traffic blocking. All this could be completely silent, or could be configured to alert, depending on user preference.
Some of the details:
- We create a central registry of the signing chains for SSL certificates for major sites that are likely to be targeted in an attack. Even a few hundred would be a great start, and we might be able to get a lot more from existing projects. And we would allow anyone to opt in by registering their own chain.
- When a browser is presented an SSL certificate (chain), it would check the offered chain against signatures from the registry.
- Browsers would report each mismatch to the registry. The user could choose to see an alert before accessing the site, but this is purely optional – the system would work fine with most users silently accepting unknown certificates. This would avoid bothering users with ‘noise’ as websites deploy new certificates, while still offering a opportunity to disable verified malicious certificates.
- The connection to the registry would be secured with a pre-shared key (PKI), but not using SSL.
- The registry tracks two things – reported mismatches, and the anonymous location of each report.
- If a suspicious certificate is reported, the registry can check with the nominal owner to determine whether it is merely a new legitimate certificate or actual fraud. This would take time and resources, although it could be automated somewhat.
- The registry will thus identify potential problems and publicly report them.
- The registry will also track request patterns, and can use these to help identify locations (ISPs or countries) which block connections to the registry.
- For users who opt in, loss of connectivity to the registry or mismatched certificate can generate visible alerts. But the primary goal is to protect the entire system – not just individual users who opt into the system.
Unlike other projects, our goal is to create a public warning system, which even benefits users who do not use it directly – although direct users would benefit from direct alerting and better browser safety. We don’t need eveyone to use the tool – just enough people. It isn’t perfect, but can get us started on scoping out the problem. It could be a plugin, an add-on to something like NoScript that’s fairly widely used (or even Convergence), or better yet even built into browsers – like Chrome’s DNS pinning, with an additional callback function.
The downside is that this will take resources. And identifying blackout areas (e.g., hostile ISPs or nations blocking the registry) relies on generating enough initial traffic to identify baseline traffic patterns.
But we could tremendously increase our ability to detect usage of fraudulent certificates. Right now, anyone who can hack a CA has an excellent chance of intercepting a great deal of traffic and not getting caught – the detection mechanisms are simply too exotic and rare.
It looks like we have many of the bits and pieces we need – especially since at least one browser developer is already building in related features. It would be absolutely awesome if any of the big browsers built this in. Or perhaps an independent registry and warning service that’s open to any browser, with plugins to implement it.
Posted at Wednesday 14th September 2011 3:22 pm
(5) Comments •
By David J. Meier
A few weeks ago a new TLS and SSLv3 renegotiation vulnerability was disclosed, and there’s been a fair bit of confusion around it. When the first reports of the bug hit the wire, my initial impression was that the exploit was too complex to be practical, but as more information comes to light I’m starting to think it’s worth paying attention to. Since every web browser and most other kinds of encrypted Internet connections – such as between mail servers – use TLS or SSLv3 to protect traffic, the potential scope for this is massive.
The problem is that TLS and SSLv3 allow renegotiation outside of an established TLS connection, creating a small window of opportunity for an attacker to sit in the middle and, at a particular phase of a connection, inject arbitrary data. The key bits are that the attacker must be in the middle, and there’s only a specific window for data injection. The encryption itself isn’t cracked, and the attacker can’t read the encrypted data, but the attacker now has a hole to inject something which could allow unanticipated actions, such as sending a command to a web application a user is connected to.
A lot of people are comparing this to Cross Site Request Forgery (CSRF), where a malicious website tricks the browser into doing something on a trusted site the user is logged into, like changing their password. This is a bit similar because we’re injecting something into a trusted connection, but the main differentiator is where the problem lies. CSRF happens way up at the application layer, and to hit it all we need to do is trick the user (or their browser) to get access. This new flaw is at a networking layer, so we have a lot less context or feedback.
For the TLS/SSL attack to work, the attacker has to be within the same local network (broadcast domain) as the victim, because the exploit is at the “transport” layer. This alone decreases the risk significantly right out of the gate.
Is this a viable exploit tactic? Absolutely, but within the bounds of a local network, and within the limits of what you can do with injection. This attack vector is most useful in situations where there is easy access to networks: unsecured WiFi and large network segments that aren’t protected from man in the middle (MITM) attacks. The more significant cause for concern is if you are running an Internet facing web application that is:
- Vulnerable to the TLS/SSL renegotiation vulnerability as described and either…
- Running a web app that doesn’t have any built in application layer protections (anti-CSRF, session state, etc.).
- Running a web app that allows users to store and retrieve things using simple POST requests (such as Twitter).
- Or using TLS/SSLv3 as transport security for something else, such as IMAP/SSL, POP/SSL, or SMTP/TLS…
In those cases, if an attacker can get on the same network as one of your users, they can inject data and potentially cause bad things to happen, possibly even redirecting your user to a new, malicious site. One recent example (since fixed) showed how an attacker could trick Twitter into posting the user’s account credentials.
Currently the draft of the fix binds a renegotiation handshake to a particular already established TLS channel, which closes the hole. Unfortunately, since SSLv3 does not support extensions there is no possible way for a secure renegotiation to happen; thus the death of SSL is nigh, and long live (a fixed) TLS.
–David J. Meier
Posted at Thursday 19th November 2009 2:22 am
(13) Comments •