New NSA Leak Shows MITM Attacks Against Major Internet Services

The Brazilian television show "Fantastico" exposed an NSA training presentation that discusses how the agency runs man-in-the-middle attacks on the Internet. The point of the story was that the NSA engages in economic espionage against Petrobras, the Brazilian giant oil company, but I'm more interested in the tactical details.
The video on the webpage is long, and includes what I assume is a dramatization of an NSA classroom, but a few screen shots are important. The pages from the training presentation describe how the NSA's MITM attack works:
However, in some cases GCHQ and the NSA appear to have taken a more aggressive and controversial route -- on at least one occasion bypassing the need to approach Google directly by performing a man-in-the-middle attack to impersonate Google security certificates. One document published by Fantastico, apparently taken from an NSA presentation that also contains some GCHQ slides, describes “how the attack was done” to apparently snoop on SSL traffic. The document illustrates with a diagram how one of the agencies appears to have hacked into a target’s Internet router and covertly redirected targeted Google traffic using a fake security certificate so it could intercept the information in unencrypted format.
Documents from GCHQ’s "network exploitation" unit show that it operates a program called "FLYING PIG" that was started up in response to an increasing use of SSL encryption by email providers like Yahoo, Google, and Hotmail. The FLYING PIG system appears to allow it to identify information related to use of the anonymity browser Tor (it has the option to query "Tor events") and also allows spies to collect information about specific SSL encryption certificates.
It's that first link -- also here -- that shows the MITM attack against Google and its users.
Another screenshot implies is that the 2011 DigiNotar hack was either the work of the NSA, or exploited by the NSA.
Here's another story on this.
Tags: Brazil, certificates, data breaches, e-mail, Google, lies, man-in-the-middle attacks, national security policy, NSA, privacy, surveillance, Tor
Posted on September 13, 2013 at 6:23 AM • 36 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
not connected to FacebookFacebook "Like"-Dummynot connected to Twitter"Tweet this"-Dummynot connected to Google+"Google+1"-Dummynot connected to LinkedIn"LinkedIn"-Dummynot connected to StumbleUpon"Stumble!"-DummySettings
Comments
Tyrranum i Liberati • September 13, 2013 6:40 AM
Exactly how does one trust someone we cannot see or meet with a service we rely on for security?
These MITM attacks seem to be the final solution for the NSA and I can't see any way around them with their current grip on the interlinks.
z • September 13, 2013 6:52 AM
Install the Perspectives browser add-on and then take a look at how many certs have been presented by Google over the last 30 days. There are a LOT of them.
Mike the goat • September 13, 2013 6:53 AM
Bruce,
I composed a similar response earlier but for some reason it didn't apply so I will retype.
What are your thoughts on hardware as a potential vector to facilitate eavesdropping? Example in point the SSL accelerator cards that many servers are using and the TPM modules that are making their way onto consumer motherboards.
I was made to defend my position on incinerating HDDs as a policy against data remanance the other day and I feel somewhat vindicated as we slowly find out about what the NSA has been up to. The customer argued it was wasteful and bad for the environment but I insisted.
Modern HDDs have a microcontroller inside that runs proprietary firmware that we - the admins - don't get a chance to audit. We also know that there is often additional capacity that is not exposed at a block layer ostensibly for remapping failing sectors but as we have seen sometimes the capacity made available is far different (eg some WD 1TB HDDs a few years back had the same physical parts as their 2TB and only had the firmware changed to simplify manufacturing). How do we know that 'interesting' content is not retained, even when erased. I can think of several OS and filesystem ways to do this, the clever way being using file carving algo to search for, say DOC or JPEG headers and stash them away. Or if you have lots of space to play with as in the case above you could merely make a delete operation remap. An algorithm could detect repeat overwrites (say by shredding tools) and preserve the mirrored copy. Obviously full disk encryption would defeat this so long as the key is secured off the media.
A more expected threat is SATA secure erase. We're told to trust it but how do we know for sure?! This is why we need open hardware and open firmware.
I suspect that the NSA has not broken RSA at least at sensibly large key sizes but that they are 'cheating it' through bad implementations. That said for those websites not using PFS what would stand in the way of picking a select few targets and putting all their resources into cracking (or stealing through human assets or remote exploits on the target host) just those?
The recent revelations about MITM attacks make sense but aren't as elegant as I would expect. I figured they were getting their traffic through a fiber tap and thus were limited to passive attacks but clearly I was wrong.
I think there needs to be a discussion on hardware as we now /know/ some of it has been subverted. Hardware crypto and RNGs are a good place to start. Remember the kerfuffle over RdRAND in Linux kernel?
Keep digging Bruce. Full disclosure is the only cure to this crisis.
Gervase Markham • September 13, 2013 7:03 AM
Sorry if I'm being dumb (although I don't understand Portuguese), but the slide demonstrating an MITM doesn't mention SSL at all. And the Flying Pig software screenshot seems to show it providing information about SSL connections, which is not the same thing as MITMing them. It's called an "SSL Knowledge Base".
Can someone connect the dots for me and show me where the released information shows that the NSA were MITMing _SSL_ connections to Google?
If that slide does show them doing that, and if it's a network-level rerouting, then if they want to remain undetected then they must be able to MITM all SSL traffic, regardless of client. That's a risky strategy now that Chrome has cert pinning with reporting - if the target uses Chrome, they will get busted. (Unless they've managed to get a fake cert from the same CA Google uses. I don't know whether Google pins to roots, or its own intermediates. Or unless Google has been enjoined to not reveal certain reported cert pinning violations.)
In other browsers it is, of course, technically possible to see the changed cert chain if you look. But perhaps they rely on no-one doing that.
If they were MITMing SSL, then then either the target clicked through warnings (unlikely) or they have subverted a widely trusted CA. (Again, if you want to be able to MITM all SSL traffic, you need a widely-trusted CA to avoid giving errors on some clients.) The $64,000 question is: which one?
z • September 13, 2013 7:14 AM
@Gervase Markham
Law enforcement has had the ability to use their own valid certs signed by real CAs for some time now. I have no doubt that the NSA can as well.
Aaron W • September 13, 2013 7:23 AM
Google rolled out forward secrecy to its SSL connections in late 2011. In theory, that made MITM attacks impossible, even if the NSA had a forged certificate, yes? Or just much, much harder?
So did Google roll out forward secrecy when it realized the NSA/GCHQ was using MITM attacks against its users? Or is this a MITM attack that's effective even against forward secrecy? Or is it a MITM attack against plain old HTTP, which would be much less of a concern?
Marian • September 13, 2013 7:34 AM
@Aaron W
> Google rolled out forward secrecy to its SSL connections in late 2011. In theory, that made MITM attacks impossible, even if the NSA had a forged certificate, yes? Or just much, much harder?
Forward secrecy (achieved in SSL by using DHE and ECDHE suites) makes impossible to recover past (or future) particular sessions when long-term keys are compromised. It does not protect against MITM, which is possible when authentication is not done correctly.
DNS666 • September 13, 2013 7:36 AM
@Gervase Markham
What would be the point of executing an *active* attack (MITM) and risking exposure against non-SSL traffic?! One would just listen in on the unencrypted traffic passively (as NSA et al. are now known to do extensively), no MITM shenanigans necessary.
Nicholas Weaver • September 13, 2013 7:37 AM
The journalists need to start searching for DigiNotar in their document set in more details. It would explain alot about the DigiNotar hack if either the NSA was involved or the NSA stole the fake certs from whoever did it.
Mike the goat • September 13, 2013 7:48 AM
I would also imagine they would need a diverse allocation of IP space (and preferably use tunnels to different locations rather than have all the routes go to one AS and make it look dodgy if scrutinized) as having a few blocks repeatedly connect to a target's web servers would look very strange indeed. Of course they could be using this attack in a very targeted way and not routing everyone through it which would be a lot more subtle.
The commenter who spoke of the Perspectives project makes an interesting point. The notary servers on perspectives may contain the smoking gun(s)
tor • September 13, 2013 7:49 AM
Quick Ant QFD Tor events. I assume qfd doesn't mean what it does in the civillian world. Maybe that is their Tor exit node tracker, or possibly servers they deploy with one click to run a tor MITM attack when victims try to download Tor Browser Bundle, they get the NSA version instead
Nicholas Weaver • September 13, 2013 7:53 AM
Some background for those unfamiliar:
Non-encrypted traffic doesn't need MITM to capture, so the MITM diagram only applies to SSL.
The DigiNotar hack was discovered when the Google certificate was used to MITM all traffic going to Google from Iran (it tripped the newly installed Chrome certificate pinning IIRC).
The fake certificates from DigiNotar match the NSA's interest list, including Google, the Tor Project, Wordpress, and others.
Nicholas Weaver • September 13, 2013 7:55 AM
A MITM attack doesn't have to change the IPs seen by the server.
Mike the goat • September 13, 2013 8:06 AM
Nicholas: no, I mean detected by server logs.
Jenny Juno • September 13, 2013 8:09 AM
"take a look at how many certs have been presented by Google over the last 30 days. There are a LOT of them."
I use the Cert Patrol add-on for firefox and over the last month it seems like every single time I go to google I get a different certificate for them. Frequently they are from different authorities.
Has there been a discussion of this anywhere? I'd really like to see an informed analysis (versus my own paranoid speculation) of what the hell is going on.
Mike the goat • September 13, 2013 8:13 AM
@tor: it certainly brings the revelations from the tor project of some ideas being decloaked by visiting any sites hosted by Freedom Hosting (which were mostly illegal stuff but also some services like tormail) into a new light. From what I remembered the guy went down for some charges and the FBI or whatever alphabet soup agency involved took over his servers and put a nice bit of Java which made a CONNECT to an IP in Maryland using some shellcode. Obviously this would go through the standard windows TCP stack and bypass tor unless they were running a VM or the routing onto tor was done upstream (say, on an OpenWRT router)
Mike the goat • September 13, 2013 8:22 AM
@Jenny - prior to their transition to 2048 certs starting Aug 1 all Google certs /should/ have been signed by the Equifax issued Google root cert. This sounds very dodgy.
Wes the Mod • September 13, 2013 8:25 AM
Funny thing about Bresnan up here in Montana, they were doing this for at least 4 years via DNS for Google as well as other sites. Due to their lack of ability to set up a fully functional network in Butte none of this seemed to matter. There were certificate mismatches, the web server would run out of connections on it's connection pool... This whole idea of hijacking traffic via routing seems a bit excessive when you can proxy the traffic and only a few people notice.
Needless to say the solution in this case was just to change your DNS servers to public ones. For a more global solution there are always the root hint servers at which point you only have to get the cooperation of one group of people.
Marcio Lima • September 13, 2013 8:41 AM
I am Brazilian and the NSA slide indeed mentions SSL MITM attack. Although it is not clear whether NSA had actually attacked the Petrobras's private network or it was just an exercise. It is being a little passionate the discussion here in Brazil. In a previous program, Fatastico showed some NSA documents that implied that the US Government has succeeded to trace the President Dilma Roussef's mobile calls to her secretaries, ministers and even relatives. The President had talked to Obama in the G20 meeting and maybe she is going to call off a visit to US because yesterday the talks between Susan Rice and Brazil's Minister of Foreign Affairs in White House was not considered productive. Many brazilians are outrageous about this matter since this is not an expected behavior from a nation that has been a long history of fiorendship including fighting together in the two World Wars.
Mike the goat • September 13, 2013 8:43 AM
@Wes - agreed. I previously worked as Chief NOC engineer for a medium sized ISP. We received warrants for subscriber information so regularly that it made me despair! I remember we were required to support Cisco's lawful interception technology at OUR cost by a certain date. As a consequence of all our network equipment being x86 running FreeBSD this caused us some problems. Even our DSL tails were terminated by a few Linux boxes running l2tpns. As a consequence of this any 'targets' had to specifically be routed through a 7xxx series Cisco which provided them with the proprietary solution they so desired (I am certain LI has been standardized now). In an act of disobedience I setup packetfilter to slightly delay those routed to the capture router so that the net result was an additional 4ms on latency and a change in TTL. I told a few of my more paranoid enterprise customers that we were legally obliged to say nothing but told them to take notice of their ping times. Funnily enough you'd also see in a traceroute the reverse DNS name was revealing enough ;-)
We also stopped transparently caching with squid as when we were doing just that we were required to maintain logs. Note that this took place outside of the US but in one of the countries mentioned in the "five eyes" in the late 90s early 2000s.
I often wondered as to why they even bothered with LI as it was common knowledge that our country's surveillance organization occupied an entire floor of the data center in which we had colocation. I guess anyone who has been in a largeish data center will know the level of access control is just far too excessive if they were merely protecting customer's racks. We were escorted to our floor and couldn't even exit the floor via the elevator without picking up the security phone and asking them. I often worried about fire code compliance. The only obvious safety equipment was a 'escape closet' which they installed on each floor when they transitioned from halon fire suppression to CO2 (asphixiating in a chilled data center isn't my idea of a nice place to die).
Anyway my point is this stuff has been going on for years. It needs to stop now.
bob • September 13, 2013 9:11 AM
It would be nice to be able to grab a server's signature via existing secure connections. If I've already visited local government sites, facebook and the bbc when I visit momandpopstore.com I could ask all the sites to verify the connection. Any MITM attack would have to be prolonged but still specific to avoid detection.
Adam • September 13, 2013 9:14 AM
It would go a long way to defeat this kind of attack if certs could be signed by more than one signatory and not just CAs but business partners, business bureaus, governments etc. to build a web of trust.
And if browsers were far more proactive in validating discrepancies between certs and actively cached them so that it could validate they didn't suddenly change for no apparent reason.
Gervase Markham • September 13, 2013 9:17 AM
z: citation needed. (If Mozilla discovers any trusted CA has been providing certs for MITM purposes, we will un-trust them.)
Marcio: thanks for the confirmation. I wonder if the NSA still think this sort of attack is safe to run, now that pinning is a reality.
Re: DigiNotar, the NSA would need to have serious control over the Iranian internet infrastructure in order to mount an attack with the pattern that was seen. Watch this video, which geolocates the source IPs of OCSP pings, which are indicative of certificate use. Whoever conducted the Iran attack was able to control the routing of a great deal of Internet traffic from inside Iran, but not outside. (Or they chose not to.) I'm not saying it's impossible, but the Iranian government seem like a much more likely culprit.
That's not to say that the NSA couldn't have re-stolen the certs from the hacker, or from the Iranians, or have _also_ broken into Diginotar themselves and used the certs they took in much more targetted attacks. (Only a tiny number of the stolen certs were ever detected in the wild.)
Winter • September 13, 2013 9:23 AM
Diginotar was the certificate notary of the Dutch government. The hack caused quite a lot of damages in the Netherlands.
If the hack of Diginotar really was perpetrated by our friends from the USA, we (the Dutch) sure do need no enemies anymore.
In other words, the NSA has waged cyber war against their allies.
Stanislav Datskovskiy • September 13, 2013 9:42 AM
At this point, if you still trust in the very idea of PKI, or rely on security software you haven't personally understood the source code of, you're a chump.
Mike the goat • September 13, 2013 9:51 AM
@Marcio - re cell phones. I imagine any kind of conference where large numbers of people are in a single area could be owned by just running your own BTS and doing a MITM attack that way. GSM was never a protocol that was particularly security oriented. I remember a Black Hat presentation a few years back where a guy whose name I cannot remember showed how he was able to quite accurately geolocate someone by combining HLR data (which should be confined to trusted telcos but is exposed by several companies to query online) with a vulnerability I believe in SS7 which gave relative signal strength on more than one tower allowing rudimentary geolocation. Hell, even HLR data is bad enough. I think the US gov't would be crazy not to use that data. It would be easy to target too - sniff traffic while people are in the airport and you have a list of IMSI's to query in 24 hours or so when you know they'll be at their destination. Keep watching and you will easily detect if you have been into any geographical area they deem interesting enough to screen you when you return.
@Gervase - I think the fundamental problem is with the centralized trust we put in the CAs. Clearly given all of the stuff ups (ignoring the NSA scandal) indicates this trust is misplaced. A PGP like trust model would be more cumbersome but more resilient. When DNSSEC becomes a widespread reality (and if we can trust the roots, which is another post in itself) perhaps the fingerprint can be put in a TXT record. That at least increases the number of organizations they need to subvert.
@Bob - even if browser's were to implement an openssh style known_hosts style fingerprint cache at least we would get a warning when a cert changes.
MatthijsK • September 13, 2013 9:54 AM
About Schneier's suggestion regarding DigiNotar: I fail to see how the contents of that slide in any way warrant the claim that it implies that the NSA was involved in, or exploited the consequence of, the compromise of DigiNotar. The screenshots show a *mention* of DigiNotar in a slide that . Am I missing something?
(Note: I am not claiming that NSA was NOT involved in, or exploited the consequence of, the compromise of DigiNotar.)
Winter • September 13, 2013 10:09 AM
"I use the Cert Patrol add-on for firefox and over the last month it seems like every single time I go to google I get a different certificate for them. Frequently they are from different authorities"
I get the same from the Netherlands. It has been this way for years. But only for Google.
Sami Lehtinen • September 13, 2013 10:19 AM
Ahem, Yahoo nor Hotmail / Outlook does encrypt email, those use plain SMTP without STARTSSL. To protect email properly you need to use STARTSSL, with authenticated certificate fingerprint.
Jacob • September 13, 2013 10:52 AM
Re DigiNotar
I seriously doubt that this was a NSA work. At the time of the breach, there was an active "discussion" by the hacker who claimed to did it (can't recall the site). He identified himself as a self-taught hacker expert from Iran, boasting that he could do wonders in penetrating servers, and that he decided as a nationalist Iranian to help the Iranian gov in its fight against internal political subversion by letting them use fake certs as MITM against the "enemies of the state". He also vaguely explained how he hacked DigiNotar.
From the language, the content, the psyche, it was not NSA.
Re Pespectives add-on to Firefox:
How fool-proof is this? this add-on lets you see if your browser see a different cert from what other clients (about 10), running on a known list of geo-distributed servers, see.
If Eve targets you and presents you with a fake cert, what will stop her from also feeding you fake acknowledgements from those geo-distributed clients?
Douglas Knight • September 13, 2013 11:00 AM
Is there a centralized repository of leaked slides?
JeffH • September 13, 2013 11:10 AM
@Stanislav Datskovskiy "At this point, if you still ... rely on security software you haven't personally understood the source code of, you're a chump."
This sort of crazy talk is why Stallman is considered a fringe nut despite his message being a sensible one. If you can't come up with sensible suggestions on how to fix problems, there's little value associated with the underlying message.
merp • September 13, 2013 11:16 AM
Understanding the source is pointless unless you build it yourself, since there's no guarantee the source for the binary you downloaded wasn't backdoored. Now we have to do deterministic building to make sure even the compiler isn't adding hidden backdoors or malware since the NSA could be intercepting your repository traffic if you are a security software engineer and they want access to your encrypted VoIP app or tor browser
Stanislav Datskovskiy • September 13, 2013 11:25 AM
JeffH: 'don't shoot the messenger.' Stallman, old dervish though he may be, turned out to be right about virtually everything.
And it is perfectly feasible to rely on properly-implemented security software that you understood (or wrote) yourself. A one-time pad engine can be a 20 line Perl script (assuming you have access to a good TRNG.) Granted, you're stuck using this strictly between your own systems, and it isn't as convenient as public-key. Such is life. Life never was easy for people who want genuine security, rather than a placebo like SSL.
Don't hate the 'conspiracy nuts' who tell you that mainstream crypto was doctored, just because there is no easy answer to the problem. We've been saying it for years, and nobody listened.