SQL Injection – wie Hacker interne Datenbanken knacken

Webtechnologien sind in unserem Alltag allgegenwärtig und Anwendungen werden zunehmend direkt als Webdienste oder Cloud Services entwickelt. Ob über den Browser bedienbare Kontrollelemente, IoT-Geräte, Webapplikation oder Online-Dienste − die Dominanz der Webservices steigt weiterhin. Somit ist auch Web Security zu einem wichtigen Thema geworden. Bei den Angriffen ganz vorne mit dabei: SQL Injections. Was es damit auf sich hat, wie Sie einen solchen Angriff erkennen und vor allem, wie Sie sich schützen können, erfahren Sie in diesem Artikel.

Allein in der Schweiz finden im Schnitt täglich 447 Web-basierte Cyberangriffe statt. Darunter zu finden sind auch sogenannte «Injection-Angriffe» − die Nummer 1 unter den OWASP Top-10-Schwachstellen 2020. Das tückische an diesen Angriffen ist, dass damit potentiell auf firmeninterne Systeme zugegriffen werden kann, die nicht im Internet exponiert sind. Dazu wird die Kommunikation eines Webservers mit beispielsweise Systemressourcen, Schnittstellen von Dritten oder einer Datenbank ausgenutzt.

Einer dieser Angriffe ist die sogenannte «SQL Injection». Bei einer SQL Injection werden Kommandos in die Kommunikation einer Applikation eingeschleust, um so auf indirektem Weg mit dem Datenbank-Managementsystem zu kommunizieren – und zwar mit böswilligen Absichten. Dabei wird SQL (Structured Query Language) verwendet, um mit Datenbanken zu kommunizieren. Mittels Kommandos können so die darin enthaltenen Daten abgefragt, verwaltet oder gar bearbeitet werden.

Von der Theorie in die Praxis – so läuft ein SQL Injection-Angriff ab

23:44 Uhr: Pascal, IT-Verantwortlicher bei einem Webdesign-Startup, wird plötzlich aus dem Schlaf gerissen. Sein Handy vibriert auf dem Nachttisch. Ein Notfall in der Familie? Auf dem Display steht «Stefan Sulzer», einer von Pascals Arbeitskollegen – ein echter Workaholic, der vermutlich noch immer am Design der Frontpage eines neuen Grosskunden arbeitet. Also nur ein IT-Problem, Glück gehabt!

Und so ist es auch. Stefan erklärt, dass etwas mit dem Projektserver nicht stimmt. Aufrufe dauern überdurchschnittlich lange und manche Seiteninhalte werden gar nicht erst geladen. Pascal muss wohl trotz später Stunde kurz einen Blick darauf werden. Er vermutet jedoch, dass nur ein nächtliches Wartungsskript am Laufen ist. Zur Kontrolle ruft Pascal die Prototyp-Startseite des Kunden auf. Anfangs Woche wurde der Server mit der Testseite im Internet exponiert und eine Subdomain zur Vorschau auf den Testserver eingerichtet. Die Testseite wurde noch mit dem alten Framework des Startups aufgebaut, da nicht alle gewünschten Features in der neuen Version vorhanden sind. Nach kurzer Zeit erscheint die Testseite, jedoch ohne Textelemente gefolgt von einer Fehlermeldung:

Warning: mysql_connect(): Access denied for user 'admin_frontpage'@ '172.18.10.33' (using password: YES) in C:\xampp\htdocs\dorpando_crm\dbCon.php on line 35

Merkwürdig, ist der Datenbank-Server offline? Pascal loggt sich in das Firmen-VPN ein, um direkt auf den Datenbank-Server zuzugreifen. Das Login mit seinem Admin-Account klappt. Die Datenbank ist also erreichbar und das Berechtigungs-Management funktioniert ebenfalls. Glücklicherweise war das Log der SQL-Befehle auf dem Entwicklungsserver aktiviert. Es sieht wie folgt aus:

210107 23:32:15  12864 Connect    admin_frontpage@172.18.10.33 as anonymous on
                          12864 Init DB       pagecontent_client
                          12864 Query        SELECT * FROM product AS p INNER JOIN offer AS o ON p.id = o.pid WHERE o.id BETWEEN 81 AND 86 UNION ALL SELECT CONCAT(0x7162707a71,IFNULL(CAST(table_name AS NCHAR),0x20),0x71626a6a71) FROM INFORMATION_SCHEMA.TABLES WHERE table_schema IN (0x73716c696578616d706c65)-- -
                          12864 Quit

Schnell erkennt Pascal, was das Problem ist. Es war ein Angriff – keine Fehlfunktion! Dabei scheint es den Angreifern durch eine Benutzereingabe auf der Testseite gelungen zu sein, die SQL-Kommandos des Servers zu manipulieren. Anhand des Logs erkennt Pascal, dass die Struktur der Datenbank ausgelesen wurde. Mit derselben Methode konnten die Angreifer aber auch die Inhalte lesen, löschen oder Berechtigungen verändern.

Pascal ist sofort hellwach. Viele Fragen schiessen ihm durch den Kopf. War es reiner Vandalismus oder haben die Angreifer möglicherweise vor dem Löschen die Datenbank inklusive der Benutzerinformationen und Passwort-Hashes extrahiert? Wurden möglicherweise noch andere Schwachstellen gefunden?

Eine SQL Injection stoppen: Geht das?

Pascal versucht trotzdem, ruhig zu bleiben. Die forensische Analyse muss vorerst warten. Jetzt gilt es, Sofortmassnahmen zur Schadensbegrenzung zu treffen. Was ist die beste Vorgehensweise? Pascal überlegt, die betroffene Datenbank von einem Backup zu restaurieren und in den Wartungsmodus zu setzen, sodass nur Lesezugriffe möglich sind. Damit würde die Seite wieder korrekt dargestellt. Es besteht jedoch das Risiko, dass der Angreifer weitere Daten aus der Instanz zieht oder andere Datenbanken auf demselben Server findet.

Zur Verhinderung einer weiteren SQL Injection sollten sogenannte «Prepared Statements» im Code der Applikation verwendet werden. Mithilfe dieser kann die Datenbank selbst zwischen manuellen Benutzereingaben und SQL-Abfragen unterscheiden, womit Benutzereingaben bewusst nicht interpretiert werden. Dies verhindert Änderungen an der Datenbank-Anfrage. Die Implementation dieser Prepared Statements würde allerdings länger dauern. Deshalb entscheidet sich Pascal, den Server durch eine Firewall-Regel vorerst vom Internet abzugrenzen, zumal es sich ja «nur» um eine Demoinstanz handelt.

Was bleibt, ist die Ungewissheit. Gibt es noch andere Sicherheitslücken im firmeneigenen Web-Framework? Wer sind die Angreifer und wie weit sind sie gekommen? Sind andere Seiten, die durch das Startup erstellt wurden und dasselbe Framework verwenden auch betroffen? Für Pascal beginnt nun eine lange Nacht…

Web Penetration Tests und Security Monitoring lohnen sich

Wenn auch in diesem Beispiel fiktiv, finden in der Realität Penetrationsversuche von Webdiensten ununterbrochen statt. Was lernt man aus solchen Vorfällen? Von Angreifern entwickelte Bots durchkämmen das Internet permanent nach verwundbaren Applikationen. Gerade deshalb sind Monitoring und vordefinierte Abwehrmassnahmen wichtig. Aber wie so oft gilt auch hier: Vorsorge ist besser als Nachsorge. Sicherheitslücken sollten an der Wurzel, an der Applikation selbst, aufgedeckt und behoben werden.

Um sich gezielt vor Web-Schwachstellen wie SQL Injection und vielen weiteren Web-Sicherheitsrisiken zu schützen, bietet InfoGuard unter anderem folgende Webapplikations-Audits an:

• Web Application Audit
  Der Web Application Audit ist der Standardtest für Web-Services und -Seiten. In diesem wird eine Web-Applikation anhand der OWASP-Guidelines sowie zusätzlichen, von der InfoGuard entwickelten Checks auf Sicherheitslücken und Fehlkonfigurationen überprüft. Auch Authentifizierungsspezifikationen wie OAuth oder SAML werden im Detail analysiert und auf Schwachstellen untersucht.
  
  
• Web API Security Audit
  Bei diesem Audit wird der Fokus speziell auf eine Web-basierte API-Schnittstelle gelegt. REST- oder SOAP-basierte APIs werden dabei nicht nur von Seiten der Eingabevalidierung oder Business-Logik geprüft, sondern auch bezüglich API-spezifischen Schwachstellen wie «Mass Assignment», bei dem mehr als die zwingend notwendigen Attribute von Objekten auf dem Server geschrieben werden können. Diese Tests lehnen sich an das OWASP API Security Project.
  
  
• Web Application Audit mit Source Code Review
  Zusätzlich zum Web Application Audit wird hier ein Review des Applikations-Quellcodes durchgeführt. Dadurch kann ein Penetration Tester Schwachstellen bereits im Quellcode erkennen und diese verifizieren. Dieses Verfahren wird auch als «Whitebox» bezeichnet.
  
  
• OWASP Top 10 Web Application Security Audit
  Beim Top-10-Audit handelt es sich um einen verkürzten Web Application Audit mit Fokus auf die OWASP Top-10-Schwachstellen, welche anhand der aktuellen Befundlage in der Software-Industrie angepasst und publiziert werden. Eine Überprüfung dieser potentiellen Schwachstellen ist eine effektive Methode, um das Sicherheitsverständnis und die Sicherheitskultur in der Software-Entwicklung zu fördern.

Sie sehen: Es gibt viele Möglichkeiten, sich vor SQL Injection-Angriffen zu schützen. Kennen Sie die Schwachstellen Ihrer Webanwendungen? Kontaktieren Sie uns! Gemeinsam mit Ihnen ermitteln wir, welcher Web Penetration Test und Audit optimal zu Ihren Bedürfnissen passt.