nezumi-lab
July 24th, 2009, 16:20
on July-23, milw0rm uploaded “Adobe Flash (Embedded in PDF) LIVE VIRUS/MALWARE Exploit ("http://www.milw0rm.com/exploits/9233")” written by @hdmoore who states that it’s (I quote) “live exploit sample for the new Flash bug (embedded in PDF)“, which is far from the truth.
the truth is - it’s the old getIcon exploit having nothing to do with the new vulnerability in ActiveScript Virtual Machine. the real worms (described here ("http://www.avertlabs.com/research/blog/2009/07/22/new-0-day-attacks-using-pdf-documents/") ) uses PDF with two embedded SWF files, one - triggers the bug, another performs heap-spraying and generates the shell-code on the fly! yeah! it uses Active Script byte-code (which is not plain text like JavaScript, it’s more like Java byte-code) to generate the shell-code, so there is no unescape strings, so my shell-detector fails to find it (of course it fails, it does not support Active Script byte code, at least not yet).
I will write about the real SWF exploit tomorrow. today we’re going talk about that faked exploit. it’s pretty interested as well. the first thing we have to do is to decompress all streams. it’s easy. zlib support that format, we just should write PDF parser… should we?! oh, not really!!!
according to RFC-1950 ("http://www.ietf.org/rfc/rfc1950.txt") a zlib stream has the following structure: CMF_FLG (more–>
. so, we can just look for CMF_FLG header, trying to decompress every stream we meet - very useful universal decompressor, supporting now only PDF, but much more (HTTP streams for example).
FLG filed has 4 bits FCHECK checksum and the header itself is quite predicable, so it’s easy to find a potential ZLIB header inside a byte stream. how to defeat false positives? (2byte header is too short to be reliable enough). well, no problem guys! if we found something looks like CMF_FLG just try to unpack the first 512 bytes by zlib inflate() function. if it fails it means - false positive, otherwise we have to call it again to unpack the rest.
ok, all streams of hereEvil.pdf are decompressed. 15th stream is JavaScript with a large Array contains unescaped string. looks like a shell-code, but hell no! decode it with a simple deURI converter and… ops!!! another JavaScript!!! yes!!! exploit inside exploit, nested obfuscation. could you believe me?! I just improved my shell-code locator, adding recursive filtering support (zlib-decompror and unescape decoder - basically are external filters for the locator engine). I have not released the new version yet, just was testing in and… wow!!! I met the exploit that really uses the nested JavaScripts for better obfuscation! well, just in time, just in time…
NOTE: if you have no idea how to write deURI decoder, download ECMA-262.pdf ("http://www.ecma-international.org/publications/standards/Ecma-262.htm") (ECMAScript Language Specification) and go to section “B.2.2 unescape (string)“. there you will find unescape decoder, written in pseodo-code.
the second (underlined) layer is not interested. it’s just Array with uneascape string contains the real shell-code includes well-known ["doc"]["Collab"]["getIcon"]. do they look familiar?! of course they do!!! it’s the old getIcon exploit, just more obfuscated.
now, about the shell-code. it’s very simple, don’t even encrypted. this is what my shell-code locator said:
URLMON.DLL, URLDownloadToFileA, update.exe, crash.php, http://viorfjoj-2.com/2/update.php?id=0
wow!!! the domain name!!! I checked it and found out that viorfjoj-2.com is down, so I went to who is who service and… ops! surprise!!!
well, maybe I should not public his contact info here because of etiquette, but… why not?! the exploit was taken from the public source, the hard-coded domain name was found, so… everyone can use the whois service to get this contact info.
well, what we’re going to do on ISP side? if you meet a packet from/to viorfjoj-2.com it means the host is infected and the packet should be blocked. well, since the server is down - obviously all major ISPs had blocked it already.
http://nezumi-lab.org/gif/pdf_fws_fake.pngfaked exploit on milw0rm - it has nothing to do with the real SWF security hole
http://nezumi-lab.org/blog/?p=227
the truth is - it’s the old getIcon exploit having nothing to do with the new vulnerability in ActiveScript Virtual Machine. the real worms (described here ("http://www.avertlabs.com/research/blog/2009/07/22/new-0-day-attacks-using-pdf-documents/") ) uses PDF with two embedded SWF files, one - triggers the bug, another performs heap-spraying and generates the shell-code on the fly! yeah! it uses Active Script byte-code (which is not plain text like JavaScript, it’s more like Java byte-code) to generate the shell-code, so there is no unescape strings, so my shell-detector fails to find it (of course it fails, it does not support Active Script byte code, at least not yet).
I will write about the real SWF exploit tomorrow. today we’re going talk about that faked exploit. it’s pretty interested as well. the first thing we have to do is to decompress all streams. it’s easy. zlib support that format, we just should write PDF parser… should we?! oh, not really!!!
according to RFC-1950 ("http://www.ietf.org/rfc/rfc1950.txt") a zlib stream has the following structure: CMF_FLG (more–>
. so, we can just look for CMF_FLG header, trying to decompress every stream we meet - very useful universal decompressor, supporting now only PDF, but much more (HTTP streams for example).FLG filed has 4 bits FCHECK checksum and the header itself is quite predicable, so it’s easy to find a potential ZLIB header inside a byte stream. how to defeat false positives? (2byte header is too short to be reliable enough). well, no problem guys! if we found something looks like CMF_FLG just try to unpack the first 512 bytes by zlib inflate() function. if it fails it means - false positive, otherwise we have to call it again to unpack the rest.
ok, all streams of hereEvil.pdf are decompressed. 15th stream is JavaScript with a large Array contains unescaped string. looks like a shell-code, but hell no! decode it with a simple deURI converter and… ops!!! another JavaScript!!! yes!!! exploit inside exploit, nested obfuscation. could you believe me?! I just improved my shell-code locator, adding recursive filtering support (zlib-decompror and unescape decoder - basically are external filters for the locator engine). I have not released the new version yet, just was testing in and… wow!!! I met the exploit that really uses the nested JavaScripts for better obfuscation! well, just in time, just in time…
NOTE: if you have no idea how to write deURI decoder, download ECMA-262.pdf ("http://www.ecma-international.org/publications/standards/Ecma-262.htm") (ECMAScript Language Specification) and go to section “B.2.2 unescape (string)“. there you will find unescape decoder, written in pseodo-code.
the second (underlined) layer is not interested. it’s just Array with uneascape string contains the real shell-code includes well-known ["doc"]["Collab"]["getIcon"]. do they look familiar?! of course they do!!! it’s the old getIcon exploit, just more obfuscated.
now, about the shell-code. it’s very simple, don’t even encrypted. this is what my shell-code locator said:
+KRNL32 BASE ADDR PEB FINDER @ 00000019hok, open the file with HIEW, go to 19h offset and see:
XOR key: 00 00 00 00 (00000000h)
#GREEN
00000019: mov eax,[eax][0C]yep, a typical KERNEL32 base address finder. what’s else?! the most interesting thing is — the shell-code has text strings. just look at them:
0000001C: mov esi,[eax][1C]
0000001F: lodsd
00000020: mov eax,[eax][08]
00000023: jmps 00000002E —
URLMON.DLL, URLDownloadToFileA, update.exe, crash.php, http://viorfjoj-2.com/2/update.php?id=0
wow!!! the domain name!!! I checked it and found out that viorfjoj-2.com is down, so I went to who is who service and… ops! surprise!!!
WHOIS information for viorfjoj-2.com:Russian guy! that’s a deal! I have no idea whether he is the author of the exploit or maybe his server was used by another person, but I wonder… I wonder… going to give him a call tomorrow just out of curiosity.
* Registration Service Provided By: DOMAIN NAMES REGISTRAR REG.RU LTD.
* Contact: +7.4955801111
* Domain Name: VIORFJOJ-2.COM
Registrant:
Private person
Dmitry Ostupin (conroetxwelc@gmail.com)
ul. Malaya Semenovskaya, d.5, kv. 28
g. Moskva
g. Moskva,107023
RU
Tel. +7.4952240537
Creation Date: 08-Jul-2009
Expiration Date: 08-Jul-2010
well, maybe I should not public his contact info here because of etiquette, but… why not?! the exploit was taken from the public source, the hard-coded domain name was found, so… everyone can use the whois service to get this contact info.
well, what we’re going to do on ISP side? if you meet a packet from/to viorfjoj-2.com it means the host is infected and the packet should be blocked. well, since the server is down - obviously all major ISPs had blocked it already.
http://nezumi-lab.org/gif/pdf_fws_fake.pngfaked exploit on milw0rm - it has nothing to do with the real SWF security hole
http://nezumi-lab.org/blog/?p=227