Endpoint Protection

 View Only

Zero-Day Attack on IE6 – JS.Sykipot Doesn’t Spare Retired Software 

Mar 10, 2010 05:11 PM

Internet Explorer 6 may have taken its path to retirement but it still remains a good target for exploits, as we can see from JS.Sykipot. This zero-day was found on March 8th and it exploits a vulnerability in some Internet Explorer versions (CVE-2010-0806 , BID 38615) that can lead to remote code execution. Upon successful exploitation, JS.Sykipot will download and run Backdoor.Sykipot, which is a back door capable of communicating with its control server to receive and run several commands.

In my tests, the exploit worked successfully on IE6, caused the browser to freeze on IE7, and did not work at all in IE8. In particular, IE8 shows an error box when running the JavaScript code, so it seems to not be affected by this vulnerability.

Let’s have a look at the exploit itself. It begins with a simple JavaScript tag; surprisingly, the code is only slightly obfuscated:

Screen shot 2010-03-10 at 9.54.29 PM.png

Image 1: The beginning

The page defines a button, then the JavaScript code will call the ‘onclick()’ method of the button to run the associated function ‘blkjbdkjb()’. This function contains the exploit code itself. Note how the code also includes another JavaScript file, named bypasskav.txt. This file only contains the following code:
var oipoipqirpoewrioipowqeriqq = unescape;

The code is used to associate the ‘unescape’ function with a variable that has a junk name. Anyway, let’s go back to the main function:


Image 2: The main function

We can see some code here, but first of all we see the function ‘eejeefe()’ being called, so we’ll have a look at it. As you can imagine, it contains the code that builds the executable shellcode:

Screen shot 2010-03-10 at 9.54.59 PM.png

Image 3: The heap spray

The code will un-escape several binary bytes that are the executable core itself (the label oipoipqirpoewrioipowqeriqq was associated to unescape, as we saw a few lines above). Then you also have the un-escape of the malicious URL (associated in the var u in the code), and then a standard code that performs a heap spray in order to fill the process memory with the malicious shellcode.

Back to the main function, the code creates a BODY element, adds the behaviour ‘#default#userData’ to it, then appends the BODY to the current document. Then, you have a loop that calls the function ‘setAttribute()’, and this is where the shellcode triggers. The attacker does not rely on some memory s/he controls in order to write a pointer to its shellcode, but knows in advance the location that will be referenced by a dangling pointer. By luck, the location contains bytes that are interpreted as a virtual address, and by luck that address matches an area being sprayed with the shellcode.

Let’s have a look at when the exploit happens:

Screen shot 2010-03-10 at 9.55.21 PM.png 

Image 4: The code jumps at the wrong address

This code is normally accessing an object in memory through a pointer and it is dereferencing the pointer in order to access the object methods and attributes. In particular, it will use the JMP instruction to execute a code from the object itself. Normally, this JMP would end up in a legitimate function, but in this case the problem is that the main object being accessed is not the expected one, but it has been instead swapped with another. Because of this, the dereference of the pointer ends up in a place that does not contain the address of a valid function. It instead contains the number 11CF6A4A, which can be a valid address in the memory space of the process and in fact, if we go and check that address:

Screen shot 2010-03-10 at 9.55.37 PM.png

Image 5: The malicious shellcode being executed

There we go! This is the shellcode sprayed by the JavaScript code (you can recognize all those 0C bytes). The code contains the executable code to download and run a file from a URL. The URL is in the bottom of the shellcode.

If we take a closer look at the address that is incorrectly dereferenced, causing the code to jump to the shellcode, we see that this address is 7DC43474 (this may differ on other computers). This address lies inside the memory of mshtml.dll and if you actually check the surrounding bytes you may recognize that they are the GUID: D48A6EC6-6A4A-11CF-94A7-444553540000. So, this memory area contains legitimate code and data for the objects needed by mshtml.dll. It just so happens that part of that GUID number can also be interpreted as a valid address that the attacker has sprayed. Talk about luck!

Taking a deeper look, IE8 shows an error when running the script:

Screen shot 2010-03-10 at 9.55.50 PM.png

Image 6: IE8 error box

That error brought me to this link, so the problem seems to be known. I’m guessing that in this case the condition happens between the BODY element and the #default#userData store; this problem causes the code to have a pointer to an object and to dereference it in an incorrect way (probably because it is considered to be another object), thus ending up—as we have seen—jumping to the wrong place.

This exploit seems to be quite unstable. I had several crashes during my tests and the exploit did not run in IE7, but it should still be considered very dangerous. So, seeing as IE6 is no longer supported by Microsoft, it is time to update your browser to a newer version or to use a different one.

Update (March 12, 2010): It has been brought to my attention that IE6 will still be supported by Microsoft until April 2014. However, the browser will no longer be supported by Google or YouTube.

0 Favorited
0 Files

Tags and Keywords

Related Entries and Links

No Related Resource entered.