Some of my colleagues from Symantec and I attended Black Hat in Las Vegas this past week. Wednesday was the first day of talks and there were some very interesting topics discussed. For me, the highlights were the following talks:
• “Stoned Boot Kit,” by Peter Kleissner
• “Using Guided Missiles in Drive-Bys: Automatic browser fingerprinting and exploitation with Metasploit,” by Egypt
• “Attacking Interoperability,” by Mark Dowd, Ryan Smith, and David Dewey
The papers for these presentations are available on the Black Hat website, but I did manage to talk to most of the presenters and get their views on various topics. In this post I’ll talk about the “Using Guided Missiles in Drive-Bys” and follow up with info on the other talks in later posts.
In his presentation “Using Guided Missiles in Drive-Bys,” James Lee (a.k.a. “...
In part one of this blog, I gave an overview of the exploitation flow for the recent DirectShow vulnerability. With no patch for this vulnerability available as of yet, the fact that we are seeing this exploit used more commonly in the wild is worrying. In this article I will discuss the exploit, how it works, and mitigation strategies to protect against it.
To get straight to the mitigation strategies jump to the bottom of the page. This vulnerability does not exist in Vista or Windows Server 2008.
The Vulnerability
To trigger this vulnerability, attackers are currently enticing users to visit a malicious page. Attackers have become quite adept at doing this by embedding iframe tags in legitimate pages, among other techniques. This is the most likely attack vector. We have seen iframe tags pointing to this exploit inside phishing pages already and we do expect to see iframe tags added...
In this article I will outline the stages involved in the full exploitation of the recent DirectShow vulnerability. In particular I will discuss a specific example of how this exploit was used in the wild. The recent DirectShow vulnerability was interesting for a number of reasons and to explore each of those reasons in detail I will first give an overview of the entire exploitation flow, and then explore individual portions in more detail.
Some of the first pages to use this exploit for this vulnerability in the wild were linked from phishing pages. The phishing pages in question not only attempted to steal the visitors’ login credentials, but also silently redirected users to a malicious Web page hosting an exploit for the DirectShow vulnerability (CVE-2009-1537). This malicious Web page loads a corrupt .avi file that exploits the vulnerability and also loads some additional...
We have recently received a new Web exploit pack called Tornado that contains exploits for 14 vulnerabilities by default. The pack also contains the usual stats and admin pages; however, the greatest success of this pack appears to be how well it has stayed under the radar.
Firstly, let’s take a look at what is in the pack. When a user logs into the Tornado administration control panel, the statistics page is shown, as presented below. This page shows how successful an exploit campaign has been to date. It shows the number of visitors to the exploit pack and how many of those visitors were successfully exploited, which includes a breakdown by OS and by browser type.
The Mpack and IcePack exploit packages havebeen on sale for some time. Now, free releases of these tools are beingdistributed, but are these free distributions all they are supposed tobe? While examining these free releases we discovered some surprises.
The Mpack and IcePack exploit packages are designed fornon-technical users. They group exploits together into one easy toinstall package and using this package, non-technical users can runexploits on the browsers of unsuspecting visitors. Ultimately thisgrants non-technical attackers the ability to infect visitors to theirsites without having to know how exactly it happens.
When these packs were first released they sold in the undergroundfor over $1,000 apiece. The packs are installed with minimumconfiguration and effort and all that the controller needs to do isattract users to the exploit site. When one of these exploit sites isopened in a visitor's browser, the exploits...
There have been lot of rumours and discussions about the recent Adobe Flash Player Remote Code Execution vulnerability.The most interesting thing is that it is a cross-platformvulnerability. Due to the fact that Flash can run in different browsersand on many different platforms, the discovery of this onevulnerability could leave all those operating systems and devices thatare Flash-enabled open (e.g., including some advanced smartphones) tothe attack.
The vulnerability has already been tested on Windows, Apple Mac, andsome Linux distributions, but many other devices that are Flash-enabledcould be affected by the problem too. For example, we verified that theNintendo Wii gaming console is also affected. Wii has an Internetchannel that runs a special version of the Opera browser with Flash,and yes… we verified that it is affected by the problem too! The Wiiconsole completely hangs while...
No, I’m not talking about typing 53704 intoyour calculator and turning it upside down! I’m referring to theincreasing popularity of inserting links to exploits into legitimateHTML pages in an attempt to infect users who visit the affected page,multiplying the effectiveness of the original infection. I’ll outlinebelow the steps used in one such attack that we recently received inour lab.
In this case the malicious links were added by hand after the Web server had been hacked. However, W32.Fujacks and W32.Fubalcause similar techniques to the ones discussed here to automaticallyinfect asp, aspx, htm, html, php and jsp files residing on the infectedmachine in order to spread themselves further. Infostealer.Lingling wasalso...
Mirror, mirror on the wall, who is the lamest of them all? Theattacker behind this scheme hopes to find out where all the l4m3rs are(his words not mine). In a classic social engineering attack, customershave been reporting that they have received an unusual piece of spamrecently.
The mail is supposedly from a hosting or collocation company and says something along the lines of this:
Dear COMPANYNAME Inc. Valued Members,
Regarding our new security regulations, as a part of our yearlymaintenance we have provided a security guard script in the attachment.
So, to secure your Web sites, please use the attached file and (forUNIX/Linux Based servers) upload the file "guard.php" in:"./public_html" or (for Windows Based servers which use ASP) upload the file "guard.asp" in: "./wwwroot" in your site. [instructionsincluded] Thank you for using our services and products. We look forward to providing you with a unique and high quality...
I recently posted a blog that refers to fuzzing techniques—inparticular I spoke about finding file format vulnerabilities usingthese fuzzing techniques. Therefore, it was with no great surprise thatI greeted the announcement of the discovery of nine different fileformat vulnerabilities affecting the Apple QuickTime application.However, what did surprise me was the number of separate file formatsthat were found to be vulnerable.
In this particularannouncement the commonly known .jpg, .bmp, .avi, and .pict fileformats were found to be vulnerable, along with several other formatsthat were disclosed. Given the number of issues discovered, there is nodoubt in my mind that these were all found using file fuzzingtechniques. For a full listing of the issues that Apple has resolvedwith a patched version of QuickTime, please refer to the...
History repeats itself. Well, that’s how the saying goes anyway. To see the future we should look to the past. So what have we seen in the recent past? The whole .wmf debacle at the end of 2005 certainly stands out. Have any lessons been learned from that? I think not, but I guess we will have to wait and see. Of course, the lessons should have been learned a long time before the .wmf exploits were ever circulated.
Why? Well, the .wmf vulnerabilities were more than likely found using some simple file format fuzzing techniques. These vulnerabilities were not the first that could have been found using file fuzzing. Indeed, we have also seen some other prominent examples of bugs in image formats that were probably found using this same technique. For example, we had the .png vulnerability in early 2005. We witnessed the icon vulnerability, also in 2005. What about the .jpeg/GDI vulnerability in 2004? All of these critical vulnerabilities could have been...
