exploit « M86 Security Labs Blog

Posts Tagged ‘exploit’

MIDI Files – Mid-Way to Infection

By Arseny Levin • January 31st, 2012 • Vulnerabilities

Microsoft’s January patch MS12-004 addressed a few vulnerabilities in Windows Media components. One particular issue, CVE-2012-0003, can be exploited via Windows Media Player ActiveX, as it leverages a heap overflow occurring in ‘midiOutPlayNextPolyEvent’ function within the Windows Multimedia Library, winmm.dll. The bad guys didn’t waste time and this vulnerability is now exploited in the wild as reported by Trend Micro. A Web page hosted on a South Korean site loads a maliciously crafted MIDI file and sprays the heap. The attacker utilizes the exploitation method presented in Nicolas Joly’s blog from VUPEN. The attack allocates an HTML element of a specific size and eventually overwrites some of its data, and thus achieves malicious code execution.

The author of this page used a Korean JavaScript obfuscator in order to obfuscate a large block of code which hides the shellcode, as can be seen in the following code snippet. In particular, the obfuscated code, generated by this tool, changes itself several times during execution.

The code also ensures that it is being executed only in Internet Explorer because that’s the only browser where this exploitation will be successful. After de-obfuscating the JavaScript code, we can analyze the shellcode itself. The author uses a common evading technique: XOR encryption, with a decrypting loop at the prologue. This technique is usually very effective against signature based detection engines.

Then the shellcode imports and calls URLDownloadToFileA to download the payload which is a packed executable, saving it with an ambiguous name such as “a.exe”.

The executable is a downloader which fetches additional malware with rootkit capabilities. The author of the attack did a decent job obfuscating the executable file, as can be seen by a Virustotal analysis:

All M86 Secure Web Gateway customers are protected from this attack by default without need to install any security update.

A new Adobe 0-day In the Wild – – But No Worries, You are Already Protected with Our Secure Web Gateway!

By Anat Davidi • December 7th, 2011 • Vulnerabilities

Yesterday Adobe released an advisory for a vulnerability in the Adobe Reader and Adobe Acrobat products. The vulnerability, titled ‘U3D Memory Corruption Vulnerability’ was part of a targeted attack and discovered by Lockheed Martin’s Computer Incident Response Team. This is not the first time a targeted attack has been aimed at the US defense industry.

This attack involves embedding a maliciously crafted Universal 3D (U3D) stream in a PDF file, one of several examples of attacks on embedded streams within PDF files, and represents a growing attack vector due to its ability to deal with defense mechanisms among which DEP and ASLR (two techniques meant to help prevent unauthorized code execution) using known techniques such as JIT Spraying.

According to Adobe’s blog post released alongside the advisory, Adobe is planning to release an update for Adobe Reader 9, the version targeted by this vulnerability, “no later than the week of December 12, 2011″. The rest of its supported versions will receive updates as part of their quarterly updates in January 2012.

M86 Secure Web Gateway, version 9.2 and above, provides zero-day protection against this attack, without requiring any further updates. Customers who wish to monitor the attack in their organization may look for attacks that are tagged with the “Adobe Universal 3D streams” block message.

We’re proud that our proactive rules block this new zero-day exploit and we’ll continue to work hard to provide this level of protection to our customers in the future.

Tags: 0day | Acrobat Reader | Adobe | CVE-2011-2462 | exploit | PDF | SWG

0-day exploit used in a targeted attack – CVE-2011-1255

By Avri Schneider • June 26th, 2011 • Cybercrime Malware Vulnerabilities

Time Element Memory Corruption – a remote code execution vulnerability, recently patched by Microsoft as part of MS11-050, bearing the Common Vulnerabilities and Exposures (CVE) number CVE-2011-1255 is being actively exploited in the wild.

M86 Security Labs team was contacted and asked to inspect the URL of a legitimate website of a large private company that was blocked by one of the proactive detection rules implemented in our Secure Web Gateway product.

We were asked to investigate if it was indeed a malicious page or a case of Over-Blocking.

The page looked benign, but inspecting each included JavaScript code, we saw that one of them:

Was injecting an iframe:

pointing to a malicious page that was very easilty classified as malicious due to shellcode patterns being part of the page’s DOM:

So, just another infected site – big deal right? But, after further inspection, we saw that it exploited an un-published security vulnerability in Internet Explorer. To verify this, we viewed the malicious page on the latest fully patched version of IE and saw a crash followed by execution of malicious code.

You can imagine the excitement on the team – finding a 0-day in the wild!

The excitement of finding a 0-day in the wild didn’t last that long, since soon after, Microsoft released details about this particular vulnerability.

Based on data we have reviewed from various sources, we can say with a high level of certainty, that the anonymous researcher who according to Microsoft’s security advisory, reported the vulnerability details to VeriSign iDefense, or at least one of his acquaintances, had used the vulnerability details for malicious purposes, as part of targeted attacks.

We decided that we should inspect the shellcode to see what the attacker was after. It used various anti-debugging tricks, but after decoding, it revealed a clear-text URL pointing to a malicious server already listed in our repository.

The attack sample stored in our repository was an attack for the well-known iepeers.dll vulnerability exploiting CVE-2010-0806.

It is interesting to note that the first saved sample of the attack was dated 21.3.10, while details of the vulnerability were reported and patched by Microsoft’s MS10-018 security patch for Internet Explorer on 30.3.10.

Two 0-day exploits served from the same server – impressive!

We wanted to find out where else he is serving his malicious code.

Remember the code snippet shown above, showing how the attacker hid the shellcode as part of the DOM?

Hiding data in the DOM of the page is a good obfuscation technique that bypasses security software that doesn’t act as an actual browser, and where their script engine does not have access to the actual DOM.

It turns out that one of the side-effects of hiding data inside DIV elements is that it makes the data indexable by search engines.

Google searching the pattern “TTu0d0f[...snip...]d0dLL1043416UU” revealed about 16 results and as of this writing, only a few were still alive.

Here is the list of the infected sites according to Google’s search result:

Not to mention the service of caching samples for us, it’s ironic that an attacker’s obfuscation technique can be used against him to find his infection servers using a simple Google search.

Tags: 0day | CVE-2011-1255 | exploit | Internet Explorer

Who’s looking for eggs in your PDF?

By Avri Schneider • November 18th, 2010 • Vulnerabilities

At M86 Security Labs, we research various attacks on a daily basis. Some of these attacks originate from malicious PDF files.

One distinctive characteristic of malicious PDF files is a chunk of javascript code performing a heap-spray on the client browser, filling it with NOP (No OPeration) instructions (also acting as a valid heap memory address) – followed by the attacker’s shellcode; then triggering a bug in the PDF reader, which directs the flow of execution to a random memory location on the sprayed heap, executing the NOP sled followed by the shellcode.

While investigating the latest PDF 0day exploit [CVE-2010-4091, Extraexploit, VUPEN, Original Full-Disclosure post] that was published to the Full-Disclosure mailing list, we noticed something interesting – the shellcode part of the malicious javascript code was very tiny:

Here’s a disassembly view of the shellcode:

What we’re seeing is a known shellcode technique called Egghunting, where the shellcode itself is very small (usually free of Null bytes) and it’s sole purpose is to search the memory space of the process for the real shellcode, and on some more advanced versions for one or more parts of the reall shellcode – collect all the pieces together, then execute the found shellcode.

It’s used mainly in types of attack that prevent the attacker from placing a large amount of shellcode at the point where he is able to gain control of code execution, while being able to control data in the memory space of the process yet lacking the exact memory address location of the controllable data.

Notice how the egghunter shellcode uses int 0x2e to call the nt!NtDisplayString kernel function, passing it a pointer to the address to check on the stack (the edx register points to the user-land stack while eax is the System Service Code – an index to the nt!KiServiceTable pointer array, pointing to the nt!NtDisplayString function). You can read more about “How do windows NT system calls really work?” in this great article.

If the memory address is un-mapped in the address space of the process, an access violation will occur and the return value in the eax register will be 0xc0000005 (STATUS_ACCESS_VIOLATION).

The egghunter shellcode compares the low byte of eax to 5, indicating un-mapped memory and increments the address to check on each loop iteration.

Each mapped memory region is searched for the pattern \x90\x50\x90\x58 which translates to:

90 – NOP
50 – PUSH EAX
90 – NOP
58 – POP EAX

- A ‘non-intrusive’ marker (‘NOP’) indicating the beginning of the real shellcode.

Once found – the egghunter jumps to the address and continues execution from there.

As a side-note, this particular sample is not functional – i.e. when the vulnerability is triggered by executing the this.printSept() javascript code, the egghunter shellcode is never executed – crashing the browser.

It would nevertheless be interesting to see were egg-hunting exploits do decide to place the real shellcode in future PDF attacks.

Finjan prevents 0-day exploit of Adobe Acrobat Reader and Flash player vulnerability

By Anonymous • July 23rd, 2009 • Vulnerabilities

Finjan’s Malicious Code Research Center (MCRC) has detected yet another case of a 0-day attack “in the wild”. This time, hackers are exploiting a vulnerability (CVE-2009-1862) in Adobe Acrobat/Reader and Flash player. By exploiting this vulnerability, the hackers can download and execute malicious code on the victim’s PC. According to Adobe, an update will be available only on July 31, 2009; leaving end users’ PC in the mean time unprotected.
As with the previous 0-day attacks we reported, Finjan’s unified Secure Web Gateway (SWG) successfully detected and prevented the attempt to exploit the vulnerability and to execute code. By utilizing its patented real-time content inspection technology, Finjan’s SWG proactively prevented the attack without any update.
As discovered by the MCRC research, the attack is being used on compromised website containing a script tag that loads the exploit from a remote malicious server. The malicious script uses heap spray technique to load the attack Shellcode and than loads a malcrafted Flash file that triggers the vulnerability.
Following is a code snippet of the malicious script:

Another interesting aspect of this exploit is that the embedded Shellcode in the script loads an obfuscated executable. This simple obfuscation is done in order to evade detection by signature-based security products. The downloaded malicious executable creates a Trojan DLL named “wmimachine2.dll” and registers it as service on the victim’s PC.
When posting the exploit on VirusTotal, we found that none of the 40 Anti-Virus products detected it as malicious.

Posting the Malicious script ended with a similar result – no detection.

Posting the Malicious flash file ended with the same result – no detection

Posting the Obfuscated payload ended with the same result – no detection.
When browsing to the compromised site serving the 0-day attack via Finjan’s unified secure web gateway, users are protected as can be seen below:

Posted by Golan Yosef

About window of vulnerability (and MS08-017)

By Anonymous • March 17th, 2008 • Vulnerabilities

We here at the MCRC conduct independent vulnerabilities research once in a while, in order to provide our customers the best protection we can offer. The last MS security update included fixes for 2 vulnerabilities in the MS Office Web Component that we have discovered, one of which (CVE-2007-1201) was reported to Microsoft two years ago (!!). This means a 2 year long window of vulnerability. Needless to say, Finjan customers have been protected for the last 2 years against exploitation of this vulnerability, even at times when this vulnerability has been used in the wild with no patch available.
The fact, that it took Microsoft 2 years to fix this vulnerability does put our vulnerability disclosure policy (responsible disclosure) under quite a strain.
The exploitation of this vulnerability takes a couple lines of code, and would leave the machine with the following register dump (pending the shellcode used…):
EAX 00000000
ECX 01D62000
EDX 057D0010
EBX 00000050
ESP 01D633B8 UNICODE “AAAAAAA..AAAAAAAAAAAA”
EBP 01D63908 UNICODE “AAAAAAA..AAAAAAAAAAAA”
ESI 00000000
EDI 06830010
EIP 00410041 iexplore.00410041
Until next time
Posted by Golan Yosef

Tags: exploit | MS08-017

BlackHat USA 2007 / DefCon 15 – some notes

By Anonymous • September 20th, 2007 • Cybercrime Malware Vulnerabilities

Dangling Pointer … Jonathan Afek

Dangling pointers are pointers that do not point to a valid object of the appropriate type, or to a distinguished null pointer value in languages which support this. It can be caused when an object is deleted or de-allocated, without modifying the value of the pointer, so that the pointer still points to the memory location of the de-allocated memory.

If the pointer is used to make a virtual function call, a different address (possibly pointing at exploit code) may be called due to the vtable pointer being overwritten. Alternatively, if the pointer is used for writing to memory, some other data structure may be corrupted.

Nevertheless, Java-based applications are not vulnerable to this exploit because the language has a built-in mechanism for de-allocating memory.

Jonathan and Adi found that they could cause the crash Web server intentionally by sending a specially crafted URL to the server and found a way to run their own code on the target machine.

Tactical Exploitation HD Moore & Valsmith

One of the most popular briefings was “Tactical Exploitation” by H.D. Moore of Metasploit , and Valsmith from offensive-computing (No place to sit or stand).

They talked about how to correctly pen-test an organization – not just by blindly using exploit code. They presented a number of tools that are not available yet but should be soon as new modules for Metasploit.

The first half of the talk focused on some lesser-known discovery and fingerprinting method, and more-known tools. They showed how to collect information (reconnaissance) on the target (person/network) as the first step of the penetrating testing process. A few examples were shown, using third-party services, such as DomainTools.com and others (such as using the web interface to Paterva’s – http://www.paterva.com/evolution.html ).Old techniques (such as reverse DNS, zone transfer) and more active technique (using SMTP bounces, brute force HTTP virtual host)

The first half ended up with some examples of real-life service fingerprinting, including graphing the traffic activity for a particular web site.

They discussed firewall discovery, client applications discovery, and even process discovery.

The second half of the talk discussed some topics, such as entry points into the external network, and issues caused by using NAS devices as file servers. It led into a discussion of NTLM hijacking, NFS tricks, abuse of the OpenSSH master mode, and a demo of stealing Kerberos tickets.
More technical stuff – http://metasploit.com/confs/blackhat2007/tactical_paper.pdf

Building and Breaking the Browser (Window Snyder)

The Mozila security crew selected a transparent approach and shared their knowledge regarding the weaknesses of their software.

One of the values from this approach can be seen by the release of tools such as the http fuzzer they have spoken about in the convection. The fuzzer is used against JavaScript.

They claim that the fuzzer has already produced some findings and released it to the public after the meeting.

One of the points mentioned in the talk was the plan to create a “blocking page” much like other security products currently offer. This is due in the next version they will release.

CaffeineMonkey: Automated Collection, Detection and Analysis of Malicious JavaScript
Ben Feinstein, Daniel Peck

The authors present a software framework for the automated collection of JavaScript from the wild that they have developed. The goal is identification of malicious code, and characteristic analysis of malicious code once identified.

The focus of the lecture was on attacks using JavaScript for obfuscation or exploitation, such as “white spaces randomization, string encoding, string splitting, and integer obfuscation.”

They presented findings & analysis based on the deployment of a distributed network of “CaffeineMonkeys”, and their method using honey clients and “behavior analysis” that was not detailed, to identify malicious code.

This was a rather reassuring lecture for us – as we know obfuscated code as highly sophisticated decryption functions that process extremely jumbled inputs that turn into malicious code (see the recent analysis of such obfuscators in the latest Malicious Page of the Month, and a couple of posts by other MCRC members). Seems like we are still ahead of the curve…

Posted by Amir Davidi

Tags: exploit | Exploit Kits | Javascript | Obfuscation | Vulnerabilities