Just two days ago we announced thediscovery of in-the-wild attacks that used the zero-day which is now known as CVE-2013-3897.At that time we also promised to provide a more detailed analysis of theexploit.
Now we have the opportunityto provide a fully and detailed analysis of the vulnerability (CVE-2013-3897) itselfthat has been used by the attacker, and examine the patterns used by theattacker comparing to the previous zero-day attack (CVE-2013-3893).
According to our research a shorter version of this exploitcan be used in order to trigger the same vulnerability.
Let's go over the building blocks of thisattack:
1. Create a TEXTAREA and apply a different element asa child using applyElement. This will place the address elementas the child of the textarea element.
2. Trigger a select event on the TEXTAREAelement to create an instance of DisplayPointer.
3. Inside onselect event change the value propertyof the TEXTAREA element, which in turn will fire the event onpropertychange.For example, usage of appendChild or swapNode will cause this behavior.
Notice that id_2 ("address" element) is a child ofthe TEXTAREA element. By swapping that element we remove it from layout of "textarea"and insert a different element, therefore the value property changes.
4. The event onpropertychange is triggered
5. In the next stage we basically need to change the positionof the display pointer within the TEXTAREA layout. In the original exploit document.execCommand("UnSelect")was used. However, selecting a different element, executing the SelectAllcommand or any operation that causes a DisplayPointer position change will alsowork.
The attacker used "UnSelect" command
6. The JavaScriptselection causes a call to CDisplayPointer::ScrollIntoView, which tries to seta new position for the DisplayPointer. At this stage, the reference toCMarkupPointer is already released by the CDisplayPointer::Release function (asa result of the "UnSelect" command) and therefore points to an attacker-controlledheap area.
The flow eventually gets into QIClassID, which tries toexecute "CMarkupPointer::QueryInterface" (located at offset 0x0 in CMarkupPointer'svirtual table).
QIClassID:
QIClassID disassemble crash point
At the crash we end up with the following stack trace:
CMarkupPointer freed and then used by QIClassID:
Samesame but different?
As mentioned in our previous blog, the discovered samplesexploiting CVE-2013-3893 and CVE-2013-3897 share many similarities, a few of themare listed below:
Controlling EIP
The two zero-day exploits use the same technique in order tocontrol the victim EIP – both append a heap-address value to the titleattribute of div elements created inside an array context. Using this techniquethe attacker can override "freed" memory with predefined heap memory address (pointing to the malicious shellcode) which can later be called by EIP.
CVE-2013-3893 code snippet:
CVE-2013-3897 code snippet:
'unescape' function
Both exploits use a similar dedicated function that receive hexadecimal values, converts them into a Unicode representation and returns those values decoded.
CVE-2013-3893 code snippet:
CVE-2013-3897 code snippet:
Variable Names
Both zero-day exploits contain similar variables andfunction names.
CVE-2013-3893 code snippet:
CVE-2013-3897 code snippet:
Despite all the similarities presented above, the malwarethat is used to infect the victims of both attacks seems a lot different. Theoriginal CVE-2013-3893 malware was a sensitive info stealer that targeted financialand technological organizations. The malware that was used by the CVE-2013-3897exploit (as already described) was a banking/online games info stealer.
Moreover, the shellcode used in these attacks is completelydifferent. The exploit for CVE-2013-3893 used a 'simple' download-and-execute shellcode;while the CVE-2013-3897 shellcode is an advanced piece of program that will tryto detect the presence of several Antivirus products.
All of this may suggest that the two exploits were writtenand/or sold by the same cybercriminal group to a different criminal identitythat used the zero-days for completely different purposes.
Trustwave's Secure Web Gateway blocked the known attacks.However we recommend that all users install the latest Microsoft patch (MS13-080)via Windows Update. For cases where theapplication environment is of high importance and risk we recommend usingMicrosoft's EMET toolwhich is capable of mitigating even zero-day exploits like this one. We alsowould like to thank our friends at AhnLab for working with us on notifying the owner of a compromised Koreanwebsite related to this investigation.
Contributors to this post: Daniel Chechik, Ben Hayak and Dan Meged.
