Posts

Zero Day Protection with Privilege Management

Image
Have you used Internet Explorer to visit a malicious website recently? Have you used Internet Explorer to visit any website lately? How do you know for sure that you are not infected? On September 17, 2012 a zero-day vulnerability for Internet Explorer versions 6-9 was  reported  affecting everything from Windows XP to Windows 7 and Windows Servers. Zero-day vulnerabilities are a common fact of life, but the same old approaches to protection continue to be insufficient. Let’s discuss this vulnerability and how privilege management can mitigate the impact. In the case of this zero-day vulnerability, a malicious website can be crafted then unsuspecting victims can visit it with Internet Explorer only to be exploited. Once exploited, security software can be disabled, files are downloaded or malicious software is installed so that system can be reused as a zombie or SPAM relay. Traditional endpoint security technologies often struggle with zero-day vulnerabilities as there is no

New Internet Explorer zero day being exploited

Image
After the  last zero day exploit on Java  we reported some weeks ago it appears that a new 0day has been found in Internet Explorer by the same authors that created the Java one. Yesterday,  Eric Romang  reported the findings of a new exploit code on the same server that the Java 0day was found some weeks ago. The new vulnerability appears to affect Internet Explorer 7 and 8 and seems to be exploitable at least on Windows XP. The exploit code found in the server works as follow: - The file exploit.html creates the initial vector to exploit the vulnerability and loads the flash file Moh2010.swf. - Moh2010.swf is a flash file encrypted using  DoSWF .  We’ve seen the usage of DoSWF in the exploit code of other targeted attacks such as: -  Several Targeted Attacks exploiting Adobe Flash Player (CVE-2012-0779) The Flash file is in charge of doing the heap spray. Then it loads Protect.html Due to the usage of DoS

New Java 0day exploited in the wild

Image
A few hours ago, FireEye published some information related to a new Java 0day exploited in the wild. The malicious JAR file was served from ok.aa24.net / meeting / index.html The html loads the Java applet passing some parameters that are used later to build the URL to download the payload. The HTML is encrypted using “Dadong’s JSXX 0.44 VIP”. The Java applet contains the following two .class files: - cve2012xxxx/Gondzz.class - cve2012xxxx/Gondvv.class The applet check if the system is running Windows and gets the parameters passed from the HTML that contains the URL to download the payload. If the system is vulnerable, the payload is downloaded and executed in the system. On the analyzed sample the payload is downloaded from ok.aa24.net / meeting / hi.exe https://www.virustotal.com/file/09d10ae0f763e91982e1c276aad0b26a575840ad986b8f53553a4ea0a948200f/analysis/1346055031/ The payload drops C:\WINDOWS\system32\mspmsnsv.dll (replace the file if presen

Several Targeted Attacks exploiting Adobe Flash Player (CVE-2012-0779)

Image
A couple of days ago,  Adobe issued a security update for Adobe Flash Player  that has been detected in the wild targeting specific objectives. Several spear phishing campaigns have been detected. The mails sent contain a Word document attachment. It contains a reference to a Flash file that is downloaded from a remote server once the document is opened. This Flash file exploits the CVE-2012-0779 vulnerability triggering a shellcode that looks for the payload within the original word document. The payload is decoded using a one byte XOR scheme, dropped on the system and then executed. Most of the malicious Flash files have low AV detection rates so it is very important to apply the vendor’s patch. We have seen several documents sent to a wide range of industries as well as Tibet related NGO’s. Some examples are: Once the victim opens the document, the malicious Flash file is downloaded from a remote server: In the vast majority of the documents we have

Secure Sockets Layer (SSL)

Image
Secure Sockets Layer (SSL): How It Works What Happens When a Browser Encounters SSL > A browser attempts to connect to a website secured with SSL. > The browser requests that the web server identify itself. > The server sends the browser a copy of its SSL Certificate. > The browser checks whether it trusts the SSL Certificate. If so, it sends a    message to the server. > The server sends back a digitally signed acknowledgement to start an SSL encrypted session. > Encrypted data is shared between the browser and the server. Encryption Protects Data During Transmission Web servers and web browsers rely on the Secure Sockets Layer (SSL) protocol to help users protect their data during transfer by create a uniquely encrypted channel for private communications over the public Internet. Each SSL Certificate consists of a key pair as well as verified identification information. When a web browser (or client) points to a secured website, th
Secure Sockets Layer (SSL): How It Works What Happens When a Browser Encounters SSL A browser attempts to connect to a website secured with SSL. The  browser  requests that the web server identify itself. The  server  sends the browser a copy of its SSL Certificate. The  browser  checks whether it trusts the SSL Certificate. If so, it sends a message to the server. The  server  sends back a digitally signed acknowledgement to start an SSL encrypted session. Encrypted data is shared between the browser and the server . Encryption Protects Data During Transmission Web servers and web browsers rely on the Secure Sockets Layer (SSL) protocol to help users protect their data during transfer by create a uniquely  encrypted  channel for private communications over the public Internet. Each SSL Certificate consists of a  key pair as well as verified identification information . When a web browser (or client) points to a secured website, the server shares the public key with

Advice from a Victim of Identity Theft: Tips for Limiting the Damage (Part 2 of 2)

Image
Working in Internet security, I try to embrace the best practices that would prevent identity theft ( see my previous blog post: Advice from a Victim of Identity Theft: Preventative Measures ), but sometimes that’s not enough. Criminals managed to get my name, address, birth date, driver’s license number, bank account number, and social security number. My guess is that a company I do business with got hacked—and they probably don’t even know it. What did the criminals do with my personal information? They made a fake driver’s license and entered branches of my bank in India and withdrew money, emptying my bank account. Then they made fake checks and managed to cash them, overdrawing my account. They also made a second driver’s license and had someone in india open multiple new retail accounts in my name. How did I find out? I logged on to do some online banking and found my checking account drained. Later, I received a call from Target asking if I had opened a Target accoun