Directory Traversal Attacks
When it comes to security, Web sites unfortunately take the back seat.
Sure, their handiness has made Web applications ever more popular with users. But their status as a channel between a company’s databases and external users also leaves them particularly susceptible to security threats from hackers.
There are many ways a site can be vulnerable: cross-site scripting, Structured Query Language injection and directory traversal. Of the three, the least talked about is the directory traversal attack. Possible targets include files that contain passwords, private keys for Secure Sockets Layer certificates and even Web server logs.
What Is a Directory Traversal Attack?
In a directory traversal attack, hackers exploit a vulnerability in a Web server’s HyperText Transfer Protocol by accessing restricted directories and then executing commands outside of the Web server’s root directory.
A typical Web server offers two means of providing security against such threats: access control lists (ACLs) and the root directory. The root directory is a precise directory on the server file system that does not allow ordinary users to access specified sensitive files on the server, namely the command file on a Windows platform and the /etc/passwd file on Unix and Linux platforms.
The Web administrator adds users and groups to the ACL depending on their access needs, with authorized users able to access, modify and execute certain files on the server. The root directory keeps users confined to specific directories on the server file system beyond which they cannot gain access. For example, when the default root directory for the Internet Information Server (IIS) on Windows is c:\inetpub\wwwroot, a user would not have access to c:\windows but would have access to c:\inetpub\wwwroot\news as well as other directories and files under the root directory — as long as the ACL has authenticated that user. When the Web application contains dynamic pages, browser input is generated via “GET” or “POST” requests and a “GET HTTP” request URL for instance, would appear as:
http://justatest.webstuff.com/stuff.asp?view=material.html.
In this example, the browser requests the dynamic page stuff.asp from the server, while it sends the view parameter (with material.html as its value). stuff.asp honors the request, retrieves the material.htm file from the server’s file system and sends it back to the user as a display on the browser. Hackers with Web browsers and an inkling of the location of default files and directories on a system would be able to carry out a directory traversal attack. Using our example, a hacker would likely input the following, based on the assumption that stuff.asp will retrieve system files:
http://justatest.webstuff.com/show.asp?
view=../../../../../Windows/system.ini.
The dynamic page would oblige by retrieving the system.ini file for display to the user. Where “../” appears, the system is being instructed to move up one directory, not an unusual operating system command. With a little trial-and-error effort, a hacker could readily determine how many directories he would need to go up to find the Windows folder on the system.
What Can Attackers Do if Your Site Is Vulnerable?
Vulnerability can exist either in the Web server software itself or in the Web application code.
Imagine you have spent a couple of years building a community of users for your business’ site. From a marketing perspective, this is a living document that helps you tweak your service or launch new products. One day a hacker comes along, puts a database command into your login page and gains entry to your forum — giving him the ability to essentially upload any comment he wants, even delete all your posts.
This is simple Web site defacement. Sadly, more treacherous hackers are not interested in such exploits. Professional hackers target data; they will employ almost any means to get at your data and will sell it for illegal uses such as credit card fraud or cyberterrorism attacks.
How to Check for Vulnerabilities
A Web vulnerability scanner is a good tool for determining weaknesses in your applications and Web sites. A scanner can run through an entire site checking for directory traversal susceptibility (as well as cross-site scripting, SQL injection and other vulnerabilities) and will suggest repairs. Although a vulnerability scanner is helpful, site security still remains the most overlooked aspect of protecting sensitive corporate data. A Web site audit will offer a more thorough examination of a site’s weaknesses.
How to Protect Against a Directory Traversal Attack
Placement of the root directories of your Web server on nonsystem, separate partitions can thwart traversal attacks, as attackers will not be able to access system files and tools. Users cannot traverse drives because most Web servers have configuration options to turn off traversing; select this option rather than keeping the default Web server Web root directories. (Note: Web sites that are Windows-based use the \inetpub\wwwroot as the default directory for Web site content location). For systems installed on the c: drive for instance, moving your site and content directory to drive another would be a better option. As always, maintaining up-to-date security patches for your Web server and applications goes a long way toward keeping attackers at bay, as does validating user input.
By requiring validation, only authorized or “white-listed” user input will be processed. Lastly, if you are using an IIS Web server, you may find it helpful to download and use the IISLockdown, a free tool available at www.microsoft.com/technet/security/tools/locktool.mspx.
