A QUANTUM Thought: Advanced Targeting

Or: Hey DGSE, here’s a good one for you…

We’ve learned a bit more about the NSA’s QUANTUM program, their technique that turned the Internet backbone into a weapon. The agreement with Sweden to test QUANTUM attacks has formalized the terms somewhat: a “tip” is a redirection, while a successful “shot” is an exploitation. Out of 100 tips in their experimental deployment, this generated only 5 shots. Now either this experiment didn’t use a very good exploit, so only 5% of attempted victims were vulnerable, or tips represented just preliminary targeting, and only 5% of the possible victims were deemed worthy of attack.

It could easily have been the former: if the attack was simply using an old, known exploit, its quite conceivable that only a few would fall victim to the NSA’s shots. Yet what if its the latter? How could the NSA turn a “this might be someone worth exploiting” tip into a “we should exploit this person” shot? Enter mass-QUANTUMCOOKIE exploitation.

We already know that the NSA will use LinkedIn or Slashdot (or, really, any page which contains user identification in the clear) for QUANTUM targeting. A QUANTUM wiretap sees both requests and replies, but only can act on requests. So it sees user cookies in every web request, but it needs to know the user associated with the cookies to know when to attack.

Thus the process is a two-part affair, and works for any site which reveals the logged-in user over unencrypted HTML. The first request reveals the cookies, and the reply indicates the user: a LinkedIn page reveals the LinkedIn name and user ID, a Slashdot page reveals the Slashdot user, a Youtube page reveals the Google username and email address, battle.net reveals the user’s WoW account, etc… This enables the QUANTUM wiretap to associate cookies to users. When it sees a subsequent request from a target, it now knows to tip the victim over to be shot.

Yet this seems like a lot of waiting: there are undoubtedly tons of traffic that the NSA would categorize as “perhaps worth shooting”, but by waiting, they might miss the opportunity for exploitation. There is a solution, a target identification tip. How could this work?

  1. The QUANTUM wiretap sees a request from a “perhaps worth shooting” target. It takes a small, inconsequential fetch and injects a tip redirecting the victim to a user-identification script running on an NSA server.
  2. The victim’s browser fetches the user-identification script and starts executing it. This script opens up a series of hidden iframes, elements in the web browser that the user doesn’t see, which cause the browser to connect to a host of user identifying sites such as Youtube, LinkedIn, etc.
  3. Back at the QUANTUM wiretap, it sees all these requests, records the cookies, and waits for the replies. Thus for any logged-in site, the wiretap now is able to map cookies to username, allowing the QUANTUM wiretap to know who should be shot based on their cookies.
  4. Back on the victim’s browser, the user identification script waits for about 10 seconds, and then opens up a second set of hidden iframes to the sites. The browser now reconnects to all these sites, enabling the QUANTUM wiretap to execute its shots.
  5. Finally, the QUANTUM wiretap sees the second set of requests and, if they are from people in the “worth shooting” category, it executes a packet injection attack on one of these requests, tipping them over and letting them get shot.

We don’t know if the NSA uses this technique, but I’d be shocked if they didn’t. It enables them to turn “perhaps worth shooting” into “worth shooting” into “shot” with laser-guided precision, while leaving very little trace in the process. It also explains how 100 tips turned into just 5 shots.

Of course, the NSA isn’t the only institution able to use this technique. Any country can use it within their own borders, and since both political and economic targets are now in-scope, everyone traveling overseas needs to assume that, if the local intelligence agency wants to attack them by name, they will be a victim.

Yet foreign intelligence agencies can do even better. Want to target every Senator, every DC staffer, and every lobbyist by name? Do you have their Gmail addresses, LinkedIn profile, and/or Warcraft player names? Have a couple of “diplomats” you can afford to get kicked out of the country on the very remote chance your caught? If so, this one is for you. So the DGSE (the French version of the NSA) should listen up.

  1. Deploy a bunch of Raspberry Pi boxes with WiFi around Washington DC, in the local Starbucks, hidden in hotels, and anywhere else there is free WiFi. Have them join the open WiFi networks and start listening in.
  2. Program these Raspberry Pi boxes to do user-identification packet injection on any visitor which might be of interest.
  3. When the injector identifies a user, it queries the command and control server to see if the user is on the target list (hint, you too can use ghost servers for command and control).
  4. If the user is in-scope, the injector then tips the victim over to your own exploit server to be shot with the exploit and malcode of your choice.

Now you aren’t going to get onto any classified systems this way, but there is a ton of unclassified material that will make juicy reading. The appointment calendars and contact lists alone will be golden. Your total hardware cost is a few thousand dollars (about $50 per Starbucks), the odds of you being identified are slim, and even if you are caught, just repeat after me:

It wasn’t us. And even if it was, you started it. I believe your saying is ‘sauce for the goose’

Of course, once you have an infected computer, if it moves into a different network, it too can become a packet-injecting attacker, identifying and exploiting possible victims. Spread the love from Starbucks to the conference room.

And why limit the fun to major intelligence services? Small countries can contact their local Vupen and Gamma International sales representatives for details (yeah, it will cost more: Raspberry Pis are cheap, but malcode is expensive, but hey), while criminal gangs can do the same thing, either also using deployed boxes or leveraging an existing botnet.

The Internet is now a very dangerous place: all unencrypted traffic is a potential attack vector! The NSA, by their broad hacking, has painted a huge target on our backs. Targets that, for anyone who wants to, they can illuminate and attack.

Update 12/30/2013: A new slide deck possibly explains the inefficiency: the initial QUANTUM implementation was simply poorly designed! Rather than implementing the attack logic at the wiretaps, the wiretaps would forward information to remote TURBINE command-and-control servers, adding hundreds of crucial milliseconds.

This easily explains why 100 attempts would only result in 5 successful shots: if the test deployment in question used the old, not well designed QUANTUM architecture you’d expect such a failure rate.

As recently as June 2011, a better design (QFIRE), where the attack logic is colocated with the wiretaps, was only in development. Its unclear whether the improved system is even operational, let alone widely deployed.

Next Story — An Anatomy of A Nice Phish
Currently Reading - An Anatomy of A Nice Phish

An Anatomy of A Nice Phish

I fear we will never robustly stop phishing, as much because we seem to insist on training users to be phished. Even generic phishing has a tendency to work, and I just received a particularly nice one that is worth examining in detail.

First the bait:

Yes, this is a very generic and unremarkable phish. But at the same time, how many of this sort of email has one seen on a regular basis that is legitimate?

There is also some amusement in how the phish is actually implemented. The link is bit.ly (naturally), which redirects to a .php script on a (presumably hacked) real estate web site. But that link is interesting:

<html><head><META HTTP-EQUIV=”Refresh” CONTENT=”1;URL=https://dl.dropboxusercontent.com/s/pziendhh708cx0z/akomesh-000001-0000.html?dl=0"></head><p><p>

Yes, it loads the actual phishing page from dropbox! And instead of just rendering the page, this bit (conveniently hosted on Dropbox) hides itself by doing yet another meta refresh, so that the content is actualyl in the URL bar!

<meta http-equiv=”Refresh” content=”0; url= data:text/html;charset=utf-8;base64,PFNjcmlwdCBMYW5ndWFnZT0nSmF2YXNjcmlwdCc+DQo8IS0tIEhUTUwgRW5jcnlwdGlvbiBwcm92

And of course, the content itself is obsfuated Javascript, which does yet another document write and decodes to HTML. The resulting page also fetches another script, this time from https://googledrive.com/host/0B5MfJSZPi35ebDRYeHVEQ1JlTVk (which appears to be a standard Javascript form validator, you don’t want people putting in bogus answers to your phish), and then posts the results to Yet Another (presumably compromised server) which is a “powered by VESTA” landing page.

The phishing itself actually goes to a second part where it wants the phone number, before redirecting to dropbox itself.

Some overall thoughts

1: We’ve trained people to be phished. The bait email looks remarkably similar to what Dropbox sends to people for legitimate purposes, and a little bit of social graph mining and you too can make fake Dropbox emails that really look like the real thing.

2: Dropbox can get an idea of how successful this phish is, at least in terms of page views, since the phishers hosted the dropbox phish on dropbox!

3: Anti-spam techniques may be working (mostly) in terms of preventing “unauthorized” sending. It looks like this was through a compromised account rather than created from whole cloth.

4: So many layers of obfuscation! The phishing email itself was base-64 encoded rather than plaintext. The phishing page was URL shortened, redirected to a compromise site, redirected to dropbox, redirected to a “page” in the URL bar, which used document-write to deencode base-64 encoded Javascript into the page. Just about anything short of an actual browser will be unable to extract the semantics.

5: Did I mention how much we’ve trained users to be phished? Look at this legitimate email:

How is a typical user supposed to know this is legitimate? The last 4 digits of a credit card #? How long until a criminal service offers that data (if they haven’t already?) And this business about “Email security zone”? It’s not like DKIM validated…

Authentication-Results: maihub.ICSI.Berkeley.EDU (amavisd-new); dkim=softfail
 (fail, message has been altered) [email protected]
Authentication-Results: maihub.ICSI.Berkeley.EDU (amavisd-new);
 domainkeys=softfail (fail, message has been altered)
[email protected]

Yeup, that checks out…

Next Story — Why I believe the NSA broke DH…
Currently Reading - Why I believe the NSA broke DH…

Why I believe the NSA broke DH…

The “Weak Diffie-Hellman” paper is almost certainly correct in the implication that this is how the NSA is breaking a large amount of cryptography. Simply because the NSA’s architecture for IPsec, a popular VPN protocol, only makes sense if they are using large-scale cryptanalysis rather than just Applied Kleptography.

To decrypt IPsec, a large number of wiretaps monitor for IKE (Internet Key Exchange) handshakes, the protocol that sets up a new IPsec encrypted connection. The handshakes are forwarded to a decryption oracle, a black box system that performs the magic. While this happens, the wiretaps also record all traffic in the associated IPsec connections.

After a period of time, this oracle either returns the private keys or says “i give up”. If the oracle provides the keys, the wiretap decrypts all the stored traffic and continues to decrypt the connection going forward.

Applied Kleptography, simply stealing private keys, is undoubtedly a cornerstone of NSA cryptanalysis. Likewise there is a large amount of product sabotage. But absent a cryptanalysis breakthrough such as the one described by Adrian et al, the NSA’s architecture is overkill: it would be far easier to just forward the decryptable connections back to the central system if the oracle can decrypt the communication.

This would also better match the security implications: just the fact that the NSA can decrypt a particular flow is a critical secret. Forwarding a small number of potentially-crackable flows to a central point better matches what is needed to maintain such secrecy.

Thus by performing the decryption in bulk at the wiretaps, complete with hardware acceleration to keep up with the number of encrypted streams, this architecture directly implies that the NSA can break a massive amount of IPsec traffic, a degree of success which implies a cryptanalysis breakthrough.

Similarly, the focus on IPsec further suggests that Adrian et al’s analysis is correct, and their technique is being exploited by the NSA. IPsec is the only major encryption protocol that uses Diffie-Hellman in a commonly vulnerable form (1024b with prime number reuse) on a near-ubiquitous basis. TLS (the protocol that secures web traffic) can use DH for key exchanges, but this is hardly ever the default, and new configurations which do use DH by default generally use larger values or elliptic curve Diffie-Hellman, neither of which are vulnerable to this attack.

The other remarkable thing is that, for now, this is a near-NOBUS (NOBody But Us) capability of the NSA: actually building a dedicated supercomputer to do this is a massive task (today), and only a couple of adversaries might even try. This makes the capability to target IPsec in this manner nearly unique among the NSA revelations, most of the rest of their techniques are amenable to hobbiest implementation or make good homework assignments.

Unfortunately Moore’s law of processing per dollar shows no sign of slowing. What takes a $100M investment today takes only a $10M investment tomorrow and a $1M investment the day after. So what is NOBUS today is not NOBUS tomorrow, but equipment purchased today is still used tomorrow.

It is critical to move away from 1024b Diffie-Hellman, because devices fielded today will be in use for a decade, a decade which can see our adversaries use these techniques against us.

Next Story — Metadata and Madison
Currently Reading - Metadata and Madison

Metadata and Madison

Brian Krebs recently identified a significant party of interest in the Ashley-Madison case, “Thadeus Zu”, and located the associated Twitter account and FaceBook Profile (although the profile photos are bogus, as those are of model Rob Evans). Although there is no concrete evidence, there is significant circumstantial evidence in the deuszu Twitter feed (including the only posting of the hack source-code seen on twitter , an announcement of the data dump a day before Wired reported it, and a discussion of setting up replication servers just before the hack announcement, while playing Thunderstruck) suggesting this account’s involvement, almost certainly at the level of “probable cause” for getting warrants.

At this point, it may be a near-dead-end for public data, but law enforcement can take these profiles and obtain a significant amount of private information. Beyond simply obtaining a copy of the accounts themselves (including all direct messages), there are other items that law enforcement should ask for with the appropriate subpoena or search warrant, enough to create a detailed profile of Thadeus Zu.

Other identifiers: Both Twitter and Facebook may have other email address or phone numbers for Thadeus Zu on file, and the warrant should provide this information. In particular, either the Facebook or Twitter account may include a verified phone number. Both accounts are also rather old, so historical identifiers might also prove useful.

Historical login data: Thadeus Zu doesn’t appear to exclusively use the Tor browser, as seen in the many screenshots posted in his feed. Thus unless he was careful and always used a VPN, historical login data might find IP addresses he used to access both Twitter and Facebook.

The IP address and browser user-agent which posted each tweet: Many of the tweets themselves appear to be part of a conversation, but a conversation where there is no @-replies, making them seem disconnected. One possibility is that the account was used by multiple individuals. If this is the case, looking at the IPs for each tweet should disambiguate the conversation.

Historical friendship data: The other possibility for a conversation is a mutual-follower relationship. I checked the current follower graph to see if there was anyone he followed who also followed him, although I was unable to find a mutual conversation in the current graph. But this could simply be due to the relationship being no-longer current. Thus knowing who followed and unfollowed deuszu, and who he followed and unfollowed over time, may find another part of the conversation.

History from the Like and Tweet This Buttons: The Like button and related elements don’t just track a person when they click “like”, they also record the pageview even if the user does nothing. Thus a request for the IP address, time, browser user-agent, and referrer of every view of the Like or Tweet This button for Thadeus Zu will reconstruct a huge amount of his browsing history.

Chain to Google: But the analysis doesn’t need to stop with Facebook and Twitter. Start by examining the pageviews and select a representative set of unique pages which contain either DoubleClick advertisements or Google’s +1 button. Then submit a warrant to Google demanding the Google ID or “anonymous” tracking cookies also associated with those pageviews (identified by IP, time, user-agent, and referrer). Once these cookies are obtained, now demand the search history, email contents (if any), and page-view history for the newly identified Google accounts.

Cellphone Metadata: If the Twitter account included telephone verification, this provides a lead on Thadeus Zu’s cellphone. A subpoena or warrant for his call history (including tower location) provides a treasure trove of information.

Taken together, all this information should paint a fairly comprehensive picture of Thadeus Zu’s online activity, including what systems he uses (from both IP and user-agent), what pages he visits, what he searches for, and tons of other clues towards identifying the man behind Thadeus Zu.

Edited to ad: This is not to say that I actually like the idea that law enforcement can get this information. I find the amount of data collected by private companies overly and dangerously broad. And one of those dangers is that governments can demand this data.

Next Story — How To Destroy the Dark Web Markets
Currently Reading - How To Destroy the Dark Web Markets

How To Destroy the Dark Web Markets

At the recent Usenix Security, Kyle Soska and Nicolas Christian presented their detailed survey of the on-line drug markets that followed Silk Road. Among the interesting takeaways from their work is that the market is now generally stable in daily volume, market takedowns seem to have only a minor effect, a few major dealers dominate the sales, and that the markets process roughly $500,000 a day.

It is this last figure, the daily volume, that points the way to disrupting these markets. Although the markets operate in Bitcoin, almost all of the buyers and sellers operate using Actual Money™ such as dollars or euros. So for almost every dollar of product sold on these dark market, there is a corresponding dollar exchanged for Bitcoin and another dollar’s worth of Bitcoin converted back into currency. I believe this represents the Achilles heel in the dark markets: if law enforcement can disrupt this money flow, they will strangle the dark markets economically.

As any security researcher who works with Bitcoin will attest, its actually rather annoying to buy and sell Bitcoin without leaving a paper trail. There are sketchy overseas exchanges, but these are mostly persona-non-grata to US banks, while the notably sketchy coin.mx just got shut down by the Feds.

Which leaves what is probably the heart of the money flow: LocalBitcoins and other decentralized transactions. Disrupt the face to face and online Bitcoin exchanging and you disrupt the markets, since without the ability to convert Bitcoin it ceases to be a vehicle for crime. And fortunately or unfortunately (depending on your viewpoint), almost every seller of Bitcoin is breaking the law: operating an unlicensed money transmission business.

So to disrupt the markets, start disrupting the money in earnest. Start with an MLAT request to Finland to get all of LocalBitcoin’s data and go after every buyer and seller, starting with the high volume players. Also simply perform a bunch of purchases, and arrest the Bitcoin sellers. In short, treat Bitcoin dealing like it is: drug dealing.

Now treating drug dealers like, well, drug dealers doesn’t take out the drug market: the epic failure of the “war on drugs” attests to that. But are those who sell Bitcoin really as risk-tolerant as drug dealers? It certainly seems to me that the crowd responsible for supporting the economics of the dark markets aren’t the drug dealing type because, well, if they were, they’d deal directly and skip the middle man.

I’m not sure this would work, but disrupting the Bitcoin ecology which supports the dark markets may be the best lever possible.

Sign up to continue reading what matters most to you

Great stories deserve a great audience

Continue reading