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

Robin Wilton <wilton@isoc.org> Sat, 14 December 2013 19:25 UTC

Return-Path: <wilton@isoc.org>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1718E1ADFF7 for <perpass@ietfa.amsl.com>; Sat, 14 Dec 2013 11:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG6CLWNAEK9T for <perpass@ietfa.amsl.com>; Sat, 14 Dec 2013 11:24:53 -0800 (PST)
Received: from smtp94.iad3a.emailsrvr.com (smtp94.iad3a.emailsrvr.com [173.203.187.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABF51AE142 for <perpass@ietf.org>; Sat, 14 Dec 2013 11:24:53 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DC5D81E0178; Sat, 14 Dec 2013 14:24:46 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 456D41E017A; Sat, 14 Dec 2013 14:24:46 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B584DE1B-C7FD-46C0-9135-4BF295BAE7EE"
From: Robin Wilton <wilton@isoc.org>
In-Reply-To: <7D801592-36E4-4C5E-8AC9-B8940A72CC8B@isoc.org>
Date: Wed, 11 Dec 2013 19:14:45 +0100
Message-Id: <61B1D772-CAFF-46A0-8295-CD54C8790C4C@isoc.org>
References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> <7D801592-36E4-4C5E-8AC9-B8940A72CC8B@isoc.org>
To: Nicholas Weaver <nweaver@icsi.berkeley.edu>
X-Mailer: Apple Mail (2.1283)
Cc: perpass <perpass@ietf.org>
Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED!
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Dec 2013 19:25:01 -0000

And this time *with* the link... I hate it when I do that.

http://webpolicy.org/2013/12/09/metaphone-the-nsa-three-hop/

Robin

On 11 Dec 2013, at 17:23, Robin Wilton wrote:

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