One-way web hacking is a technique which relies purely on HTTP traffic to attack and penetrate web servers and application servers. This technique was formulated to demonstrate that having tight firewalls or SSL does not really matter when it comes to web application attacks. The premise of the one-way technique is that only valid HTTP requests are allowed in and only valid HTTP responses are allowed out of the firewall.
My research on one-way web hacking began as early as April 2000, when I was faced with the need to upload an arbitrary file on a compromised web server which had a restrictive firewall. Since then, many other techniques developed and the collection of all these techniques resulted into the creation of the one-way web hacking methodology.
One-way web hacking has been demonstrated at the Blackhat Briefings in Amsterdam 2001, Las Vegas 2001 and HACK 2002 in Kuala Lumpur.
There are four components in a web application systems, namely the web client which is usually a browser, the front-end web server, the application server and for a vast majority of applications, the database server. The following diagram shows how these components fit together.
The web application server hosts all the application logic, which may be in the form of scripts, objects or compiled binaries. The front-end web server acts as the application interface to the outside world, receiving inputs from the web clients via HTML forms and HTTP, and delivering output generated by the application in the form of HTML pages. Internally, the application interfaces with back-end database servers to carry out transactions.
The firewall is assumed to be a tightly configured firewall, allowing nothing but incoming HTTP requests and outgoing HTML replies.
Consider the example where an attacker finds a vulnerable web application, and is able to exploit it using techniques such as the ones mentioned previously. The attacker has achieved arbitrary command execution, but due to the restrictive firewall, is unable to proceed further into the network. To make an attack effective, two things are essential:
A tight firewall can make it very difficult to achieve the above objectives, however, it is not impossible. To get around these restrictions, with a little bit of web application programming knowledge, we can create a web based command prompt and a file uploader.
The one-way hack begins when we are able to achieve remote command execution on the target web server. We can use any of the common techniques used to attack web servers. We shall present a few examples of various ways of achieving remote command execution based on different types of URL mappings as described previously. A detailed discussion on web server and application vulnerabilities is beyond the scope of this paper.
Our objective is to create a backdoor by moving the shell interpreter (/bin/sh, cmd.exe, etc) to an area within the web server's document root. This way, we can invoke the shell interpreter through a URL. We present three examples which illustrate how to create backdoors using various exploitation techniques.
The diagram below illustrates some of the techniques used to find an entry point:
Our objective of creating a backdoor by moving the command interpreter or the shell into the web document root is to be able to invoke it remotely over HTTP. The HTTP POST method is best suited for this purpose. Using POST, the input data gets passed to the invoked resource over standard input, and the web server returns the output generated by standard output back over the HTTP connection. We shall illustrate how to send commands to command interpreters over POST, with two examples - one for CMD.EXE on IIS and Windows NT and the other for sh.cgi (which is a copy of /bin/sh) on Apache and Linux.
After achieving remote command execution, we need to be able to interactively run commands on the target web server. Common ways of doing this would be to either spawn a shell and bind it to a TCP port on the target web server, or to launch a shell connection back to a TCP listener, or to launch an xterm to a remote X display [2]. However, given a tight firewall which allows only HTTP requests as incoming traffic and HTTP responses as outbound traffic, such techniques will not work. We shall present here examples of "web based command prompts" to get around these restrictions. A web based command prompt provides the functionality of a semi-interactive shell terminal, via an HTML form. The form accepts the command as an field and displays the resultant output as pre-formatted text. The reason why web based command prompts are semi-interactive is because they do not save the state of the terminal, such as the current working directory, system environment, etc. These can be implemented by session based HTML forms, however, that is beyond the scope of this paper. Commands executed by such web based command prompts assume the privileges of the web server process. Typically, for Unix systems running Apache, the uid is "nobody", whereas for Windows systems running IIS, the privileges are those of "IUSR_machinename" or "IWAM_machinename" Given below are four examples of a web based command prompt:
Using remote command execution, we can run commands such as "echo" and redirect the output into a file. Using multiple "echo" commands, we can create a file, one line at a time, on the remote web server. The only pre-requisite here is that we need a writeable directory on the target web server.
In addition to being able to run commands on the target web server, an attacker would also be interested in transferring files into the web server. Usual techniques such as FTP, NFS, NetBIOS, etc. do not work since the firewall would prevent all these. To get around this obstacle, we need to create a file uploader. The technique mentioned in section 4.1.2 can be painfully slow for large files. There is a better option, though. It is possible to upload files using the HTTP POST Multipart-MIME [3] method. The contents of the file get sent to the server in an HTTP POST request. On the server, an upload script receives these contents and saves them into a file. A detailed discussion of HTTP Multipart-MIME POST requests is beyond the scope of this document. To perform file uploads, we would require a directory where the web server process (nobody, IUSR_machinename, IWAM_machinename, etc.) has privileges to create and write to files. Given below are three examples of such upload scripts: