Common Gateway Interfaces
Attacking Tomcat CGI
CVE-2019-0232 is a critical security issue that could result in remote code execution. This vulnerability affects Windows systems that have the enableCmdLineArguments feature enabled.
An attacker can exploit this vulnerability by exploiting a command injection flaw resulting from a Tomcat CGI Servlet input validation error, thus allowing them to execute arbitrary commands on the affected system. Versions 9.0.0.M1 to 9.0.17, 8.5.0 to 8.5.39, and 7.0.0 to 7.0.93 of Tomcat are affected.
The CGI Servlet is a vital component of Apache Tomcat that enables web servers to communicate with external applications beyond the Tomcat JVM. These external applications are typically CGI scripts written in languages like Perl, Python, or Bash. The CGI Servlet receives requests from web browsers and forwards them to CGI scripts for processing.
In essence, a CGI Servlet is a program that runs on a web server, such as Apache2, to support the execution of external applications that conform to the CGI specification. It is a middleware between web servers and external information resources like databases.
CGI scripts are utilised in websites for several reasons, but there are also some pretty big disadvantages to using them:
Advantages
Disadvantages
It is simple and effective for generating dynamic web content.
Incurs overhead by having to load programs into memory for each request.
Use any programming language that can read from standard input and write to standard output.
Cannot easily cache data in memory between page requests.
Can reuse existing code and avoid writing new code.
It reduces the server's performance and consumes a lot of processing time.
The enableCmdLineArguments setting for Apache Tomcat's CGI Servlet controls whether command line arguments are created from the query string. If set to true, the CGI Servlet parses the query string and passes it to the CGI script as arguments. This feature can make CGI scripts more flexible and easier to write by allowing parameters to be passed to the script without using environment variables or standard input. For example, a CGI script can use command line arguments to switch between actions based on user input.
Suppose you have a CGI script that allows users to search for books in a bookstore's catalogue. The script has two possible actions: "search by title" and "search by author."
The CGI script can use command line arguments to switch between these actions. For instance, the script can be called with the following URL:
Here, the action parameter is set to title, indicating that the script should search by book title. The query parameter specifies the search term "the great gatsby."
If the user wants to search by author, they can use a similar URL:
Here, the action parameter is set to author, indicating that the script should search by author name. The query parameter specifies the search term "fitzgerald."
By using command line arguments, the CGI script can easily switch between different search actions based on user input. This makes the script more flexible and easier to use.
However, a problem arises when enableCmdLineArguments is enabled on Windows systems because the CGI Servlet fails to properly validate the input from the web browser before passing it to the CGI script. This can lead to an operating system command injection attack
For instance, an attacker can append dir to a valid command using & as a separator to execute dir on a Windows system. An example of this is http://example.com/cgi-bin/hello.bat?&dir, which passes &dir as an argument to hello.bat and executes dir on the server.
Enumeration
nmap can identify Apache Tomcat, for example Apache Tomcat/9.0.17 running on port 8080.
Finding a CGI script
One way to uncover web server content is by utilising the ffuf web enumeration tool along with the dirb common.txt wordlist. Knowing that the default directory for CGI scripts is /cgi, either through prior knowledge or by researching the vulnerability, we can use the URL http://10.129.204.227:8080/cgi/FUZZ.cmd or http://10.129.204.227:8080/cgi/FUZZ.bat to perform fuzzing.
Fuzzing Extentions - .CMD
Fuzzing Extentions - .BAT
Exploitation
As discussed above, we can exploit CVE-2019-0232 by appending our own commands through the use of the batch command separator &. We now have a valid CGI script path discovered during the enumeration at http://10.129.204.227:8080/cgi/welcome.bat
Navigating to the above URL returns the output for the dir batch command, however trying to run other common windows command line apps, such as whoami doesn't return an output.
Retrieve a list of environmental variables by calling the set command:
From the list, we can see that the PATH variable has been unset, so we will need to hardcode paths in requests:
The attempt was unsuccessful, and Tomcat responded with an error message indicating that an invalid character had been encountered. Apache Tomcat introduced a patch that utilises a regular expression to prevent the use of special characters. However, the filter can be bypassed by URL-encoding the payload.
Another way to exploit
Using metaploit's module:
Attacking Common Gateway Interface (CGI) Applications - Shellshock
A Common Gateway Interface (CGI) is used to help a web server render dynamic pages and create a customized response for the user making a request via a web application. CGI applications are primarily used to access other applications running on a web server.
CGI is essentially middleware between web servers, external databases, and information sources. CGI scripts and programs are kept in the /CGI-bin directory on a web server and can be written in C, C++, Java, PERL, etc. CGI scripts run in the security context of the web server.
They are often used for guest books, forms (such as email, feedback, registration), mailing lists, blogs, etc. These scripts are language-independent and can be written very simply to perform advanced tasks much easier than writing them using server-side programming languages.
CGI scripts/applications are typically used for a few reasons:
If the webserver must dynamically interact with the user
When a user submits data to the web server by filling out a form. The CGI application would process the data and return the result to the user via the webserver
Broadly, the steps are as follows:
A directory is created on the web server containing the CGI scripts/applications. This directory is typically called
CGI-bin.The web application user sends a request to the server via a URL, i.e, https://acme.com/cgi-bin/newchiscript.pl
The server runs the script and passed the resultant output back to the web client
There are some disadvantages to using them: The CGI program starts a new process for each HTTP request which can take up a lot of server memory. A new database connection is opened each time. Data cannot be cached between page loads which reduces efficiency. However, the risks and inefficiencies outweigh the benefits, and CGI has not kept up with the times and has not evolved to work well with modern web applications. It has been superseded by faster and more secure technologies. However, as testers, we will run into web applications from time to time that still use CGI and will often see it when we encounter embedded devices during an assessment.
CGI Attacks
Perhaps the most well-known CGI attack is exploiting the Shellshock (aka, "Bash bug") vulnerability via CGI. The Shellshock vulnerability (CVE-2014-6271) was discovered in 2014, is relatively simple to exploit, and can still be found in the wild (during penetration tests) from time to time. It is a security flaw in the Bash shell (GNU Bash up until version 4.3) that can be used to execute unintentional commands using environment variables. At the time of discovery, it was a 25-year-old bug and a significant threat to companies worldwide.
Shellshock via CGI
The Shellshock vulnerability allows an attacker to exploit old versions of Bash that save environment variables incorrectly.
Typically when saving a function as a variable, the shell function will stop where it is defined to end by the creator. Vulnerable versions of Bash will allow an attacker to execute operating system commands that are included after a function stored inside an environment variable. Let's look at a simple example where we define an environment variable and include a malicious command afterward.
When the above variable is assigned, Bash will interpret the y='() { :;};' portion as a function definition for a variable y. The function does nothing but returns an exit code 0, but when it is imported, it will execute the command echo vulnerable-shellshock if the version of Bash is vulnerable (in the context of the web server user)
If the system is not vulnerable, only "not vulnerable" will be printed.
This behavior no longer occurs on a patched system, as Bash will not execute code after a function definition is imported. Furthermore, Bash will no longer interpret y=() {...} as a function definition. But rather, function definitions within environment variables must now be prefixed with BASH_FUNC_.
Hands-on Example
Enumeration - Gobuster
We can hunt for CGI scripts using a tool such as Gobuster. Here we find one, access.cgi.
Next, we can cURL the script and notice that nothing is output to us, so perhaps it is a defunct script but still worth exploring further.
Confirming the Vulnerability
To check for the vulnerability, we can use a simple cURL command or use Burp Suite Repeater or Intruder to fuzz the user-agent field. Here we can see that the contents of the /etc/passwd file are returned to us, thus confirming the vulnerability via the user-agent field.
Exploitation to Reverse Shell Access
Once the vulnerability has been confirmed, we can obtain reverse shell access in many ways. In this example, we use a simple Bash one-liner and get a callback on our Netcat listener.
From here, we could begin hunting for sensitive data or attempt to escalate privileges. During a network penetration test, we could try to use this host to pivot further into the internal network.
Mitigation
This blog post contains useful tips for mitigating the Shellshock vulnerability. The quickest way to remediate the vulnerability is to update the version of Bash on the affected system. This can be trickier on end-of-life Ubuntu/Debian systems, so a sysadmin may have first to upgrade the package manager. With certain systems (i.e., IoT devices that use CGI), upgrading may not be possible. In these cases, it would be best first to ensure the system is not exposed to the internet and then evaluate if the host can be decommissioned. If it is a critical host and the organization chooses to accept the risk, a temporary workaround could be firewalling off the host on the internal network as best as possible. Keep in mind that this is just putting a bandaid on a large wound, and the best course of action would be upgrading or taking the host offline.
Last updated
