Online Virus / Malware News

Just after Adobe released its out-of-band patch for CVE-2010-2862, we discovered a malware exploiting a new zero-day vulnerability in the wild. Similar to the iOS PDF jailbreak vulnerability and CVE-2010-2862, this zero day occurs while Adobe Reader is parsing TrueType Fonts. We’ve analyzed and confirmed that the vulnerability affects the latest Adobe Reader, Version 9.3.4.

This zero-day vulnerability is a typical stack buffer overflow; exploitation of this issue is expected to be relatively easy. Although the latest version of Reader has been compiled with stack protection (/GS), the exploit uses an Return Oriented Exploitation (ROP) technique to bypass /GS protection and data execution prevention (DEP).

We saw a similar technique used to exploit an older Adobe TIFF parsing vulnerability. All this seems to point to the fact that ROP is gaining wider acceptance by malware writers to bypass DEP and existing stack protections.

McAfee Labs is coordinating with Adobe PSIRT, and we’ve provided them with additional details on the bug. The Adobe team is actively working on this issue, although there is no patch available at the time of writing this blog. Adobe Acrobat users are urged to update their security definitions for the various products.

McAfee protection to date:

• McAfee Network Security Platform: Coverage provided under the signature 0×40293c00, UDS-HTTP: Adobe Reader Unspecified Buffer Overflow
• DAT files: Coverage for known exploits provided in the 6099 DAT release under the signature Exploit-PDF.ps.gen
• Host IPS: Generic buffer overflow protection provides partial coverage
• Foundstone: The FSL package of September 8 includes a vulnerability check to assess if your systems are at risk

The Anti-Malware engine is a critical and core piece of the McAfee anti-malware solutions. As with any core technology, the engine must be rock-solid stable, fast, and functionally rich.

A new McAfee Labs whitepaper outlines these engine technologies and values, covering both endpoint and gateway uses. Beyond introductions to malware detection methodologies–ranging from exact detection to heuristics, and technologies from exploit detection to cloud-based detection, the new paper especially outlines McAfee’s approach to Cooperative Anti-Malware on Endpoint and Gateway. “Cooperative” in this case refers to the added value of combining anti-malware on the endpoint and on the gateway: a true defense-in-depth strategy in action.

In this defense-in-depth implementation we have engine technologies that are optimized for the endpoint and the gateway, respectively, and both are connected through our Global Threat Intelligence back-end, or “cloud.” This combination allows strict enforcement and the highest proactive catch rates at the network perimeter, keeping the majority of threats outside of your network, and effectively and accurately protecting the desktops in an enterprise as well.

Download and read it now!

While reading Microsoft’s confirmation of the DLL preloading risks in arbitrary Windows applications vulnerability, somehow it reminded me of the wave of LD_PRELOAD vulnerabilities that were exploited many years back on multiple non-Windows-based systems. It’s not a new class of vulnerability; the recent LNK file zero-day was probably the last biggest flaw that allows untrusted components to be loaded using a legitimate technique designed into the system.

I had the privilege to speak with a few McAfee customers during the outbreak of LNK exploits and one of the most frequent questions they asked was how it could have been possible without any buffer overflow. Lately, security practitioners had been putting a lot of focus on fuzzing and buffer overflow protection against zero-day vulnerabilities, but these design flaws in general operating systems and applications are allowing libraries and executable objects to be loaded from untrusted locations without exploiting any buffer overflow or memory corruption–by legitimate design.

The original advisory used iTunes as an example, but the same flaw is likely to exist in many applications. The attacker can plant a document or media file on a remote location that is opened by the application which loads external libraries insecurely. When the file is opened, a malicious library can be loaded from the remote location.

In the following example, a Microsoft application loads a document file “screen” from network drive Q:\ and tries to search for a DLL it requires on the same drive Q:\.

The DLL is loaded and running from the network drive Q:\.

McAfee VirusScan Enterprise users may choose to configure, and test, access protection rules to prevent access of at least “*.dll” and “*.ocx” from untrusted file locations where you share documents but are unlikely to be loading program libraries from:

In this case, notepad.exe tries to read a DLL from a network drive and the operation is prevented:

Note: This rule may also block nonmalicious applications from running on network drives and should be tested in each environment.

McAfee Labs is closely monitoring the exploitation of this technique in the wild and will provide more information as we find it.

Like many iPhone users, I “jailbreak” my iPhone. I do this for many reasons, but mainly for console-level access and the darn cool infosec tools that are available through Cydia. Like many iPhone users, I was quite happy when the Electronic Frontier Foundation (EFF) was able to get jailbreaking included under “fair use” within the Digital Millennium Copyright Act. Like many iPhone users, I was also very happy to learn that Dev-Team would soon make remote jailbreaking possible by simply visiting their jailbreakme website. Alas my happiness was not to last.

While still at Defcon, I saw through Twitter that one exploit or another was being used to remotely jailbreak the iPhone. (I believe the first tweets I saw were from Brian Krebs.) I then saw posts from VUPEN that several flaws were being exploited. From their advisory:

Technical Description

http://www.vupen.com/english/advisories/2010/1992

Did you notice the line “VUPEN is not aware of any vendor-supplied patch”? In the security business we call those zero-day vulnerabilities. We call code that takes advantage of zero-day vulnerabilities zero-day exploits. (I have not seen confirmation from Apple that these are in fact zero-day vulnerabilities, so keep that in mind).

I hope I am not the only one who is bothered by this because it begs the question “What else can this be used for?” Vulnerabilities with reliable exploit code tend to get reused and repurposed for other attacks/malware/uses. Just look at the .LNK vulnerability that Microsoft fixed yesterday via an out-of-band patch. It originally targeted power-plant control systems as the Stuxnet worm and then appeared in more mainstream malware because it was an unpatched vulnerability with working exploit code. Read this article in The Register for a real nice breakdown of it.

This should serve as a wake-up call for anyone with a mobile device: Remote exploitation is real and here to stay. For now these vulnerabilities are being used only (as far as we know) to jailbreak iPhones, but they could be used to do many other things to iPhones and their owners around the world.

As McAfee Labs predicted in a previous blog post regarding the Microsoft Windows Shell .LNK vulnerability, it was just a matter of time before malware started using Exploit-CVE2010-2568 to take advantage of this new Microsoft zero-day flaw. The flaw is described in CVE-2010-2568.

First, there was talk about PWS-Zbot (a.k.a. Zeus) using the vulnerability in encrypted emails that contained the malicious .LNK file(s); then our research team found a new variant of Downloader-CJX that extended its previous .LNK propagation strategy using social engineering with the new Exploit-CVE2010-2568 .LNK files.

Downloader-CJX is a malware family that installs .LNK files mimicking current Windows and user folders such as Music, Documents, or New Folder. The malware changes the attributes of the real folder to hide it from Explorer, and drops the .LNK files with folder icons, so the user is lured into clicking on these malicious links that appear as legitimate folders. These .LNK files are detected as Downloader-CJX!lnk when found in an infected machine.

The new variant drops additional files on infected systems:

The file x.exe is another copy of Downloader-CJX that in turn drops xxx.dll, a DLL component of Downloader-CJX.

The additional .LNK files exploit the CVE-2010-2568 vulnerability, enabling the malware to load the DLL file when users browse the folder.

These .LNK files are already detected as Exploit-CVE-2010-2568 and the new Downloader-CJX variant as Downloader-CJX.gen.g.

We offer you yet another reminder to keep your anti-malware software updated with the latest DATs, because the bad guys are always updating their software, too.

Today Microsoft updated the security advisory that was initially published last Friday (July 16), stating that they’re working on issuing a security patch for this vulnerability. Earlier, malware exploiting this issue was found in the wild. Researchers at McAfee Labs have been busy tracking this issue over the weekend and we have come up with some more quick Q&A’s.

1. What is the issue with .LNK files and how can it be exploited?
A. McAfee Labs researchers analyzed malware that was exploiting a design flaw in parsing shortcut (.LNK) files. This issue gets triggered because the Windows Shell component does not validate parameters sent out in the shortcut. This issue can be exploited via any mechanism that makes the user load the icon of the .LNK file.

2. Does the malware need a payload (shellcode) to exploit this flaw?
A. Since this is a design issue in the way shortcuts are parsed, no malicious payload (shellcode) is required to exploit this flaw. The .LNK file needs to point to a malicious file, the path of which needs to be hardcoded in the shortcut.

3. What are the requirements to successfully exploit this flaw?
A. This flaw can be triggered when Windows Explorer or Internet Explorer tries to render a malformed .LNK file that points to a malicious executable. The user need not double-click on the .LNK file to trigger the vulnerability; just opening the folder containing the malicious shortcut is enough to get infected.

4. What are the most likely attack vectors used to exploit this vulnerability?
A. USB drives are likely to be affected the most. The malware discovered in the wild was exploiting this issue via a USB drive. File sharing over SMB is another likely vector to exploit this flaw and this can lead to widespread malware infections over internal networks. WebDAV shares are equally susceptible to exploitation.

5. What are the affected platforms?
A. Microsoft has acknowledged that all supported platforms are affected. More details are available in the Microsoft security advisory. Windows XP SP2 is not listed in the list of affected platforms from Microsoft, so there is a chance of Windows XP SP2 users might remain vulnerable.

6. How widely is the issue being exploited?
A. The issue is known to be exploited by malware in the wild. Initial attacks were limited. However, an exploit module in metasploit was published today that uses WebDAV shares as an exploit vector. We expect wider exploitation of this issue. Users should keep their anti-virus software updated with the latest DATs (signatures).

We’ll keep our readers updated on this issue as we analyze more malware and techniques used by malware writers to exploit this flaw.

Malware authors have long taken advantage of high-profile incidents and trends to infect naive Internet users with malware. Historically, we have come across innumerable incidents like Michael Jackson’s demise or the Benazir Bhutto assassination as an avenue to spread malware.

We have seen instances from recent times where FIFA World Cup themes have been extensively used as bait to lure unsuspecting users into opening malicious attachments. With lots of recently discovered vulnerabilities and widespread distribution, PDF files are a perfect vector for these kind of attacks. These threats can be delivered as emails or poisoned search-engine results leading to malicious PDFs.

This particular PDF file is directed at certain high-profile targets. Upon executing the malicious PDF file on a vulnerable version of Adobe Reader or Acrobat, it drops an innocent PDF file as shown in the figure below to spoof the unsuspecting user.

This PDF exploits a vulnerability in the way Adobe Acrobat and Reader handle TIFF files and affects all Versions 9.3 and earlier.

This malicious PDF drops and executes a malicious payload detected as BackDoor-ERZ, while the malicious PDF is detected as Exploit-pdf.b with McAfee’s 6022 DATs.

The news that Google is supposedly dropping Microsoft Windows is spreading like wildfire all over the Internet today. Without getting into any “which OS is better or more secure” holy war, let’s review some facts to see if this “decision” has any basis in reality. (I caution readers to remember this is not confirmed, even if it is true.)

The supposed cause of this change is Operation Aurora, the attack that affected Google and many other companies. From the McAfee Labs Threat Center:

“Operation Aurora was a coordinated attack which included a piece of computer code that exploits the Microsoft Internet Explorer vulnerability to gain access to computer systems. This exploit is then extended to download and activate malware within the systems. The attack, which was initiated surreptitiously when targeted users accessed a malicious web page (likely because they believed it to be reputable), ultimately connected those computer systems to a remote server. That connection was used to steal company intellectual property and, according to Google, additionally gain access to user accounts.”

What many people fail to realize is that Operation Aurora was not really about any technical issues.

But you may ask “Marcus, how can you possibly say that? Have you gone mad? Aurora 0wned multiple computers on multiple networks! They were all running that evil Microsoft Windows. Surely removing Windows will solve all the problems!”

These objections are not even close to the real issue. Sure, the attackers used a very effective zero-day vulnerability. And, certainly, they used lots of evasion techniques in delivering the payload? But the real vulnerability has not been discussed.

People were the weak link.

The attackers who launched Operation Aurora knew their targets well from both corporate and personal viewpoints. They knew what their victims were running and what their roles were. The attackers even knew what application versions they used. (Ever wonder why the zero-day was limited in effectiveness to Internet Explorer Version 6 when the attack commenced? The attackers knew that was all they needed.)

The intel that the attackers gathered to make Operation Aurora work is what made it a success–not the operating system involved. The targets were the people.

Would it make any difference if the victims were running Linux or any other operating system if an attacker builds such a sophisticated profile? Not remotely. Linux, Windows, Mac, whatever–everything has weaknesses. Especially the users of those systems.

When an attacker knows the details of a company’s technical deployment and personnel to the level we saw in Operation Aurora, the difference between one operating system and another is irrelevant. Any system or network can be technically compromised. Likewise, malware can be written for any operating system.

If determined attackers and gatherers of intelligence invest the time to get to know their targets–their behaviors, likes, dislikes, technical backgrounds, job roles, etc.–the actual exploit is trivial. All they have to do is get their victims to click a link. The more they know about their targets, the more likely users will click it.

Social engineering and intelligence gathering trumps technology every time. It always has and always will.

Today’s cybercriminals frequently use “exploit packs” to easily snare victims for their botnets. Users with underprotected computers who visit booby-trapped websites become the latest botnet zombies. I often receive requests asking me which exploit packs are current and which vulnerabilities they use.

To answer these inquiries, I’ve created a table that lists the exploits referenced by their Common Vulnerabilities & Exposures (CVE) names and their related kits. (Click on the image to enlarge it.)

Looking at this table, we can see that the most up-to-date kit is Crimepack.
Version 3.0 alpha is in the wild. In March 2010, Version 2.2.1 was offered for $400.

Next is the Phoenix Exploit Kit. Its price was around $400 in November 2009.

The Eleonore exploit pack is another popular tool. It was recently in the news after the hack of the United States Treasury website. In February 2010, Version 1.3.2 sold for $1,200. In July 2009, the Version 1.2 went for $700 plus $50 for an encrypter. For $1,500, buyers received a version allowing them to manage the tool through their own domains.

Next we have Fragus ($800), Yes Exploit Kit, and Siberia. In April 2010, the Yes Exploit Kit Standard Edition sold for $900. For an additional $250, buyers could include an “abuse-immunity” Virtual Private Server for one month and two “abuse-immunity” domains.

In the final four columns you’ll find the oldest common tools, offered from 2006 to 2008: El Fiesta, Icepack, MPack. and WebAttacker.

I was just reading Byron Acohido’s writeup on Microsoft ending security support for patches for Windows XP Service Pack 2 and Windows 2000. Now as I work for a vendor myself I completely understand why Microsoft is going EOL (or is it EOS for end-of-support?? I forget…) for these operating systems – better, more robust OS choices exist and no company has unlimited resources to support application and technologies that have seen better days.

I get that, I really do. I do, however, think some larger issues certainly loom:

1. Legacy applications that will not run on higher patch builds
2. Point-of-Sale and embedded devices (think ATM’s an such….) ESPECIALLY if you have a global deployment
3. Patching and upgrading is never easy anyway
4. The agility of cybercriminals

Now I will also concede that its relatively straightforward to compromise a fully patched system. The tools and techniques are readily and easily available if you have a browser and even limited Google search skills – but let’s also be honest: its WAY easier to own an older unpatched build especially when all the vulnerabilities that XP Service Pack 2 and Windows 2000 have are so well documented and available. Malware also tends to be fairly backwards compatible in many cases.

I am not so certain this will cause a great shift in toolkits or focus of your average malware writer or cybercriminal. I DO think it is an excellent opportunity for scammers tho. Just think of the spam campaigns or link spam possibilities – its a great lure.

“MS has stopped support for XP Service Pack 2 click here for low cost upgrades!!!”
“Your machine seems to be running Windows 2000. Click here to upgrade to Windows 7 for a low price.!”

I can see the spam runs, phishing sites and associated fake-av installs now… Be forewarned my friends. And is it just me or is whitelisting and application control looking better and better??