Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] [tor-talk] messing with XKeyScore

isis isis at
Fri Jul 4 14:36:23 PDT 2014

Hash: SHA512

Eugen Leitl transcribed 5.8K bytes:
> Errata Security
> Advanced persistent cybersecurity
> Friday, July 04, 2014
> Jamming XKeyScore
> Back in the day there was talk about "jamming echelon" by adding keywords to email that the echelon system was supposedly looking for. We can do the same thing for XKeyScore: jam the system with more information than it can handle. (I enumerate the bugs I find in the code as "xks-00xx").
> For example, when sending emails, just send from the address "bridges at" and in the email body include:
> bridge =
> bridge =
> bridge =
> ...
> Continue this for megabytes worth of bridges (xks-0001), and it'll totally mess up XKeyScore. It has no defense against getting flooded with information like this, as far as I can see.

Hi. I maintain and develop BridgeDB.

For what it's worth, the released XKS rules would not have worked against
BridgeDB for over a year now. I have no knowledge of what regexes are
currently in use in XKS deployments, nor if the apparent typos are errors in
the original documents, or rather typos in one of the various levels of
transcriptions which may have occurred in the editing process. If these typos
were at some point in the original rules running on XKS systems, then *no*
bridges would have been harvested due to various faults. None.

Ergo, as Jacob has pointed out to me, the regexes which are released should be
assumed to be several years out of date, and also shouldn't be assumed to be
representative of the entire ruleset of any deployed XKS system.

I am willing to implement tricks against specific problems with them, mostly
for the lulz, because fuck the NSA. But it should be assumed that the actual
regexes have perhaps been updated, and that highly specific tricks are not
likely to land.

The ticket for this, by the way, was created by Andrea this afternoon, it's

> Note that the regex only cares about 1 to 3 digit numbers, that means the following will be accepted by the system (xks-0002):
> bridge = 75.748.86.91:80
> The port number matches on 2 to 4 digits ([0-9]{2,4}). Therefore, bridges with port numbers below 10 and above 9999 will be safe. I don't know if this code reflect a limitation in Tor, or but assuming high/low ports are possible, this can be used to evade detection (xks-0011).
> Strangely, when the port number is parsed, it'll capture the first non-digit character after the port number (xks-0012). This is normally whitespace, but we could generate an email with 256 entries, trying every possible character. A character like < or ' might cause various problems in rendering on an HTML page or generating SQL queries.

Interesting. I'm glad someone else is paying that close of attention to these
regexes. I'd totally take a patch which implements the BridgeDB equivalent of
little Bobby'); DROP TABLE Students.

Granted, as I said above, it likely won't land. But for the lulz. :)

> Robert Graham 

- -- 
 ♥Ⓐ isis agora lovecruft
GPG: 4096R/A3ADB67A2CDB8B35
Current Keys:



More information about the liberationtech mailing list