Hacking: The Next Generation

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.

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:[e-mail]?
    body=Mailto protocol handler example.">
Send a mail!
</a>
</body>
</html>

Figure 4-2. Mailto:// link

When the user clicks on the hyperlink, the browser will pass the entire mailto:// link (mailto:[e-mail]?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 [e-mail]?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.

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.

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.

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 mailto://[e-mail] 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.

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.

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.

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