Thanks Nicholas - this is useful and relevant analysis.

In case you haven't already seen it, this piece about some new research (at 
Stanford... sorry ;^)  ) gives a similarly worrying perspective on the role of 
"hub" sites in expanding the scope of the "three hops" rule. Your Step 2 is, I 
think, a very similar mechanism, and has significant privacy impact.

Yrs.,
Robin

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email protected]
Phone: +44 705 005 2931
Twitter: @futureidentity




On 11 Dec 2013, at 16:43, Nicholas Weaver wrote:

> 
> 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,
> [email protected]                full of sound and fury,
> 510-666-2903                                 .signifying nothing
> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
> 
> _______________________________________________
> perpass mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to