[perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED!

[Nicholas Weaver <[e-mail]>]

Cookies and user tracking are wonderful things.  If you are a intelligence service, that is.

Its now clear that the NSA (and, remember, any other intelligence service that might see such traffic can do the same thing) uses cookies/advertising for both tracking (e.g. HAPPYFOOT: Advertisement libraries (esp on Android) which broadcast location + IMEI in the clear -> easy user tracking) and targeting (e.g. Know the victim's google PREFID cookie through other means, then use it to target exploitation: 

http://apps.washingtonpost.com/g/page/national/nsa-signal-surveillance-success-stories/647/#document/p3/a135602

http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/
)

Everyone on this list should now consider themselves an in-scope target from at least one foreign intelligence service...


But the intelligence services can do even better if they want.  Here's how:

The NSA or foreign intelligence wiretap has a possible candidate for attack, but not probable.  That is, they THINK they may want to do an exploitation attack but aren't sure...


1)  On the packet-injecting wiretap, it sees a possible candidate and it does a packet injection of a 302 redirect to a "User ID" script on the exploit server for something inconsequentially small.


2)  The user-ID script creates a hidden iframe.

Within that iframe, it opens up a bunch of other iframes to various sites, e.g.www.youtube.com,www.linkedin.com, www.yahoo.com, slashdot.org, etc.  Namely ANLY (and well, all) sites which

a)  Identifies the user in the response

b)  Uses a user-identifying cookie that can be sent in the clear.

This causes the possible victim's browser to visit all these sites, identifying the victim to any wiretap that can see it.


3)  Back on the packet-injecting wiretap, it looks for request/response pairs to the targeted sites, using the request to extract the user ID cookies and the response to match the user identification by quick & dirty parsing of the HTML in the response.

Since the wiretap knows the user identifications it wants to exploit, it now knows the user ID cookies it wants to exploit as well.


4)  Back on the user-ID script, after a ~10 second delay, it then creates a second set of iframes to the various sites for different URLs.  This causes the possible victim's browser to revisit all the sites.  These requests contain the user's ID cookies, which any wiretap has now been able to map to "is this the actual person I want to target"


5)  The packet injecting wiretap, now that it knows the user ID cookies it might want to target, packet injects an exploit against any desired user ID cookie...


This enables the packet injection/exploitation system to leverage all known user-identifying sites in the clear to target their exploitation with high precision, even when the potential victim doesn't attempt to visit the user identifying sites in the clear.



The requirements for ANY intelligence service to do this to target YOU are:

a)  They must see ONE web request from you in the clear pass ONE of their wiretaps when they consider you "just might be a possible target"

b)  They must see ONE of the user-identifying web requests pass ONE of their wiretaps, and you must be logged into that site.


As you can imagine, the set of possible actors able to do this actually ends up being pretty darn big...

The IETF needs to work for HTTPS-only, NOW, out of simple self defense.


--
Nicholas Weaver                  it is a tale, told by an idiot,
[e-mail]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc