Paid Advertising
web application security lab

Remote Execution of XSS Malware

One of the main problems with detecting cross site scripting (XSS) is that it is not an easy feat to traverse the document object model (DOM). Rendering engines are slow, and they are processor intensive. But let’s just suspend disbelief for a second and say that we could do exactly that. On every new submission to every form, let’s pretend we had enough processor time to execute each submission once and see the results before it was sent to the browser, looking for anything that might denote something malicious from a web application security perspective.

That would be great, in theory! I could suddenly remove obfuscation (the entire reason for the XSS Cheat Sheet) as an attack vector, because I could detect any possible variant, just by watching the DOM execute. Pretty slick, right? Well, no. Even setting aside for a second the problem mentioned above with processing power, there are other troubling issues with this.

The first is timed functions, or remote execution. The problem with JavaScript from a detection and parsing standpoint is that it is a full fledged language, that supports all sorts of interesting things. One of those interesting things is the ability to pull in remote information and do analysis on it. Let’s say I set up a JavaScript function specifically to pull in a remote image (from a server I have at least partial control over). If the image is over a certain height or width or the combination is just right, the JavaScript will execute malware. If you get really tricky you can use a combination of sized images as a decoding key for some enciphered peice of code. Here’s an example:

image_1 = new Image();
image_1.src= "";
if (image_1.width > 1 ) {
// Execute malware

Now, that pretty much puts to rest the notion that you could traverse the DOM and get the same results as the user will (once I switch the images out). So if I know you are going to scan my block of code prior to letting it get posted, I can simply allow it to stay put until that grace period is over. When I’m convinced that you won’t be scanning it any further, I’ll change the images out, and the code will execute for all future users, until I either change it back, or the code is removed.

There is still one other problem, which is that you have to pick a rendering engine to do this with. You’re now saying, “Well, of course you do! That’s a stupid thing to say!” Well which one would you pick? IE seems to have the most vectors that effect it and the highest penetration, so that would seem to be the obvious choice, but are you going to allow the Gecko (Firefox) only vectors to go through - thereby allowing double digit percentages to be infected by the malware? Tough choice, and certainly not bullet proof.

The remote execution issue is the biggest in my mind, though. Because the attack is now controlled by a remote device (an image or series of images) it is now out of the hands of the user to even decrypt if you so choose. Typically JavaScript is a very easy function to de-obfuscate, if you have the human eyes and time to do it, but in this case, if the images aren’t there or are different sizes, the decryption is meaningless. And even if you could scan every single input, you’d still be at the mercy of a timed function where the image changed after a certain point.

This could give a ceneral command and control aspect to XSS worms, where the central image controlled the timing function, as to keep the attack under wraps until the timing was right. This would be particularly effective in DoS attacks. The downside is that the single command and control is easy to remove - unlike self sufficient viral code which depends on nothing but itself and the machine for propogation and originating page for roots to continue growth.

4 Responses to “Remote Execution of XSS Malware”

  1. Someone Says:

    if (image_1.width > 1 ) {
    // Execute malware

    any example for execute malware :S

  2. RSnake Says:

    I’m not sure what you’re asking… that is the example… The malware itself is something that could be as simple as stealing a cookie, or something loading up an executable (virus) or otherwise. It totally depends on your application.

  3. web application security lab - Archive » Cross Domain Leakage With Image Size Says:

    […] A few days ago I posted about how to control cross site scripting remotely.  This is a pretty powerful tool in the web application security toolkit - specifically for attackers attempting to mount remote attacks.  I did fail to mention one thing about this.  But let me start from the beginning.  Once upon a time, I was trying to get Gerv to implement content restrictions and additionally dynamically resizing iframes based on the embedded content.  Both had their uses for isolating user information in another domain or at minimum restricting what they can do in the realm of the page they are residing on.  The bug had issues going through as it is deemed a security issue to know the state of a user on another site via cross site request forgeries. […]

  4. Benson Says:

    I think Someone is implying the “Execute malware” codes could be scanned by human eyes irregardless of the timed-dependant control flow at runtime, unless the “Execute malware” codes are also not locally available and/or time-variant as well?!