SQL-Injection-Lücken finden

© Andrei Kuzmik, 123RF

Gift für alle Fälle

Kaum ein Tag vergeht ohne Meldungen über Einbrüche in Regierungs-, Militär- oder Firmen-Server. Wer die Vorgehensweise der Hacker genauer analysiert, wird schnell feststellen, dass in fast 90 Prozent der Fälle eine sogenannte SQL-Injection zur Komprimierung des Servers geführt hat.
Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Hacker-Gruppen wie Anonymous oder Lulzsec sind für jeden Administrator ein Albtraum. Innerhalb von nur wenigen Stunden können Angreifer in der Lage sein, eine vollständige Server-Infrastruktur kompromittieren. Oft ist das Einfallstor für die Angreifer ein klassischer Fehler in einer Webanwendung: die Anfälligkeit für SQL Injection. Nicht nur sensible Daten sind in Gefahr, die gesamte Server-Infrastruktur kann von Angreifern übernommen werden. Die bereits seit über zwölf Jahre bekannte Lücke ist nach wie vor das beliebteste Angriffsziel von Hackern.

Dieser Artikel beschreibt anhand von realitätsnahen Beispielen die Angriffsvektoren einer SQL-Injection, erklärt wie diese durch Unachtsamkeit auftreten können und wie weitreichend solch eine Lücke sein kann. Demonstriert wird dies zunächst manuell an einem potenziell verwundbaren Skript und dann mithilfe des Tools SQLmap in einer Testumgebung mit entsprechend verwundbarer Software.

Ein Merkmal, das fast alle Webapplikationen gemeinsam haben, ist die Anbindung an eine oder mehrere Datenbanken. Ob zum Abrufen von E-Mails, Einkaufen im Internet oder zum Lesen von News: Eine oder gar mehrere Datenbanken stecken immer dahinter. Egal, in welcher Programmiersprache die Web-Applikation geschrieben wurde, die Kommunikation mit der Datenbank erfolgt immer nach demselben Prinzip: Das serverseitig abgelegte Skript übermittelt die SQL-Abfragen an die Datenbank, wertet die zurückgegeben Werte aus und liefert diese dem Anwender zurück.

Ungenügend informiert

Die Ursache für Sicherheitslücken in Web-Applikationen ist oft im mangelnden Sicherheitsbewusstsein von Programmierern zu suchen. Die wesentlichen Probleme entstehen vor allem durch fehlende Überprüfung der eingehenden Werte. Das folgende PHP-Skript, das zu einem gängigen Login-Screen gehört, demonstriert einen typischen Programmierfehler.

$query = "SELECT * FROM users WHERE user='" . $_POST['username'] . " ' AND password=' " . $_POST['password'] . " ' ";
$response = mysql_query($query) ;

Entgegengenommen werden als Werte der Username und das Passwort. Das Skript überprüft nun nach Eingabe der jeweiligen Daten, ob sie mit den in der Datenbank hinterlegten übereinstimmen. Wird der jeweilige User in der Datenbank gefunden, und passt das angegebene Passwort, so ist der Nutzer legitimiert. Das hierfür zuständige SQL Statement wird folgendermaßen übergeben :

SELECT * FROM users WHERE user='...' AND password='...'

Die Datenbankabfrage wird demnach durch die zwei Variablen Username und Passwort ergänzt. In der Theorie funktioniert dies, bis ein Angreifer die Abfrage folgendermaßen abändert:

Password = ' OR 'a' = 'a'

Die Anfrage an die Datenbank sieht nun folgendermaßen aus :

SELECT * FROM users WHERE user = 'Patrik' AND password = ' ' OR 'a' = 'a'

Die hierbei neu generierte SQL-Abfrage prüft zuerst die OR-Verknüpfung und anschließend die AND-Verknüpfung. Die OR-Verknüpfung prüft, ob sich mindestens eines der beiden Argumente als wahr erweist. Die logische Abfrage, ob 'a' = 'a' ergibt, ist immer wahr. Die AND-Verknüpfung überprüft, ob der Username »Patrik« in der Datenbank vorhanden ist. Ist dies der Fall, wird auch dies als wahr zurückgegeben. Da beide dieser Argumente sich als wahr erweisen, wird der Angreifer auf dem System authentifiziert, ohne überhaupt das Passwort zu kennen. Weil hier statt einfachen String-Werten vom böswilligen Anwender SQL-Befehle in die ursprüngliche Abfrage "injiziert" wird, spricht man von einer SQL Injection.

Verhindern lässt sich ein solcher Angriff, indem die Webanwendungen alle Eingaben prüft und statt einfacher String-Verkettung sogenannte Prepared Statements verwendet. Die Skriptsprache stellt dann sicher, dass nur die gewünschten Datentypen wie Strings in die Abfrage gelangen.

Verdammt verletzlich

Um weitere Angriffsmethoden für SQL-Injection zu demonstrieren, verwendet der Rest des Artikels eine potenziell verwundbare Testumgebung. Dies ist ein XAMPP-Webserver mit einer vorsätzlich fehlerhaften Anwendung namens DVWA (Damn Vulnerable Web Application [1]). Es handelt sich hierbei um eine Web-Applikation die auf PHP und MySQL aufbaut und speziell für Sicherheitsspezialisten konzipiert ist. Damit ist es möglich, in einem legalen Umfeld verschiedenste Angriffe auf Web-Applikationen zu testen.

Nach der Installation des Microsoft Windows Server 2003 und der Einrichtung der Webapplikation DVWA muss sich der Benutzer zunächst über das Login-Feld mit dem Benutzernamen »Admin« und dem Passwort »Password« auf dem System anmelden. DVWA bietet drei verschiedene Schwierigkeitsmodi, die unterschiedliche Szenarien der Server-Sicherheitseinstellungen simulieren können. Für die Demonstration der SQL-Injection muss im Reiter »DVWA Security« die Einstellungen auf »Low« gestellt werden, um sicherzustellen, dass alle Sicherheitsmechanismen, die eine SQL-Injection verhindern könnten, ausgeschaltet sind.

Nun kann das entsprechend verwundbare Modul links im Reiter ausgewählt werden. In diesem Artikel ist dies das Modul »SQL-Injection« (Abbildung 1).

Abbildung 1: Das SQL-Injection-Modul der Damn Vulnerable Web Application.

Ähnliche Artikel

Kommentare

Sehr gut!

Sehr informativer und guter Artikel! Weiter so!

comments powered by Disqus

Artikel der Woche

Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2018