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