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.
Image 1: The beginning
’ method of the button to run the associated function ‘blkjbdkjb()
. 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
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.
(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.