While I was writing a new detection for Downloader-BCA, something struck my eyes. I had an open window of IE with an address bar of an empty value! My first thought was that the application was still launching, but the page started appearing and no address was shown. So, I hit the ESC key, and then I found the address!

The video above demonsrates how that malware tried to hide the address of that page, and I had to press the ESC key few times in order to show the hidden value.

Since this has turned out to be a regular thing, I’ve decided to give this feature an official name: Simple Security. Security discussions don’t have to require you to have a degree in computer science for them to be useful, even though they can certainly sound that way. I opted for the simplest, most approachable name since I’m aiming to provide you with explanations in the most simple, approachable terms.

And now, on with the show!

While you may be in the privacy of your home reading this blog, by connecting to the internet you might as well be in Times Square. People may not be able to see that you’re reading this in your rattiest sweats (although maybe some of them can), but you’re interacting with people either directly or indirectly each time you get your email or surf the web. While most of us have a fair idea of how to deal with strangers while we’re out and about in real life, it doesn’t seem that most people understand the rules of dealing with strangers on the internet. And truly, to a certain extent everything on the internet should be considered a stranger initially. You can’t exactly sense email senders/websites to verify they are who they say they are like you would in person, so you need to be a little more thorough.

It’s not news to say that most email viruses are spoofed to appear to be from someone trustworthy. They can seem to be from your friends, your ISP, the FBI, an AV Company… anything that can make the request appear urgent or trustworthy to you. It is not rude, if an email comes to you unexpectedly with webpage links or attachments, to politely inquire whether someone intended to send you that email. (i.e. “did you mean to send this to me?” vs. “zOMG!!1!!1 YOU (%*&, YOU SENT ME A VIRUS!!!”) The email will either go to your friend, or to the ISP/FBI/AV company that’s probably gotten thousands of such inquiries - it’s not going to go back to the virus writer. If the email indicates that you should not reply to it, call the company it purports to be from, or go to their website from your own bookmark or by typing in the URL. Do not click the link in the email.

Now, if the email appears to be someone wholly unfamiliar to you, that’s an easy one. Dump it. Do not pass go, do not collect $200, just hit the Delete key. Again, it’s not considered impolite to do this, and it’s really the safest thing to do. It is, in all likelihood, either spam or a virus. By opening it, you’re essentially letting them into your computer, with all your valuable data. It’s just not worth the risk.

As for websites, this can be a bit trickier. There are some more clear-cut cases where the website itself is dodgy - warez sites, software-cracks sites, etc. If you’re getting stolen or hacked software, you run the risk of getting more than you bargained for, plain and simple. A website can also be basically innocent, yet still be problematic: Websites need to be protected and patched just like any other machine. Even big websites can be hacked to serve up nasty code to be dumped on you when you come to visit, like in the case of the recent ANI zero-day exploit.

If a website has 3rd-party ads, this can open another level of potential problems: Those ads may or may not be thoroughly vetted before they’re posted, especially if they’re a smaller or less reputable site. The ad-providers themselves could be malicious, or they could have been hacked. Either way, this is where we most often see “drive-by-downloads”.

You may be wondering now, is there such thing as a totally innocent website? Well, perhaps not 100%. No security is completely bullet-proof. But bigger, more reputable sites have a vested interest in making sure their security is better. That means they can be considered reasonably trustworthy once you’ve ascertained they are who they say they are (by typing in the URL, for instance, and seeing the expected site). Am I saying not to enjoy your favorite homegrown webpage? No, go ahead. Go to it through your own bookmark, and as long as everything is behaving as expected (not, for instance, asking for you to download some ActiveX component you’re not expecting), you’re probably fine.

The moral of the story is this: Your machine is full of valuable information which people would very much like to get at. It’s best to protect your valuables (with updated AV software, updated software patches, and a firewall) and treat every interaction with a bit of skepticism unless it’s happening wholly as you’d expect. You wouldn’t hand your wallet to someone off the street who says they’re from your bank, but if you actually go into your bank, you can reasonably expect a teller will ask you for your account number.

Next time on Simple Security: Critters “In the Wild” or “In the Zoo” - What does it mean to you?

(And as always, if you have a topic you’d like to see discussed in a future article, please leave us a note in the comments!)

In the past two weeks McAfee Avert Labs is observing activity by a new parasitic worm named W32/Almanahe.a. Apart from its parasitic nature, this worm is particularly interesting because of the rootkit technique implemented by it to hide and protect itself.

Some background:

Rootkit techniques vary from simple “user mode” to complex “kernel mode”. Most of the techniques create some kind of hook to the normal execution path of a call or an API. A more detailed explanation of various techniques can be read in the latest whitepaper by McAfee here.

As explained in the whitepaper, one widely adopted kernel mode hook technique is via SSDT patching as shown in Figure 1. In order to detect such rootkit activity many freely available tools exist along with traditional virus scanners. An easy way to detect such activity is to perform a quick range check on the addresses pointed to by functions listed in SSDT. If the address lies outside Ntoskrnl.exe address range, it implies that the SSDT may be hooked. For example in Figure 1, Rootkit.sys lies outside the address range of Ntoskrnl.exe. A query on address pointed to by hooked NtDeleteKey in SSDT will raise an alarm as it is within address range of Rootkit.sys. 

Figure 1. Common SSDT hook method. Note that Rootkit.sys
is outside the address range of Ntoskrnl.exe. 

W32/Almanahe approach to SSDT hooking

An easy yet efficient way to bypass a range check technique is to introduce a detour approach while keeping the entry point of detour within Ntoskrnl.exe image. Figure 2 illustrates this scenario.

Figure 2. SSDT hook by W32/Almanahe.sys. Detour is created
within Ntoskrnl.exe body to thwart some analysis tools. 

As shown in Figure 2, the address of NtDeleteKey entry in SSDT is within range of Ntoskrnl.exe. Tools that only check to see if address pointed to by a function in SSDT lies within this range will fail to find the rootkit activity.

W32/Almanahe uses this approach of creating a detour which starts within the Ntoskrnl.exe body. It searches for cavities between section boundaries to introduce its detour code. As an example, Figure 3 shows the memory of Ntoskrnl.exe taken from a clean XPSP1 system. Figure 4 shows the memory of Ntoskrnl.exe on an infected machine, the malicious device driver has successfully patched the cavity space.

Figure 3. Cavity between section boundaries in
Ntoskrnl.exe displayed in Windbg 

Figure 4. Patched cavity by W32/Almanahe.

Performance of various code/hook analyzers on W32/Almanahe infected system

We ran some quick tests on few freely available rootkit analysis tools and looked at their code/hook analysis components only. In the figures 5, 6, and 7 it is evident that hook/code analysis components of these tools fail to pin-point the offending rootkit file by just analyzing the SSDT.

Figure 5 is a snapshot of a range check based tool. It can be noted that it fails to realize that the SSDT is hooked.

Figure 5. SSDT hooks can’t be displayed using just range check methods.

Figure 6. SSDT hooks are visible, however the
hooking entity is displayed as Ntoskrnl.exe.

Other popular rootkit analyzers like IceSword and GMER do a little better where they are able to show that SSDT is hooked. However, they fail to point out the device driver responsible for creating a mismatch in SSDT table and display the hooking module as Ntoskrnl.exe itself. 

Figure 7. SSDT hooks are visible, however the hooking
entity is displayed as Ntoskrnl.exe.

It should be noted that since many of the rootkit analysis tools implement various other techniques to catch rootkits, they may still be able to warn the user of suspicious activity.

Conclusion

The detour approach implemented by W32/Almanahe is neither ground breaking, nor a novel idea, but it is the first instance of use in the wild, observed by McAfee Avert Labs. This is yet another testimony to the fact that rootkits in the wild are adopting new techniques to conceal their nefarious code and seep deeper into the kernel.  In order to correctly find out which device driver is creating the SSDT hooks, rootkit analysis tools will have to dig deeper to perform code analysis by following the control flow of the detour, thus giving them something more to work on in this never ending battle.

Recently Gartner slammed 3Com’s TippingPoint division for sponsoring zero day contests without giving the vendor Apple Inc. a chance to fix the flaws before their patch release. They apparently paid $10,000 bounty to Dino Dai Zovi, a well distinguished security researcher at the recent CanSecWest conference.

Wow! It is rather ironic that a security company, who presumably wants to protect customers, will first put everyone to risk, not notify the vendor on time, and then release signatures! The anti-virus community, long the target of (bogus) claims that they write viruses to make money, wouldn’t touch a contest like this with a barge-pole. In fact, even staunch full-disclosure advocates note the ethical disconnect implicit in security companies producing content earlier than their competitors via such initiatives (see http://blog.ncircle.com/archives/2005/08/3coms_zero_day_initiative_cest.html and our premier issue of Sage.)

As security vendors, our mission is to protect our customers and the internet community at-large , not to create hype and FUD by giving the world a chance to exploit unpatched flaws!! Failing to disclose to anyone leaves the good guys in the dark - but supporting irresponsible disclosure give the bad guys night vision…

As one of the Researchers responsible for the McAfee Avert Labs Security Advisories, my job is to find and report on issues that could affect our customer’s networks and resources in any number of negative ways.

Let’s face it, with vulnerabilities released almost constantly it’s extremely difficult for administrators to not only find all the latest threats, but to also map them to how well they can mitigate against them. Questions like, “Does my defense-in-depth strategy protect me against vulnerability X?” or “How does this new malware affect my remote VPN hosts?” will replace those sugar-plum dreams quicker than you can say ‘covered’. Vulnerabilities, exploits and patches are published at a pace that seems to increase daily. Sometimes these are coordinated in ‘responsible disclosure’ ways with coordinated researcher/vendor notification. More often than not however, they are not. Ever hear of the term ‘Zero Day’?

As the aforementioned threat researcher by trade, I would like to give you a little narrative about the basics one may follow to find and mitigate threats. You may not have the resources available to you such as several research teams that are dedicated to discovery like McAfee and others do, so just adjust to your size pond as necessary.

Step One. Grab your net.

You obviously want to have the biggest net possible to gather the most issues. This is true in threat discovery as well as in fishing (notice, no ‘ph’ pun here). Like the growing numbers of disclosures, the sheer numbers of sources can overwhelm. Just think - how many URLs are in your ’security favorites’? Or how many newsletters and RSS feeds do you subscribe to? Can you possibly cover them all? Sticking with the ‘heavy-weights’ is a safe bet for major issues, but what about one-offs that are published on obscure sites? Be sure to grab as many resources as feasible to use the biggest net.

Step Two. Evaluate the net.

Now that you have the mother-of-all fishnets, evaluate it. If the holes are too big, you may let the fish slip through. If the holes are too small, you can gather way more information than you could possibly use – let alone even care about. A local denial-of-service vulnerability in Joe Bob’s Digital 8-Track Player most likely does not warrant review. This is especially true when a vulnerability will certainly be popping up in a more widely-used application. Fishnets have holes for a reason. Pinpointing your sources can assist in making sure the holes are just the right size.

You may have resource limitations that limit the amount of data you can process - so relevance is important. Remember, pure security is about defending what you can –and- accepting the risk for what you can’t. (Of course, tell your boss that right?)

When looking for threats, evaluate the needs of your enterprise before-hand. A list of applications that can be found on any important host is a start. That way, when you discover an issue - you can reference this list and correlate quickly with what is important to you. Although really nice, an asset inventory application may not fit your budget. Script up some quick and dirty code to scan an Excel doc if need be. Just be sure that you are capturing only the relevant threats - information overload can become your enemy when attempting to determine a threat’s importance.

Step Three. Evaluate the catch.

So now you’ve thrown the net and pulled in the catch. That’s a lot of food – or is it? What you find in your net may range from the best-of-breed sport fish to the algae feeding bottom dwellers. You may not even know if they are edible.

Now you need to filter the most pressing issues. Risk ratings (another topic for another day) alone may or may not tell the whole story - there are few across-the-board standards for ratings. You need to just jump in and look at the threat and determine its potential impact. Ask yourself questions like: Does it execute code? Does it execute code remotely? Is user interaction needed? Is there a public exploit? Follow the Threat to its end-result if it was successfully exploited and make a list of ones to watch for, in order of importance.

You can now compare the list of issues with your defense audits. (You have done your audits to know what you’ve got to defend with, potential threat vectors, and user account access to name a few - right?) Follow the path an attacker may use from external and internal start points to the most valuable of assets that may be affected. Along these points you will know where your defenses lie. This will get you a list of changes that need to be made in order to mitigate, or that will allow you to have some time before patching.

Step Four. Fish Fry

Now that you have chosen the net, cast it, and sorted your catch, you can go out and fry up the perfect one that didn’t get away.

Armed with a plan, you can set about defending against the most potent of threats.

Yesterday Microsoft patched 19 vulnerabilities; among them are the DNS-RPC vulnerability that was exploited by botnets in April and the Word vulnerability that was first disclosed on this blog. One of the new vulnerabilities, the Exchange MIME decoding vulnerability, can be remotely exploited without user interaction and should get high priority if you are running Microsoft Exchange.

When creating the graphs below I realized that I wasn’t even a tiny bit surprised by the high number of patched vulnerabilities. Time will tell if we will return to the days when the number of monthly patches was in the single digits. For now, I seem to be used to the high number of patches on Patch-Tuesday probably helped by similar large patch releases by Oracle, Apple and other vendors.