Anatomy of Javascript Hack 3

Posted by Christopher Smith Fri, 02 May 2008 18:28:00 GMT

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 BOFHSysAdmins 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.

Awesome Comic On Java & Javascript's Tortured History

Posted by Christopher Smith Mon, 21 Apr 2008 16:29:00 GMT

Hell Freezing Over

Posted by Christopher Smith Mon, 13 Nov 2006 17:15:00 GMT

Now that the election is over and I’m starting to feel healthier again, I thought I should mention two events in the programming world that I think are very significant. They both involve two incredibly popular but often misunderstood and vilified programming languages who are forever associated with each other and the birth of the web.

The older news story is the Tamarin project, which is finally going to bring JIT technology to the world of Javascript in a big way (technically Tamarin was already in Acrobat’s Javascript engine, but let’s face it, most Javascript isn’t written for that platform). Word to the ignorant: up until now, Javascript has been painfully slow. Back when I was in the lab someone wrote a spring physics based graph-layout engine in Javascript. They were having problems with the algorithm, and being kind of weak in Javascript, I rewrote the thing in Java. After we got all the kinks out of both versions, the Java version appeared to be an easy 100x faster (possibly 1000x). Seriously.

Since then, I’ve looked a lot more closely at Javascript and discovered it’s not nearly as bad as I’d perceived it to be. It’s kind of a LISP-y language, with some handy little scriptisms in it, and SpiderMonkey makes it fairly easy to embed in C programs (someone needs to make a C++ interface that is like Boost’s Python library so I can say the same thing about C++).

The other big news is that today, Java is getting GPL’d. Specifically the HotSpot VM is being GPL’d along with Javac, with the standard libraries to follow (the VM is far more interesting as Java’s standard libraries tend to be only marginally better than what GNU Classpath has to offer). It will be interesting to see what comes of this, but the optimist in me hopes this will finally make Java more acceptable to the broader open source community and will lead to Java working better on more platforms. Myself, I want to see just how quickly I can hack a more async I/O style interface for Java’s IO libraries (yes, one could do this with JNI before, but you can do more interesting things with access to the full runtime). It’d also be fun to try to hack in an execution model that allows processes to share more of the Java VM’s resources, although that will undoubtedly take more time. I suspect more than a few people will be looking at ways add support for explicit disabling of bounds checking. The really most awesome hack to the Java VM has to be adding support for efficient unsigned arithmetic. That requires new byte codes, but man would it be wonderful.

The irony with both of these milestones is that in some ways they are both non-news events… except for how long it has taken for them to come around. Given Javascript’s popularity, you had to think that sooner or later JIT’s or some equivalent would become the norm. Instead, Javascript’s lackadaisical performance has helped relegate the language to “least common denominator status”, although AJAX allows you to offload work on to the only resource likely to be slower than your local Javascript engine: the web server. ;-)

As for Java becoming open sourced… Sun has been playing hot-and-cold on this one seemingly almost since the language was invented (a prize for whoever finds the oldest comment from a Sun executive which suggests that Java might in any way become open sourced). Based on what’s been in the press, this would have been a non-news event five or six years ago.

I have to say, I worked at Sun back when it was still getting sales by being the “dot in .com”, and one of the primary reasons I left the company was that it was clear to me that internally they just didn’t grok what was happening with open source and why what they absolutely needed to address this on the Solaris side of things in some fashion (either by the OpenSolaris route they chose or by porting Solaris tech to the Linux kernel and abandoning Solaris altogether) and simply make Java open source ASAP (while I thought what they did with openoffice was great news for the open source world, it didn’t strike me as indicative of a larger understanding). Gosling’s history with the free software movement didn’t exactly give one confidence that this was going to change either.

It’s good to see them coming around on this. I’m increasingly running out of reasons not to have a Solaris box at home. I’m about ready to look at the OpenSolaris hardware compatibility list and see just how cheap a box I can put together (I just don’t have enough RAM on my desktop to do Solaris justice with VMware).