McAfee VirusScan has now been (incorrectly) flagging a file installed with TrojanHunter as malware for several weeks. We have contacted McAfee to get them to fix this false positive, but so far to no avail. One has to wonder if McAfee are doing a little creative “competition control” as they haven’t bothered replying to or taking action on our false positive report. No doubt several of their users must have contacted them about this as well by now.

People, if you’re emailing the technical support address because you have a problem with some software, here is a great example of what not to write:

I’m having a problem with the program.

While I’m sure some support technicians love Zen koans as much as the next guy, you might want to clarify exactly what problem you have running the program. All the above will lead to is another email where the support technician has to get back to you and ask what exactly the problem is.

Total Secure 2009 is a rogue anti-malware product (meaning it floods you with fake alerts about malware that you don’t actually have on your system). While analyzing the product for inclusion in the TrojanHunter detection database I experienced the annoying effects of this program first-hand.

There are lots of removal guides out there, but most of them miss a crucial file. This is a DLL file that is loaded into explorer.exe and causes incredibly annoying “warning” messages to appear when you browse folders in Windows Explorer. For all practical purposes it makes Windows Explorer useless.

The latest variants place the offending DLL file in C:\Windows\system32\ with the name sysbase32.dll. Note that it is difficult to remove this file manually while loaded into explorer.exe. I recommend booting into Safe Mode and removing the entire Total Secure 2009 folder from there, as well as the DLL file. The DLL file also changes names between releases, so use a signature-based scanning product like TrojanHunter to detect and remove it. Note that TrojanHunter is able to unload and remove the DLL file from a running system which is something that no other program is able to do at the moment.

A university student who discovered vulnerabilities in his school’s computer network, investigated them and then sent a full report of how to fix them to the administrators is currently awaiting trial on computer intrusion charges.

The 20-year old student from Ottawa, Ontario will hopefully have a shining career as a security expert some day. What he did could easily be labelled “penetration testing”, only in this case the university got the professional services for free instead of having to fork up $550 per hour.

Security Focus has more details.

Apparently you can’t get away forever with fooling users into thinking they have malware on their system when they really don’t, and then offering to sell them a “removal tool” that does absolutely nothing but remove the fake alerts.

The creators of such programs as Antivirus XP, Registry Cleaner XP and WinDefender are getting sued by Microsoft and the state of Washington under the state’s Computer Spyware Act which prohibits making false claims of spyware or malware on a system. The penalty is actual damages incurred or a punitive damage of $100,000 per offense, whichever is greater.

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.

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.

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 support@misec.net 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.

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;

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.