Monthly Archives: September 2008

ClickJacking - The New Browser Security Threat

Leave a reply

The latest buzzword these days is “ClickJacking”. There is discussion about this going on in various places.

The basic exploit at work here is loading a web site (such as MySpace) in an IFRAME. You then cover the IFRAME with your own content (such as e.g. a very exciting monkey-punching game). Then you position shiny, clickable portions of your monkey-punching game so that they overlap user interface elements on the MySpace page. Thus when the user clicks on your monkeys he will in reality be executing some action on his MySpace account. This works because most often the cookie will be set for the MySpace page and the user will already be logged in. With some clever design the malicious page could get you to perform complex sequences of actions on the desired target page (think forwarding your entire GMail inbox to someone else).

So how do you protect yourself against this? So far there is no live malicious web page known to take advantage of this. Frankly, I think this is a bit overhyped at the moment. But if you’re worried, you need to disable IFRAMEs on your web browser. You can do this in a variety of ways. On Firefox (which unfortunately doesn’t have a way to disable IFRAMEs in its settings) you need to install the extension NoScript. Then bring up NoScript’s configuration dialog and enable the option “Forbid <IFRAME>”. This will disable IFRAMEs and keep you safe from ClickJacking attack.

So what’s the long-term solution to this? Various browser and HTML extensions have been proposed to deal with this. Personally I think that the safest solution is to prevent IFRAMEs from loading pages from an external domain unless the user specifically authorizes it. IFRAMEs are a horribly ugly crutch anyway, and if you’re relying on them in your web page you need to either fire your web designer or read up on better ways to accomplish the same thing without using them.

New Malicious Firefox Extension: FirestarterFox

Leave a reply

A malicious Firefox extension called FirestarterFox is being installed by some of the latest malware variants. This extension hijacks all search requests through Google, Yahoo and Microsoft Live search and redirects them through the Russian site thebestwebsearch.net. This is done with the intention of showing ads on the search results page which presumably make money for the creator of this piece of malware.

Luckily the extension can’t be silently installed since Firefox alerts users to all new extensions. So if you ever start Firefox and get the message that a new extension called FirestarterFox has been installed you will immediately know that you have malware on your system and should take steps to remove it or reformat your system.

New Anti-Rootkit Tool: Packed Driver Detector 0.9 Released

Leave a reply

We’ve just released the beta version of a new tool named Packed Driver Detector.

Download: http://www.misec.net/products/PDD.exe
(No installation required - simply run file.)

What does this thing do?

Drivers are system files that are used in kernel mode to execute system code. Rootkits use a driver (.sys) file to subvert the Windows kernel and hide their presence in the system. Recent rootkits have begun packing and/or encrypting their driver files to make them harder to detect.

This tool identifies packed driver files. On an uninfected system there should be no packed driver files. Use this tool to identify any packed driver files on your system.

How can I help?

This is the first beta release of Packed Driver Identifier. If you want to help out testing it, download and run it to scan your system. If the tool identifies any packed drivers, don’t panic. This is the first release of the tool and the identified files are very likely legitimate. Please email the detected driver files to [email protected] along with your scan log. We will analyze the files for you and tell you if they really are something to worry about.

It would be very helpful if you could post your scan report as a comment to this post even if no packed drivers are identified. This is to help verify that the tool is actually not reporting any packed files on most (presumably clean) systems.

How to terminate a process without calling TerminateProcess

Leave a reply

This is absolutely beautiful stuff that very few people will understand. I’m just putting it out here so that those who know can look at it and go “ah!”. This assembler code calls TerminateProcess by using the sysenter function. The first line of code executes a new process and stores its process handle in the variable called Handle.

Note that this code will only work on Windows XP since Win2K uses int 2e instead of sysenter to call the kernel. (Also won’t work on Vista as the syscall function number is different there — see this metasploit page for a table of the different system call numbers.)

  Handle := ExecNewProcess;
  asm
    push 0              // Exit code for the process we're terminating
    push Handle         // Handle of the process we're terminating
    push offset @@done  // Return address (not used)
    push offset @@done  // Return address

    mov eax, $101       // We want system function 0x101 = TerminateProcess
    mov edx, esp        // Save esp in edx so that syscall knows where our function parameters are
    mov ecx, offset @@done  // Save the address to return to in ecx

    sysenter           // Call the kernel!

    @@done:
    add esp, $0C       // Restore stack pointer
  end;

Old-School File Hiding

Leave a reply

A new sample came in today - an ad injector for Internet Explorer. I was analyzing it and noticed that the malware hid several of its key files. “Aha - a rootkit!” I thought and proceeded to find out how the trojan had hooked into the system to hide its traces. An SSDT hook perhaps, or maybe an injected user-mode DLL?

I looked and looked and couldn’t find a thing. No rootkit, no driver, no IAT modifications; nothing. Even stranger, the trojan seemed to have rootkitted the entire C:\Windows\system32 folder - it was invisible in Windows Explorer and couldn’t be seen when executing dir in a CMD prompt. That’s strange - why would a rootkit want to hide the system32 folder? If anything would tip you off that something is horribly wrong with your system, a missing system32 folder would be it (see figure 1 below).

Fig 1. Bad things are going on if you open up Explorer and see this.

After about an hour of looking for the rootkit and not finding it I started to get frustrated. So I decided to take another look at RegMon to see what the trojan was doing with the registry. That’s when I stumbled upon this:

Fig 2. The trojan modifies the ShowSuperHidden setting for Windows Explorer

The HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ShowSuperHidden determines whether or not Explorer shows files that have the hidden and system attribute set. It wasn’t a rootkit after all! The trojan simply disabled this setting and this caused all files with the system and hidden attribute to be invisible in Windows Explorer. And since the lab machine had the ShowSuperHidden setting enabled the trojan was hidden after performing the above registry tweak.

However, this didn’t explain why the files and folders were invisible in a Command Prompt as well. The explanation is obvious and simple: I had entered a simple “dir”. And since the system32 folder and the trojan files had attributes +h +s (hidden and system) set, they were hidden in the listing. Doing a “dir /ah” showed the missing files.

Moral of the story: Somtimes malware will use “old reliable” instead of messing about with a rootkit and drivers. So check the obvious stuff first before assuming it’s something more advanced.