Der zweite Teil unserer kleinen Serie rund um Penetrationstests dreht sich um die Analyse der Sicherheit, bzw. das was häufig als der eigentliche Angriff wahrgenommen wird. Damit Angriffe möglichst erfolgreich verlaufen, investieren Penetrationstester und Angreifer viel Zeit, um alle möglichen Informationen über ihr Ziel zu sammeln. Details hierzu hatten wir bereits im letzten Teil unserer Serie besprochen.
Bei einem Penetrationstest, kurz Pentest, versuchen sich Angreifer ganz unterschiedliche Probleme zu eigen zu machen. Genauso unterschiedlich wie die Ursachen sind ihre Folgen. Da das Thema sehr umfangreich ist, gehe ich nur auf ein paar Klassiker ein, die bei Webseiten immer wieder auftreten:
- Fehlerhafte Konfigurationen finden
- Entlarven von Authentifizierungsproblemen
- Ein- und Ausgaben manipulieren
Da jeder dieser Punkte ein paar erklärende Sätze verdient, werde ich sie in unterschiedlichen Blogeinträgen aufarbeiten. Der erste Punkt beschäftigt sich mit der Problemstellung, dass eine Web-Anwendung oder ein Web-Server durch Misskonfigurationen angreifbar werden. Im zweiten Punkte wird dann besprochen wie ein Angreifer beispielsweise versucht, Passworteingaben zu umgehen. Und zu guter Letzt möchte ich ein paar Beispiele für Cross-Site-Scripting und SQL-Injektionen und ihre Folgen aufzeigen.
Fehlerhafte Konfigurationen finden
Robots.txt durchsuchen
Eine Seite, die vermutlich zu den meistbesuchtesten Seiten im Internet gehört, ist die /robots.txt. Web-Crawler wie sie beispielsweise von Suchmaschinen eingesetzt werden suchen diese Datei auf, um zu wissen, welche Seiten sie von der Webanwendung indizieren können und welche sie lieber ignorieren sollen. Vor allem der letzte Teil verleitet viele Administratoren dazu, in die robots.txt Seiten mit sensitiven Informationen zu schreiben, damit diese nicht über Suchmaschinen auffindbar sind. Ein Beispiel wie es uns schon in freier Wildbahn begegnet ist, soll das folgende Snippet sein :
User-Agent:*
Disallow: /assets/wichtiger-vertrag_1.pdf
Disallow: /assets/wichtiger-vertrag_2.pdf
In diesem Beispiel sind Pfade zu eigentlich geheimen Verträgen eingetragen. Ein Angreifer kann sich diese Information leicht zu nutze machen. Des Weiteren lässt die Art der Benamung darauf schließen, dass die Verträge durchnummeriert werden. Ein naheliegender Schritt wäre also, weitere Verträge wie /assets/wichtiger-vertrag_3.pdf und /assets/wichtiger-vertrag_4.pdf auszuprobieren. Man spricht in diesem Zusammenhang auch von einer File Enumeration.
Login-Seiten finden
Neben Dateien ist es für einen Angreifer auch spannend, Login-Seiten zu enummerieren. Die robots.txt kann auch hierbei behilflich sein. Findet sich darin keine Information, lassen sich häufig im Quelltext einer Webseite nötige Informationen finden. Das folgende Beispiel zeigt einen Ausschnitt einer Webseite:
...
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="https://example.com/wp-includes/wlwmanifest.xml" />
<meta name="generator" content="WordPress 4.6.1" />
...
Dieser Ausschnitt offenbart, dass die Webseite mit dem Wordpress-CMS erstellt worden ist. Auch die genaue Version kann ein Angreifer hier entnehmen, um im Weiteren nach zugehörigen Schwachstellen zu suchen. Findet sich keine solche offensichtliche Information, verraten die verlinkten Pfade in der Regel wichtige Details. So tauchen in Wordpress häufig Pfade mit dem Prefix wp- auf. Das obere Beispiel enthält einen entsprechenden Pfad zu einer XML-Dateien. Mit der Kenntnis, dass es sich bei der vorliegenden Anwendung um eine Wordpress-Applikation handelt, kann ein Angreifer nun gezielt versuchen, die Login-Seite example.com/wp-admin oder example.com/wp-login.php aufzurufen.
Dieses Vorgehen ist übrigens nicht auf Wordpress-Seiten beschränkt, sondern gilt auch für andere CMS. Sollten trotz Recherche keinen Informationen auf ein bestimmtest CMS hinweisen, bleibt immer noch die Möglichkeit, Seiten zu raten, bzw. auszuprobieren.
Verzeichnisse lesen
Eine weiteres sehr beliebtes Vorgehen nennt man im Englischen Directory Traversal und beschreibt einen Angriff, bei dem es möglich ist, auf normalerweise nicht verfügbare Dateien zuzugreifen.
Die folgende HTTP-Anfrage greift auf die index.html-Seite einer Anwendung zu:
GET /main.cgi?file=index.html HTTP/1.1
Host: www.example.com
Um die Seite auszuliefern, wird das Skript main.cgi ausgeführt und der Parameter file= ausgewertet. Wird die Eingabe nicht ordnungsgemäß validiert, kann ein Angreifer oder Pentester versuchen, den Parameter so zu verändern, dass lokale Dateien ausgeliefert werden. Die folgende Anfrage verdeutlicht dieses Vorgehen, indem sie die Datei /etc/passwd versucht auszulesen.
GET /main.cgi?file=../../../../etc/passwd HTTP/1.1
Host: www.example.com
Liefert die Webanwendungen nun als Antwort den Inhalt der entsprechenden Datei, handelt es sich um eine schwerwiegende Sicherheitslücke.
Weitere typische Probleme, insbesondere Authentifizierungsprobleme, diskutieren wir dann in einem der nächsten Blogeinträge.