Please comment and correct, if you find mistakes, we will add the corrections. Many thanks!
There are 4 settings for DEP :
- AlwaysOff
- Opt-in
- Opt-out
- Always On
‘Opt-in’ is the one used by default on every Desktop Edition of Windows, while ‘opt-out’ is the default for Server Editions.
‘Opt-in’ only protects software that is fully compatible with DEP (those software programs are marked at compilation with the flag ‘/NXCOMPAT’).
‘Opt-out’ protects every software program (even the ones without /NXCOMPAT) except the ones explicitly added by the administrator to a white list.
“AcroRd32.exe” is not /NXCOMPAT, thus if an execution occurs in a page in memory marked as ‘not executable’ (the heap for instance), DEP in ‘opt-in’ mode will ignore the fault and silently change the rights of the page to ‘EXECUTE’. On the other hand, if DEP is set to ‘opt-out’, it will immediately kill the faulting process. This is why most exploits using heap spraying actually do work. Because even though execution occurs on the heap (NO EXEC) when the execution flow is redirected into the ‘nop’ slide, DEP in opt-in mode will not block the attack.
Now the writers of the exploit used in this case obviously wanted to go a step further by bypassing DEP even in its ‘opt-out’ or ‘always-on’ mode.
Which means that they had to find a way to execute their payload without triggering any ‘page fault’ in NO EXECUTE memory.
The best way to do so is to use some kind of ‘ret into libc’ technique (in this case a ROP technique). Instead of redirecting the execution flow into the heap, they redirect it to a CODE section in a DLL (which got EXECUTE rights) by overwriting saved eip on the stack. Of course no DLL exactly have the code that the attacker would like to execute, so the idea is to chain calls into this DLL on small code portions using return addresses smartly placed on the stack before the vulnerability is triggered. The problem with this technique is that it requires the attacker to use ‘hardcoded’ addresses pointing at each code portion that he wishes to execute.
Starting with Windows Vista, Microsoft introduced a new protection called ‘ASLR’ for Address Space Layout Randomization. This protection, among other things, randomize the base address of each DLL when they get loaded into a process address space (the random base address changes at each boot). This protection was meant to defeat attacks, which used hardcoded addresses, since a randomized DLL place in memory is changing at each boot.
So to defeat both DEP and ASLR, the attacker got AcroRd32.exe to load a DLL not compatible with ASLR into its address space (I do not know how they managed to do so at the moment).
The DLL used is “icucnv34.dll”, the fact that it is not compatible with ASLR means that it will always get loaded at the same address in memory, thus allowing the attacker to use ‘hardcoded’ addresses pointing to this DLL.
The thing is, it’s very complicated to build a whole shellcode using this kind chained call into a DLL. So the attacker used it only to get a place in memory allocated with exec rights, copy his shellcode on it and, eventually, jump on it and do whatever he wants without caring about DEP anymore.
In this exploit, the attacker manages to do so by chaining 4 API call in “icucnv34.dll”.
1) CreateFileA:
IN LPCTSTR lpFileName = 4a8254e0 = « iso88591 »
IN DWORD dwDesiredAccess = 0x 10000000 = GENERIC_ALL
IN DWORD dwShareMode = 0 = not shared
IN lpSecurityAttributes (OPTIONAL) = 0
IN DWORD dwCreationDisposition = 2 = CREATE_ALWAYS
IN DWORD dwFlagsAndAttributes = 0x102 = FILE_ATTRIBUTE_TEMPORARY | FILE_ATTRIBUTE_HIDDEN
Here the attacker creates an empty file called “iso88591” at the location where the pdf was opened.
2) CreateFileMappingA
IN HANDLE hFile = 0x1c4 = handle on « iso88591 »
IN OPT lpAttributes = NULL
IN DWORD flProtect = 0x40 = PAGE_EXECUTE_READWRITE
IN DWORD dwMaximumSizeHigh = 0
IN DWORD dwMaximumSizeLow = 0x10000
IN OPT LPCTSTR lpName = NULL
Since the file is empty, the attacker has to specify an arbitrary size for the file mapping.
At this point the attacker is ready to map the file into memory.
3) MapViewOfFile
IN HANDLE hFileMappingObject = 0x2dc = Handle from CreateFileMappingA
IN DWORD dwDesiredAccess = 0x22 = FILE_MAP_EXECUTE | FILE_MAP_WRITE
IN DWORD dwFileOffsetHigh = 0
IN DWORD dwFileOffsetLow = 0
IN SIZE_T dwNumberOfBytesToMap = 0x10000
Now the attacker’s got a 0x10000 bytes space with EXECUTE rights allocated into memory. All that he has to do to complete his ‘DEP-evading-technique’ is to copy the shellcode that he wishes to execute in this newly allocated exec space and jump on it.
Which he does by calling :
4) MSVCR80!memcpy
Dst = 0x05bc0000 // Base Address returned from the MapViewOfFile above
Src = 0885f118 // Not sure whether it is an address from the mapping of the pdf itself or something that he sprayed on the heap before
Len = 0x1000
And here we are, after this call the real payload (at 0x0885f118) is mapped into an ‘EXEC’ memory space (at 0x05bc0000). The jump to the the payload is actually made by the memcpy call itself since the return address set on the stack by the attacker for this call is the destination of the copy (0x05bc0000) ! BAM! Both ASLR and DEP are defeated!
Now one may ask : ”Ok nice, icucnv34.dll is not ASLR-compatible, but kernel32.dll is, so how did the attacker get the required API addresses?”. Well, it is pretty simple actually, he just had to use API imported by icucnv34.dll ! When this DLL got loaded, its import table got fixed by the loader with the addresses of all API required by the DLL.
Since the base address of icucnv34.dll is known by the attacker, he just had to retrieve the needed addresses from icucnv34.dll import table :)
about the fact that this pdf is using a technique similar to one found in Aurora.
DFS.bat from ad_1_.jpg (Aurora)
