Thursday, July 30, 2009

Conficker on the rise - again!

The infamous Conficker computer virus (also known as Downup, Downadup and Kido) appears to be making a comeback. In this past week we've seen two clients from different industries attacked by this worm. The worm uses a combination of advanced malware techniques, which has made it difficult to counter and has since spread rapidly into what is now believed to be the largest computer worm infection since the 2003 SQL Slammer.

At a minimum, all your computer systems should be updated with the latest virus definations and Microsoft has released a removal guide for the worm, and recommends using the current release of its Windows Malicious Software Removal Tool to remove the worm, then applying the patch to prevent re-infection.

Read more!

Tuesday, July 28, 2009

Launching Exploits with Browser Detection

I recently published the latest FireFox 3.5 Heap Spray exploit to the public. This vulnerability took advantage of a font tag overflow which ultimately allowed the attacker to perform a heap based spray and execute code on the remote system.

A little basic background on heap sprays, they are relatively simple to exploit. The attacker essentially fills the heap with tons of "nops" (no operation) (in this case 0c0c0c0c which ends up being our return address) and ultimately the shellcode. When the return address is overwritten, it will point to a place in the heap (0c0c0c0c) which is a pretty good shot will be somewhere in our nops and ultimately continue to process no operations until we hit our shellcode. The reason why these exploits are not 100 percent successful is while we have a good percentage (typically 90-95% clip sometimes smaller) to hit our nops and ultimately our shellcode, sometimes we can land in the heap where we haven't overwritten everything, or in the middle of our shellcode, which would produce a crash.

Take a peek at the exploit code here: http://www.milw0rm.com/exploits/9181

Basically, the exploit will setup a webserver on port 80, you then connect a FireFox 3.5 browser (already patched by the way) it will trigger the overflow, spray the heap, and ultimately execute a bind shell on port 5500. This exploit code is inefficient in major way because it will attempt this exploit on anyone connecting to it regardless of browser, OS, or whatnot. More importantly, this exploit is ONLY for Windows based systems. To have a little more fun with this one, I decided to craft it a little differently now that the patch is out. We can make this much more reliable and efficient but throwing in some simple browser javascript detection and make this more of a universal exploit for a variety of different operating systems. If you look at the latest Fast-Track commit:

http://svn.thepentest.com/fasttrack/bin/exploits/firefox35.py

I've taken a few steps to allow you to attack both OSX, Windows, and Linux systems.

First lets take a peek at the first line:

// Initial detection for Firefox.
if (navigator.userAgent.indexOf("Firefox") != -1)
{

This will detect if FireFox is present, if so, continue on:

// Detect Windows and Linux
if (navigator.appVersion.indexOf("Win") !=-1)

If the OS is Windows, then set the payload and nops/return address to Windows based systems.

// Detect OSX and Firefox
else if (navigator.appVersion.indexOf("Mac") !=-1)

If browser is "Mac" then load the payload and nops/return address to Mac based systems.

// Detect Linux and Firefox
else if (navigator.appVersion.indexOf("X11") !=-1)

If system is *NIX, then load the payload and nops/return address to *NIX based systems. In this instance, it will only cause a FireFox crash.

Next:

else
{
window.location="about:blank"
}

If none of the criteria are met, then just load a blank page. This is useful for us when we have something like Internet Explorer or Safari that we know is not vulnerable, no need to actually execute the exploit right?

Alternatively using python it is also just as easy. I'll blog later on the method about detecting user-agents within the HTTP server within Python and handling those requests to perform the same functionality.

Read more!