Login  |  Register  |  Contact


Sunday, February 10, 2013

TidBITS: Isolate Flash Using Google Chrome

By Rich

My latest TidBITS piece on Mac security:

Under normal circumstances, we recommend updating immediately whenever an important security patch is released, but in this case, we have a somewhat different recommendation. Instead of leaving Flash on your Mac, you can instead isolate it and thus reduce the attack surface available to the bad guys. This is both easier and require far less fuss going forward than you might think, and it is how I’ve been using my Mac for the past year or so.

This may not work for those of you in enterprise environments (my TidBITS writing is all for consumers), but you should consider it. The technique should work on Windows, not just Macs.

Some people also like ClickToPlugin, which blocks all plugins on a page until you click to enable them. I deliberately left this out of the TidBITS piece because it is more advanced users.

Then again, if you are in enterprise security I suggest you take a hard look at Bromium, Invincea, or any competitors who crop up. They can give fairly good results without interfering with user experience at all.


Friday, February 08, 2013

Flash actively exploited on Windows and Mac; how to contain, not just patch

By Rich

Adobe just released a Flash update due to active exploitation on both Macs (yes, Macs) and Windows:

Adobe is also aware of reports that CVE-2013-0634 is being exploited in the wild in attacks delivered via malicious Flash (SWF) content hosted on websites that target Flash Player in Firefox or Safari on the Macintosh platform, as well as attacks designed to trick Windows users into opening a Microsoft Word document delivered as an email attachment which contains malicious Flash (SWF) content.

Instead of patching, do the following:

  1. Uninstall Flash from your computer (WIndows, Mac).
  2. Download Google Chrome.
  3. Profit!

Use Chrome’s internal Flash sandbox, so you can uninstall Flash at the OS level. Not perfect, but much better than using Flash through other browsers and having it available on your system for things like those nasty embedded Word attachments.


Thursday, January 03, 2013

SSLpocalypse, part XXII

By Rich

For the short version, read Rob Graham at Errata Security.

Google detected someone attempting a man in the middle attack using a certificate issued in Turkey. TURKTRUST issued two subsidiary Certificate Authority certs which allowed whoever had them to sign any certificate they wanted, for any domain they wanted. Yes, this is how SSL works and it’s a big mess (I talked about it a little in 2011).

Google likely detected this using DNS Pinning. Every version of Chrome checks any Google certificate against a list of legitimate Google certificates, which they build into Chrome itself. If there’s a mismatch, Chrome detects and can report it.

Nice, eh? That’s why Rob says don’t mess with Google. You try to MitM any of their domains, and if any users run Chrome they are likely to find out. Everyone else (who can) should do this.


Tuesday, September 18, 2012

It’s Time for Enterprises to Support a “Backup” Browser

By Rich

In today’s news we see yet another zero-day Internet Explorer exploit being used in the wild.

And once again, soon after becoming public, an exploit was added to Metasploit. Well, sort of. While the in-the-wild attack only works against Windows XP, the Metasploit version works against Windows 7 and Vista. (Note that IE 10 isn’t affected).

You can read the article linked above for the details, but this gets to something I have been recommending privately for a while: support 2 browsers, even if one is only for emergencies.

First of all, ideally you’ll be on a modern operating system. I’m not one to blame the victim, but allowing XP is a real problem – which I know many of you fight every day. Second, this advice doesn’t help with all browser-based attacks, especially Java. But you can configure it in a way that helps.

  • Choose a secondary browser that is allowed for web browsing. Chrome is most secure right now, but make sure you set its privacy defaults to not bleed info out to Google.
  • Ideally block Java in the browser. Maybe even Flash, depending on how you feel about the Chrome sandbox.
  • If something like this IE flaw hits, notify users to use the secondary browser for outside websites (odds are you need IE for internal web apps programmed by idiots or 19th-century transplants, and so cannot ban it completely).
  • If you can, set a network policy that (temporarily) blocks IE from accessing external sites (again, you can make exemptions for partners). Unfortunately I don’t believe many tools support this.

I know this advice isn’t perfect. And there are tools like Invincea and (soon) Bromium that can likely stop this stuff cold in the browser – as well as a few network tools, although history shows signature-based defenses aren’t all that effective here. But if you can pull it off you aren’t stuck waiting for a patch or another workaround. Especially if you go with the “block Java / isolate or block Flash” option. This approach allows you to still only support one browser for your applications, and use a secondary one when needed without users having to violate policy to install it themselves.


Wednesday, September 14, 2011

Building an SSL Early Warning System

By Rich

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. 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.
  2. When a browser is presented an SSL certificate (chain), it would check the offered chain against signatures from the registry.
  3. 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.
  4. The connection to the registry would be secured with a pre-shared key (PKI), but not using SSL.
  5. The registry tracks two things – reported mismatches, and the anonymous location of each report.
  6. 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.
  7. The registry will thus identify potential problems and publicly report them.
  8. The registry will also track request patterns, and can use these to help identify locations (ISPs or countries) which block connections to the registry.
  9. 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.