You will know this has worked when a wall of the NSA’s Utah Data Center bulges and bursts spilling bits and bytes all over the desert.
On Jul 4, 2014, at 9:56 AM, Eugen Leitl <[email protected]> wrote: > > 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. > > > 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. > > > You can also jam the system with too many Onion addresses (xks-0003), but > there are additional ways to screw with those. When looking for Onion > addresses, the code uses a regex that contains the following capture clause: > > ([a-z]+):\/\/) > > This is looking for a string like "http://"; or "https://";, but the regex has > no upper bounds (xks-0004) and there is no validation. Thus, you can include > "goscrewyourself://o987asgia7gsdfoi.onion:443/" in network traffic, and it'll > happily insert this into the database. But remember that "no upper bounds" > means just that: the prefix can be kilobytes long, megabytes long, or even > gigabytes long. You can open a TCP connection to a system you feel the NSA is > monitoring, send 5 gigabytes of lower-case letters, followed by the rest of > the Onion address, and see what happens. I mean, there is some practical > upper bound somewhere in the system,, and when you hit it, there's a good > chance bad things will happen. > > Likewise, the port number for Onion address is captured by the regex (d+), > meaning any number of digits (xks-0005). Thus, we could get numbers that > overflow 16-bits, 32-bits, 64-bits, or 982745987-bits. Very long strings of > digits (megabytes) at this point might cause bad things to happen within the > system. > > There is an extra-special thing that happens when the schema part of the > Onion address is exactly 16-bytes long (xks-0006). This will cause the > address and the scheme to reverse themselves when inserted into the database. > Thus, we can insert digits into the scheme field. This might foul up later > code that assumes schemes only contain letters, because only letters match in > the regex. > > > In some protocol fields, the regexes appear to be partial matches. The system > appears to match on HTTP servers with "mixminion" anywhere in the name. Thus, > we start causing lots of traffic to go to our domains, such as > "mixminion.robertgraham.com", that will cause their servers to fill up with > long term storage of sessions they don't care about (xks-0007) > > > Let's talk X.509, and the following code: > > fingerprint('anonymizer/tor/bridge/tls') = > ssl_x509_subject('bridges.torproject.org') or > ssl_dns_name('bridges.torproject.org'); > > Code that parses X.509 certificates is known to be flaky as all get out. The > simplest thing to do is find a data center you feel the NSA can monitor, and > then setup a hostile server that can do generic fuzzing of X.509 > certificates, trying to crash them. > > It's likely that whatever code is parsing X.509 certificates is not > validating them. Thus, anybody can put certificates on their servers claiming > to be 'bridges.torproject.org' (xks-0008). It's likely that the NSA is > parsing SSL on all ports, so just pick a random port on your server not being > used for anything else, create a self-signed CERT claiming to be > "bridges.torproject.org', then create incoming links to that port from other > places so at least search-engines will follow that link and generate traffic. > This will cause the NSA database of bridges to fill up with bad information > -- assuming it's not already full from people screwing with the emails as > noted above :). > > > <img src="http://www.google.com/?q=tails+usb"; /> > > Putting the above code in a web page like this one will cause every visitor > to trigger a search for TAILS in the XKeyScore rules. The more people who do > this, the less useful it becomes to the NSA (xks-0009) in labeling people as > suspicious. Likewise, putting <title>tails.boum.org/<.title> in your webpages > will cause the same effect, even when CSS/JavaScript makes such a title > invisible. > > > In theory, the NSA should only be monitoring foreign traffic, and not traffic > originating from the United States (or, apparently, the other five-eyes). So > here is the fun thing (xks-0010): run your jamming tools from United States > IP addresses against those servers in Iran you know the NSA is monitoring. > Since the code should already be ignoring the traffic because it originates > from the United States, then they can't complain if you've filled up their > databases full of Tor Onion and bridge addresses. > > Robert Graham -- 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].
