Wednesday, December 01, 2010

Random notes on Wikileaks vs. Amazon AWS Web Service

The twitterverse exploded with accusations that Amazon caved to political pressure and stopped hosting If you'll remember, on Sunday, the site was taken offline with a DDoS attack (where thousands of machines flood a victim with requests). Therefore, Wikileaks moved to Amazon's "cloud" servers, which should be immune to DDoS. However, Wednesday morning, Amazon canceled the account, and Wikileaks had to move back it's original servers.

I ran the well-known "dig" tool to find where the website was located. The top part of the window shows me running it yesterday (Tuesday, November 30), which shows the site was hosted on Amazon's cloud. The bottom part of the windows shows me running the same command today, showing the site hosted on non-cloud servers:

As you can see, the 'dig' command from yesterday shows that the cablegate website resolved to, which is "". The 'dig' command from this evening shows that it's being hosted on "" and "" ( was the previous provider that was hit with DDoS Sunday).

The next screen shows running 'wget' yesterday, and an attempt to run it this morning around 11am EST (to a site that wasn't up yet). Yesterday, 'wget' was successful using Today, it failed on another Amazon cloud computer.

The reason it failed is probably because the DNS entry was stale, pointing to the old address while Wikileaks was transitioning to a new server. (This screen shows 'wget' from this morning around 11am, the previous screen shows 'dig' from around 10pm, after the DNS was updated).

Christopher Hoff has a theory that Amazon wasn't actually hosting the cables. I don't think he's right, but sadly, I can't prove him wrong either.

The reason I doubt him is the fact that my 'wget' shows that it grabbed the files from the server:

This isn't proof they were on the server. I'm not sure, but I think the Amazon server could have returned a "redirect" message that looks like:
HTTP/1.1 302 Found
In that case, the files could have been located on another server. The only way to prove where they actually came from is with a packet-capture file showing the packets streaming from an Amazon cloud address.

I have such a capture file, but sadly, it doesn't show precisely what I want. It shows getting some of the files in other directories, but none in the all important /cable/ directory. Here is the results filtered for the /tag/ directory.

If we pick one of those transactions, we get the following response. As you can see, at least for the /tag/ directory, the files are hosted on Amazon.

In my capture, all the files are hosted on Amazon's server, but sadly, the /cable/ files don't appear in my capture. The failure is due to the fact that in this case, I stopped 'wget' early while the packet-sniffer was running (I ran 'wget' multiple times). In that directory, there were no /cable/ files either.

In other words, I was running a packet-sniffer while testing wget, but when I ran wget for real (when it grabbed the cables), I wasn't running the packet-sniffer anymore.

In the absence of any other information, I believe strongly that Amazon was hosting the cables. On the other hand, I couldn't prove it beyond a reasonable doubt. If Amazon claimed they were doing 302 redirects on the /cable/ directory, I'd believe them.

Update: I hear rumors that Wikileaks claims only their homepage was on Amazon's cloud servers. I don't believe Wikileaks, since as my packet-capture shows, much more than just their homepage was on the Amazon cloud.

Update: Here is an interesting post on Amazon hosting Iraqi war logs from Wikileaks:

1 comment:

mokum von Amsterdam said...

A site I like a lot for quick DNS inspection:

For a quick lookup of some [inconsistent] hosting history: