Sunday, September 26, 2010

Please note that I am not the owner of the exploit pack and will not post any files for the download. Thank you ~ Mila

Update 2 Sept 29

The cryptor.php, which is the pdf builder, indeed contains enough code to build malicious pdf for the last Adobe zero day CVE-2010-2883. However, it appears to be work in progress and not a fully implemented feature. Will post more information as it becomes available.

Update 1 sept 27 Percy Sabourin @Garlandors pointed out that one piece of code was taken from the Metasploit exploit for the "Cooltype" Adobe 0 day CVE-2010-2883, which became public on Sept. 9, 2010. See the last screenshot and below this paragraph. The code indeed looks the same, we first thought it was only for the content part of the pdf but at this time it is not clear whether the pdf generator would actually generate a working pdf exploit using this vulnerability CVE-2010-2883. There are no corresponding ini or php files in the pack too. Also, nearly all php files in the pack are encrypted with ionCube encoder.

Also, it means the pack or at least crypter.php was produced during the period Sept 9-21, 2010

Tuesday, September 21, 2010

CVE-2010-2883 Stack-based buffer overflow in CoolType.dll in Adobe Reader and
Acrobat 9.3.4 and earlier allows remote attackers to execute arbitrary
code or cause a denial of service (application crash) via a PDF
document with a long field in a Smart INdependent Glyphlets (SING)
table in a TTF font, as exploited in the wild in September 2010.
NOTE: some of these details are obtained from third party information.

Cédric Gilbert, from SkyRecon Systems sent a short and later (per my request, because I wanted to understand it ) , a more detailed explanation for the DEP bypass - in clear terms, for people who don't already know everything :)
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”.

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.

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.dllis 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.dllis known by the attacker, he just had to retrieve the needed addresses from icucnv34.dllimport table :)

Cédric Gilbert, SkyRecon Systems

Update7 - Aurora?

Here here an interesting observation by Itzhak Avraham (Zuk) @ihackbanme about the fact that this pdf is using a technique similar to one found in Aurora.

DMS.bat mentioned in Update 6, has been observed during analysis of ad_1_.jpg file, which was one of the files recovered during the Aurora investigation (see Aurora US-CERT advisory here)

Exploit in action:(see a video demo in the end of this post)
According to Sophos researchers (many thanks to Chester Wisniewski) -

the shellcode drops hlp.cpl DLL to user %tmp% folder and then manually parses to its StartUp export and runs from there.

wincrng .exe gets downloaded using the DLLs's "DownloadFile" export from hxxp://academyhouse .us/from/wincrng exe to user Application Data folder, renames it to winhelp32.exe and runs it. The domain is currently under the control of Shadow Server (http:/internal/tools/whois/?domain=academyhouse.us)

The DLL then calls its "MakeAndShowEgg" export, which reads a filename from the original PDF ("Golf Clinic.pdf") and then drops a clean PDF file (golf clinic.pdf 6AF93ED231AEA3B00769FC8283943E75) and launches it in Acrobat Reader so as not to arouse suspicion. The text of the PDF, however, still arouses a lot of suspicion - see below :)

Finally the DLL calls the imaginatively-titled "DeleteMyself" export to drop the file DMS.bat which deletes the DLL and then itself.

Malware samples are available for download by any responsible whitehat researcher. By downloading the samples, anyone waives all rights to claim punitive, incidental and consequential damages resulting from mishandling or self-infection.