Anatomy of Javascript Hack

Christopher Smith — Fri, 02 May 2008 11:28:00 +0000

NOTE: Several of the links in this article point to the original Javascript of this exploit or transformations of the original Javascript. If you actually execute the Javascript you will be performing the exploit. I suggest readers download the links and then look at the source in an editor, rather than clicking on the link and risking their browser attempting to execute the Javascript. I’ve set the content types of these links to “text” in order to minimize the risk of this, and I’m sorry if that creates an inconvenience.

One of the user groups I participate in is the UUASC. Recently, one of the ~~BOFH~~SysAdmins in the group posted a rather cryptic bit of Javascript that they saw flowing over their network. Their question was pretty simple. What does this do?

So starting with the outer bits of the code first, it is pretty clear that the bulk of the message is escaped Javascript which is fed in to eval. Not exactly a good sign, but not necessarily a bad thing. The first step I took was to unescape the relevant data (without performing the eval of course), which yielded this.

The source was clearly obfuscated, so I went through it, cleaned up the formatting and attempted to assign more meaningful names to variables and functions. This yielded this. The transform1 function included a use of eval(someString.replace(/blah/, ”)), which was clearly just a way of obfuscating how myCallee was computed, so I performed the replace and substituted the result, yielding this much clearer source, which shows that myCallee is actually the function itself!

So, it now becomes clear that the obfuscation of transform1 was not entirely random in nature, as the source itself was used as part of the key to decode the “payload” (the string passed in to transform1 after its definition). The easiest way to accurately decode this was to create both the original fpTu function in all its obfuscated glory, then set myCallee to fpTu in transform1, and then see what we got back from transform1 when we passed it the payload.

Not surprisingly, we have another somewhat obfuscated chunk of Javascript. After reformatting it (thank you Steve Yegge for js2-mode and providing some more meaningful function and variable names, the payload now looks like this.

There are still a bunch of places where the replace(/blah/, ”) idiom is being used to obfuscate things, and another place where a variant is used where all alphanumeric values are being replaced with a period, and then all instances of multiple periods are replaced with a single one. After unraveling those, the intent of the code becomes clear and we can attach more meaningful names to the functions and variables. Thus I ended up with this.

We can now see that the code points to 3traff.cn (don’t you feel safer already? ;-), and it cleverly embeds an iframe pointing to 3traff.cn in to each document as it is loaded. I’m not up on my browser exploits, but it looks like the intent of all this is to at the very least track users as they go off site, and also might be hoping to confuse a browser about which domain a document came from, and therefore potentially cause cookies to leak to 3traff. Either way, this isn’t the kind of code I like running in my browser.

Once again, Safari makes the world look better.

Christopher Smith — Mon, 27 Aug 2007 08:06:00 +0000

So, if you’ve been reading this blog much, you’ve undoubtedly been noticing its completely lack luster performance. I’ve been trying to isolate the problem, and frankly I’ve been getting frustrated enough that I’ve considered just writing my own blogging software that merely shares Typo’s database back end.

Instead of doing that, I noticed that despite updates to the software on my system, I was still running an old version of Typo. It turns out you have to explicitly upgrade each deployment of Typo (not necessarily a bad thing). As always, there is an easy way to do this…. and it didn’t work for me (probably PEBKAC, but nonetheless frustrating). Anyway, after several false starts, I managed to upgrade to Typo 4.1.1.

There are a number of improvements that have come with upgrade that look to make life better on xblog. Oddly though, the new theming seems to be completely broken –except for on Safari. Yup, if you are looking at this with anything other than Safari (actually, I haven’t tested with Opera yet), you are probably seeing a pretty ugly looking site. Firefox shows the site as broken on Linux, Mac, and Windows. IE7 looks the same.

I haven’t diagnosed the how and the why behind all this, because I’ve been stunned by the downright awesomeness of this. The problem seems likely related to stylesheets, but for the life of me I am trying to figure out what is so different about my setup from a typical Typo configuration, and more importantly just look in awe at Safari.

Xblog: Tag browser

Anatomy of Javascript Hack

Once again, Safari makes the world look better.