Blog

mkind

Penetrationstest Teil 2

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:

  1. Fehlerhafte Konfigurationen finden
  2. Entlarven von Authentifizierungsproblemen
  3. 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.

mkind

Penetrationstest Teil 1

Penetrationstests gehören zu den beliebtesten Dienstleistungen im Bereich IT-Security. Auch bei uns sind sie das am meisten nachgefragte Produkt. Eine solche Form der IT-Sicherheitsüberprüfung ist für den ein oder anderen Kunden das erste Mal, dass er sich diesem Thema widmet. Daher hören viele Kunden sehr interessiert zu, wenn wir Details erzählen. Als Folge dachten wir uns, dass es eine gute Idee wäre, die wichtigsten Schritte eines Penetrationstests einmal in Blogeinträgen zusammen zu fassen. In einer neuen Reihe möchten wir also einen Einblick in das geben, was bei einem Penetrationstest passiert. Solche Tests lassen sich übrigens auf alles Mögliche anwenden wie auf Webseiten, auf Programme oder sogar auf Hardware. In unserem Beispiel konzentrieren wir uns auf das Überprüfen von Webseiten.

Die Phasen eines Pentests

Ein Penetrationstest dient dazu, Schwachstellen ausfindig zu machen. Das Besondere bei dieser Art von Überprüfung ist, dass ein Tester die Rolle eines Angreifers einnimmt. Er geht also genau so vor, wie ein Angreifer üblicherweise vorgehen würde.

Bei einem Pentest, wie ein Penetrationstest auch genannt wird, unterscheiden wir in der Regel vier grobe Phasen:

  1. Vorbereitung
  2. Informationsbeschaffung
  3. Analyse
  4. Dokumentation

Bei einem richtigen Angriff unterscheidet man leicht andere Phasen (Informationsbeschaffung, Exploitation, Post-Exploitation). Das liegt unter anderem daran, dass ein Angreifer in der Regel nicht aufhört, wenn er in ein Netzwerk eindringen konnte und er häufig auch nicht an einer verständlichen Dokumentation für Kunden interessiert ist. Da jede Phase für sich sehr spannend ist, möchten wir jeder dieser Phasen einen eigenen Blogartikel widmen. Dieser Eintrag beschäftigt sich im Wesentlichen mit den ersten beiden Punkten.

Die Vorbereitung eines Penetrationstests

Bevor wir einen Angriff auf eine Anwendung wirklich simulieren können, ist es notwendig, dass wir uns mit dem interessierten Kunden auf wichtige Details verständigen. Ein richtiger Angreifer würde das natürlich nicht tun und direkt mit der Informationsbeschaffung loslegen. Da wir aber helfen wollen, ist es wichtig, dass wir uns mit unseren Kunden genau abstimmen. Folgende Punkte sind hier besonders spannend:

  • Ziel des Penetrationstests: Je nachdem wie umfangreich beispielsweise eine Anwendung ist, bietet es sich an, die Überprüfung auf bestimmte Komponenten zu fokussieren.
  • Art des Pentests: Werden einem Penetrationstester Informationen über das Ziel zur Verfügung gestellt, spricht man häufig von einem white box Test. Wird ein Tester völlig im Dunkeln gelassen, nennt man den Test black box.

Los geht es mit der Informationsbeschaffung

Die erste Phase eines Penetrationstests ist häufig eine entscheidende. Je mehr Informationen ein Angreifer über sein Ziel hat, desto größer sind die Erfolgsaussichten. Als Ausgangspunkt hat die Informationsbeschaffung häufig die Web-Adresse, die es zu überprüfen gilt. In unserem Beispiel ist das example.com.

Ein Klassiker: Die Suchmaschine

Um Informationen über das Ziel zu sammeln, greifen Angreifer wie Penetrationstester häufig auf ein klassisches Werkzeug zurück, wie es jeder täglich selbst nutzt: die Suchmaschine. Suchmaschinen besuchen häufig jede erreichbare Seite einer Web-Anwendung und bieten daher in der Regel einen guten Start. Ein Pentester würde sich also zunächst mit dem Suchbegriff site:example.com alle Ergebnisse zu unserer Zielseite anzeigen lassen. Bekommt man sehr viele Seiten zurück, kann ein Tester die Anfrage jetzt weiter einschränken, in dem er beispielsweise nur an Seiten interessiert ist, die das Wort Passwort enthalten: site:example.com intext:Passwort. Wenn es jetzt darum geht, nur Dateien mit einer bestimmten Endung zu bekommen, bietet eine Suchmaschine ebenfalls hilfreiche Möglichkeiten. So lassen sich mit der folgenden Abfrage log-Dateien anzeigen: site:example.com filetype:log. Über diese Art der Suche lassen sich häufig spannende Informationen zu Tage tragen, die für das erfolgreiche Angreifen einer Webseite essentiell sein können. Es gibt übrigens eine gut aufbereitete Übersicht über solche Suchanfragen, die Google Hacking Database.

Weitere Domains finden

Eine weitere, sehr interessante Information zu einem Ziel sind Subdomains oder IP-Adressen. Eine Domain ist aufgeteilt in verschiedene Teile. Nehmen wir beispielsweise die Domain www.example.com. Hier ist das com die sogenannte Top-Level-Domain, example die Domain und www eine Subdomain. Nun ist es häufig so, dass es auf verschiedenen Subdomains weitere Seiten gibt. So gibt es manchmal eine Entwickler-Version der Webseite unter dev.example.com oder eine erste Vorschau-Version der neuen Webseite unter preview.example.com. Hin und wieder ist es so, dass eine Webseite durch Sicherheitssoftware wie eine Web-Application-Firewall geschützt wird. Dann kann es eine Option sein, dass man diese umgehen kann, wenn man auf eine andere Subdomain zugreift. So haben Entwickler häufig Interesse an detaillierten Ausgaben und möchten nicht, dass eine Sicherheitssoftware die Entwicklung beeinträchtigt. Wenn dem so ist, hat ein Angreifer über das Zugreifen auf dev.example.com einen wichtigen Schritt getan, um Sicherheitsmechanismen zu umgehen. Dieser Prozess, die Subdomains einer Webseite zu finden, lässt sich glücklicherweise sehr gut automatisieren. Mit Programmen wie dnsenum lässt sich ein Großteil der üblichen Subdomains finden.

Webserver identifizieren

Ein letzter Teil, den ich hier anschneiden möchte, ist das Identifizieren eines Webservers. Das ist vor allen spannend, um zu schauen, ob es für die vorliegende Version bereits bekannte Schwachstellen gibt. Wenn ein Browser eine Web-Seite anfragt, dann werden diese Daten mit Hilfe des Protokolls HTTP vom Webserver zum Anfrager übertragen. Es werden aber nicht nur die Webseiten selbst kommuniziert, sondern häufig auch sogenannte Meta-Informationen. Das folgende Beispiel zeigt eine fiktive HTTP-Anfage an example.com und die dazugehörige Antwort:

GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Sun, 15 Oct 2016 17:12: 37 GMT
Server: Apache/2.4.31
Content-Type: text/HTML; charset=iso-8859-1

...

Die ... stehen hier für die eigentliche Webseite, die zur Zeit nicht weiter spannend ist. Tatsächlich liegt das Augenmerk auf dem Feld Server: Apache/2.4.31. Diese Feld zeigt dem Angreifer, dass ein Apache Webserver mit der Version 2.4.31 zum Einsatz kommt. An dieser Stelle zeigt sich, ob ein Zielsystem beispielsweise veraltete Software einsetzt.

Übrigens, all die Informationen, die ein Penetrationstester findet, tauchen im Abschlussreport wieder auf. Auf die Art hat jeder Kunde eine Übersicht, über die Sachen, über die ein Angreifer stolpern würde.

Wie schon angedeutet, lässt sich die Informationsbeschaffung sehr weit treiben. Das ist auch wichtig für einen erfolgreichen Angriff. Im zweiten Teil der Penetrationstest-Serie offenbaren wir dann die nächsten Schritte, die bei einem Angriff passieren.