There is no honor amongst thieves and malicious code writers are no different. Why would anyone go through all the work of writing an exploit from scratch when there is a good amount of boilerplate available? When I first took a look at this 0day PDF attack I noticed the string “a pwning u3d model”. A quick google search leads you to an older exploit (CVE-2009-2990) PoC written by Felipe Andres Manzano with a lot of matching details. Below is a walk through of how the attackers may have leveraged this existing code to construct the exploit.
The working malicious document contained three pages, but it was unclear at first if there were reason behind this. After doing some research I found that one page needed to be blank so the heap spray could execute and then a second page would be needed to render the vulnerable U3D object. Three pages were not required, but were present and below is a screenshot of the code why.
Above shows the use of “app.platform” and “this.pageNum” by Felipe’s code. It is worth noting that the platform check is not necessary and was likely left in by the attackers because of laziness. Felipe included this only to differentiate between which exploit to fire since he had both Windows and Linux.
For the exploit to work a U3D annotation needs to be created. This annotation essentially defines the U3D object and how it is going to render within the document. Below is Filpe’s code to generate his annotation.
This is an exact match to what we see within the malicious document.
Observed within the malicious document were a couple things I didn’t quite understand. Within object 7 for instance was a flatedecoded “(Aaaaa) Tj”. This value doesn’t appear to play any role in the exploitation, but it is also included in Filpe’s code. Also included is metadata defining the author, email and web. While this has changed it is funny to note that the attackers left the matching “googlepages.com” domain.
Obviously this portion of the code was not stolen, or at least not in its entirety. Within the U3D content are several strings that identify parts of the human arm. There has been a link circulating on Twitter of a Swiss FTP site containing code to generate a U3D stream with the same strings found present in the malicious document. Without the full source it is hard to say if this code was modified to produce the exploit, but it is a theory worth listing.
Analyzing the Attacker
When looking at these attacks I like to try and understand how the attacker may have generated the document and the reason behind their process. There is an old saying that goes “if it ain’t broke, don’t fix it”. I think this is highly applicable in this case as the attackers likely just modified what was already working. All that needed to be replaced was the heap spray code which was easily defined and the U3D stream.
Given the static data present in all the samples I have, I also believe that the tool used to create this document has little modularity or sophistication. For this reason alone I have a hard time believing this attack was created by a nation state government. Instead, I think this was done by a small group of people who’s motivation would be to support their government and send data back to them. This sort of behavior fits the Chinese hacker model and gives a bit more value to the Chinese traits identified within the document and dropper.
Doing development makes people lazy which is great, but not when you are writing exploits. The attackers re-used code that was publicly available and therefore makes our jobs as incident responders easier. Until any changes are seen within the documents being sent out, I think it is safe to say we have a good list of static signatures that can be used to identify them. This attack also shows that attackers read what researchers publish and sometimes put it to use. More value needs to be placed on proof-of-concept attacks and what attackers could do before it actually happens.