This is tragic news, indeed. We have heard of software flaws costing customers hefty amounts of money, man hours, bandwidth, disk space, etc. But now the cost has reached an unprecedented level–causing HyperVM’s creator to apparently commit suicide. The problem started earlier this week, when a large web host company that relied on HyperVM to manage their VPS had more than 100,000 websites of their customers destroyed by an attacker who used a zero-day exploit in HyperVM. A few hours later, K. T. Ligesh, the 32-year-old Bangalore-based developer was found dead on Monday, leaving behind him plenty of worried customers who were left with their VPS installations unpatched. Vulnerability discovery in security research is of the utmost importance and so is ethical disclosure. Zero-day vulnerabilities and their exploit counterparts cannot only cost businesses money, but now it seems (if the reports are correct) they can also cost lives.

Our condolences to Mr. Ligesh’s family.

Today we at McAfee Avert Labs released an excellent paper on browser attacks. Written by Christoph Alme, this paper deals with the many complexities of browser security and attacks. From the paper:

Web Browsers: An Emerging Platform Under Attack
“The widespread use of highly interactive “rich client” web applications for e-commerce, business networking, and online collaboration has finally catapulted web browsers from straightforward HTML viewers to a full-blown software platform. And as corporate users are performing a significant portion of their work on the web, whether it’s researching or collaborating, the safety of the underlying platform is critical to the company’s success. ”

Other areas the paper covers include:

• The shift in spam to mainly malicious web link usage

• “Web 2.0” sites—whether weblogs, social networking or portal sites—are increasingly spammed with links to malicious sites

• Legitimate sites are compromised and misused to either host malicious code or link to a malicious website

• Use of malicious video banners placed in advertisement networks

• Use of popular search terms to advertise and drive (search query) traffic to a malicious website. In a recent case in Germany, attackers used Google AdWords to attract users who searched for “flash player” to the attacker’s fake Adobe-look-alike site

Download the paper in its entirety here.

On April 30, an exploit targeting a zero-day vulnerability in the Baofeng media player was published on the Internet. The proof-of-concept exploit had more than enough details for others with malicious intent to create more malicious variants.

Baofeng is a widely popular media player in China, and it plays many common media file formats. May 1 to 3 was the May Day weekend in China. One can imagine many Chinese users surfing the net or searching for their favorite video clips could be hit by this vulnerabililty during the holidays.

Because this vulnerability exploits an ActiveX component, attackers may inject malicious code via common means such as SQL exploits, or they can simply upload malicious web content onto certain websites. Once users browse these web pages, attackers may execute arbitrary code on the users’ computers via the flawed ActiveX component.

Currently, the vendor has confirmed this flaw and the following versions are reportedly affected by this vulnerability:

•  Build versions: 3.09.03.30，3.09.03.25，3.09.04.17，3.09.04.27.

A patch has been released for this vulnerability. Affected users should immediately contact the vendor for the security update.

McAfee VirusScan has proactively detected this exploit as the JS/Exploit-BO.gen Trojan since as early as the 4679 DATs (January 20, 2006).

Recently, our APAC threat intelligence team discovered a couple of Windows kernel zero-day vulnerabilities in the field, which could be potentially used for malicious purposes.  These were discovered in some discussion forums in China.

One of these issues exists in Windows NT/2000/XP according to the description provided. The issue arises due to insecure win32 syscalls, the buffer being supplied from usermode. This can lead to a Blue Screen Of Death (BSOD) if the kernel address is overwritten, leading to a Denial of Service (DoS) condition.  However, this issue requires admin privileges and hence cannot lead to a privilege escalation. But a deeper look suggests that this could be used to subvert or install kernel mode hooks, which can be used for malicious purposes.

Besides this issue, another kernel bug with similar behavior was found recently in the field. In this case it involved atapi.sys. 

The cause of this bug is also the same: It doesn’t verify the data passed from user mode and results in a buffer overflow. In most cases it will also cause a BSOD.

From the point of view of software design, data passed from user mode should never be trusted and must be always validated. Many of the known Windows local vulnerabilities exist because of this reason. Microsoft noticed this problem and fixed many potential defects in the kernel’s main module. However, many defects still exist in the win32k kernel part because it’s extremely complex. Most kernel vulnerability diggers are now targeting this module and have discovered many vulnerabilities in the past two years. With Windows 7 we will hope that kernel security will grow stronger.

We’ve notified Microsoft of both of these issues before posting this blog and technical details have been omitted here as the vulnerabilities are unpatched. We’ll do a follow up post after the issues are resolved.

McAfee Avert Labs has received a new variant of the infamous Conficker worm. Like the previous variants, this one also spreads using the MS08-067 vulnerability in Microsoft Windows Server Service. But unlike the previous variants, which arrived as a Windows DLL file, this variant seems to arrive as an .EXE file.

Detection for this variant of the worm will be available as W32/Conficker.worm.gen.d from the upcoming 5579 DAT release. Users of McAfee Artemis Technology are already protected in real time against this threat.

We have also updated our stand-alone cleaning tool–Stinger–to detect and clean this variant.

More information on this variant of the Conficker worm is available here. McAfee’s coverage and protection for the MS08-067 vulnerability, is available here.

For measures to protect yourself and your organization against Conficker, please visit:

• http://www.mcafee.com/us/threat_center/conficker.html

We will continue to monitor this threat in our labs, and will update our blog with any new findings.

As a follow-up to my colleagues’ blog post about the newest Office exploits, here is an analysis of one of the Microsoft PowerPoint Zero-Day exploits that once again are used in targeted attacks to infect victims with a trojan horse. The malicious presentation files abuse a new, yet unpatched hole in Microsoft PowerPoint and causes it to execute code infiltrated by the attackers. This blog post shows how the shellcode works and what it does, right after an innocent victim opens the malicious file - if the attacker gets their way of course!

For size reasons, the code is split up into several parts that are scattered among the malicious PowerPoint file. Part one of the shellcode consists of an “egghunter”, which is used to relocate the remaining part of the shellcode in memory. In order to do that, it first sets up an exception handler that prevents crashes when accessing bad memory locations, then goes on a hunt for the shellcode’s prepended egg (0xD1CF11E0). Once that egg (which is a marker for the beginning of the shellcode’s second part) is found in memory, code execution is transfered to the code following it.

Part two of the shellcode begins with a loop that looks for a writable memory block of at least 1KB in size (starting at address 0×30000000). Another loop then XOR decodes another part of the shellcode into that memory location and branches to it. Once decoded, a filename (”fssm32.exe”) can be seen in the disassembly. In order to either download or drop a second-stage executable, shellcode needs access to operating system API functions. The ones it needs are going to be imported by parsing OS internal structures, such as the Process Environment Block, to locate kernel32.dll, then parsing the library’s PE header to locate the desired function pointers.

As shellcode mostly needs to fit into a size-limited block of memory, this piece of exploit not only has its code split into several parts for it to work reliably, it also uses 32bit hashes of API functions to import, rather than a list of respective function names which would consume more space. The shellcode’s ROR-13 hashing algorithm iterates over any exported API function name and compares it against its given list at run-time. Applying the same technique when statically analyzing shellcode, the list of imported functions becomes readable. Looking at the now readable list, it does not contain any function which would indicate the shellcode to download a file but rather drop an embedded one from the PowerPoint file and execute it.

Using a hex-search for typical indicators of an executable file, such as an “MZ” or “PE” header doesn’t yield any feasible results - which is not astonishing at all. Of course, the attackers responsible for having built the exploit intended to prevent their cover being blown by something as obvious as an executable that is embedded into a PowerPoint presentation file! By looking more closely at the shellcode, there is another suspicious XOR-decoding loop.

The loop decrypts a given memory block using an 8bit XOR key. By incorporating the same decryption-loop into a Python script and applying it to the PowerPoint file (see screenshot below), both an MZ- and PE header surface in the hex editor. It’s the embedded executable that was assumed to hide between the PowerPoint “slides” - the malware can finally be extracted.

McAfee VirusScan products detect this threat as Exploit-PPT.k trojan, McAfee Anti-Malware Gateway Edition (former Secure Computing) detects the new exploits as Heuristic.Exploit.OLE2.CodeExec.PGPG.

We’ve just seen the Microsoft Excel 0-day attacks in February. Today, Microsoft published a new Security Advisory reporting a new unpatched vulnerability in Microsoft Office PowerPoint.

McAfee Avert Labs investigated and discovered multiple attacks in the field using the PowerPoint exploit. McAfee VirusScan products detects this threat as Exploit-PPT.k trojan using the 5573 DATs to be released on the same day. 

As with most other document exploits, these PowerPoint files install malicious trojans in the background but displays an innocent PowerPoint presentation to the victim as a deceptive measure. The following list shows a variety of malware files installed in these attacks:

• fssm32.exe: 428,032 bytes (Muster.c trojan)
• IEUpd.exe : 45,056 bytes (Muster.c trojan)
• setup.exe : 13, 1072 bytes (Muster.c trojan)
• PeerCM.exe : 80,666 bytes (Generic BackDoor.u trojan)
• ws2_42.dll :10,6740 bytes (Generic BackDoor.u trojan)

Some of these specially crafted exploits arrived as PowerPoint Showfiles with the “.pps” extension. Such files typically opens in full screen mode and hides the  applications running on the desktop such as system monitoring tools that could give any clue to the dodgy installation of trojans to the victim.

Please keep your DAT files up-to-date and refrain from opening any PowerPoint files from any untrusted sources until a patch is made available by the vendor. Where possible, verify with the sender to make sure what you get is what was intended.

McAfee Avert Labs will now produce more detailed documentation on prevalent threat families. The “Combating Threats” document series is designed to arm security staff within organizations with more information concerning prevalent threat families as well as to provide additional mitigation steps that can be taken. The first two documents in this series, “W32/Virut Family” and “Finding W32/Conficker.worm,” are now available via our blog, prior to our “Combating Threats” web page going live.

UPDATE MARCH 17th

Apologies for the busted links yesterday. All seem to be resolving fine now.

– Update Feb 24, 10:15 PDT –
Microsoft has released a security advisory for this issue (CVE-2009-0238):
http://www.microsoft.com/technet/security/advisory/968272.mspx

Many versions of Excel are vulnerable, including 2000, 2002, 2003, 2007, 2004/2008 for Mac, Excel Viewer/Excel Viewer 2003.
 –

A Trojan exploiting an unpatched Microsoft Excel vulnerability has been reported from the field. McAfee Avert Labs has confirmed that Microsoft Excel 2007 and 2003 are affected. Other versions may also be impacted.

McAfee DAT files identify known malicious Excel spreadsheet files as Exploit-MSExcel.r Trojan, and dropped files as BackDoor-DUE Trojan in the 5534 DATs.

As with the initial Exploit-PDF.i threat, current attacks are very targeted and limited. When succesfull, it installs a backdoor that attempts to connect a remote site port 80 and waits for commands.

The mitigation for this infection is to block unknown TCP connections. However, one of the best protection methods is to remain vigilant against Excel files from untrusted sources or sent at an unexpected time until a security update is available.

Needless to further remind everyone, zero-day attacks are the preferred choice of cyber criminals and will continue to be so in 2009. If the recent W32/Conficker.worm (MS08-087) and Exploit-XMLhttp.d (MS08-078, MS09-002) were not good enough to prove our point, here is another one.

At the turn of 2009, malicious PDF documents were discovered to be exploiting a 0-day vulnerability affecting Adobe Reader 8,x and 9.x. In parsing a specially crafted embedded object, a bug in the reader allowed the attacker to overwrite memory at an arbitrary location. The attacks, found in the field, use the infamous “HeapSpray” method via JavaScript to achieve control of code execution (see below):

In the above image, the eax register is specially crafted to point to the malicious shellcode that installs a trojan. When successful, the attack installs a backdoor to enforce remote control and monitoring on infected systems. Further characteristics of this backdor and detection details are posted at http://vil.nai.com/vil/content/v_153842.htm

While the distribution of this exploit thus far appears to be targeted, new variants are expected as more information is made public. As with the Conficker experience, the lack of good patch management is a very worrying trend that deserves more attention from IT security practitioners. Adobe is expected to release a patch very soon:

http://www.adobe.com/support/security/advisories/apsa09-01.html

An exploit found to be targeting a recently patched vulnerability for Internet Explorer 7 was discovered in-the-wild.  Malware crooks were quick to develop a working exploit for the vulnerability in Internet Explorer 7, which was part of the February Microsoft patch release. Microsoft rated this vulnerability critical with the possibility of a consistent exploit code. The modus operandi bears close resemblance to the zero-day attack using word documents, we blogged about in December 2008.

The attack, delivered in the form of a maliciously crafted document, is sent out to unsuspecting users. This word document contains an embedded ActiveX control which upon opening, connects to a website hosting the MS09-002 exploit.

Malware authors are always working to create new and improved ways to evade detection and control compromised machines. This time, malware authors introduced obfuscation (base64 encoding) possibly to evade easy analysis and detection.

The ActiveX control facilitates connection to the malicious website to launch and execute the MS09-002 exploit.

For those who have not patched their machines, we suggest you install the MS09-002 patch immediately. It will just be a matter of time before different variants of this exploit start circulating in the wild and become incorporated into various Do-It-Yourself web attack toolkits.

The malicious word document is detected with the current DATS as Exploit-MSWord.k and the Internet Explorer 7 exploit is detected as Exploit-XMLhttp.d / Exploit-CVE2009-0075.

Over the years, the window between exploit discovery to its incorporation into a worm candidate has shrunk from months, to weeks, to zero-day. This leaves administrators with very little time to schedule and deploy patches to all servers and workstations on their network. Virus authors, on the other hand, have been at the cutting edge for including exploit code in their creations whenever a critical vulnerability is reported. The chart below shows the time frame between a vulnerability being reported and how long it took for virus authors to incorporate it into a worm candidate.

The year 2007 was the only exception in recent times for a worm not exploiting any critical Microsoft vulnerability.

It’s easy for an outsider to criticize or pass judgment on a network that was hit with a zero-day worm. Spare a thought for the IT administrator; most do not have the flexibility to deploy patches immediately to the network for policy reasons. For example, the organization could be using legacy software, which could break if a new service pack was applied. And keeping these legacy applications running takes precedence over applying the latest Windows hot fixes. Most system administrators, who work in hospitals and other mission critical jobs, don’t have the luxury of doing a Windows update!

To add to these woes, every once in a while a hot fix from Microsoft breaks something in the operating system or adversely affects other applications. Once a patch is rolled out via WSUS (Windows Server Update Service) it cannot be rolled back centrally; a faulty patch from the vendor can prove costly for the organization. For these reasons administrators need more time to deploy these hot fixes in a test environment and QA them properly before deploying them to the enterprise.

So what can an administrator do in these circumstances? Relying solely on mainstream-antivirus desktop protection or firewall-style perimeter protection is insufficient to deal with today’s modern threats. The need of the hour is defense-in-depth. Administrators, who don’t have the luxury of applying patch updates, should seriously consider having a HIPS (host intrusion prevention system) installed on the end point to prevent exploit-based worm infections. Host intrusion prevention systems not only protect systems against zero-day vulnerabilities but also give administrators more time to test and deploy patches. The recent W32/Conficker.worm outbreaks could have been nipped in the bud if more organizations had chosen to protect their systems with HIPS.

Recently we blogged about an unpatched Internet Explorer 7 exploit in the wild. With the vulnerability information made public, McAfee Avert Labs has noticed a spike in the number of active websites hosting this exploit. Lately we are seeing customized versions of the IE 7 exploit with varying degrees of obfuscation.

Malware authors have been coming up with innovative mechanisms to leverage this exploit to social engineer the not so tech-savvy internet users. One of the most prominent and unique techniques adopted by the malware authors involves a Microsoft word document being sent out to an unsuspecting user.

Upon opening the word document the embedded ActiveX control with the following classid  is instantiated and executed.

• {AE24FDAE-03C6-11D1-8B76-0080C744F389}

This control stores configuration data for the policy setting Microsoft Scriptlet Component.

The control then makes a request to the webpage hosting the IE 7 exploit. The charm with this approach is that the exploit is downloaded and run without the knowledge or permission of the user. To the unsuspecting user it will just appear as yet another normal Doc file.

Microsoft has issued workarounds to block known IE 7 exploit attack vectors. We want to reiterate to all our readers to be vigilant and cautious while opening unknown Doc files or visiting dubious websites, while we continue to monitor the threat and protect our customers against the menace .

We have lost count of how many blogs we have written this year that have anything to do with zero-day threats or unpatched vulnerabilities.

Today, many Internet users in China have reported an infection, presumably from browsing the web using a fully patched version of Microsoft Internet Explorer 7.x. My colleague Xiaobo Chen and I investigated the incident and found it to be an active exploit containing downloader shellcode that installs the Downloader-AZN Trojan (proactively detected as New Malware.n since 2005 when scanning with heuristics enabled).

The root cause was found to be the incorrect handling of certain XML tags in Internet Explorer 7.x that references already freed memory in the mshtml.dll.

We have confirmed this vulnerability to be affecting, at least, a fully patched Windows XP SP3 and a Vista SP1 system. The exploit uses publicly known heap-spray techniques that enable control over a vtable pointer, allowing arbitrary code execution.

Fortunately, the 5404 DATs proactively detect the Downloader-AZN Trojan, but there could be other variants. Additional coverage is going into today’s DATs to detect the malicious web scripts as Exploit-XMLhttp.d or Exploit-XMLhttp.c Trojan.

Details about this vulnerability, as well as exploit code, are known to be publicly available.

More information on this situation will be posted as it becomes available.

Today McAfee released its Virtual Criminology Report, our annual study of global cybercrime. We found that cybercriminals are targeting their scams to play off of the economic recession, and governments need to be doing more collaboration to face the problem.

The economic downturn affected cybercrime scams almost immediately. As soon as banks started struggling and mergers and acquisitions became commonplace, we started seeing an immediate increase in banking scams asking users to ‘update their account information’ before the bank changed hands. With almost all of today’s malware being financially motivated, even cybercriminals are looking for more business in tough economic times and are really stepping up their game.

This represents an evolution in the trend of cybercriminals getting smarter and faster about what they do. When news of a specific banks going under hits, scams and malware utilizing that messaging will emerge the very next day. The same happened with threats throughout this year’s presidential race as well as post-election; when President-Elect Barack Obama messaged malware emerged as early as November 5.

The environment of fear and anxiety in consumers that is being caused by the downturn also provides opportunity for cybercriminals to lure consumers into what they think are ‘internet sales marketer’ positions, where they are actually unknowingly assisting in criminal activity as money launderers. We have been seeing an increase in the number of these job postings and recruitment emails promising job seekers will ‘get rich quick.’ The scams are also strategically worded to place high on Google job searches, and are of course designed to look like legitimate job postings.

It is more important than ever that computer users educate themselves in safe searching and safe computing habits. Technology alone cannot solve the problem. Education alone cannot solve the problem. Both combined, however, can enable us all to use the Internet the way we want.

Download your copy of the report here.

Educate. Advocate. Protect.

Today marks another day of momentous change for McAfee’s research teams.

I just spent two days with my new colleagues from Secure Computing and some of my team members from McAfee Avert Labs. It was two grueling days of discussion and education as we both came up to speed on our research methodologies and technologies. Let me say that I am truly excited to be working with Dmitri Alperovitch, Sven Krasser, and Paula Greve, who head up the research group there. These are sharp and capable research leaders who have done amazing things. TrustedSource is a great technology and has so many applications that McAfee can leverage. Once our new Artemis technology begins to leverage TrustedSource capabilities McAfee will become the undisputed leader in security intelligence in the Internet “cloud.” Together we will see millions of spam messages, evaluate thousands of web sites, and see thousands of new pieces of malware–all in the span of 24 hours. We now have the ability to see and react to the threat landscape better than ever before. This is something that every McAfee product, technology, appliance, and SAAS (software as a service) solution will come to leverage, differentiating themselves from the competition even more.

At first we thought we would have overlapping technologies, but this is definitely not the case. In combating spam, web, and malware we have approached these threats from very different directions; thus we find our technologies very complementary. In the case of anti-spam protection, for example, we have two technologies that provide better than 99% detection using very different methodologies and approaches. Once combined, we will have the most robust solution on the market. The same holds true for the SmartFilter and SiteAdvisor technologies, as well as our malware solutions.

Today we have very good security intelligence. Tomorrow, with a bit of nurturing, we will have great security intelligence.

We welcome Secure Computing to the McAfee research family.

Jeff Green
Senior Vice President
McAfee Avert labs

It has been over 2 years since I last wrote about malware exploitation of a major vulnerability in the Windows Server Service (MS06-040) by malware.

In 2006, worm authors were quick to adopt the remotely executed exploit in just 4 day following a security update released as part of the regular Patch Tuesdays - IRC-Mocbot, W32/Sdbot, W32/Spybot, W32/Opanki, et ceteras.

Now in 2008, we are faced with malware authors, motivated by profits, more organized, and are more likely to target zero-day vulnerabilities, as we have reported on several critical incidents we have discovered since 2006. Like déjà vu, Microsoft released an out-of-cycle security update today to address in-the-wild attacks against a new MS08-067 vulnerability targeting the same Windows Server Service.

Attacks seen in the wild so far seem to have come from variants of the Spy-Agent.da trojan. When run, it may not be immediately apparent to the victim that it was using any exploits. Taking a quick glimpse into the binary code of basesvc.dll (Spy-Agent.da.dll), one of the DLL components installed by Spy-Agent.da, one can see strings that would look very familiar to those familiar with MS06-040.

On closer analysis, Spy-Agent.da.dll seeks out potentially vulnerable Windows machines in the local network, and sends maliciously crafted DCERPC requests to exploit the Server Service (SvrSvc).

When successful, hardcoded shellcode embedded within the malware, is executed on the targeted machines to download Spy-Agent.da (or possibly other variants or files) from a web server hosted in Japan.

(shellcode after decoding)

Just hours following the patch release, public source code has already been seen distributing on the Internet. What more can I say ? Patch your systems ! Yes, NOW !

Spy-Agent.da and Spy-Agent.da.dll are now detected using the current 5414 DATs. See Dave’s blog for McAfee’s coverage.

(thanks to Joey Koo and Xiaobo Chen for providing analysis data and packet dumps used in this blog)

[This entry was updated on November 3.]

Lately, the topic of “clickjacking” has gained popularity in discussions on the Internet. It is a new type of web attack. I decided to find out what it’s all about.

I found an online video from OWASP NYC AppSec 2008 here. In the video, Jeremiah Grossman and Robert “RSnake” Hansen reported this new vulnerability in a presentation titled “New Zero-Day Browser Exploits-–ClickJacking.” I also found a demo of this attack here.

In the videos they describe only parts of the vulnerability, but we can learn enough to gain a basic idea of what clickjacking is.

To explain, I’ll use an example. You have a web page A controlled by an attacker. A contains an IFRAME element B. In a clickjack attack, B would be set to transparent and the z-index property of the layer set to higher than other elements of page A via cross-site scripting. The area of B will also need to be so big that the user can easily click its content. The attacker places a button in B that leads to any action he wants. Then the attacker places some buttons on page A that will attract users. The location of the buttons in B must match the buttons in A so when users appear to click a button on page A, they are actually clicking the button in B because the z-index property of B’s buttons are higher than A’s buttons. This attack uses DHTML and does not require JavaScript, so disabling JavaScript will not help.

This vulnerability affects multiple web browsers. Unfortunately, no patch for it is currently available, so users should be careful. The vulnerability has also been found to affect Adobe Flash Player, the most popular rich-media Internet application today. Adobe has released a security advisory and provided a workaround.

We will continue to watch for new information about this vulnerability.

Issue 5 of the publication formerly known as Sage has been released. This issue we take aim and tackle the rather murky subject of social engineering. We have nine excellent articles for you from some of our finest researchers as well as two academic experts. Some of the topics covered include:

The Origins of Social Engineering
Social Engineering 2.0 - What’s Next?
Vulnerabilities in the Equities Markets
The Future of Social Networking Sites
Typosquatting - Unintended Adventures in Browsing

Many aspects of social engineering are dissected and investigated as well, some not found anywhere else! Definitely worth the download and read.

Available here.

News about the Artemis project has been out for a little while. As the rollout continues we want to post some of juicy backstage gossip here, making you some of the first people to see this outside of the core project team!

If you’ve not heard about the Artemis technology yet, it’s our “in-the-cloud”-based malware detection; head over to the McAfee Artemis micro-site. I highly recommend the podcast (hidden on the right-hand side) as my colleague Dimitry Gryaznov outtalks our communications guru Dave Marcus.

One of the things Artemis provides to researchers is very clear telemetry on active malware campaigns, and I want to share a few interesting examples. All the “measles maps” below show a one-day period and were all taken at the same time earlier today.

First up is today’s typical ecard malware:

As you might expect, there are lots of hits all around the globe, sent very quickly. [Take note ISP's: You're the first line of defense and you delivered this to our users.]

This is a previous ecard campaign from a week ago:

(There’s always one.) This isn’t saying that the campaign is over and protection is no longer required. Since Artemis gets queries only for those without current detection in the DATs, this simply means that the map shows endpoint(s) that need to update.

Sex (still) sells. The current “tits.exe” campaign:

This picture looked like the first one on Friday. Protection is relatively new for this threat and we’re seeing the queries tail off as customers update. This is exactly the point of Artemis, providing protection for new threats between updates, and efficiently, too. (I’ve no idea why this one appears to be more popular in Australia.)

This is the current data from the “tits.exe” campaign from last weekend (21 September):

Yes it’s a blank map. In fact, the last query was at 00:45 on 25 September from an ISP in California. This is quite a revelation: Artemis fills a gap far wider than I first envisaged.

Dimitry’s podcast also explains how we are able to deploy Artemis without an upgrade and that Artemis has been dormant in the DATs for quite a few months already. Those on the Artemis-enabled beta programs have been enjoying its added protection for months as well.

A quick note about privacy before the vultures circle. The dots on the map roughly represent ISPs rather than individual users (we couldn’t read it otherwise). We use the data purely on a statistical basis and we don’t keep it longer than we need to. The dots are geolocated by a service that has well-understood accuracy “limits,” so relax. Artemis does not know where you live, or what color the car on your driveway is. For that, you need to ask Google; they have pictures of it. Artemis queries are short checksums or fingerprints. Those wishing to disable Artemis should unplug themselves from the Internet at this point. It’s far easier to track our blog readers, for instance.

Some other trivia about Artemis:

• Queries are not sent for every file, just the suspicious ones.
• It will probably be invisible in the consumer products. (It’s a special driver.)
• A query and a response is around 340 bytes.
• It’s checksum/fingerprint independent, too.
• Actionable responses are cryptographically strong.
• Telemetry can be used to prioritize sample processing.
• Today Artemis should gain about 1.5 million new users.

Enterprise customers, please feel free to call Platinum Support if you want to test out Artemis early.

Lastly, any malware authors who want free third-party real-time telemetry on their campaigns should contact us ASAP! Our legal hounds are waiting to take your calls.

A zero-day exploit against the latest QuickTime (Version 7.5.5) and iTunes (8.0) was released yesterday. The exploit author announced this as a remote heap overflow so we decided to take a look and analyze it.

After our research, we found that this is actually an off-by-one stack overflow. Some noteworthy points:

1. QuickTime has the /GS switch option enabled, hence a cookie is put into the stack.

2. Since this is an off-by-one stack overflow, the attacker can just overwrite one byte of the cookie. The Check_stack_cookie function is called when the function returns. If the Check_stack_cookie found out that the cookie is not matched, then the program exits. This results in the crash of QuickTime and iTunes.

The crash means it is unlikely that code execution would be feasible via this attack vector. Howerver, users of these apps should take the attack seriously and look at appropriate defenses.

Following the public advisory of a zero-day attack published by JustSystems and McAfee® Avert® Labs on August 26, an official security update is now available from the vendor at: http://www.justsystems.com/jp/info/pd8002.html.

The protection has also been available to McAfee customers in the 5368 DATs since August 22. As Avert Labs continues to update our protection for ongoing attacks, Ichitaro users are highly advised to patch this vulnerability as soon as possible.

The debate of full disclosure vs. responsible disclosure vs. nondisclosure has been going on for years, and we have discussed it several times in blogs and even in one of our earliest AudioParasitics podcast sessions:

- http://www.avertlabs.com/research/blog/?p=270
- http://podcasts.mcafee.com/audioparasitics/AudioParasitics-Episode7-5-2007.mp3

We would like to highlight the importance of responsible disclosure such as this. In case of a new attack, restricted information and protection must be made available to all affected users just sufficient to detect and protect against the latest security compromises. All information must be released without compromising the security of affected users, and while providing ample time for affected vendors to verify the issue and inform their customers. No details must be given that would allow the bad guys to discover and exploit the vulnerabilities; however, keeping the existence of a known vulnerability secret leaves users unprotected and uninformed.

As our vulnerability research colleague Rahul Kashyap puts it in his blog, “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 gives the bad guys night vision.”

Ichitaro zero-day vulnerability response:

One of the issues that we’ve been highlighting at our recent conference presentations and blogs was the emergence of major localized threats around Asia. McAfee Avert Labs discovered yet another unidentified vulnerability in the Japanese word processor , Ichitaro, last Friday.

This Japanese application have been known to be under the targeted attacks for several years and a few 0-day vulnerabilities were discovered and exploited in the past. Other than Ichitaro, other popular and localized applications are often targeted by 0-day exploits. We also frequently observe exploits targeting vulnerabilities, even months after they have already been patched by the vendor.

Users should continue to stay vigilant of any suspicious email attachments, and do not open unknown files. Please be sure to update your applications, whether it is popular or not, with the latest security patches to protect you and your organization from the known attacks.

These newly crafted malicious documents are detected as Exploit-TaroDrop.e trojan, and the payload as BackDoor-DRZ trojan in the 5368 DATs.

The vendor has acknowledge the vulnerability and will be posting a patch.

We recently came across this article published in one of the Chinese Security E-zines, called pstzine, which talks about a new zero day Cross Domain Scripting flaw in IE6. This is still unpatched in IE6 as of now but IE7 and FireFox are not vulnerable to this.

The issue is very similar to the “Ghost Page” issues in IE, which was originally raised by security researchers, Manuel Caballero and Fukami at Microsoft Bluehat 2008 , and there were some discussions on this topic on online blogs like GNUCitizen.

We’ve notified Microsoft about this information. Until a patch is available, we advise IE6 users to disable scripting in the browser or upgrade to IE7 to avoid potential exploitation due to the public disclosure of this vulnerability.

Last night our researchers identified similarities between the recent Adobe Flash exploits and a known (patched) vulnerability: CVE-2007-0071. At first, this appeared to close the case, but there was a report of a patched version of Flash falling victim to one of these attacks, and we’ve seen an SWF file referencing a missing file named WIN 9,0,124,0i.swf, which also suggests that the latest version of Flash is the target of that file.

The exploits that we have captured from the field do not appear to exploit the latest version of Flash. We continue to hunt for missing 9,0,124 exploits and will post an update should one be discovered. In the meantime, it’s best to update to the latest player, if you haven’t yet done so.

Here’s a quick update to the earlier post on a new unpatched Adobe Flash vulnerability.  Through looking for sites serving these SWF exploits we’ve found a connection with recent mass hacks.  Hacked sites reference an external script, just as they have for quite some time.  But, the external scripts now reference an SWF file.  This SWF file references another SWF file named: WIN%209,0,124,0i.swf (WIN 9,0,124,0i.swf), which seems to be off-line.  While we can not confirm this last SWF file attempts to exploit this new vulnerability, Symantec mentioned the same domain serving the exploit earlier.  SANS also mentions another domain, and 2 presumed exploits, named WIN%206,0,79,0ff.swf (WIN 6,0,79,0ff.swf), and WIN%206,0,79,0ie.swf (WIN 6,0,79,0ie.swf) also off-line.  These file names suggest 3 things.

1) Different exploits are crafted to exploit different versions of Adobe Flash, in this case 9,0,124,0 and 6,0,79,0.
2) Versions of the exploit may also exist, or be under development, to target other operating systems, as the aforementioned file names begin with WIN.
3) Exploits exist for both Internet Explorer and Firefox, as the file names end in “i”, “ie”, or “ff”

Thus far we’ve identified 2 particular domains involved in mass hacks that are also believed to have served these Flash exploits.  Combined, Google yields approximately 250,000 page results when searching for those references (ie. compromised sites that link to scripts that link to flash exploits).

Again this threat is still under analysis, more details to follow.

Here’s a quick note about an unpatched vulnerability affecting Adobe Flash Player. McAfee Avert Labs has received submissions of samples of exploits from many sources spanning multiple domains over the past 24 hours. We’re currently investigating the flaw.

Stay tuned for more details.

Almost two years ago in 2006 Debian decided to clean up their OpenSSL implementation. They found a few lines of code that were causing Valgrind and Purify to complain about access to uninitialized memory. Without a major investigation into the purpose of the suspect lines of code they were simply removed. All basic tests continued to pass with the lines of code removed and Purify and Valgrind both stopped complaining about the improper memory access. The change was forgotten and everyone believed that the OpenSSL implementation was working just fine.

For the purposes of all the OpenSSL algorithms there was no deficiency. Encryption and decryption and hashes would be calculated correctly. The problem was that the PRNG used for generating keys by the OpenSSL library had been crippled when those critical lines were removed back in 2006. This was not discovered until just this week when Luciano Bello discovered that without those lines the only ‘random’ data used to seed the PRNG was the PID of the OpenSSL process. On many Linux systems the PID is limited to a positive signed 16 bit value. This means there are only 32,767 possibilities. When new keys and certificates were generated by OpenSSL they relied on this number to provide all of their entropy.

The consequence of this bug is that from September 2006 until May 2008 there were only 32,767 possible keys that could be generated by OpenSSL. Several individuals have generated “black lists” of every possible key that this OpenSSL implementation could generate. According to some reports this entire list can be generated in a couple hours. This weakness affects any key generated by OpenSSL including SSH and DNSSEC keys among others.

Many machines will fail to be updated in a quick manner after the discovery of this vulnerability. There are already many botnets which spread by simply brute forcing common username and password combinations over SSH. It will probably not be long until some of these networks are modified to start attempting RSA authentication using the faulty OpenSSL keys. These attacks will not take long to develop and have the potential to compromise large numbers of machines. It is important for administrators to note that even if they replace and upgrade the OpenSSL package they must recreate and replace any keys or certificates generated by the broken OpenSSL kit.

The moral for developers is to always be sure you understand the impact of your code changes. This goes extra for critical libraries like OpenSSL. Minor and seemingly inconsequential changes can leave major problems festering undetected for years. There may also be some changes in the way that Debian developers work with the developers of other related software packages like OpenSSL. Hopefully increased communication between the development teams in the future can prevent this kind of bug from recurring.

Sometime back we had come across this interesting vulnerability posted by a Chinese researcher in his blog, claiming to have found a zero day vulnerability in php 5.2.3.

We got a chance to dig a bit deeper into this and were able to reproduce the vulnerability based on the information provided in the blog. After investigation, we found that this vulnerablility affects not only verion 5.2.3 but also version 5.2.5. It is a heap overflow which can be triggered when a web server with PHP receives a malformed URI request, it can be a simple request like “GET /index.php/aa HTTP/1.1″ . Successful exploitation of this can result in arbitrary code execution with the privileges of the WEB Server.

This happens because the author misplaced the bracket resulting in miscalculation of the buffer which can result in a heap overflow. So fixing this issue is also simple viz: In \sapi\cgi\cgi-man.c do a grep for: “ptlen + env_path_info ? strlen(env_path_info) : 0;” , and replace this with “ptlen + (env_path_info ? strlen(env_path_info) : 0); ”

This is one of the classic examples of small human errors (which can sometime be even typos) that can result in vulnerabilities.

We had reported this issue to PHP dev team almost immediately after we had come to know about this issue in the wild and they’ve just come out with a patch for this. We highly recommend users to update with the latest version of PHP 5.2.6 released . This patch besides this issue, fixes a host of other security related fixes, some of which we deem as critical. This specific issue affects FastCGI packages of PHP.

This issue has been given the identifier CVE-2008-0599.

We shall continue to monitor this threat and update if we come across anything malicious.

There’s been considerable stink lately about the Race to Zero contest that is to be held at Defcon. I, for one, am a bit perplexed by this. This article from ZDNet Australia is what finally made my eyes cross in confusion/aggravation.

I don’t know at what point the collective “wisdom” became that signature-based AV was ever intended to be about defending against every threat ever devised, before it was ever devised. Signature-based scanners are intended to detect and clean known threats. If you modify a known threat, it’s not really “known” anymore, is it? Now it’s a variant of a known threat.

It’s certainly desirable to have protection against all threats, known and not-yet-known. This is what things like firewalls, Intrusion Prevention Systems, Data Leakage Prevention and all those other wonderful security products are intended to do, in concert with AV. Most AV software now also includes proactive static detection like Generic and Heuristic detection, along with more dynamic detection like emulation or behavioral detection. Many AV programs now also include broader security functionality like a firewall or IPS.

Generic and Heuristic detection is certainly better at picking up unknown threats than simple signature-based scanning, but there are three things that limit it. For one, it’s still reactive, basing detection on known bad techniques. Secondly, it’s static - obfuscation can still muck up the detection, if it causes the file to deviate from the known bad technique. Finally, there’s still a need for these detections not to be false-prone. Heuristics and generics essentially cover known “really, really bad” techniques. The threshold of badness must be quite high to make it into AV products. Consider how many commercial products and widely used administration tools blur those lines, and you may come to appreciate what a very fine line it is.

It’s not clear from what I’ve seen whether the contest’s judges intend to use the most paranoid settings available within the various products, but their description does seem to indicate they’ll only use the static detection, rather than running it real-time through the products. This does not accomplish a full testing of the products capability, it only tests one component. The results they get will not be what an average user will get.

The contest organizers and participants are playing with fire in order to prove what we already know: Signature-based scanners are meant to protect against known threats. That doesn’t mean that AV is dead, or that it’s useless. The industry is evolving, and its products with it. AV is intended to be one tool in a complete security arsenal. Defense in depth is where it’s at, if you’re really looking to protect your network.

A Microsoft Works ActiveX potential zero-day threat has been disclosed on a handful of Chinese blog sites. This threat was originally posted as a proof of concept that caused a Windows host to crash, but very soon after, a working exploit was posted. (Show of hands: Who’s surprised?)

Here’s the meat of this: The flaw lies in an ActiveX component of Microsoft Works Image Server (WkImgSrv.dll). Yes, it appears successful exploitation would allow for code execution via a controlled pointer. For this to occur, the victim would need to visit a malicious Web site.

On the plus side, this control is not marked safe, and attempts to use it should be accompanied with a warning from Internet Explorer. Even though this is the case, you will want to set the kill bit for clsid:00E1DB59-6EFD-4CE7-8C0A-2DA3BCAAD9C6 to help mitigate. Initial testing on Windows XP SP2 and Internet Explorer 7 shows this to be easily exploitable once past the “warning” hurdle.

In the mean time, McAfee Avert Labs will continue researching this issue.

Update: June 6, 2008
Microsoft has confirmed that exploitation of this issue is not possible due to the control not being safe for scripting, nor safe for initialization. They have a nicely written, thorough write-up here explaining why.

A vulnerability has popped up (no pun intended…really) in Internet Explorer (IE) — or at least is claimed by a researcher named Juan Pablo Lopez Yacubian on the popular Bugtraq mailing list. It allows one to spoof the address of a popup without affecting the underlying page. This means that a bad guy could send the victim a legitimate link, have them follow it, and popup a spoofed window when they land on the attacker-controlled site (or hacked legitimate site). If this popup window is enticing enough, the attacker could persuade the victim to disclose information, click malicious links, or do other nefarious stuff.

There are a good amount of fairly obvious caveats for successful exploitation, however. First off, the victim must allow scripts to run, otherwise IE blocks it. Second, even if scripts are allowed, a good popup blocker should effectively be able to stop the window from popping up. Next, any click within the body of the popup will reveal the true identity of the address. Lastly, to be aesthetically pleasing, the address is limited to a certain character length.

All in all, this is nothing really spectacular…

That said, the main point here is to remind you to be sure to have basic browser protection (script blocking, trusted-domain model, popup blockers, etc.) in place and use common sense when you receive unsolicited links and unexpected popups.

Safe surfing…

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.

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.

When a colleague pointed me at this article about some MS research on using worm techniques to distribute patches more efficiently, I had a moment of extreme déjà vu. After all, Fred Cohen was talking about beneficial uses of viruses in the mid-80’s. But since then, we’ve had a number of attempts occur that prove the old adage that the road to hell is paved with good intentions.

Back in 2001 we saw CodeGreen attempt to locate and patch machines infected with the infamous CodeRed worm. In a variety of other cases, one piece of self-propagating code (worm) has tried to patch backdoors or vulnerabilities, but usually in a self-preservation attempt against a rival author rather than for any altruistic purpose. Examples of this include the Linux Cheese worm and a variety of Bagle and Netsky variants that attempted to remove the other during the much-publicized “Virus Wars” of 2004.

The use of self-replicating code to fix other security problems has invariably proved to be a Bad Idea in the real world because we simply do not understand the epidemiology of the complex, heterogeneous universe we call the Internet. Rather than steal his thunder, I’d invite you to check out Igor Muttik’s talk on “Good Viruses” in the Research Revealed track at RSA this April 9th, if this topic interests you. Alternatively, check out Vesselin Bontchev’s paper on this subject here.

On the other hand, if you actually read the Microsoft research at http://research.microsoft.com/~milanv/, he’s really looking at how the epidemiology of good code versus bad code works. Given that most worms are Windows-based, and Microsoft, by definition, is providing the patches to block those worms that exploit vulnerabilities in their software, this is not irrelevant. While biological analogies to computer viruses are often dismissed, this is one area where a “computer epidemiology” discipline would be most welcome.

McAfee pushes something like a petabyte (Pb) of DAT signatures out in a month, so I can’t even imagine how much bandwidth Microsoft consumes delivering patches to all the Windows machines on the planet. And given how little we really understand about how information flows between computers on the internet, there’s something to be said for advancing the science of information dissemination.

Unfortunately, what most researchers concentrate on is the spread of self-propagating worms exploiting services, like Slammer, Blaster, CodeRed, Witty and other high-profile, fast-spreading worms. Today, though, we’re much more likely to see a huge variety of fairly prosaic threats that rely as much on social engineering as exploits to propagate. And this is an area where there is painfully little research.

What are the different propagation rates for Web 2.0-based threats like the spate of MySpace or FaceBook attacks over the last couple of years, versus any other web-based attack? How do regional idiosyncrasies like localized software vectors or language of social engineering affect threat propagation? How fast do patches or AV signatures need to be distributed to dampen the spread of threats propagating at different rates? How do different peer-to-peer (P2P) strategies compare to other mechanisms for “good code” dissemination. All of these are increasingly valid and relevant questions in the Wild West of today’s internet.

Let’s just remember that there is no “beta” version of the internet we can experiment on at scale.

Zero-day emerges

On February 9, zero-day exploit code [1] was posted on milw0rm site. It exploited
vulnerability in Linux kernels Versions 2.6.17 to 2.6.24.1. This bug allows
an unprivileged local user to gain root privileges. This vulnerability was
assigned CVE-2008-0600.
There are reports that this exploit is reliable and actively used in the wild.
The inner workings of this exploit are quite interesting from the
technical point of view; let’s have a look.

Details on the vulnerability and methods of exploitation

The vulnerability lies in the get_iovec_page_array function
(in fs/splice.c, line numbers from 2.6.23.1-42.fc8 kernel),
reachable from the vmsplice() system function:

1286:       if (unlikely(!len)) // "len" variable is under user's
            control
1287:               break;
...
1296:       off = (unsigned long) base & ~PAGE_MASK;
...
1306:       npages = (off + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
1307:       if (npages > PIPE_BUFFERS - buffers)
1308:               npages = PIPE_BUFFERS - buffers;
1309:
1310:       error = get_user_pages(current, current->mm,
1311:                              (unsigned long) base, npages, 0, 0,
1312:                              &pages[buffers], NULL);

The get_user_pages function expects its fourth argument (the
number of pages descriptors to fill; it limits the return value) to be at
least 1. In the preceding code it is assumed that the npages variable is at least 1 (because len must be nonzero, so the off + len + PAGE_SIZE - 1 expression should be greater or equal than PAGE_SIZE). However, if the len variable is close to UINT32_MAX, then the off + len + PAGE_SIZE -1 computation will result in an integer wrap, and npages can be zero.

As a result, get_user_pages may return more than
PIPE_BUFFERS entries, and the pages array will
overflow. However, the overflow payload is not controlled by the attacker,
so it would be difficult to turn this overflow into reliable code execution.

The reliable exploitation happens thanks to the subsequent loop:

1320:       for (i = 0; i > error; i++) {
1321:               const int plen = min_t(size_t, len,
                    PAGE_SIZE - off);
1322:
1323:               partial[buffers].offset = off;
1324:               partial[buffers].len = plen;
1325:
1326:               off = 0;
1327:               len -= plen;
1328:               buffers++;
1329:       }

Here, the partial array, which is also PIPE_BUFFERS
elements long, is overflowed with (off=0, plen=0×1000) pairs. Now, depending on the variables
layout chosen by the compiler, various data structures (that follow partial array) can be overwritten with zero. In the most common case, the pages array will be located after the partial array. The pages array contains pointers,
thus after the preceding loop, it will contain NULL pointers.

Normally, when the kernel tries to access a NULL pointer, it will result in an
exception and the process will be terminated. However, the attacker can map
memory pages at address zero, and store arbitrary data there. In such a scenario,
when the kernel dereferences pointers from the pages array,
attacker-controlled data will be processed, which may result in arbitrary
code execution in the kernel context. In our case, the convenient technique is
to make an entry in the pages array look as a compound page
descriptor, which will result in a function call to an attacker-controlled
address in user space:

37 static void put_compound_page(struct page *page)
   /* attacker controls arg */
38 {
39     page = (struct page *)page_private(page);
40     if (put_page_testzero(page)) {
41             void (*dtor)(struct page *page);
42
43             dtor = (void (*)(struct page *))page[1].lru.next;
44             (*dtor)(page); /* so attacker controls the target
                of the call
45     }
46 }

To sum up, the exploitation involves:

• integer overflow
• buffer overflow
• mapping the zero address to allow NULL dereference

Workarounds

The kernel upgrade is the preferred solution; but if it is not feasible, there
are workarounds.

A simple kernel module, which disables the sys_vmsplice system
call, has been posted [2].

The exploit we’ve discussed relies heavily on the possibility to map memory at
address zero. Starting with kernel 2.6.23, there is a mechanism to forbid such
mapping via procfs. The echo 65536 > /proc/sys/vm/mmap_min_addr
command will set the lowest possible mapping to be at 64K. Note that:

• SELinux must be enabled (in enforcing mode) for this command to take effect.
• Although this setting certainly makes the current exploit fail, there is a nonzero probability that the vulnerability can be exploited without mapping the zero address. I know of no code capable of such exploitation; however, it cannot be ruled out.
• This setting may prevent exploitation of future NULL pointer dereferences vulnerabilities. Very few programs make legitimate use of mapping the zero address.

References

[1]
Linux vmsplice Local Root Exploit By qaaz
[2]
Runtime disable of sys_vmsplice

McAfee Avert Labs is tracking an active exploitation of a recently patched vulnerability in Adobe Acrobat Reader now in the wild. The current vulnerability can be embedded in a PDF file and manipulated through Adobe JavaScript.

The first evidence of such maliciously crafted PDF files was posted to an Italian message forum from an alert administrator who noted that three of his workstations had been infected. Successful exploitation leads to the embedded JavaScript being executed on the victim’s machine. The script attempts to download a Trojan from an IP address in the Netherlands.

This exploit works for both browser-based and email attack vectors and affects the following Adobe products:

• Adobe Reader 8.1.1 and earlier versions
• Adobe Acrobat Professional, 3D, and Standard 8.1.1 and earlier versions

Complete mitigation requires upgrading Acrobat and Adobe Reader 7.x and 8.x to Version 8.1.2.

Malware authors will find this technique of using exploit-laden PDF files in spear phishing attacks very profitable–especially since the Portable Document Format (PDF) is a de-facto standard for exchanging electronic documents online. PDF files have traditionally been unfiltered at the gateway and until recently were considered risk free–in contrast to the notorious history associated with Microsoft Office documents.

With the release of Windows Vista and Microsoft Office 2007, however, Microsoft has made it more difficult for attackers to use buffer overflow exploits. Thus we expect to see exploit writers target the lower hanging fruit. Exploiting vulnerabilities in popular applications from Adobe, Apple, or RealPlayer are proving to be just as advantageous and profitable for the bad guys.

We strongly advise users running vulnerable versions of Adobe Reader and Acrobat to update them from the Adobe site. McAfee users are protected against these maliciously crafted PDF files with today’s 5227 DAT release, which detects them as Exploit-PDF.b.

Zero-day vulnerabilities in Yahoo products are not something novel and should be taken very seriously. Last year, we also saw a couple of ActiveX based vulnerabilities in Yahoo Messenger that are still exploited and incorporated into various web-based attack kits. One of the most prolific still is the Yahoo Webcam ActiveX Controls buffer overflow vulnerability .

Yahoo Music Jukebox is free music-management software that lets you play music files, burn CDs, and tune into your favorite Web radio stations. Within a day of the new Yahoo Jukebox zero-day being publicly disclosed on February 2, a fully working exploit was developed and widely circulated in various forums.

The first vulnerability is a stack-based buffer overflow in the overly long “url” parameter passed to the AddButton and AddImage functions in the YMP DataGrid ActiveX control (datagrid.dll).

The second vulnerability is a buffer overflow with a long “bitmapUrl” parameter passed to the AddBitmap function in the YMGMediaGridAx ActiveX control (mediagridax.dll).

This issue has been observed with Mediagridax.dll version 2.2.2.056 and datagrid.dll version 2.2.2.056, which are distributed as part of latest version of Yahoo Music Jukebox 2.2.2.056 and few older Yahoo Messenger versions.

A further temporary workaround for the problem would be to set the killbit for the offending ActiveX controls:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{5F810AFC-BB5F-4416-BE63-E01DD117BD6C}
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{22FD7C0A-850C-4A53-9821-0B0915C96139}

It could be only a matter of time until we see customized versions of these exploits make their way into the wild to be employed by malware authors to infect machines. McAfee customers have been protected from this threat since the 5223 DATS–as JS/Exploit-YahooGrid.

Last Thursday, McAfee Avert Labs picked up another zero-day vulnerability targeting the JustSystems Ichitaro office application in the wild, the fourth since August 2006. Targeted attacks were directed at multiple enterprise and government users of Ichitaro in Japan, using two versions of a maliciously crafted Ichitaro document. Both exploits install the same BackDoor-DLI Trojan payload.

Now, Ichitaro, unlike Microsoft and being a local application, is not a popular area of interest among vulnerability researchers. The most high-profile vulnerabilities reported in 2007 would most likely be Internet Explorer and popular image and media players (e.g., QuickTime RTSP vulnerability, Exploit-AniFile.c–both with high success rates in the wild). In fact, Ichitaro caught the eye of vulnerability research labs only following a series of zero-day attacks. Prior to Exploit-TaroDrop.d, the most recent incident, in August 2007, was followed by the first three vulnerabilities publicized by a commercial research lab (http://www.ipa.go.jp/security/vuln/200710_Ichitaro.html), which was promptly followed up by the vendor with the latest security patches.

Notably, the bad guys did not leverage the reported vulnerabilities in the latest attacks. Instead, they fueled the attack with their own zero-day vulnerability, which was unknown to the world prior to the attack. Not following the herd, they did not use a Microsoft or QuickTime vulnerability. Their objectives are clear: only specific targets, and using specific exploits against the weakest links available, not what is popular.

The latest security patch for Exploit-TaroDrop.d was already released from the vendor on last Friday.

You may have seen a number of news reports in the past day or two on the active exploitation of a Microsoft Access vulnerability. Here is one story by PC World.

The US-CERT’s current activity Web page, “a regularly updated summary of the most frequent, high-impact types of security incidents currently being reported to the US-CERT,” warned about this active exploitation on December 10.

It is rumored that the vulnerability being exploited is CVE-2007-6026.

Avert Labs is working to find out more. As they say in the press, watch this space!

While we wait, here’s what we know about CVE-2007-6026. It’s a stack overflow in Access. A user would have to open a specially crafted Access database for an attack to take place. Although user assistance is required for exploitation, an exploit could be delivered over various attack vectors, including the Web, e-mail, and IM. Attacks could be coupled with well-establishing social engineering techniques. And now for the rub: This vulnerability is currently unpatched.

It seems to be about that time to, once again, get out our computer security crystal ball and conjecture about the upcoming year.

Many things are changing. Some are staying the same. In some areas we are in uncharted territory.

Threats are moving quickly to technologies such as VoIP and instant messaging. Virtualization will have a huge impact on both data security and the data security industry itself. Professional and organized criminals continue to drive much of the malicious activity. The complete set of predictions is available for download on McAfee’s Threat Center as well as a bonus episode of our podcast AudioParasitics.

Most of the virus researchers in Avert spend their days analyzing samples coming in from customers. With a good percentage of the samples coming in every day being unknown, there’s plenty to keep us busy, 24/7/365. But what is it like, sorting through an unending stream of samples every day? What does that entail?

It’s a bit like trying to identify a life-form from a disconnected body part. Sometimes the body part is actually the whole animal, but it’s often just a toenail or a feather. There are times where we don’t even get a body part, but a footprint or a piece of the animal’s droppings.

Sometimes we’ll get lucky and it’s an animal whose footprint we know really well, or which has very distinctive feathers. Then we can say “there’s a good chance what you have is a peacock”, based on just that feather. But more often than not, people are dealing with something entirely new or rare. Perhaps this critter only displays its distinctive traits in very specific circumstances.

Of course, our favorite sort of sample is one which is a complete body with a good explanation of where and how the animal was found. Whereas a foot accompanied by no information may get an answer of “This is an amphibian”, more of the animal or more context can increase the odds of us being able to say something more specific: “This is Litoria caerulea - aka the Dumpy Tree Frog. It lives in Australia and it is often found hiding in downspouts.”

So how does someone wishing to submit something for analysis go about doing it?

For starters, include as much info as you can: What version of security product are you using? In the case of our products, what version of the product, what engine and DAT files are you using? Are you seeing detection with some AV product? What filename and virus name was given? Are you seeing strange behavior that you associate with the file?

Getting the whole beast can be a bit more tricky. There’s sort of a continuum of sneakiness, from very spammy looking emails with attachments, to bots which get in through software vulnerabilities and then drop rootkits. If you’re the “lucky” recipient of the easy variety, ZIP up that email and send it to us.)

If your sample falls somewhere on the sneakier side of the spectrum, files can really be scattered all over a machine, and some of them are particularly good at hiding. You may want to try scanning your system with the Rootkit Detective or the Beta DATs from the Avert Tools page. This can help identify more suspicious files.

Maybe you’re pretty astute and you’ve noticed that after you ran a file a strange file, it created hundreds of randomly named files in your Windows directory. We may or may not need more than one of those files. You’ll want to check for duplicates, to make sure. If you know how to generate hashes for a file, just make sure you have one of each unique hash, up to about 10. (If you have something parasitic or polymorphic this will give us a decent representation) If you’re not sure how to create a hash, there are certain programs which can help you. One of my favorites is the CRC option in WinZIP (in Configurations, under the Options menu). This allows you to group by CRC and get rid of any duplicates.

In short, try not to just send a blurry video of Sasquatch (or is that a guy in a gorilla suit?) or to send us a hundred disembodied ant legs. The more thorough and complete the sample, the better the chances of getting a complete picture of what’s plaguing your machine.

McAfee Avert Labs today observed e-mail messages with malicious PDF attachments exploiting the critical Adobe Acrobat Mailto Unspecified PDF File Security Vulnerability (CVE-2007-5020) being spammed in the wild. Successful exploitation leads to a batch file being executed on the victim’s machine that disables the built-in windows firewall and then downloads a password stealer from an ip address located on the RBN network.

Malware authors will find this technique of sending exploit-laden PDF files extremely profitable especially in targeted attacks since the Portable Document Format is the de-facto standard for exchanging electronic documents. PDF files have traditionally been unfiltered at the email gateway and until recently were considered risk free in stark contrast to the notorious history associated with Microsoft Office documents.

But with Microsoft making it difficult for attackers by raising the bar for buffer overflow exploits with the release of Windows Vista and Microsoft Office 2007, we expect to see exploit writers target the lower hanging fruit. Abusing exploits in popular applications such as Adobe, Apple, RealPlayer or Antivirus products are proving to be just as advantageous and profitable for the bad guys. McAfee Avert Labs anticipate spammers in collusion with malware authors to continue exploiting popular application flaws and it is imperative that users are educated on how to avoid becoming a victim.

Users running vulnerable versions of Adobe Reader and Acrobat 8.1 or earlier are strongly advised to update them from the Adobe site. McAfee users are pro-actively protected against Exploit-PDF based threats with the latest dat files.

Earlier today we posted a blog entry: RealPlayer Zero Day Exploit Hits the Web.  Well RealPlayer responded RealQuick.  In less than 24 hours they managed to ship a patch.  That’s what I call rapid response.  Real also states that more information will be posted on their Security Updates & Incident Reports page.

Earlier today McAfee’s Regional Virus Info identified over 250 unique machines reporting Exploit-RealPlay.a detections, 99% of which reside in the US.  This does not mean that each of these systems were vulnerable, but it does mean that in all likelihood thousands of systems worldwide were exposed to the malicious code.

Last night we obtained a sample of a RealPlayer zero day exploit.  RealPlayer 11 Beta, 10.5, and older versions are affected.  Today’s DAT release, version 5145, contains detection under the name Exploit-RealPlay.a.  At this point, exposure appears to be limited, but we can expect public exploit code to surface before too long.  At that point exploitation is likely to follow the path of many other drive-by exploits and become fairly well distributed.

The vulnerability lies in a RealPlayer ActiveX control, and can be mitigated by setting the appropriate kill bit via the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\
ActiveX Compatibility\{FDC7A535-4070-4B92-A0EA-D9994BCC0DC5} 

While we generally keep this blog research focused (and shy away from mentioning products), zero day exploit announcements seem half-done without some mention of information on how our products deal with the threat.

McAfee product coverage information will be sent out via a McAfee Avert Labs Security Advisory service shortly.  This includes coverage information for the following product lines.

• All McAfee virus scanning technologies that utilize the DAT files, including:
• GroupShield
• LinuxShield
• PortaShield
• Secure Internet Gateway
• Secure Messaging Gateway
• Secure Web Gateway 
• Total Protection (TOPS)
• VirusScan Enterprise
• VirusScan Online
• VirusScan Enterprise Buffer Overflow Protection
• Host IPS
• IntruShield
• Foundstone
• McAfee Network Access Control (MNAC)
• McAfee Policy Auditor and McAfee Remediation Manager compliance

The patches for the Webcam vulnerabilities we reported earlier have been released by Yahoo. We urge Yahoo Messenger users to download the latest Messenger. Thanks to the Yahoo security team for working with us to resolve this issue in a short time. Here’s what you need to know.

Another exploit targeting a Japanese application is found today. This time, a free decompress tool, LHAZ v1.33, was used in a targeted attack. Maliciously crafted zip files could take advantage of an unidentified vulnerability in this tool and drops a BackDoor-CKB trojan.

Two months ago, we’ve published information about an exploit against a free LHA decompress tool, Lhaca which is quite popular in Japan.

Whilst these tools may not be as widely used as commercial tools, perception could be that such free tools are not worth targeting and are safe to use. Exploit-LHAZ.a is just a reminder that software, Windows or MacOS, English or localized, free, open source or commercial, are subjected to the same security threats.

More details of Exploit-LHAZ.a at http://vil.nai.com/vil/content/v_142976.htm.

[UPDATE]
Yahoo has fixed its Webcam vulnerability. The patches for the Webcam vulnerabilities have been released by Yahoo. We urge Yahoo Messenger users to download the latest Messenger. Thanks to the Yahoo security team for working with us to resolve this issue in a short time. Here’s what you need to know.

[Original blog:]
Earlier today Karthik had blogged about details of a new zero day in Yahoo! Messenger being published on some security forums in China, we got a chance to dig a bit deeper into this and were able to reproduce the vulnerability on Yahoo! Messenger version 8.1.0.413 based on the information provided in the forum. It seems like a classic heap overflow which can be triggered when the victim accepts a webcam invite. Note that this vulnerability is different from the recently patched one in June which exploited the Yahoo! Webcam ActiveX controls. 

We’ve been able to reach Yahoo! security team and have informed them about this issue. 

We recommend the following to users using Yahoo! Messenger Webcam:

1) Don’t accept webcam invites from untrusted sources until a patch for this is released.

2) It’s advisable to block outgoing traffic on TCP port 5100 until the vendor patches this vulnerability.

To mitigate this, we’re releasing our NIPS IntruShield signatures today to protect Yahoo! Messenger users from this threat. We shall keep on monitoring this threat and update if we come across anything.

A post on a Chinese-language security forum claims that there is a zero-day vulnerability in Yahoo Messenger. Researchers at Avert Labs have found that this flaw may allow for user-assisted remote-code execution attacks. No code exploiting this flaw has been published yet.

 We’re currently working with Yahoo to be able to confirm or deny that this is a zero-day.

We’ll keep you updated.

On July 31st Apple released the iPhone patch 1.0.1. The next day, Charles Miller released details of a vulnerability that was included in the patch release. The vulnerability was in an open source application on the iPhone, the PCRE (Perl Regular Expression Library) parser used by the JavaScript engine in Safari. Even though Miller found the exploit via fuzzing, he made a really interesting point which can lead to attackers finding easy 0-day exploits for the iPhone: the iPhone is running outdated open source applications. In this case, it was PCRE 6.2 with the latest version being 7.2. Just by simply looking at the changelog you can see that PCRE version 6.7 documented the vulnerability that was used,

18. A valid (though odd) pattern that looked like a POSIX character class but used an invalid character after [ (for example [[,abc,]]) caused pcre_compile() to give the error “Failed: internal error: code overflow” or in some cases to crash with a glibc free() error. This could even happen if the pattern terminated after [[ but there just happened to be a sequence of letters, a binary zero, and a closing ] in the memory that followed.

As more layers are uncovered with the iPhone and the Mac OS X underneath expect more 0-day exploits using the simple technique of open source version diffing. Also, hopefully, Apple will learn from this experience and keep the open source components up to date.

Oh the irony: Apparently someone has taken issue with some of the things I have said about the Immunity Debugger, available from Immunity and posted about an alleged backdoor within the program to the full-disclosure mailing list! Below is a copy of beginning of the post:

From: goudatr0n
Date: Thu, 9 Aug 2007 13:58:01 -0400 (EDT)

2. OVERVIEW
The Immunity Debugger contains a backdoor that emails
session history, running applications and other system
information (location, IP address, machine Owner Name)
to an email address at immunitysec.com

The original post with full text and comments can be read here. Needless to say, I am not involved in any way. Let me restate that I think this to be a very powerful tool that was written for all the right reasons. My objections to it are how it can be used by all the wrong people to write more zero-day exploits, quicker and more efficiently. That puts users at risk. I know this is not the intent of the tool or Immunity.

I gotta say tho that anyone who takes the time to go through this much trouble to goof on me, I got nothing but love for!

DefCon gets quite a lot right and it is not just great content. Actually the content, IMHO, might be the LEAST important aspect to DefCon.

Let’s be honest here. We are all infosec warriors in the information age. We all keep pretty much up to date on security research, malware developments, game hacking, etc…. on a daily basis. Blogs, forums, podcast and other mediums allow us to stay bleeding edge. We have to. Most information in most presentations at most conferences is a good 6 months old (not always, but usually). This is where DefCon distances itself from the pack.

If you really want to see where security theory and research practicality collide (fueled by Brew and Coffee Wars!) then the floor of DefCon is the place to be. Truthfully, it is the activities of DefCon, not the presentations, that you need to get caffeinated for:

* The Network @ DefCon
* 0wn the b0x
* Phreaking Challenge
* CTF (if you gotta ask…….)
* aCTF
* LPCON5 - Lockpicking Contest
* Hacker Jeopardy (one of my personal favorites)
* TCP/IP Drinking Game
* Wardriving Contest
* Wireless Village - ChurchofWiFi
* Lockpicking Village

No disrespect to the presenters or any of their content but pwning-in-action is what makes DefCon well…….. DefCon. This is where the training, conferences and theory all meets the pavement. Can you get root? Can you stop someone from getting root? Do you really know what you are doing? Hey, is that a custom PWS variant that just pwned my data? Ohhhh, I never saw that evasion before!!! It is events like the above where the real education takes place.

Oh and the the Toxic BBQ! Part 2 later today…..

An exploit found to be targeting an unpatched (as of the time of this writing) vulnerability for the Japanese word processor, JustSystem Ichitaro was discovered in-the-wild on 3rd August. We identify the threat as Exploit-TaroDrop.c trojan.

The modus operandi bears close resemblance to the 0-day attack we blogged about in April 2007. The attack, delivered in the form of a maliciously crafted document drops BackDoor-DKI.gen, a trojan that was used amongst other malware in the April attacks. The shellcode drops a clean copy of the document as “aa.jtd” and re-opens it in the word processor. Other than that, additional obfuscation code is added on top of the basic XOR encryption we saw in the past.

We caution all Ichitaro users that we may continue to see such attacks against this localized applications. More details of Exploit-TaroDrop.c at http://vil.nai.com/vil/content/v_142899.htm .

Later this week the malware count will most likely go beyond the 300.000 barrier for malicious items count.

Malicious items have come and gone over the years, but some remain persistent. The types of malware are not constant but evolves over time. From the late 80’s till early nineties they were mainly the MS-DOS 8 bit .com & .exe files & boot infectors.

From 1995-2000 VBA code was very dominant, first as a side-effect as people would exchange infected .doc/.xls files unknowingly, later malware code would just read all items from the outlook address book and would automatically mail itself out.

From 2000-2003 Javascript/VBScript items along with 32 bit PE files were dominant, exploits and multi-component malware began to appear.

From 2004 onwards the binary massmailing worms were the topic of the day, resulting in many overloaded Exchange Servers. On some occasions we even had to go to “Medium” risk multiple times a day. The Netsky/Bagle wars are over luckily.

From 2005 onwards the shift went to BOTs and Trojans plus Adware & Spyware & Phishing attempts grew.

The Bots are especially problematic as they’re so hard to fight. The bot networks were mainly used to distribute adware/spyware but on some occasions were also used for DDoS attacks, for “fun” or worse, for ransom etc. Although we still see many bots appearing they don’t seem to be that dominant any more. Nowadays the focus is more on the obtaining of money from adware and trojans but there’s also much spyware. Also specific targeted attacks are more common.

So even though the general public doesn’t hear that much of outbreaks as in the Netsky/Bagle wars, malware numbers still grow very fast using more silent methods with adware/spyware and targeted attacks.

In 2000 we had a little over 50.000 malicious items. That figure went to 100.000 in 2003. In August 2006 we passed the 200.000 barrier and almost exactly 1 year later, august 2007 , we will be passing the 300.000 barrier. With these huge numbers appearing the handling of samples can’t be maintained by humans only. It also continues to raise many questions around the naming of malware.

Parts 3 and 3.5 of this series covered when and how Zero Day Threats are released, this last part briefly covers key events over the past year and touches on what we can expect over the next year.

There have been a few significant developments in the zero day threat space over the past 12 months.  A year ago to the day, the first Month of Bug project was launched, during which browser related vulnerabilities were disclosed, one for each day of July.  Most of these threats had not been disclosed previously.  Many security researchers followed the project closely, numerous press articles were published, and just in general a lot of attention was given to the project, those behind it, and the vulnerabilities that were disclosed.  Since then there have been 8 other Month of Bug Projects.  Many of the vulnerabilities irresponsibly disclosed are considered to be zero day threats. 

While these projects are growing tiresome and the media attention has largely subsided, this existence of these projects highlight the motivations of those behind them, primarily fame, peer praise, vendor bashing, and raising awareness of the issues.  Some vendors have been more responsive than others as you’d expect.

Another fairly recent event is the release of a new Metasploit Framework.  A description from the Metasploit site:

This release speaks to the maturity of vulnerability assessment tools as well as exploit automation.  Speaking of vulnerability assessment tools, the AxMan fuzzer was used to discover nearly 20 different ActiveX flaws during the first of the Month of Bug projects.  Fuzzers are programs designed to test the inputs, or parameters, of an application. While fuzz testing dates back to 1989, recently fuzzers have been used to discover numerous critical security vulnerabilities.  Here’s a list of fuzzers released around the time of the first Month of Bug Project.

Some fuzzers used during other Month of Bug projects were also later released.

A third significant and recent event was the in-the-wild discovery of a targeted zero day attack on the infrastructure.  I’m talking about the RPC DNS Server Service Vulnerability (CVE-2007-1748). The evolution from discovery to mass-attack was not unfamiliar, but this could be a sign of times to come, where targeted attacks branch out from the more typical application vector (namely MS Office) and focus more on the infrastructure. 

So what lies ahead?

• The Month of Bug projects should start to slow down before too long; as the newness wears off and researchers look to other means of raising awareness
• The development of exploit tools will continue to mature with continued and increasing collaboration as well as availability
• The market for quality exploits will continue to expand
• Web applications will continue to be a major target for attackers
• The infrastructure will be a growing target moving forward

I hope you’ve enjoyed this blog series.  This data and commentary represents a fraction of the content that my colleges and I have been preparing for threat forecast reports covering a wide range of threat topics; content that is being used by customers and McAfee alike, to plan for the future, invest more wisely, and mitigate risk.  These forecasts are being produced and updated on a regular basis.  Look for excerpts in future blog postings and series.

This is just a quick update to clarify a couple points and respond to some comments / posts I’ve read on the matter.

First off, the definition:

So what’s wrong with this definition?  Well, someone can exploit an unknown and unpatched vulnerability to attack someone else, without any public disclosure or even knowledge.  This is true.  Of course, without being aware of the details (or even existence) one could not validate and label the threat as a zero day.  But after you have this information my simple definition is satisfied.  In other words, a zero day is not a zero day until it’s a zero day.

Another likely point of contention is the inclusion of the word public.  Public is included for the specific reason of dismissing vulnerabilities and exploits that are privately reported to the vendor; and without the term being included, virtually all vulnerabilities shared with anyone are zero days, including those found by the vendor themselves.

While it is not perfect, I do think it’s a good–simple–general purpose definition.

Second, the inclusion of low-risk vulnerabilities in the stats, such as those limited to local denial of service:

I didn’t make assumptions as to the motivations of those who disclosed zero day information.  If someone was out to create a headache for Microsoft by generating more work or publicity at “a bad time” they might strategically release their DoS-only exploit around Patch Tuesday.

Clearly a vulnerability that allows for arbitrary code execution is significantly more critical, and valuable, than something that is limited to DoS.  Many vulnerabilities are reported as DoS, which may potentially be exploitable (allow for remote code execution).  It can take significantly more effort to confirm code execution and, depending on the motivation of the reporter, they may not make the effort.  You have cases where some vulnerabilities may or may not be limited to DoS.

So for the sake of the blog, I did not discount any vulnerability types.  FWIW here’s a breakdown of only those threats categories as remote code execution discovered/disclosed ±3 days of Patch Tuesday.

• 2005   0% (8)
• 2006 41% (40)
• 2007 30% (10) as of April 15

As I stated in my previous post, the dates associated with threats discovered though active exploitation are unreliable.

Third, “Exploit Wednesday”

My post really didn’t cover this.  Exploit Wednesday is less about malicious attackers sitting on exploits until the day after Patch Tuesday, and more a result of those who previously, and responsibly, reported a vulnerability to Microsoft and then waited until Patch Tuesday before going public.  After Microsoft releases a patch, they then disclose enough details that allow for the creation of an exploit.  Another factor is those who reverse engineer the patch to discover the vulnerability and then write, and release, an exploit.

The 4th and final part of this blog series is in the works.

In part 2 of this blog series, I touched on the profile and motivations of those behind Zero Day Threats.  In part 3, we’ll take a look at when and how these threats are released/discovered.

In 2003, Microsoft moved to a monthly patch release cycle (commonly known as Patch Tuesday, for the second Tuesday of each month).  After a while people noticed a correlation between when zero day vulnerabilities were discovered/disclosed and the proximity to Patch Tuesday.  Some concluded that many zero day threats are strategically released very close to Patch Tuesday as a means to maximize the Window of Vulnerability (time that an attacker can take advantage of a yet-to-be patched vulnerability).  To test this theory, I took a look at some 200 Microsoft zero day vulnerabilities since January 2005, tracking when they were discovered relative to the closest Patch Tuesday.  You may be asking, 200 Microsoft zero day vulnerabilities since January 2005 ?!?  While some consider local denial-of-service vulnerabilities not to be zero days, I’ll defer to my previous definition, which was used for the purpose of creating the chart below:

This chart plots the proximity of discovery from the closest Patch Tuesday.

This data can be broken down as follows:

• In 2005,   7 (18%) Zero Day threats were discovered ±3 days of Patch Tuesday.
• In 2006, 36 (31%) Zero Day threats were discovered within the same time frame.
• In 2007, 10 (24%) Zero Day threats were discovered within the same time frame (as of April 15)

NOTE: ±3 days is a 7 day window.  Given an even distribution, one would expect to find 23% of all vulnerabilities during this window.  The data suggests that at least in 2005 and 2007 strategic releases were not that common; and even 2006 only showed an 8% deviation.

There is another significant factor to consider…vulnerabilities discovered through active exploitation have been erroneously assigned the date of disclosure, rather than the date of release.  Of course there is a good reason for this, the release date is not always known.  There have been cases in the past where server logs showed evidence of zero day vulnerabilities being uploaded well in advance of the discovery date.

The following chart represents the number and method that zero day threats were discovered/disclosed when comparing two six month periods:

Roughly 10% of all vulnerabilities were first discovered through active exploitation.  While a significant number, 42% of these were discovered within the ±3 day window, we don’t know the actual release date for many of them.

So where does this leave us?  Well, undoubtedly some attackers are waiting for the right moment to strike, but this is somewhat akin to trying to sell stock at its peak price.  Attackers can’t really know how long their zero day threat will go unnoticed, when it will be reported to the vendor, patched, etc.  They can be sure that if they release their threat within a few days before Patch Tuesday that Microsoft would have to pull-off something yet-to-happen to date; the release of an emergency patch in under 6 days.  If they release say 10 days before Patch Tuesday, it’s a gamble that the threat will go unnoticed for at least a few days before being reported to Microsoft.  Of course they could wait until just after Patch Tuesday to release, but by doing so they would fail to maximize the duration of effectiveness.

It’s more likely that many attackers do not wait and simply release their threats as soon as they are ready to be released.  The more time that passes, the greater the chance that the vulnerability will be disclosed and/or patched.

Check back later in the week for the 4th and final part of this blog series.

In part 1 of this blog series, I presented a definition for zero-day threats. Now that we know what they are, let’s explore how they come to be–why they exist.

Many years ago security researchers discovered vulnerabilities in software and took their findings to the manufacturer, or vendor. Oftentimes they, or their findings, were either ignored or not taken seriously. Out of frustration researchers began seeking other means to have their issues properly addressed, and their voices heard. (For more on this, listen to McAfee’s AudioParasitics podcasts Episode 4 & Episode 5 with special guest Stuart McClure.)

Back then, fighting “for the people” and making software more secure were certainly motivating factors for researchers; and of course notoriety and peer praise played a role.

Nowadays there is another primary motivating factor, money. The rewards range from the few hundred dollars that vendors like Mozilla pay, to the thousand dollars that vendors such as Verisign iDefence, 3com TippingPoint, Digital Armaments and, more recently, Netragard’s Snosoft fork over, to the many thousands of dollars offered by private companies and individuals on the black market.

Charlie Miller recently published a paper entitled The Legitimate Vulnerability Market: Inside the Secretive World of 0-day Exploit Sales describing the challenges of selling vulnerability information.  As discussed in this paper, there are a number of obstacles when trying to line up a buyer, negotiate a fair price, prove the validity of the vulnerability, and close the deal without either party getting burned. Many researchers who are fed up with these problems opt to trade in the currency of fame rather than fortune. Some of these researchers have contributed to various “Month of X Bug” projects, including blogs built for the regular and scheduled disclosure of vulnerabilities. The first few MO_B projects got quite a bit of attention, but now that there have been seven of these projects, they are becoming tiresome.

So why buy a zero-day threat? Research organizations created bounty programs to buy zero-day threats to protect and share the vulnerabilities with their customers, for marketing and press–oh–and to notify the vendor to patch the problem. Private parties must buy them for the same reasons, yes? Wait a moment, private parties have no customers and they don’t want the attention of press. Why would they want the vulnerability patched? That would only devalue the information. What are the remaining reasons for them to purchase these vulnerabilities? To carry out attacks, of course, or to resell the threats. It’s also conceivable that in an age of cyberwarfare, governments may purchase zero days to both remove the threat from the market and to beef up their defenses.

Tune in next week for Zero-Day Threats, Part 3: When & How Are They Released?

During the past seven years at McAfee Avert Labs, I’ve had the opportunity to fill several roles. More recently I’ve stepped away from day-to-day threat processing and focused on mid- and long-term threat intelligence. Namely this includes threat forecasting; gathering and analyzing threat trends and upcoming influential factors to forecast what may lie ahead. The resulting data is being used by customers to help them plan for the future, invest more wisely, and mitigate risk. The information also helps drive and shape McAfee product offerings.

One of the areas that I’ve spent some time analyzing is that of the zero-day threat. The first step when considering a threat is to define it. Over the years, the term zero day has been used for a number of things; from vulnerabilies and exploits, to viruses, Trojans, and even spam and phish. I define a zero-day threat as follows:

Exploit information does not necessarily mean a working exploit, or even proof of concept code, but at a minimum it means that enough technical details are available for someone to find the vulnerability on their own, to create a working exploit.

This definition excludes a number of things that some would not like to exclude:

• Malware that doesn’t exploit anything new. Some like to refer to new malware as a zero-day threat, so that they can claim zero-day protection. We already have a term for that, proactive protection.
• Spam & phish that doesn’t exploit anything new. The same applies here.
• Vulnerabilities that are privately disclosed to the vendor. I do not consider brief, yet public, “Upcoming Advisories” that are published when a vendor is notified to be a zero-day threat; unless sufficient vulnerability details are also made public.

The two recent Yahoo Messenger vulnerabilities were an interesting case. Ryan Naraine’s blog has a good write-up. eEye published an “Upcoming Advisory” after discovering the vulnerabilies and reporting them to the vendor. A Yahoo spokesperson inadvertently spilled the beans and gave additional details that were not public. While I wouldn’t say that those details were sufficient to call these zero-day threats at that point, they were enough for a researcher to find the vulnerability within an hour, give or take. The results of that research, proof-of-concept exploit code posted to the Full Disclosure mailing list, were zero-day threats. Shortly thereafter, other exploit code was posted to the Web, and attacks were discovered in the field. In the end it didn’t much matter what the zero-day timestamp was for this threat, Yahoo users were put at risk, and certainly attacked. Yahoo did manage to turn around a patch in an amazing 48 hours, but surely there are many thousands of users who have yet to apply the patch.

There’s much more to cover on the topic of zero-day threats. Stay tuned for part 2 of this series.

– Update June 14 –
Part 2 has been posted: Zero-Day Threats, Part 2: Who’s Behind Them and Why?

As we talked about organized cyber crime on the rise, the script kiddies are not taking a break. CVE-2007-2221 was patched in MS07-027 on May 8th, 2007; barely two days after a proof of concept was published on the Internet. During the weeks that followed, we saw the original proof of concept exploit code posted onto hundreds of script kiddie websites and forums. Fine, all proof of concepts we’ve seen in the past already spread like fire; and CVE-2007-2221, a vulnerability for a non-default Windows service, is unlikely to have an impact quite like Exploit-AniFile.c. So what’s the big deal ?

Amusingly, we see many variations of the original proof of concept code. In most cases, we know they all originated from the same source because none of the comments or author’s name were changed (oh yes, script kiddies give credit too). Some impress with shellcode “boosters”, others rip off a heap buffer overflow “turbo-kit” from Exploit-VMLFill; all that for a vulnerability that doesn’t even cause a buffer overflow. With so much script kiddie goodies, it deserves a GUI script kiddie tool written by a 18-year old.

What brought this to our attention was an in-the-wild discovery of Exploit-CVE2007-2221. We believe this would be the first time that a malicious exploit for CVE-2007-2221 is discovered in the wild. Exploit-CVE2007-2221 is abusing a vulnerability in a Microsoft Windows Media Server 4.1 component through Internet Explorer. When successful, attackers can overwrite any files on the victim’s machine with malware.

The discovered exploit code was hosted on hxxp://web733{blocked}914.{blocked}.128web.com which was reportedly hosting the infamous Exploit-AniFile.c back in March 2007. At the time of writing, the malicious payload was no longer available for download. Exploit-CVE2007-2221 used on this site was, as you guessed, generated with that “shellcode-enhanced” script kiddie tool.

As for the malicious sites which are monitored by McAfee Avert Labs, some are dead, moved or no longer host exploit codes. However, as long as site administrators do not enforce a policy of taking malicious sites down, many can continue to seek opportunities to host new malware, and will be awakened whenever a new exploit made available for their malicious activities. But did they tell you the exploit code doesn’t even have to make sense ?

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…

A new Nirbot variant has been discovered that attempts to exploit the recent zero day vulnerability in Microsoft’s DNS Server Service (CVE-2007-1748).

Vulnerability to Worm Timeline:

• April 7 - This vulnerability was first reported by SANS in what was believed to be a targeted attack
• April 12 - Microsoft posted Microsoft Security Advisory (935964)
• April 14 - An exploit was made public
• April 15 - Three other exploits were made public
• April 15 - The first worm was submitted to McAfee Avert Labs late in the day

Analysis is on going. More details will be posted here.

Update April 16, 20:30 PDT
A second variant has been discovered.

First Variant
File Name: mdnex.exe (writes c:\U.exe)
File Size: 199,680 bytes
MD5: 0xc1a6a22b2415ba608fb894b4e036e19c

Second Variant
File Name: mozila.exe (writes c:\U.exe)
File Size: 270,848 bytes
MD5: 0×8f6cb8d895e60387fe3e41377d0f0d3f

Last week was spent combating a slew of exploits for the vulnerabilities patched by Microsoft on April 3.

Yesterday saw the release of several Microsoft Office zero-day exploits in security forums. Some of these flaws may allow for remote code execution. McAfee Avert Labs is investigating all these zero-days. Today is Patch Tuesday for April. So, yes: this is yet another time that zero-day flaws have been published around a Patch Tuesday, possibly to maximize the public’s exposure to these flaws until the next month’s Patch Tuesday.

Update, 2pm PST

Further research by Avert Labs indicates that all but one of the Office zero-days reported yesterday result in denial of service. There is one heap-overflow flaw that might be exploited for code execution. We’ll keep you updated.

Update, 5pm PST

Avert Labs has been analyzing proof-of-concept code for a zero-day vulnerability in Microsoft Windows’s handling of HLP files. This is another heap-overflow flaw that might be exploited for code execution. Stay tuned.

Update, April 17
Microsoft has ruled out the possibility of code execution in the zero-day vulnerabilities in Word 2007 released last week.

On April 6th, 2007, our heuristics proactively detected a new document exploit for Ichitaro, a popular Japanese word processor, that was being exploiting a new 0-day vulnerability in the wild. The vendor was notified immediately and confirmed we have identified a new and previously unknown vulnerability. This follows the other 0-day vulnerability for Ichitaro that was exploited in the wild in August the previous year.

The specially crafted document (Exploit-TaroDrop.b) came with a Japanese filename with extension “.jtd” that is used by Ichitaro.

When users open this document, Exploit-TaroDrop.b causes a buffer overflow, executes shellcode, drops a malware called %Windir%\System32\downhk.exe (BackDoor-DKI.dldr) and silently terminates. Before the user could realize the disruption, Ichitaro is restarted and they can continue to view the document but with a different filename “a.jtd”.

What goes on behind the scenes was really Exploit-TaroDrop.b taking control over code execution from Ichitaro after a buffer overflow occurred and caused the application to terminate. The malware author attempts to “repair” the user experience by dropping a clean document that can be viewed in Ichitaro so as not to arouse any suspicion.

We are seeing similar methods used in the other document type exploits for Microsoft Office applications. Although this method may vary in other cases, it would be worth checking the filename in the application title bar, and take note of any abnormal behavior as such.

We can expect malware authors to continue discovering and creating new exploits in localized (and often neglected) applications; and using various social engineering methods to keep these threats undetected. Users must be armed with both advanced heuristics and good vigilance and intuition and even then threats like these are going to be increasingly difficult to track and defend against.

A security patch is being developed by the vendor to deal with this vulnerability.

This malware was reported by both Shinsuke Honjo and Geok Meng Ong of McAfee Avert Labs.

Just when you think you have had enough of obfuscation in executable files and web scripts, McAfee Avert Labs has been tracking a series malformed image files in the current wave of 0-day ANI exploits since the wild fire started burning about 2 weeks ago. Some of these ANI exploits introduce what I would like to call obfuscation in image files.

ANI files are cursor icon images that are commonly used on the Windows platform of which its format specifications based on Resource Interchange File Format (RIFF) are public and open. In the ANI exploit code that were made public, we found common ANI headers that were modified and redundant noise prepended, in an attempt to circumvent detection in most traditional content filtering and anti-virus products that lacks proper scanning, in the context of the threat, and proactive exploit protection.

All of these “malformed” image files are rendered by Internet Explorer and can cause remote code execution or memory corruption in unpatched Windows systems, in our tests.

In this sample, the ANI exploit generated by a popular free-for-all toolkit, uses a lot of random tags such as “gIZU”, a nonsense RIFF tag. It looks like it was inspired by “TSIL”, a reversed “LIST”, found in the first variants of the 0-day to be discovered. The RIFF specifications does not forbid 4-byte ASCII identifiers outside the common list of ANI tags and most image viewers including Internet Explorer parses them without any problems until it hits upon the relevant parts that causes the buffer overflow issue to occur.

As of today, approximately 10 days after the initial reports of the original Windows ANI 0-day vulnerability having reached public domain, many exploits generated and obfuscated using freely available toolkits still go undetected by a majority of anti-virus products tested.

(click here for full size image)

Just as ambiguity and variations in specifications and implementation can lead to bugs and security issues, they can also be exploited by malware authors to circumvent conventional detection. This presents a new challenge to security products that scan image files for malicious content using basic methods that ignore the context of the threat.

Windows users are once again reminded to install the security patch for this vulnerability from Microsoft.

Š

Another follow-up to my Unpatched Drive-By Exploit Found On The Web post.

Last month Websense reported that the official website of Dolphin Stadium, host of Super Bowl XLI, was compromised and serving malicious code.  In fact that was a massive attack affecting thousands of websites.  Those sites were injected with a script reference that pointed to exploit code.  At that time, the code exploited known vulnerabilities.

The SANS Institute did some investigating into that incident.  They posted portions of a response they received from a system admin where it was clear that a remote attacker exploited a SQL injection vulnerability to embed the malicious script.  The same script is now serving the ANI file 0-day exploit reported yesterday.  Googling the referenced script yields 113,000 results.  It’s likely that most of those sites were compromised through SQL injection vulnerabilities.  Of course many of these sites have been cleaned up, malicious references removed, but not all.

Several of my posts over the last few months have centered around very targeted zero-day attacks.  This post covers an exploit that McAfee researchers discovered in the field, posted to a message board.  That posting was simply a proof of concept; however McAfee Avert Labs has since received a malicious sample as well.  It is quite likely that similar exploits targeting this vulnerability are currently being used in other attacks on the web.

Preliminary tests demonstrate that Internet Explorer 6 and 7 running on a fully patched Windows XP SP2 are vulnerable to this attack.  Windows XP SP0 and SP1 do not appear to be vulnerable, nor does Firefox 2.0.  Exploitation happens completely silently.

The vulnerability lies in the handling of malformed ANI files.  Known exploits download and execute arbitrary exe files.  This vulnerability is reminiscent of MS05-002.

More information will be posted as it becomes available.

Update March 29 @ Noon
Additional information has been posted here:
http://www.avertlabs.com/research/blog/?p=233

This is an update to the update on CVE-2007-0870.

A few days ago I blogged about a new Word vulnerability that was used in a targeted attack (I know, it’s hard to keep these straight). Later that day Microsoft stated that the vulnerability was limited to denial of service, rather than remote code execution, and the blog was updated accordingly.

Well, since then our researchers continued to look at the issue, as did Microsoft’s. Today, McAfee Avert Labs’ analysis shows that this vulnerability is likely not limited to denial of service and that remote code execution may in fact be possible. Microsoft has also acknowledged that the vulnerability may not be limited to denial of service. Word 2000 and Word XP are believed to be vulnerable, though exploiting this flaw is non-trivial.

I suspect that a Microsoft Security Advisory for this issue will be released soon.

In related news, the team is currently analyzing proof-of-concept Excel files that were posted publicly today as “Microsoft Office Excel 2003 XLS File Denial Of Service”.

Update Feb 14, 6:15pm
A short while ago Microsoft did indeed release Microsoft Security Advisory (933052).

Earlier today Symantec posted a description for Trojan.PPDropper.G.  The vulnerability mentioned in the description has been assigned CVE-2007-0913.  SANS added it to their missing Microsoft patches table.

However, McAfee Avert Labs’ testing shows this issue was patched today in MS07-015 along with the Office Zero-Day reported by McAfee on February 2 (CVE-2007-0671).  This testing suggests Trojan.PPDropper.G may in fact be a PowerPoint version of the Office zero-day exploit used in Exploit-MSExcel.h.

We will post an update when we have more definitive information.

Update Feb 14,  2007
Microsoft has confirmed that this is patched in MS07-015 and related to CVE-2007-0671.

There have been numerous stories recently covering unpatched Microsoft Word vulnerabilities. For reference, the CVE designations for these vulnerabilities are:

• CVE-2006-5994
• CVE-2006-6456
• CVE-2006-6561
• CVE-2007-0515
• CVE-2007-0621 (Microsoft has stated that this is not a new, but related to CVE-2006-6456)

Recently McAfee Avert Labs added detection for Exploit-MSExcel.h, an Excel document that was submitted from the field. This exploit is consistent with other targeted zero-day attacks and is believed to be contained.

Microsoft has confirmed that this exploit targets an unpatched vulnerability. According to Microsoft’s Security Advisories Archive (Microsoft Security Advisories are released in advance of patch releases, not to be confused with Microsoft Security Bulletins), the only Excel-related security advisory in the past 20 months, was patched in MS06-037. Numerous other Excel-related patches have been released during this time.

Update Feb 2, 2007 at 7 pm PST
Microsoft Security Advisory (932553) has been released and CVE-2007-0671 has been assigned. Microsoft describes this vulnerability as affecting the following products:

• Microsoft Office 2003 
• Microsoft Office XP 
• Microsoft Office 2000
• Microsoft Office 2004 for Mac

From the advisory:

Workarounds for Microsoft Office Remote Code Vulnerability:
Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified in the following section.

• Do not open or save Office files that you receive from un-trusted sources or that you receive unexpectedly from trusted sources. This vulnerability could be exploited when a user opens a specially crafted Office file.

McAfee Avert Labs has confirmed Microsoft’s testing; not opening malicious Office files successfully mitigates this threat.

While various bits of North America have seen wintry flurries in the past fortnight, those in computer security have seen a flurry of four Microsoft-related zero-day exploits.

The first three of these flaws affect Microsoft Visual Studio:

• Microsoft Visual Studio .CNT Buffer Overflow
• Microsoft Visual Studio .HPJ Buffer Overflow
• Microsoft Visual Studio .RC Vulnerability

The fourth flaws affects Microsoft Word:

• Microsoft Word 0-Day Vulnerability IV

All four flaws would allow a remote attacker to execute arbitrary code on a vulnerable machine. For an attack to occur in all four cases, user interaction is required; e.g., a user would have to visit a Web site that hosts a malicious file or open a malicious file locally.

With Microsoft’s next Patch Tuesday falling on February 13, these flaws will remain un-patched for at least two more weeks. So stay warm this winter, and insulate yourself from these zero-day exploits too!

This just hasn’t been a great year for the security of applications or responsible disclosure, has it. First we have the Month of Apple Bugs (which is finding a number of application-specific vulnerabilities), then we have a raft of Adobe product vulnerabilities. Now we have VeriSign offering a substantial bounty for people to poke holes in IE7 and Vista.

It seems that what we’re seeing in the malware world is also happening in the vulnerability world. Financial motivation, a vast increase in overall traffic with no one incident being particularly huge, and a general feeling of being in the Wild West. Lawlessness and vigilantism seems to be the order of the day. That doesn’t generally lead one to feel like the internet is a shiny, happy place.

But what are we to do about this? Telling people they’re naughty and need to behave, when they’re getting such notoriety or financial gain obviously isn’t going to work. Making the notoriety and money stop coming is a largely futile effort as well, it would seem. Even suing Adware makers, as an example, seems to be reasonably ineffective.

Maybe the key lies in the consumer side of the equation. Maybe as the general populace becomes more aware of what things to avoid, and what things to do to protect themselves, this will become a moot point. The glut of malware and vulnerabilities will be like flies buzzing in our ears - an academic concern rather than a constant state of emergency. I do find it hopeful that people are becoming more aware of security issues, even if we have a very long way to go yet.

For many, the Portable Document Format (PDF) has become the de-facto standard for exchanging documents. In using PDFs, some wish to sidestep the risks of malware-prone Microsoft Office documents. But with the announcement of six new PDF-related vulnerabilities in several security forums last week, we should all now be more careful with PDFs.

The first five of these new vulnerabilities have to do with the Adobe Reader plugin. Attacks that exploit these flaws may result in one of more of these results: HTTP-response splitting, cross-site scripting, session forgery, session riding, denial of service, memory corruption, or code execution. This scary list of attack results notwithstanding, a user would have to open a malicious web URL for an attack to occur. Adobe has issued Adobe Reader 8 that remedies these flaws.

The sixth new PDF vulnerability is also the sixth of the Month of Apple Bugs (MoAB) installment. If a malicious PDF document crafted to exploit this flaw were opened by a user, it would corrupt memory and could lead to code execution. Landon Fuller has posted or referred to temporary fixes for all eight MoAB flaws so far. The fix for the MoAB PDF flaw can be found here. Thank you, Landon!

Please stay secure against the PDF vulnerabilities, as we continue to protect our customers against such threats.

No, it’s not a Massive Ordnance Air Blast Bomb, thankfully. But could users of Apple software feel that it’s really that bad? January 2007 is the Month of Apple Bugs (MoAB), in which a new Apple-related vulnerability is announced for every day of the month.

The first two MoAB bugs affect Apple Quicktime and VLC Media Player respectively. If exploited, both bugs would allow remote code execution — however user interaction is needed.

MoAB is a project similar to November 2006’s Month of Kernel Bugs (MoKB). The bugs released during the MoKB affected software from a gamut of vendors, including Apple, Linux, Microsoft, NetGear, and others. In both projects, security researchers announce previously-unknown bugs in selected software in order to raise awareness about the state of security in these software products.

While many MoKB bugs remain un-patched and the software they affect remain vulnerable, Apple users affected by MoAB can thank Landon Fuller for some temporary relief. Landon, a system architect, has promised to develop unofficial patches for software affected by MoAB bugs.

The researchers at McAfee Avert Labs will continue to follow MoAB closely, so keep reading!

Well, we’ve seen the first of the promised bugs for Apple and Apple products as a part of the “Month of Apple Bugs“. And perhaps unsurprisingly, the first bug is also applicable to Windows as well, being a buffer overflow vulnerability for QuickTime. There’s also some saying that this may be rather difficult to implement.

So in short, this month of bugs that’s supposed to take Mac fans down a peg…also exposes holes in Windows. And maybe it works, maybe it doesn’t. Way to start it off with a bang, there!

As a Mac fan who realizes Apple software is written by humans just like any other software, which will inevitably have the occasional bug, perhaps I’m not the demographic they’re looking to deflate. But really, I think you’d be hard pressed to find even the most rabid Mac fan who believes Apple software is 100% bulletproof. That’s just plain deluded. I think most Mac users at this point are of the opinion that it’s more akin to the risk of mosquito bites in August at Crater Lake, versus in January at the South Pole. There’s just a lot more nasty critters flying around the Windows environs than the OS X environs for the time being.

But even from a strictly researcher perspective, I am curious to see what this month brings up, both in terms of exploits and the discussion around them. Expect to see lots more here on that subject as things progress!

Apparently not! On December 20, a new zero-day exploit for Microsoft Windows operating systems was released. This exploit targets a weakness in the Client Server Run-Time Subsystem, and allows local privilege escalation or denial of service.

Microsoft has acknowledged this vulnerability and admitted that its newest operating system, Windows Vista, is vulnerable.

Keep reading for more on exploits released this holiday season. Happy holidays!

In the week leading up to 12 December 2006, two new Microsoft Word zero-day vulnerabilities became public (Word I, Word II). Microsoft’s December Patch Tuesday fell on December 12, but this cocktail of Microsoft’s patches did not include fixes for the two new Word flaws. To make matters worse, on December 12, a third zero-day Word flaw was released (Word III).

Although one could argue that the December 12 release of a new Microsoft flaw was only a coincidence, it fits the trend of the disclosure of Microsoft vulnerabilities on or just after a Patch Tuesday. November’s trend-fitter, a vulnerability in Microsoft Active Directory, did not include a public proof-of-concept; this month’s trend-fitter, however, does have a public proof-of-concept.

So the Word zero-day trio has a window of exposure of at least a month. Please stay secure as we continue to protect our customers against such attacks.

Last Wednesday, Microsoft posted an advisory for a targeted “zero-day” attack using a Microsoft Word vulnerability CVE-2006-5994, we refer to this as “Microsoft Word 0-Day Vulnerability I”.

In our tracking of this new 0-day vulnerability, I analyzed a Word Document sample for MessageLabs. Just when you would have thought this could be the same 0-day which was most recent, Microsoft confirmed upon our request that we are seeing double trouble — this was really “Microsoft Word 0-Day Vulnerability II”.

I previously wrote about non-executable file formats being a popular vector in recent years; this is a trend that will continue into 2007 and deserves to be given ample consideration in planning for security resources, policies and user education programs.

McAfee Avert Labs released DAT coverage for payload associated with “Microsoft Word 0-Day Vulnerability I” in DAT version 4914 for Downloader-AZQ and Downloader-AZR. The new threat that is exploiting “Microsoft Word 0-Day Vulnerability II” is now covered in DAT version 4915 as Exploit-MSWord.b.

Today, Avert Labs announced the availability of its podcast on the “Top Ten Security Trends in 2007”.

As part of this podcast, McAfee will identify those threats it believes businesses and consumers will face in 2007 as computer criminals become more organized and professional in their approach.

Download the podcast

On Sunday November 5th, we blogged about a 0-day exploit discovered in the wild that was targeting a Microsoft XML Core Services vulnerability. McAfee Avert Labs had been tracking and monitoring the payload deployed by this exploit.

W32/Kibik.a was the detection name assigned on Sunday, which was soon included in the McAfee VirusScan DAT release the following week. With rootkit heuristics, behavioral detection and IP blacklists being the talk of the (security) town in recent years, W32/Kibik.a makes an interesting attempt to survive in this competitive matrix of today.

W32/Kibik.a is a parasite that attaches to Windows Explorer (explorer.exe), even covering backup copies of explorer.exe in system restore, service pack installation and windows installer folders, making it a hard time for the victims to restore the original system file. On the process list, explorer.exe has its perfectly legitimate presence; on disk, the infected explorer.exe file has no distinction in filesize because W32/Kibik.a attaches to unused segments in the original file. Behavioral detection products looking for rootkit characteristics or autorun register keys will find nothing, because there isn’t any rootkit or autorun key.

To make it even difficult to track for network administrators, W32/Kibik.a sends innocent looking search requests to Google Blogsearch - only the search keywords are unique hexadecimal strings. Google Blogsearch, unlike Google Web Search that we are most familiar with, indexes blog entries with RSS and Atom feeds from blog authors. This makes blog content more readily searchable than Web search. When indexed, search results can return dynamic data, such as URLs to download, or commands to execute in a synchronized manner. At the time of writing, W32/Kibik.a’s searches have not yielded any results thus far.

From silent installation via a 0-day exploit, to silent residence and operations and virtually silent and innocent looking Google search; W32/Kibik.a could well be the start of a new trend in scalable remote controlled malware (a.k.a. botnet) in 2007. It is no wonder with its stealthy elements, few security vendors had detected or repaired W32/Kibik.a to date.

McAfee Avert Labs continues to monitor W32/Kibik.a and other malware using these techniques.

Š

Microsoft recently posted Security Advisory (927892) for a critical vulnerability in Microsoft XML Core Services. This vulnerability was discovered in the field and allows for remote code execution. This equates to another means for drive-by attacks via Internet Explorer. Exploitation is not believed to be wide spread at this time, but we can expect exploit code to become public early in the week at which point exploitation will pick up exponentially.

Workarounds include setting the kill bit for the XMLHTTP 4.0 ActiveX Control and modifying Internet Explorer’s security settings. For more information, see:
http://www.microsoft.com/technet/security/advisory/927892.mspx

McAfee Avert Labs is currently analyzing this threat.

In my last blog entry I talked about the consequences of Microsoft’s policy of releasing security updates only once a month. Is this encouraging exploit writers to release zero-day Microsoft exploits soon after a month’s Patch Tuesday to maximize the vulnerability’s window of exposure? Yesterday, on 24 Oct 2006, exploit code was released for a Microsoft Internet Explorer (IE) vulnerability. This proof-of-code code could cause denial-of-service (DoS) in IE. Avert Labs is investigating this exploit further.

Patch Tuesday next month falls on November 14. So this IE bug’s potential window of exposure is at least three weeks…

As timescales compress in computer security, research organizations feel increasing pressure to be first to report on a threat. It’s hard to perform lengthy fact checking in hours time. In the last couple of months we heard about two different 0-day attacks from two different major security vendors, neither of which were 0-day attacks. This week analysis was posted on a “new” anti-virtual-keyboard technique used by a password stealing trojan; only problem is that technique is at least 3 years old. And this week an IE 7 0-day vulnerability turned out to be more than 5 months old.

Of course the irony is that other researchers have to chase the claims, which reduces the amount of time available for fact checking prior to release for the issues they’re trying to report on; so it’s a vicious cycle. Additionally, people who report on such issues are often excited and anxious to spread the news, not to mention the competitive aspect of all of this.

Generally speaking, the largest organizations tend to lean towards lengthy validation cycles, taking a long time to react, while smaller shops may only do a quick check to validate their claims.

Personally I think either extreme is not good and a balance needs to be found. Part of that balance should include going with what you know at the time, allowing for terms like ‘under investigation’ or ‘believed to be’, while reserving absolute statements until after due diligence has been given.

Maybe that’s just me?

Patch Tuesday refers to the second Tuesday of each month when Microsoft releases security updates for its products. As a matter of policy, Microsoft releases patches only on Patch Tuesday. (One recent exception to this was an out-of-cycle patch for the Internet Explorer VML vulnerability.)

The researchers at McAfee Avert Labs follow Patch Tuesday with interest: Microsoft’s products are used by the lion’s share of industry and home users, and un-patched vulnerabilities in Microsoft’s products can often have an impact on global security.

Back in July 2006, Patch Tuesday fell on July 11. On July 12, a Trojan, Exploit-PPT.b, was released. This Trojan exploited a previously-unknown Microsoft PowerPoint vulnerability.

An exploit for a new vulnerability follows a Patch Tuesday. A one-time event?

This month, on 12 October 2006-two days after the October Patch Tuesday-we discovered a zero-day exploit in the wild for a new Microsoft PowerPoint 2003 vulnerability, CVE-2006-5296. Microsoft has said on its TechNet blog that this exploit could carry out code execution on the victim’s machine.

Security expert Bruce Schneier has commented that exploits might be released to follow a Patch Tuesday to maximize the “window of exposure”-the time until next month’s Patch Tuesday arrives with security patches for the new vulnerability.

Is Zero-Day Wednesday (or Thursday) going to become a trend? We’ll be watching.

Today Microsoft patched 26 vulnerabilities, a record high since their monthly patch cycle started. Among the patched vulnerabilities are the 0-Day vulnerabilities in Word and PowerPoint that have been used in targeted attacks against large enterprises. The vulnerability in the WebViewFolderIcon ActiveX object that allows for Internet Explorer drive-by-install and drive-by-download attacks, has been patched as well. None of today's patched vulnerabilities has been tagged as a worm candidate.

The anticipated remediation of the vulnerability in the DirectAnimation.PathControl ActiveX object in Internet Explorer did not see the light yet.

The update of our graphs of last month is found below. The graphs show that Microsoft has continued the trend of patching a large number of critical vulnerabilities each month.

To follow up on my Another Day, Another 0-day post; today (Sep 27, 2006), Microsoft has released a security advisory for this vulnerability:

Microsoft Security Advisory (925984)
Vulnerability in PowerPoint Could Allow Remote Code Execution

The following versions of PowerPoint are affected:

• PowerPoint 2000
• PowerPoint 2002
• PowerPoint 2003
• PowerPoint 2004 for Mac
• PowerPoint v. X for Mac

CVE-2006-4694 was assigned for this vulnerability on Sep 11, 2006.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4694

As one zero day gets patched, (Microsoft released an out-of-cycle patch for the recent VML Fill vulnerability) another is found.

Today we discovered an exploit affecting Microsoft PowerPoint (preliminary testing shows Office 2000, Office XP, and Office 2003 are affected). A single target of this exploit has been identified, so like other recent Microsoft Office 0-day discoveries, it appears that this one is also a targeted attack.

What makes this attack interesting, is the fact that it appears that Microsoft’s antivirus product added detection three days ago. The only public information on these threats is the boiler plate Malicious Software Encyclopedia entries (which show an incorrect discovery date of Sep 26, when virus definition files from Sep 23 detect):

• Exploit:Win32/Controlppt.W
• Exploit:Win32/Controlppt.X

There isn’t a public advisory from Microsoft; suggesting the Microsoft’s security team knew of this in-the-wild attack but did not make the information public.

For the record, I am not a fan of full disclosure (the concept, not explicitly the mailing list). I believe that more money has been lost, more data stolen, and more illegal activity around exploits has happened because of full disclosure. Historically, those with the skills to find vulnerabilities and create exploits are not the ones who write Blaster and Sasser, etc. Generally, the people who heavily abuse exploit code have “copy & pasted” the work of others. They customize the payload and release, and in these cases damages would have been significantly reduced if it were not for the availability of exploit details.

That said, if an attack is in the wild, acknowledgment of the attack is not something to conceal. Non-disclose the nitty-gritty details, but do inform.

- Update Sep 27, 2006 9:30 -
Correction, coverage went into the 4861 DAT release.

- Update Sep 26, 2006 17:00 -
McAfee antivirus coverage for these two exploits was released earlier today in DAT version 4860; detected as Exploit-PPT.d trojan.

Today was launched the ZERT - ZeroDay Emergency Response Team . The goal of this group of security professionals is to study 0day exploits and develop unofficial patches when those exploits pose a security risk to the internet or users in general and a vendor-supplied patch has not been released yet.

This is an interesting approach, since we have recently seen so many critical security vulnerabilities and exploits without patches. Remeber the Windows WMF vulnerability?

On the other hand, despite of the fact that the ZERT group may perform extensive testing, it is ALWAYS advisable to perform your own tests in your own environment, if you plan to apply them, since it may break applications or conflict with a software/hardware vendor guarantee.

Anyway, it is nice to see efforts like this.

Thousands of websites are compromised everyday. Many end up defaced or vandalized with greetz to the hacker and flames to the system administrator for failing to maintain server security. Defacing is the lowest form of internet graffiti and is usually done for fun or attention.

More sinister is when organized crime groups use compromised web servers to host malware. The compromised web pages are modified to host zero-day exploits which compromise users via drive by downloads or can be used as staging servers for trojan downloaders to pull and push further malware. Attack script toolkits like WebAttacker are being sold on the internet and are then custom configured to infect visiting computers without any user interaction. An attacker only needs to send spam via email addresses or instant messenger messages inviting recipients to visit a compromised website hosting the vulnerability and its malware exploit.

So how does one know where the attacks will come from? What can be done to track down the bad guys and combat them? One, of many ways, is to scan the internet for vulnerable systems and then monitor the sites that are found to be vulnerable, waiting for them to be hacked. Once the site is compromised, don’t attempt to get the compromised server shutdown as that would only make the bad guys move elsewhere. Rather keep an eye on the server and monitor it for any malicious uploads and downloads.

To quote a recent example, when code for the Exploit-WMF was released, a security company was able to come up with a listing of over a hundred sites that were compromised and hosting this exploit, much faster than big search engines indexed the Internet. Critics may argue that this is akin to watching the enemy plant landmines and waiting for hapless victims to step on it because one happens to be in the business of manufacturing prosthetic limbs. The more intel that can be gathered, the better chance the security community has of shutting down the bad guys. Let us all work with the law enforcement and intel communities.

The internet is a scary place as crime increasingly becomes an omnipresent menace. The window between vulnerability discovery to its incorporation into exploit code has shrunk from months or weeks to true zero-day as attackers and security experts are perpetually in a race against time. Browser vulnerabilities and exploits such as the Exploit-VMLFill are just a prelude to a series of pending exploits that pose the fastest growing threats to internet surfing. At the time of writing, a security update to address this vulnerability is being worked upon by Microsoft and their goal is to release the update on Tuesday, October 10, 2006, or sooner.

With ever increasing browser-based attacks, it is more important than ever that users not trust seemingly familiar or safe links particularly when received via Instant Messengers, Internet Relay Chat or Email. McAfee Avert Labs is committed to continued research against all known exploits of the Vector Markup Language vulnerability and will continue to update our coverage as new attack vectors and threats emerge. The problem will not go away…. but we can sure make life difficult for the bad guys.

Overview

Encrypting File System (EFS) [1], is integrated in Microsoft’s Windows platform since Windows 2000. Additionally, Windows XP Professional, Windows 2003 Server and Windows 2005 Media Center operating systems also support it. EFS uses public key cryptography that makes use of a user’s account login and password pair to encrypt a private key. The private key is used to encrypt the original data (files or folders). Encrypting any files or folders, in the supported operating systems, is a trivial task and can be done in many ways. For example as shown in the image below calc.exe can be encrypted just by clicking on “advanced” and then checking “Encrypt contents to secure data”.

Programmatically this can be achieved using calling various APIs that support file encryption like CreateFile with FILE_ATTRIBUTE_ENCRYPTED flag or EncryptFile function. Microsoft’s commandline utility Cipher.exe can also be used for encrypting directories and their contents. The result of such encryption is that only authorized user can view these files. Many businesses or home users frequently use it to encrypt the confidential data that needs to be protected from hackers, uploader trojans or somebody gaining physical access to machine.

Concerns

Recently a trojan was seen to take advantage of EFS to protect itself and execute with administrative privileges. This malware is composed of obfuscated DLL and PE files that are thoughtfully crafted. It has two main components, a dialer component that is detected as Qdial-45 the other is a downloader/dropper component detected as Spy-Agent.bf that drops this dialer along with an EFS encrypted downloader file. McAfee has been detecting variants of this trojan since August 02, 2006, however we have observed an upsurge in infection rates in last few weeks.

The trojan creates an administrator login account with a random name and random password. Using this login key pair it then encrypts the downloader component that it drops. It then creates a random service that points to the encrypted file with logon properties of the newly created login and password. This service can be arbitrarily started. The encrypted file is executed with the logon credentials that the trojan created, to download the updated variants of spy-agent.bf. Some variants of this trojan also drops a Browser Helper Object, a DLL file in alternate data streams. The DLL file is obfuscated as well and tries to download updated copies of Spy-Agent.bf trojan.

It has been observed to contact the following IPs and domains for updates and DNS queries.

• shiptrop.com
• 195.225.176.85
• 195.225.177.22
• esthost.com
• wscooler.com

The downloader component of the trojan uses steganographic techniques to hide the downloaded packets from network sniffers. From its download servers it downloads a packed file with a “gif” header. It decrypts this fake gif file in memory and creates a random named executable in “C:Documets and Settings\%LocalUser%My Documents” folder and launches it. The origins of these trojans appear to be the domain names “Gromozon.com”, “xearl.com”, and “micotad.com”. Most of them resolves to IP addresses in range 195.225.176.* - 195.225.177.*. It is advisable not to visit these web sites as they may still contain various browser exploits. We have always seen a tendency toward copycat malware. More malware may adopt similar techniques of self preservation using EFS. It is useful to understand what proactive steps can be taken to prevent such an attack.

Prevention

1. As a best practice disable download of unsigned ActiveX controls in the browser and always update Windows and McAfee products for latest signatures and updates.

2. VirusScan Access Protection rules.

• Block Access to Cipher.exe so that it cannot be used to encrypt arbitrary files and folders.
• Prevent Creation of NTFS stream in windows and its subdirectories by adding following rule to prevent file creation.
  • “%windir%**:*”

3. If EFS is not needed it can be disabled by following registry modifications.

• Navigate to the key HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionEFS
• On the right pane, right click to select New, and then click DWORD Value.
• Enter EfsConfiguration for the value name and 1 for the value data to disable EFS.
• Restart the system.
• Any attempt to encrypt the file at this stage will result in the following message. “An error occurred applying attributes to the file: filename. The directory has been disabled for encryption.”

4. EFS can also be disabled by adding a desktop.ini file, with the following lines, in the folder that needs to be protected from adding encrypted files.

[Encryption]
Disable=1;

5. Programmatically EFS can also be disabled using API EncryptionDisable(DirPath, BOOL) [2].

References

[1] Encrypting File Systems in Windows XP and Windows Server 2003

[2] Disabling EFS for a Specific Folder

Yesterday McAfee Avert Labs updated the W32/Mofei.worm entry. This threat has recently been seen in the wild being dropped by Microsoft Office documents that used a 0-day exploit to compromise the victim’s computer.

To respond to some questions I received in Paris, I took a look at this sample.

The dropper is a malformed Microsoft Word document exploiting an undocumented and previously unknown vulnerability in Microsoft Word. The file I used for my tests is a Japanese 3 page Word document. It is approximately 79,265 bytes in size. Via the properties windows, we can see 2 five-uppercase-letters names as author and company names. Names started with the letter K. According to the statistics folder it was created on September 1st.

After I opened this document (Office 2000 on a Windows 2000 machine), 2 files were silently installed in my %windir%system32 directory:

• clipbook.dll (30,720 bytes)
• clipbook.exe (33,713 bytes)

A word document was also created in the %windir% directory (28,160 bytes). It is a “clean” copy of the malformed one.

The files in the system32 directory are related to an old network share propagation worm previously named W32/Mofei.worm. It attempts to spread by copying itself to the ADMIN$ share of remote machines. It scans IP addresses, tries to gain access to the share by trying weak administrator username and passwords. It creates temp and/or log files in the system32 directory. On my system I noticed a file named clipbook.dat.

The Microsoft Word dropper is now detected as W32/Mofei.worm.dr.
Exe and dll files are now detected as W32/Mofei.worm with DAT-4844. With older signature files, clipbook.exe is detected as “Trojan or variant New Malware.n” (since DAT version 4677).

Last night Sunbelt blogged about a zero day IE exploit being discovered in the wild. This attack has taken shape much the way Exploit-WMF did back in December 2005. A trojan toolkit known as WebAttacker was updated to include exploiting a new Vector Markup Language Buffer Overflow vulnerability. This toolkit is known to be sold on the underground for as little as $17 US, but just like the Exploit-WMF case, we can expect exploit source to be readily available shortly.

General advice around this kind of attack is to stay on the straight and narrow path while touring the Internet. However, WebAttacker has historically been installed on compromised web servers, and we’ve seen message board posts and blog entries that include iframes to refer to other sites that are running WebAttacker. Disabling JavaSript effectively neuters known attacks. Using an alternate web browser also thwarts this attack.

Microsoft has posted an advisory including workarounds:
http://www.microsoft.com/technet/security/advisory/925568.mspx

McAfee product coverage (including proactive 0-day protection) can be found here:
Exploit information: http://vil.nai.com/vil/Content/v_140629.htm
Vulnerability information: http://vil.nai.com/vil/Content/v_vul26881.htm

P.S. As I write this entry, Exploit-WMF remains as the top most reported malware blocked by our VirusScan Online products.

An epic transformation in the world of security is upon us. Today, we released the first issue of our semi-annual security magazine Sage. We will leverage this communication vehicle to deliver meaningful and sometime raw content to the masses. We take our responsibility to protect the public from malicious malcontents very seriously and will not shy away from difficult content or taboo topics. Instead, we will share with the world our day-to-day fight and let you decide how important the concepts being broached are to you.

The premiere issue examines the use of open source by the malware writing community. We show the pivotal role that code sharing and full disclosure have played in the evolution of the threat environment, and we anticipate a surge in malware quality and reliability as the malware writers become more professional. Though open source cannot be blamed for how some unsavory individuals may choose to use its tools, techniques, and methodologies, the movement should acknowledge that there are dangers associated with some of its fundamental beliefs.

Sage is meant to be a forum for thought leadership and serious discourse on topical security issues. By drawing on the Labs wealth of data and expertise, and writing challenging security articles, we hope to provoke important discussion about the digital battlefield we have found ourselves in.

Get Sage now from the McAfee Threat Center site:

http://www.mcafee.com/us/threat_center/white_paper.html

Last week, Microsoft announced that it had received a single report for a new 0-day vulnerability involving Excel. A malicious spreadsheet was attached to an e-mail and sent to a targeted victim. Various information is available from Microsoft and an interesting FAQ is also available on the Securiteam blog:
http://blogs.technet.com/msrc/archive/2006/06/16/436174.aspx
http://www.microsoft.com/technet/security/advisory/921365.mspx
http://blogs.securiteam.com/?p=451

Today, this threat has been deemed Low-Profiled due to media attention. FrSIRT has also posted an announcement at http://www.frsirt.com/english/advisories/2006/2361.

According to various reports, the original file is named okN.xls. Supposedly when a user opens the file the software unexpectly closes and some binary files are dropped in the Windows System directory as well as the system root directory.

I have studied a sample. It had a 127,488 byte size. On my French system, the file had a long name with semi-graphical ASCII characters possibly of Asian origin. After I renamed the file and opened it on an English Microsoft Excel 2000 version running on a Windows 2000 environment, the expected exploit did not occur. The filename visible on the left and high corner of the window indicated to me that the file was partially loaded, but no spreadsheet was visible. When I attempted to close Excel, I received an application error message saying some memory address could not be read. I made another test on a Windows XP-PRO (French) environment and with Excel 2002. This time an error message appeared and the file could not be loaded.

My colleagues also tested the file in a Japanese environment with the same disappointing results. We suspect that the exploit is more specifically crafted for Excel 2003 running on a specific OS version. It perhaps uses hardcoded return EIP offsets.

Despite these problems, the XLS file and its embedded downloader are detected as downloader-AWV.dr and downloader-AWV.

A zero day Yahoo! Mail vulnerability was exploited today that results in the execution of arbitrary code.  The vulnerability lies within Yahoo's onload event handling, allowing an attacker to craft an email message that results in script execution when users read their Yahoo! Mail.  In today's attack, a virus author utilized this exploit to run JavaScript that spams @yahoo.com and @yahoogroups.com recipients with a new virus (JS/Yamanner@MM - http://vil.mcafeesecurity.com/vil/content/v_139913.htm).  Yahoo is reportedly working on a fix and blocking these messages.

A new 0-day working exploit code for an unpatched vulnerability in Oracle Export Extensions was posted to Bugtraq last week. US-CERT announces that successful exploitation may allow a remote attacker with some authentication credentials to execute arbitrary SQL statements with elevated privileges. This may allow an attacker to access and modify sensitive information within an Oracle database.

Rare in 2003/2004, 0-day attacks seem to be more and more common. This term applies to distribution of an exploit linked to a vulnerability which has not yet been corrected. In this case, the period between the appearance of the exploit and that of the corrective patch is null or negative : null if the exploit and the patch arrive on the same day, negative if the patch arrives several days after the exploit.

More information about this new vulnerability can be found here:
CERT-US : Public Exploit Code for Unpatched Vulnerability in Oracle
Secunia Advisory: SA19860

On May 2nd, we are not aware of any vendor-supplied patches for this issue.