-----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 > "[email protected]" 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----- -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
