Admin Misconfigurations
| | ||
This section will cover vulnerabilities that web administrators are typically responsible for introducing through lack of awareness or carelessness. Fortunately, they can do something about it directly. We'll cover the following classes of common configuration vulnerabilities:
-
Unnecessary web server extensions
-
Information leakage
Unnecessary Web Server Extensions
Some of the worst web platform attacks in recent memory 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, which gave rise to the Slapper worm. We demonstrated 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 criticaland commonvulnerabilities 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 they are installed by default by the software provider!), and thus will be covered here. The two examples we'll give include basic web extension modules (such as the HTR chunked encoding issue) and WebDAV.
IIS HTR Chunked Encoding Heap Overflow
| Popularity: | 9 |
| Simplicity: | 7 |
| Impact: | 9 |
| Risk Rating: | 8 |
Attack We'll delve back a bit in history to provide a good example of what can happen if such extensions are left open to prying eyes: the Microsoft IIS HTR Chunked Encoding Heap Overflow.
In June 2002, eEye Digital Security announced discovery of a buffer overflow within the IIS web server extension that handles .htr files. Microsoft uses Dynamic Link Libraries (DLLs) to extend its web server, and the particular extension at fault in this case was located in %systemroot%\System32\ism.dll. HTR was Microsoft's first attempt at a scripting architecture, and it was long ago replaced by ASP. However, for some unfathomable reason, HTR functionality has shipped with IIS to this day (although it is disabled by default in IIS 6).
The vulnerability arises from the way the HTR extension handles chunked encoding . About the same time the HTR heap overflow was discovered, a number of chunked encoding vulnerabilities was discovered in web servers from many vendors . Chunked encoding is an option defined by the HTTP specification for the client to negotiate the size of " chunks " of data that it will send to the server. The HTR DLL had a programming flaw that caused it to undercalculate the amount of buffer necessary to hold the chunk specified by the client, allowing a malicious request to be formulated to overflow the buffer and load exploit code onto the heap (not the stack).
Here's what a proof-of-concept HTTP request exploit looks like:
POST /file.htr HTTP/1.1 Host: victim.com Transfer-Encoding: chunked 20 XXXXXXXXXXXXXXXXXXXXXXXXBUFFER00 0 [enter] [enter]
The key things to note here include the request for an .htr file. Note that the file does not have to exist; this just serves to route the request to the vulnerable HTR extension. Of course, you must also specify the chunked encoding option in the HTTP header, and finally you must send the appropriate buffer. This is a fairly classic IIS buffer overflow exploitation: Target the appropriate DLL, ensure that any additional HTTP headers are included (often, the Host: header is necessary, as we see here), and then target a large buffer of data to overrun the code.
And, as with many such vulnerabilities, published exploit code soon abounded on the Internet. Most such proof-of-concept exploits involved sending a specially crafted buffer that throws back a command shell to the attacker's system. All the attacker has to do is set up a listener on his own system to "catch" the command shell returned from the victim server on a pre-defined port. In the following example, we illustrate the use of the netcat tool to "catch" a shell from an incoming vulnerable server on port 4003:
C:\> nc -l -vv -p 4003 listening on [any] 4003 ... connect to [192.168.234.34] from MIRAGE [192.168.234.119] 3056 Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\WINNT\system32> C:\WINNT\system32> whoami whoami MIRAGE\IWAM_MIRAGE
The command prompt you see here is a remote control session on the victim machine, 192.168.234.119 (hostname MIRAGE). We have executed the Windows Server Resource Kit utility whoami to show that the shell is running in the context of the lower-privilege Windows IWAM account, as would be expected on a default IIS 5 machine. If this had been an IIS 4 machine, we could've been running as the ultra -privileged LocalSystem account, since HTR runs in a more privileged process by default in that version.
Web Server Extension Countermeasures
Countermeasure We hope that 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. 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 it's this important to disable extensions, and they've found a way to do it without hurting their multi-billion 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:
-
Open the IIS administration tool (runiis.msc).
-
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.
-
At this final screen, remove the mapping for the desired extensions. Figure 9-2 shows the .printer mapping to msw3prt.dll selected.
Figure 9-2: Removing the extension mapping for the .printer extension in the IIS 5 Admin tool (iis.msc)
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. |
Information Leakage
The next class of common configuration problems we'll discuss is quite broad. It's a set of problems that can reveal information that was not intended by the application owners , and that is commonly leveraged by attackers towards more efficient exploitation of a web app. These problems aren't rooted in any specific web server extension or add-on module, but rather result from many different configuration parameters, and so we've grouped them here for individual treatment. The specific vulnerabilities we'll discuss in this section include these:
-
File, path , and user disclosure
-
Status page information leakage
File, Path, and User Disclosure
| Popularity: | 9 |
| Simplicity: | 2 |
| Impact: | 5 |
| Risk Rating: | 6 |
Attack One of the most common causes of information-leakage from web sitesbecause of poor housekeepingis 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 pristinethe 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 of very useful information for attackers. There are several methods you can use 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 can contain all kinds of juicy information, in comments (search for "<!--" tags), include files (look for .inc file extensions), and so on. Since the source code is primarily the domain of web developers, we'll discuss some key examples in the upcoming section "Developer-driven Mistakes."
Directory Guessing The first method is the simplestguessing 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 themselves 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 9-3.
| Code | Meaning |
|---|---|
| HTTP/1.1 200 OK | This indicates, on most web servers, that the directory exists and it returned its default page. |
| HTTP/1.1 403 OK | A 403 Forbidden means that the directory exists but you are not allowed to view the contents, not that you do not have access to the contents of the directory. Remember that; it is important. |
| HTTP/1.1 401 OK | A 401 response indicates that the directory is protected by authentication. This is good news for you to take note of because it means the contents of the directory are important enough to secure. |
| HTTP/1.1 302 OK | A 302 response is a redirection to another web page. And depending on the configuration of the web server, more often than not the 302 response indicates success, while in other instances, you're just redirected to an error page. |
| HTTP/1.1 404 Object Not Found | A 404 means that the page does not exist on the server. |
| Note | Links to information about HTTP status codes can be found in the "References and 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 DeniedThis 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. This means that 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 about web statistics? Doing further research we enter the search query inurl:/stats/ +"index of" into Google to identify common files other sites tucked away into 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 are returned 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 seen in Figure 9-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.
Figure 9-3: A web statistics page revealed in a directory-guessing attack
Common Filenames Guessing As we mentioned earlier, web site admins are notorious for leaving filesold code, outdated files, and other stuff that just shouldn't be therelying around the web root. You want to use this laziness to your advantage. Most don't realize that these files can be downloaded just as any other files on the web site. All an attacker needs to know is where they're 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.
| Note | We'll discuss the special case of include (.inc) files on IIS in the upcoming section entitled "Developer-driven Mistakes." |
For example, many developers use a popular source code control system named CVS (Concurrent Versions System). This software allows developers to easily manage multiple people collaborating on the same software. CVS will ferret through the entire folder structure where source code is kept and add its own /CVS/ subfolder. This subfolder contains three filesEntries, Repository, and Rootthat 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 will take the entire / WebProject/ directory and upload 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 9-4.
Figure 9-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 9-4 shows common files that attackers look for when reviewing a site. Remember that attackers will leave no folder or subfolder un-turned in their search!
| Tip | For many of the filenames listed in Table 9-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. |
| Filename | Description |
|---|---|
| /etc/passwd | UNIX/Linux password file. |
| /winnt/repair/sam._ | Windows backup SAM database. |
| web.config | An ASP.NET configuration file, may contain passwords. |
| Global.asa | An IIS database configuration file. |
| /W3SVCx/ | Common naming convention for virtual web root directories. |
| /stats/ | Site statistics directory, usually hidden. |
| /etc/apache/httpd.conf | Apache configuration file. |
| /usr/local/apache/conf/httpd.conf | |
| /home/httpd/conf/httpd.conf | |
| /opt/apache/conf/httpd.conf | |
| htaccess | Apache password file. |
| /usr/netscape/suitespot/ https -server/config/magnus.conf | iPlanet (Netscape) configuration. |
| /opt/netscape/suitespot/https-server/config/magnus.conf | |
| etc/apache/jserv/jserv.conf | Apache JServ configuration. |
| /usr/local/apache/conf/jserv/jserv.conf | |
| /home/httpd/conf/jserv/jserv.conf | |
| /opt/apache/conf/jserv/jserv.conf | |
| core | Core dump. Core dumps, if you look carefully , can reveal very insightful information. You'll find these often. |
| WS_FTP.LOG | In certain versions of WS_FTP, this file is left in the upload directory. These will reveal every file uploaded and its location. |
| <name of site>.zip | Many sites have a compressed copy of everything sitting in the root folder of the site. So requesting www.site.com.tar.gz may just give you everything in one swoop. |
| README, Install, ToDO, Configure | Everyone leaves application documentation lying around. Find the README file and discover what applications are being used and where to access them. |
| Test.asp, testing.html, Debug.cgi | With test scripts, which are very common, you just never know what you'll learn from their contents once you find them. It may be a page of junk or detail about how to run administrative tasks . |
| Logs.txt, access_log, debug.log, sqlnet.log, ora_errs.log | Log files are always left around. If the web server is running Oracle, eight times out of ten you'll find sqlnet.log somewhere. |
| Admin.htm, users.asp, menu.cgi | If you find an administrative directory but no files, try guessing. Look for files that are associated with administrative functions. |
| *.inc | Include files are often downloadable on IIS due to misconfigurations. |
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, they 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 diligences and tested their new application for security vulnerabilities and declared them 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 older web site version here. Our hacker surfs to http://web.archive.org (Wayback Machine) which is a web site that maintains completely browse-able archives of web sites, shown in Figure 9-5.
Figure 9-5: The Wayback Machine
The attacker now enters the site's web address, browses throughout 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 listed the contents of articles: http://www.site.com/article.asp?id=121879.
Armed with this information, the hacker 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 it still pulled data from the company's database. Our hacker smiles as he discovers the old application is vulnerable to SQL injection and as a result, 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 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 it quite useful for you to identify, for instance, that an Oracle user exists on the system, 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 8. |
File Disclosure Countermeasures
Countermeasure It's easy to remedy this security problem: 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 make sure you check rigorously.
-
Deploy your web root on a separate volume. This is particularly important on IIS systems, as there has been a history of exploits that break out of web root, often into %systemroot% to run juicy files such 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 a hacker 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
| Popularity: | 5 |
| Simplicity: | 1 |
| Impact: | 3 |
| Risk Rating: | 5 |
Attack 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 there are plenty of deployments that still enable this feature. Finding the status pages 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
-
http://www.site.com/status
Shown here is an example of a server status page that might get turned up with one of these requests:
| Apache Server Status for www.apche.org Server Version Apache/2.0.54 (Unix) mode_ssl/2.0.54 Openssl/0.9.7a DAV/2 SVN/1.2.0-dec
Current Time: Wednesday, 21-Sep-2005 20:52:23 CEST Restart Time: Thursday, 25-Aug-2005 17:56:30 CEST Parent Server Generation: 27 Server uptime: 27 day 2 hours 55 minutes 53 seconds Total accesses : 106433456 - Total Traddic: 3963.8 GB CPU Usage: u480.996 s276.233 cu1438.56 cs0 - .0937% CPU load 45.4 requests/sec - 1.7 MB/second = 39.1 kB/request 180 requests curentiy being processed , 175 idle workerd |
Status Page Information Leakage Countermeasure
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>
| | ||
EAN: 2147483647
Pages: 127