How to detect TrueCrypt blobs being passed around

So, challenge accepted:

@ErrataRob you’re up for writing the blog post “detecting TrueCrypt/encrypt blob transfers” on the wire…

— the grugq (@thegrugq) March 29, 2016

tl;dr: The NSA should be able to go back through it's rolling 90 day backlog of Internet metadata and find all other terrorist cells using this method.

From what we can piece together from the NYTimes article, it appears that ISIS is passing around TrueCrypt container files as a way of messaging. This is really weird. It has the has the property of security through obscurity, which is that it has the nice property of evading detection for a while because we'd never consider that ISIS would do such a strange thing. But it has the bad property that once discovered, it now becomes easier to track. With the keys found on the USB drive, we can now start decrypting things that were a mystery before.

We are going off of very little information at the moment, but let's imagine some fictional things.

First, we need to figure out what is meant by a file or hosting site in Turkey. Such hosting sites are all over the place, as you can find with a little googling. Their primary purpose is to exchange copyrighted material (movies, music, games, ebooks) and porn. They are also a convenient way to host viruses that I'll trick you to load in phishing emails.

Half of these appear to use SSL during file transfers. In such cases, there's not much we can do in order to detect this particular transfer on the wire. However, we aren't completely out of luck. Presumably, the containers created by the terrorists were always the same size, such as 1 megabyte. We can monitor SSL connections and detect transactions of this size, uploaded by a customer in Europe and download by a customer in Syria or Iraq, with just one download.

Presumably, this is something the NSA can track down. According to Snowden, they keep metadata of all TCP transfers in places like Turkey, Syria, and Iraq. These logs are supposed to go back 90 days. Thus, a creative analyst should be able to sit down at the console and start making these queries to tease out such info. We are looking for the IP addresses in Europe making a few small uploads, and the IP addresses in Syria and Iraq making many downloads. With a 90 day backlog, this should go back to the start of the year, before the Brussels bombing, and catch any active terrorists.

The next thing to do would be to update the code of their sniffers to detect this on the wire. I created a TrueCrypt container file and uploaded it. Here's what I saw sniffing the packets. It's a normal POST command, where this is the contents of the POST, starting at the "WebKitFormboundary"

The thing about TrueCrypt containers is that they are completely random. The first 8 bytes are random salt, followed by the encrypted contents of everything else. If they do it right, it's impossible to distinguish TrueCrypt from purely random data (such as the output of /dev/urandom on Linux).

But luckily for us intelligence agents, TrueCrypt is rare in that property. Compressed files and encrypted ZIP files are also supposed to be random -- except they have headers identifying themselves. They've all got non-random bits to them, so while I can't easily identify TrueCrypt, I can easily identify everything that's not TrueCrypt.

Thus, if the NSA has a sniffer eavesdropping next to these non-SSL file-upload sites, they can do the following. First of all, they can classify all known file types somebody would be uploading (images, movies, virus code, ZIP files, RAR files, etc.). Of the remaining, they would then apply a simple entropy measurement system that tests the randomness of a file. This will weed out things like text files, or anything else of an unknown format. (Back in the day, my intrusion prevent system did this -- applying entropy tests to SSH and SSL connections once they were established, in order to discover exploits that would later send unencrypted data on these sessions, like the GOBBLES SSH exploit).

I have no experience eavesdropping on file upload sites, but I imagine the remaining files would be fairly small and manageable. Note that at this point, the NSA can start capturing the sessions so that later, when they capture terrorists and grab their keys, that they can decrypt old files. (This is one of the flaws of this terrorist dead-drop system: no "forward security").

So these are the thoughts so far. I'm sure I'll be tweeting back and forth with @thegrugq and will think of some more ideas. I'll update this later.

---

Update: It would be the sniffers associated with the NSA's XKeyScore system that would need to be updated to detect this. Presumably, this system can already track file uploads/downloads like this, and use file types as one of the search criteria when making queries.

One bit of code that would be useful to add to the sniffers would be some that automatically tried to password guess TrueCrypt container files. When it sees completely random bytes at the start of an upload, it can try to decrypt it using known passwords, and see if the result produces "TRUE" in the first few bytes, which is the string TrueCrypt uses to identify its files once decrypted. As passwords/passphrases are collected, they can be disseminated out to the sniffers, which can then identify these files in particular being transferred.

---

Notes: Instead of a keyfile used by the terrorists, I used a 5 lower-case letter password. You should be able to copy the bytes above into something that'll crack the password.