Inhaltsverzeichnis:
Video: Roland Berger Webinar – „Do's und Don'ts in Case-Interviews“ German 2024
In dieser Fallstudie teilte Chip Andrews, Experte für SQL Server-Sicherheit, diese Erfahrung des (ethischen) Hackens mit einem Kunden. Datenbank, um Sicherheitslücken aufzudecken. Dieses Beispiel bietet eine Warnung, um Ihre wichtigen Informationen zu schützen, indem Sie auf einer soliden Datenbanksicherheit bestehen.
Die Situation
Während eines routinemäßigen Penetrationstests führte Andrews die obligatorischen Google-Suchen, die Recherche nach Domainnamen, das Fingerabdrücken von Betriebssystemen und Port-Scans durch. Diese Website war jedoch fest verschlossen. In der webbasierten Anwendung, die auf dem System ausgeführt wird, wurde er sofort mit einer Anmeldeseite konfrontiert, die SSL-verschlüsselte Formularauthentifizierung verwendet.
Beim Überprüfen der Quelle der Webseite stellte er fest, dass ein verstecktes Feld "App_Name" an die Anwendung übergeben wurde, wenn ein Benutzer versuchte, sich bei der Site anzumelden. Könnte es sein, dass es den Entwicklern nicht gelungen ist, eine korrekte Eingabeüberprüfung für diesen unschuldig aussehenden Parameter durchzuführen? Die Jagd war an.
Das Ergebnis
Zuerst war es an der Zeit, das Toolkit zusammenzustellen. Zum Zeitpunkt dieses Penetrationstests zog Herr Andrews es vor, Folgendes zu verwenden: Paros Proxy, Absinthe, Cain & Abel, Data Thief und das Microsoft SQL Server Management Studio / SQL Server (Express Edition), die alle kostenlos verfügbar sind…
Für den Anfang verwendete er Paros Proxy, um mehr Kontrolle und Sichtbarkeit für die Webanforderungen zu ermöglichen, die an den Webserver gestellt wurden.
Nachdem die Website für verfügbare Seiten gespikt und eine schnelle Anfälligkeitsprüfung für die SQL-Injection durchgeführt wurde, wurde bestätigt, dass der Parameter App_Name anscheinend dazu führte, dass die Anwendung eine Error 500-Ausnahme auslöste und einen Anwendungsfehler anzeigte. Penetrationstests sind eine der seltenen Gelegenheiten, bei denen ein Anwendungsfehler ein wünschenswertes Ergebnis ist.
Da der Anwendungsfehler darauf hinwies, dass Herr Andrews unbeabsichtigte Zeichen in den SQL-Code injizieren konnte, der von der Anwendung an die Datenbank gesendet wurde, konnte er erkennen, ob es sich um eine ausnutzbare Bedingung handelt.
Ein gängiger Test, der mit Microsoft SQL Server-Datenbanken funktioniert, besteht darin, einen Befehl wie WAITFOR DELAY '00: 00: 10 'einzufügen, wodurch der Datenbankserver für 10 Sekunden blockiert wird. In einer Anwendung, die normalerweise eine Seite in einer Sekunde oder weniger zurückgibt, ist eine konsistente Verzögerung von 10 Sekunden ein guter Indikator dafür, dass Sie Befehle in den SQL-Datenstrom einfügen können.
Als nächstes versuchte Mr. Andrews, das Data Thief-Tool zu verwenden, um die Anmeldeseite anzugreifen.Dieses Tool versucht, die Datenbank dazu zu zwingen, einen OPENROWSET-Befehl zu verwenden, um Daten aus der Zieldatenbank in die Datenbank von Herrn Andrews im Internet zu kopieren.
Dies ist normalerweise eine sehr effiziente Methode, um große Datenmengen aus anfälligen Datenbanken zu entfernen, aber in diesem Fall wurde sein Angriff vereitelt! Der Datenbankadministrator am Ziel hatte die OPENROWSET-Funktionalität deaktiviert, indem er die Option Adhoc Distributed Queries deaktivieren korrekt konfiguriert hat.
Mit dem Fleiß als seine Parole beharrte Mr. Andrews auf dem nächsten Werkzeug - Absinthe. Dieses Tool verwendet eine Technik namens Blind-SQL-Injektion , um mit einfachen Ja oder Nein-Fragen der Datenbank Bestimmungen über Daten zu treffen. Zum Beispiel könnte das Tool die Datenbank fragen, ob der erste Buchstabe einer Tabelle kleiner als "L" ist. "
Wenn ja, könnte die Anwendung nichts tun, aber wenn nein, könnte die Anwendung eine Ausnahme auslösen. Mit dieser einfachen Binärlogik ist es möglich, diese Technik zu nutzen, um die gesamte Datenbankstruktur und sogar die darin gespeicherten Daten sichtbar zu machen - wenn auch nur sehr langsam. Mithilfe des Tools identifizierte er eine Tabelle mit vertraulichen Kundeninformationen und lud mehrere hundert Datensätze herunter, um den Kunden zu zeigen.
Endlich war es an der Zeit, einen letzten Akt der Datenbankunterschlagung zu versuchen. Zuerst hat Herr Andrews das Werkzeug namens Cain & Abel geladen und es in den Schnüffelmodus versetzt. Dann benutzte er unter Verwendung von Paros Proxy und dem bereits identifizierten verwundbaren Parameter die erweiterte gespeicherte Prozedur xp_dirtree, die für SQL Server-Datenbankbenutzer verfügbar ist, um zu versuchen, ein Verzeichnis auf seinem mit dem Internet verbundenen Rechner unter Verwendung eines Universal Naming Convention-Pfads anzuzeigen.
Dadurch wurde die Zieldatenbank gezwungen, sich tatsächlich gegen Mr. Andrews 'Maschine zu authentifizieren. Da Cain & Abel den Draht abhörte, erhielt es den Hash der Abfrage, mit der die freigegebene Dateifreigabe authentifiziert wurde.
Durch Übergeben dieses Hashs an den in Cain & Abel integrierten Passwort-Cracker hätte Mr. Andrews den Benutzernamen und das Passwort des Kontos, unter dem der anfällige SQL-Server in kürzester Zeit ausgeführt wurde.
Würde dieses gehackte Konto dasselbe Passwort verwenden wie das Admin-Konto der Webanwendung? Wäre dieses Passwort das gleiche wie das lokale Administratorkonto auf dem Host? Das waren Fragen für einen anderen Tag. Es war an der Zeit, alle gesammelten Daten zusammenzustellen, einen Bericht für den Kunden zu erstellen und die Werkzeuge für einen weiteren Tag abzulegen.
Chip Andrews ist Mitbegründer der Sicherheitsberatungsfirma Special Ops Security, Inc. und Inhaber von SQLSecurity. com, das über mehrere Ressourcen zur Microsoft SQL Server-Sicherheit verfügt, einschließlich des SQLPing3-Tools. Als Co-Autor für mehrere Bücher über SQL Server-Sicherheit und einen Black-Hat-Moderator fördert Mr. Andrews seit 1999 die Sicherheit von SQL Server und Anwendungen.
