At the beginning of October 2006, I noticed a strange occurrence while surfing the web using Tor (The Onion Router). After some investigation, I forwarded what I had found to the Internet Storm Center (ISC). Since there isn't a great deal of public information about these types of attacks, I thought I'd share what I had put together. That information is reproduced below.
It turns out what I had discovered was work done by Andrew Christensen at Fortconsult. The resulting paper "Practial Onion Hacking" is available from Packet Storm Security. The ISC later posted a diary entry about this.
The following is the information I sent to the ISC:
I've been using Tor for some time now, and this is the first time I'd
seen this trick so I thought I'd pass it along.
Background info: I am running Firefox on Linux. I have a standard Tor
and Privoxy configuration based on the documentation. I have
Javascript enabled, Java disabled, and Flash is not installed. I have
the Torbutton extension (https://addons.mozilla.org/firefox/2275/)
installed to easily enable/disable Tor. Normally I would only enable
Tor when surfing to more questionable parts of the internet or using
hidden services, but recently I've been playing with strict egress
filter rules that only allow Tor traffic from the host.
So while browsing one of my own websites at home, I came across a page
that was corrupted. There was a suspicious rectangular box rendered
at the top of the page and Firefox was prompting to install a missing
plugin (Flash). I viewed the source of the page and after the opening
"body" tag, there was an "iframe" with a "src" attribute of
"http://qyq.dk/4289XXXX.h". This text had been placed in there as a
byte for byte replacement, so the existing tags and text had been
overwritten. This was causing the page to not render properly.
I immediately assumed that my website had been hacked, closed the
source window and refreshed the page. What I got back was the page
that I expected, not the corrupted page that had first appeared.
Maybe my box hadn't been hacked after all. From a separate machine, I
logged onto my webserver and running Tripwire confirmed that no files
had been modified and there were no out of place log entries.
It was at this point that I became suspicious that something very
strange was going on. Unfortunately, I hadn't saved the original page
source for the corrupted page because I had jumped to the faulty
conclusion that it was a hacked web server. But, I had the name of
the site and the resource that had been referenced. So, using wget, I
requested the default page from "http://qyq.dk". This returned an
"index.html" HTML document with a title of "TORture", a comment of
"Welcome to my private Echelon. Enjoy your stay.", and a body of
"Nothing here, move along.". Clearly, someone was being clever.
Once again using wget, I requested the original resource
"http://qyq.dk/4289XXXX.h". This returned a document containing only
the text: "WIERDNESS HAPPENED. SORRY...".
I was pretty certain that this wasn't the original content that had
been returned when referenced in the iframe. After some googling, I
decided that I could probably recover the original content from my
browser cache using CacheView
(http://www.progsoc.uts.edu.au/~timj/cv/). So I closed my Firefox,
zipped all of my browser's cache files and copied them to a Windows
instance running under VMWare. (In retrospect, I should have checked
for any session cookies from the site before closing the browser).
Using the CacheView program, I was able to extract the original
"4289XXXX.h" file.
The "4289XXXX.h" file is an HTML file that contains a series of
Javascript functions and an object reference to a flash file
"socket.swf". I downloaded this file via wget from
"http://qyq.dk/socket.swf", but didn't investigate it further. The
javascript code appears to connect to a server running on host qyq.dk
on port 8080. Some very basic data would be exchanged as part of the
connection. There is a discussion of this technique here:
http://blog.thinkphp.de/archives/117-Real-Javascript-Sockets!.html I
don't know whether this server is functioning or not.
What caught my eye in the file is the string "66.137.XXX.XXX" in the
data exchange. This is the IP address of my webserver. This leads me
to believe two things:
1) the file "4289XXXX.h" file was being generated on the fly because
it contains the IP address of the webserver I was browsing to
2) in Tor routing, only the exit node is going to know the target IP
address, so the exit node is responsible for all of this
All told, I find this to be a very interesting approach to subverting
Tor. The whole concept of Tor depends on the exit nodes behaving as
good citizens. There is always the fear that the exit node may be
snooping on you, but modifying the traffic is pretty wicked. With the
ability to change the HTML, one could inject XSS, cause driveby
downloads, add webbugs, etc.
Unfortunately, I don't have the time to investigate further, but I
thought I'd pass along what I had. This may be old news, but it was
the first time I'd seen it and it peaked my interest.
I've attached a zip file ("qyq-dk.zip") with the following contents:
qyq.dk
qyq.dk/cached
qyq.dk/cached/4289XXXX.h
qyq.dk/SHA1SUMS
qyq.dk/wget
qyq.dk/wget/4289XXXX.h
qyq.dk/wget/index.html
qyq.dk/wget/socket.swf
The "SHA1SUMS" file contains the sha1 sums for the other files. The
"cached" directory contains the "4289XXXX.h" from my browser cache.
The "wget" directory contains the files I downloaded using wget. I
wouldn't depend on any of the timestamps of the files since I moved
them from machine to machine and wasn't careful about keeping them in
sync.
You may notice that some of the HTML files have additional script
elements containing a 'PrivoxyWindowOpen' function. This is
automatically being added by Privoxy, so these files aren't actual
representations of what the webserver is returning.
The following files were included. They have been modified to obfuscate my IP address so the SHA1 sums no longer match: