Operator On The Wire
Waitlist
← Back to Knowledge Base
OOTW / Chapter III - Web / Web Servers / Servers

Apache

Apache HTTP Server is a modular web server used for static files, PHP applications, reverse proxying, CGI, WebDAV, and many legacy application stacks.

Apache is especially important because it supports directory-level configuration through .htaccess. That feature is convenient for hosting environments, but it also creates a large attack surface when uploads or writable webroots are involved.

Where Apache Appears

Common deployment patterns:

Apache -> static files
Apache -> mod_php
Apache -> PHP-FPM
Apache -> CGI scripts
Apache -> Tomcat through mod_proxy
Apache -> backend application through ProxyPass

Apache behavior depends heavily on loaded modules. Always identify modules before making assumptions.

Important Paths

Debian and Ubuntu:

/etc/apache2/apache2.conf
/etc/apache2/envvars
/etc/apache2/ports.conf
/etc/apache2/sites-available/
/etc/apache2/sites-enabled/
/etc/apache2/mods-available/
/etc/apache2/mods-enabled/
/var/www/html/
/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/apache2/other_vhosts_access.log

RHEL and CentOS style layouts:

/etc/httpd/conf/httpd.conf
/etc/httpd/conf.d/
/var/www/html/
/var/log/httpd/access_log
/var/log/httpd/error_log

Useful local commands when we have shell access:

apache2ctl -S
apache2ctl -M
apache2ctl -t
apachectl -S
apachectl -M
apachectl -t
ps aux | grep apache

apache2ctl -S shows virtual host routing. apache2ctl -M shows loaded modules.

Core Configuration

Example virtual host:

<VirtualHost *:80>
    ServerName example.local
    DocumentRoot /var/www/html

    <Directory /var/www/html>
        Options -Indexes
        AllowOverride None
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Important directives:

VirtualHost       Site definition
ServerName        Primary hostname
ServerAlias       Additional hostnames
DocumentRoot      Webroot
Directory         Filesystem access rules
Location          URL access rules
Files / FilesMatch File-name access rules
Alias             URL-to-filesystem mapping
ScriptAlias       CGI mapping
ProxyPass         Reverse proxy mapping
AllowOverride     Whether .htaccess can override config
Options           Directory features such as Indexes and FollowSymLinks
Require           Authorization rule

Directory, Location, And Files

Apache has different containers for different things.

Directory applies to filesystem paths:

<Directory /var/www/html/admin>
    Require ip 10.0.0.0/8
</Directory>

Location applies to URL paths:

<Location /admin>
    Require ip 10.0.0.0/8
</Location>

FilesMatch applies to file names:

<FilesMatch "\.php$">
    Require all granted
</FilesMatch>

Security bugs appear when the wrong container is used for the security boundary. Filesystem paths and URL paths are not the same thing.

.htaccess

.htaccess files allow per-directory configuration when AllowOverride permits it.

Risk pattern:

<Directory /var/www/html>
    AllowOverride All
    Require all granted
</Directory>

If an attacker can upload .htaccess, they may be able to change handler behavior inside that directory.

Example dangerous override:

AddType application/x-httpd-php .txt

Now a file ending in .txt may be treated as PHP in that directory, depending on the server and module configuration.

Safer default:

<Directory /var/www/html>
    AllowOverride None
    Options -Indexes
    Require all granted
</Directory>

Use .htaccess only when there is a clear operational reason. Central config is easier to review and harder for web content to modify.

Modules To Notice

Common security-relevant modules:

mod_php       PHP execution inside Apache
proxy         Reverse proxy base module
proxy_http    HTTP reverse proxy
proxy_fcgi    FastCGI / PHP-FPM proxying
rewrite       URL rewriting
headers       Header modification
auth_basic    Basic authentication
authz_core    Authorization
status        /server-status
autoindex     Directory listing
cgi / cgid    CGI execution
dav / dav_fs  WebDAV
ssl           TLS

Loaded modules change the attack surface. A server with dav enabled is very different from a server without it.

Enumeration

Remote checks:

curl -i http://target/
curl -i http://target/nonexistent
curl -I http://target/
whatweb http://target/
nikto -h http://target/

Interesting paths:

/server-status
/server-info
/icons/
/cgi-bin/
/.htaccess
/.htpasswd
/.git/
/uploads/
/manual/

If LFI exists, read:

/etc/apache2/apache2.conf
/etc/apache2/envvars
/etc/apache2/sites-enabled/000-default.conf
/etc/apache2/ports.conf
/etc/httpd/conf/httpd.conf
/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/httpd/access_log
/var/log/httpd/error_log

Common Weaknesses

Directory Listing

Risk:

<Directory /var/www/html/files>
    Options Indexes
    Require all granted
</Directory>

Indexes enables directory listing when no index file exists.

Better:

<Directory /var/www/html/files>
    Options -Indexes
    Require all granted
</Directory>

Exposed Server Status

Risk:

<Location /server-status>
    SetHandler server-status
    Require all granted
</Location>

server-status can leak client IPs, requested paths, virtual hosts, backend behavior, and traffic patterns.

Better:

<Location /server-status>
    SetHandler server-status
    Require local
</Location>

.htaccess Handler Override

If uploads allow .htaccess, the attacker may be able to remap extensions.

Example chain:

1. Upload .htaccess that maps .txt as PHP.
2. Upload shell.txt.
3. Request shell.txt.
4. Apache executes it through PHP.

This depends on AllowOverride, module support, upload path, and handler configuration.

.htpasswd Exposure

.htpasswd contains HTTP Basic Auth password hashes.

It should never be downloadable from the webroot.

Findings:

/.htpasswd accessible
/.htaccess accessible

Impact:

  • Usernames leak.
  • Password hashes can be cracked offline.
  • Auth-protected areas can be mapped.

CGI And Shellshock

CGI scripts execute programs on the server.

High-value path:

/cgi-bin/

Old Bash-backed CGI environments were historically vulnerable to Shellshock. Modern systems should be patched, but CGI remains high risk because it bridges HTTP input and operating system execution.

WebDAV

WebDAV allows HTTP methods used for remote file management.

Check:

curl -i -X OPTIONS http://target/

Interesting methods:

PUT
MOVE
COPY
DELETE
PROPFIND
MKCOL

If WebDAV permits writes into an executable path, upload impact increases sharply.

Alias And ScriptAlias

Alias maps URL paths to filesystem paths.

Alias /downloads/ /srv/shared/downloads/

ScriptAlias maps URL paths to executable CGI directories.

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

Review:

  • Does the alias expose unexpected files?
  • Does access control apply to the filesystem path?
  • Are CGI scripts writable?
  • Are backup scripts reachable?

Log Poisoning

Apache access logs commonly include the user agent.

Poison marker:

curl -A "ootw-log-marker" http://target/

High-value log files:

/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/httpd/access_log
/var/log/httpd/error_log

Log poisoning becomes execution only when an LFI/include primitive causes the runtime to interpret the log as code.

Defensive Checklist

  • Disable Indexes unless directory listing is intentional.
  • Keep AllowOverride None unless .htaccess is required.
  • Block direct web access to .htaccess and .htpasswd.
  • Restrict /server-status and /server-info.
  • Disable unused modules.
  • Keep CGI disabled unless required.
  • Keep WebDAV disabled unless required.
  • Keep uploads outside executable paths.
  • Do not allow uploaded .htaccess.
  • Review Alias, ScriptAlias, and ProxyPass.
  • Use apache2ctl -S to validate virtual host routing.
  • Use apache2ctl -M to validate the module attack surface.