Apache HTTP Server for Pentesters

What is Apache HTTP Server?

Apache HTTP server is one of the most popular webservers being used on the internet today, dominating almost 1/3 of the market Apache is open source, and was launched in 1995, making it over 25 years old! Its purpose is to serve web content to clients that request it via HTTP. Apache can run on both Unix and Windows systems alike, making it a versatile choice for anyone looking to quickly and efficiently spin up a website.

How does Apache work?

We can understand how Apache works on a high level by going through the process of a HTTP request. Apache runs as a process listening for HTTP requests on a specific port, usually 80 for HTTP, and 443 for HTTPS (although this is not a hard and fast rule, and you will frequently find Apache listening on other ports, for example, on 8080). When Apache receives a request, it parses the content and returns the requested file to the client. Behind the scenes, Apache uses a threaded architecture, which means that it assigns each request to a thread which is responsible for fetching and returning content to the client that opened the connection. When the content has been returned, the connection is closed, and that thread is then free to handle another requests.

Apache configuration

Linux

Apache configuration files are stored in different places by default on different flavors of Linux. For example, on Debian systems, they are stored in /etc/apache2/, and on Centos, they are stored in /etc/httpd/. These configuration files can be valuable sources of information in conjunction with an LFI vulnerability, a SQLi with file read ability, or during privilege escalation. By looking in /etc/apache2/apache2.conf, or /etc/apache2/sites-enabled/000-default.conf (Debian) you can often find information such as the document root (usually /var/www/html), and where logs are written to. Additionally, you might find some scripts being used by that website, as well as comments from the server admin that may have sensitive information. Virtual hosts are also configured within these config files. These virtual host blocks are the reason multiple websites can be hosted on the same port of a single web server. Apache will route requests to the correct website based on the Host header in the web request.

The configuration might look something like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Listen 8080
<VirtualHost *:8080>
    DocumentRoot "/www/example1"
    ServerName www.example.com
</VirtualHost>

<VirtualHost *:8080>
    DocumentRoot "/www/example2"
    ServerName www.example.org
</VirtualHost>

In the above example, taken from the Apache website, two virtual hosts are being served, www.example.com and www.example.org. Another sensitive file that might contain useful information is an .htaccess file, commonly found in the root of the webserver directory. Apache uses .htaccess files to make configuration changes on a directory and subdirectory level, without modifying server configuration files. The .htacces file might point to an .htpasswd file that contains credentials used to limit access to certain directories with usernames and passwords. Note that an .htpasswd file can be referenced in the apache configuration file as well.

Windows

Apache can also be installed and configured on Windows operating systems. It is generally found as part of a WAMP stack, or installed with XAMPP. The configuration files in a XAMPP setup can usually be found in C:\xampp\apache\conf\, and most of the above will still apply.

Apache and PHP

PHP is an extremely popular server side scripting language that is used by many developers for web development. Apache is configured to support PHP out of the box, provided that PHP is installed on the system. This is important to us as pentesters, because it means that if we know that the webserver is apache, and we can somehow write a PHP webshell to the webroot, (through unrestricted file upload, SQLi, etc.) we may be able to get code execution on the machine. The following is a simple webshell:```

1

<?=`{$_REQUEST['_']}`?>

Its important to note that the PHP $_REQUEST method is being used, because it will accept both GET and POST requests. POST requests are generally preferred for webshells in Apache, because the content of the request does not show up in the Apache access log (located at /var/log/apache2/access.log by default), making this method stealthier. In the example log snippet below, the first log shows a GET request, while the second shows a POST. Notice that the POST doesn’t show the request content like the GET does:

1
2
3

10.0.2.2 - - [21/Jun/2022:03:04:18 +0000] "GET /shell.php?_=uname%20-a HTTP/1.1" 200 329 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36"

10.0.2.2 - - [21/Jun/2022:03:04:20 +0000] "POST /shell.php HTTP/1.1" 200 329 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36"

Log poisoning

Another popular attack chain involving PHP and Apache is log poisoning, which leverages a local file inclusion (LFI) vulnerability in conjunction with Apache logs to gain code execution on a machine. The attack works as follows: An LFI is found that can read files from anywhere on the host OS. The attacker will send a request to Apache with with a PHP webshell, or some other PHP code in the user agent or any other part of the web request that gets written to the logs. The attacker will then trigger the LFI and point the file at Apache’s log file, which will execute the PHP code that was just inserted in the last request. More detailed instructions can be found here: https://www.hackingarticles.in/apache-log-poisoning-through-lfi/

Apache CGI

Apache supports CGI, which stand for Common Gateway Interface. CGI is a way for web servers to interact with external scripts, generally used for dynamic content or sysadmin functions. CGI scripts can be written in many languages, and provide another attack vector for pentesters. The Apache configuration file will specify where these scripts are stored, and they can usually be accessed by from the /cgi-bin/ directory on apache (for example, http://www.example.com/cgi-bin/script.pl). It was the CGI capabilities of Apache that made it a vector for the use of the shellshock vulnerability.

Famous Apache exploits and attacks

There have been many Apache HTTP server exploits over the years, ranging from mild to “we better patch that ASAP”. Two of the more famous ones are below:

Shellshock (CVE-2014-6271)

This vulnerability is not actually in Apache itself, but rather with Bash. However, Apache’s CGI capability was a popular attack vector due to its ease of exploitation. One simply had to replace the user agents string with something like () { :;}; echo PWND to execute code on remote systems. A POC can be found here.

Slowloris DoS

Apache is vulnerable to the Slowloris denial of service attack, based on the threaded nature of its backend. As explained above, Apache handles requests by assigning each incoming request to a thread, which is kept alive for the duration of that specific interaction. Apache has a limit as to how many threads it can run concurrently which opens it up to the Slowloris attack. Attackers will open as many connections as possible with a given webserver, and keep those connections alive for as long as possible. This causes Apache to tie up all its allocated threads responding to these bogus requests, thus denying any legitimate requests from being handled. This attack is dangerous because it is trivial for a single attacker to run, due to the fact that it does not require immense resources. A POC can be found here.