[tor-talk] messing with XKeyScore

[isis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Eugen Leitl transcribed 5.8K bytes:
> 
> http://blog.erratasec.com/2014/07/jamming-xkeyscore_4.html?m=1 
> 
> 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 torproject.org" and in the email body include:
> 
> https://bridges.torproject.org/
> bridge = 0.0.0.1:443
> bridge = 0.0.0.2:443
> bridge = 0.0.0.3:443
> ...
> 
> 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
#12537: https://trac.torproject.org/projects/tor/ticket/12537


>
> 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.  https://xkcd.com/327/

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


> 
> Robert Graham 

- -- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
GPG: 4096R/A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt

-----BEGIN PGP SIGNATURE-----

iQMhBAEBCgELBQJTtx5XBYMB4TOAVhSAAAAAACUAKGlzaXMrc2lnbnN1YmtleUBw
YXR0ZXJuc2ludGhldm9pZC5uZXRGQzYzQUE1Q0QxOTM4NjlDMzIzNzE0NUE1QzE3
Nzc2RTI3RjdFODRESxSAAAAAABoAKGlzaXNAcGF0dGVybnNpbnRoZXZvaWQubmV0
MEE2QTU4QTE0QjU5NDZBQkRFMThFMjA3QTNBREI2N0EyQ0RCOEIzNS4aaHR0cHM6
Ly9ibG9nLnBhdHRlcm5zaW50aGV2b2lkLm5ldC9wb2xpY3kudHh0LJhodHRwczov
L2Jsb2cucGF0dGVybnNpbnRoZXZvaWQubmV0L2lzaXMudHh0AAoJEFwXd24n9+hN
fmQP/iEIfzuCqp4Tb4sfqP4mc4jQhH5bgxcrd9gWhbv14xgdNL6e46rvFATq9quW
satL1yyID4zlsdIW3cnmADWlO40eUdTSAKIoIUGAVBA9OCy6d1blqsZjl7mjfbaq
PMReaRhYoRP6cg+GBw75DK3Yk0MQ0roE2aXy8B8dwl0d0HdyxfJE5yYU0XGWrIE9
3VCRHie16+9lFrQEEF7Yb6h0and+SAAzNUZF1OL9Dxs+kwgDzusSGZDjDMNg+Uj6
RvLZxmWp9YvIDRttRCA9skc0nKYD6Nf9jIJzHLrh65RZH1ht2Ti/IQC0LVOb/I3F
9h2/LklrzQeK4wgIOu5W/OdmHeOCy2fWoDJXzWo4bEqHfIDmHU+pFGcN/dPOYYg8
hML4GuTvdtWVesjHtU5IbclbWAxhwqgfhSsO37mt9xb0KhoznJF2WBbC4V2dEkGH
M9K173nUDBl/yu1dX3DZMta9xWlZfMDhlEMTC9dR8cnDsmUU5hOKAgZ7px2fD44C
n1M8GNkw3NwhokLOgW+YoyUBh4wm5L9hTqUqt+22aj7BCjtgPrt/tWkntzX/+pI2
80PY08t18nX8qu80jrvaIh5B6S28n08duS2Hk4j432vB4DkwBF1drTByZXdq8zRj
ZTVIrn4OG865eSthXnKCXzZnUuB35niADviL6t7pWG9Vo+cB
=EcGi
-----END PGP SIGNATURE-----