Suchen

Analyse neuer SQL-Attacken SQL-Injection-Angriffe mit neuen Angriffsmustern

Autor / Redakteur: Adi Kaplou, Eliran Goshen* / Peter Schmitz

SQL-Injection-Angriffe auf Datenbanken, bei denen bösartige SQL-Abfragen zur Ausführung in ein Eingabefeld eingegeben werden, gehören zu den weltweit häufigsten Angriffsvektoren. Sicherheitsexperten zeigen, welche Entwicklungen es in den letzten Monaten gegeben hat und worauf sich IT-Verantwortliche einstellen müssen.

Firmen zum Thema

SQL-Injections nutzen Sicherheitsschwachstellen in Anwendungssoftware und können für Angriffe auf SQL-Datenbanken aller Art verwendet werden.
SQL-Injections nutzen Sicherheitsschwachstellen in Anwendungssoftware und können für Angriffe auf SQL-Datenbanken aller Art verwendet werden.
(Bild: adimas - Fotolia.com)

Vor einem Jahr hat das Check Point-Forscher Team ein automatisches SQL-Injection Tool namens „Havij“ (Karotte) analysiert und allgemein aufgezeigt, wie sich SQL-Injection basierte Attacken abwehren lassen. Inzwischen hat sich einiges getan und SQL-Injection-Angriffe nehmen zu. Welche Entwicklungen es in den letzten Monaten gegeben hat und worauf sich Sicherheits-Verantwortliche einstellen müssen, schildern die Experten von Check Point im folgenden Beitrag.

SQL-Injection-Angriffe, bei denen bösartige SQL-Abfragen zur Ausführung in ein Eingabefeld eingegeben werden, gehören zu den weltweit häufigsten Angriffsvektoren. SQL-Injections nutzen Sicherheitsschwachstellen in Anwendungssoftware und können für Angriffe auf SQL-Datenbanken aller Art verwendet werden.

Bildergalerie

Im vergangenen Jahr hat Check Point für seine IPS-Software-Blade mehrere angepasste Schutzfunktionen gegen SQL-Injections entwickelt. Die Analyse des Verkehrs, der diese Schutzfunktionen in den durch Managed Security Service von Check Point überwachten Netzwerken auslöste, ermöglichte das Erkennen aktueller Trends und Muster von versuchten SQL-Injection-Angriffen.

SQL-Injection durch Werbeanzeigen

Laut reddit.com zwingt dieser Angriffsvektor die angegriffenen Server, Anzeigen zu hosten. Die Check Point IPS-Schutzfunktion „SQL Servers MySQL Vendor-specific SQL Injection“ fand HTTP-Anforderungen im ermittelten Verkehr, der die Zeichenfolge „Wo man die Abtreibungspille kaufen kann“ enthielt. Einer der Berichte deutet an, dass diese Kampagne nicht neu ist und bereits im Juli 2014 als Spam-Kampagne aktiv war (per inman.com).

SQL-Injection durch Werbeanzeigen: Vollständige Quelle
SQL-Injection durch Werbeanzeigen: Vollständige Quelle
(Bild: Check Point)

Gemeinsame Erkennung durch mehrere Schutzfunktionen

Die zwei Funktionen „SQL Servers MySQL Vendor-specific SQL Injection“ und „SQL Servers SQL Injection Evasion Techniques“ ermittelten einen Angriffsversuch zum Schutz vor SQL-Injections. Ausgelöst wurden diese beiden Schutzfunktionen von Verbindungen, die die gleiche HTTP-Anforderung enthielten, wie oben gezeigt:

Beispielcode eines Angriffsversuchs zum Schutz von SQL-Injections
Beispielcode eines Angriffsversuchs zum Schutz von SQL-Injections
(Bild: Check Point)
Diese Schutzfunktionen wurden nacheinander und von denselben IP-Quelladressen ausgelöst. Hierbei handelt es sich jedoch keinesfalls um den einzigen Fall, bei dem mehr als eine Schutzfunktion Versuche zur Ausnutzung von SQL-Schwachstellen erkennt. Die Analyse mehrerer, in überwachten Netzwerken entdeckter Angriffsversuche, zeigt, dass der Angreifer versucht, jeweils mehrere SQL-Schwachstellen gleichzeitig auszunutzen.

Einige der Schutzfunktionen, von denen mindestens je vier zusammen ausgelöst wurden, sind im Folgenden aufgeführt:

  • 1. SQL Servers Blind SQL Injection
  • 2. SQL Servers MySQL Vendor-specific SQL Injection
  • 3. SQL Servers SQL Injection Evasion Techniques
  • 4. SQL Servers UNION Query-based SQL Injection
  • 5. SQL Servers Oracle Vendor-specific SQL Injection
  • 6. SQL Servers Unauthorized Commands SQL Injection
  • 7. SQL Servers Time-based SQL Injection
  • 8. SQL Servers Stack Query SQL Injection

Havij Tool-Erkennung durch mehr als eine SQL-Injections- Schutzfunktion

Bei einigen der von der Schutzfunktion „SQL Servers UNION Query-based SQL Injection“ entdeckten Angriffe gab es einen wiederholten hexadezimalen Text in den HTTP-Anforderungen:

‚31303235343830303536’ - die entschlüsselte Zeichenfolge lautet: 1025480056. Diese Zeichenfolge wurde dem Havij SQL-Injection-Tool zugeordnet (stackexchange.com, isc.sans.edu). Hinzu kommt, dass diese Schutzfunktion zur gleichen Zeit ausgelöst wurde, in der der Traffic entdeckt wurde, der das automatisierte Havij SQL-Injection-Tool verwendete. Das Havij-Tool findet im Verlauf von SQL-Injection-Angriffen breite Anwendung. Daher bedeutet jede Erkennung seiner Aktivität einen weiteren Schritt im Bewusstsein und im Umgang mit einem SQL-Injection-Angriff.

Nächste Seite: Die neuesten SQL-Injection Muster ‚in freier Wildbahn’

Die neuesten SQL-Injection Muster ‚in freier Wildbahn’

Im Folgenden werden Angriffsmethoden, die bei den jüngsten Angriffsversuchen verwendet wurden, analysiert:

1: Information Schema-Methode – eine Methode, bei der der Angreifer auf einen bestimmten Teil der Datenbank zugreift, die Informationen in anderen Teilen der Datenbank enthält. Dadurch hat der Angreifer Zugriff auf vertraulichere Informationen.

Beispiel 1
Beispiel 1
(Bild: Check Point)
In Beispiel 1 ist die verdächtigste Methode eine Anfrage nach dem „information_schema“, obwohl leicht zu erkennen ist, dass dieser Vektor einen komplexen SQL-Abfrageversuch enthält.

„INFORMATION_SCHEMA“ ist die Informationsdatenbank, also der Ort, der Informationen über alle anderen Datenbanken speichert, die der MySQL-Server unterstützt. Darüber hinaus versucht der Angreifer, auf die COLUMNS-Tabelle zuzugreifen, die Informationen über Säulen in Tabellen liefert. Deshalb versucht diese Abfrage zudem, die in der Datenbank gefundenen Informationen zu manipulieren - auch ohne die Tabellennamen zu erraten.

2: Mehrere Methoden in einer Anforderung – Kombinationen mehrerer SQL-Injection-Methoden in einem Versuch, um die Erfolgschancen einer einzelnen zu erhöhen.

Beispiel 2
Beispiel 2
(Bild: Check Point)
In den Beispielen 2 und 3 finden sind mehrere verdächtige Muster zu finden: %2f**%2f – dieses Muster ist ein Versuch - bekannt als mehrzeilige Kommentare - der dazu verwendet wird, eine Abwehrtechnik zu umgehen, die aus der Ermittlung und Entfernung aller Leerzeichen besteht, oder der Verkürzung des Werts auf das erste Leerzeichen des Benutzereintrags.

Beispiel 3
Beispiel 3
(Bild: Check Point)

Information_schema – wie oben erläutert.

0x696e666f726d6174696f6e5f736368656d61, 0x6d7973716c, 0x256d61696c25 – dies ist die hexadezimale Verschleierung von information_schema, mysql und %mail%. Es gibt auch viele Manipulationen, die Merkmale verwenden, bei denen Groß- und Kleinschreibung unterschieden wird, was diese Entwicklung noch verdächtiger macht.

4: Mehrzeilige Kommentare – bestimmte Zeichen, die in der SQL-Injection verwendet werden können, um bestimmte Abwehrmechanismen zu umgehen.

5: „Always True“-Vektor – ein bestimmtes Muster oder ein bestimmter Vektor, der die SQL-Sprache ausnutzt, um von einem Teil der Datenbank viele Informationen zu erlangen.

Beispiel 4
Beispiel 4
(Bild: Check Point)

Beispiel 4 zeigt ein paar allgemeine SQL-Injection-Merkmale:

Where ‚1’=‚1’ – die SQL-Abfrage where „“=„“ (oder jedes andere where<x>=<x>) liefert stets das Ergebnis ‚wahr’. Diese wird oft bei diesem Angriffstyp verwendet, um alle Zeilen der Tabelle zu bekommen.

/**/ – verwendet mehrzeilige Kommentare. Eine Abwehrtechnik ermittelt und beseitigt alle Leerzeichen oder verkürzt den Wert auf das erste Leerzeichen der Benutzereingabe. Zur Umgehung solcher Beschränkungen können mehrzeilige Kommentare verwendet werden.

Die Abfrage kann manchmal verschleiert werden, wie bei diesem Angriff:

ua00rhsatp01:80/search.phpp?words=%’/%2A%2A/UNION/%2A%2A/SELECT/%2A%2A/1%2CCONCAT%28’%3C1%3E’%2Cname%2C’%3A’%2Cpassword%2C’%3C2%3E’%29%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10/%2A%2A/FROM/%2A%2A/site_administrators/%2A%2A/%2

(2A ist der hexadezimale Wert von * – diese hexadezimale Verschleierung ist in SQL-Injection-Vektoren üblich.)

(user,0x3a,password) – Der Angreifer versucht, Informationen über Nutzerkonten zu erlangen.

6: Always True-Variante #2 - Eine HTTP-Anforderung, die am Ende „1=@@version—“ oder „<x>=<x>“ enthält, ist ein weiteres Muster, das stets das Ergebnis ‚wahr’ liefert, was bedeutet, dass es Informationen liefert, deren Export von der Webseite angefordert wird. In Beispiel 5 versuchte der Angreifer durch Anwendung von „1=@@version“—, was 1 entspricht, „1=1“ zu verstecken.

Beispiel 5:

/ÿÿÿ-ÿÿÿÿÿ/**/or/**/1=@@version—

SQL UNION Operator – kombiniert die Ergebnissätze von mindestens zwei SELECT-Anweisungen zur Ausführung einer SQL-Anfrage bei einem bestimmten Teil der Datenbank.

Einer der üblicherweise verwendeten SQL-Befehle ist „Union“. Damit der Befehl „Union All Select 1,2,3,4…“ richtig läuft, gelten für den SQL UNION-Operator folgende Anforderungen:

  • Die beiden Abfragen müssen genau die gleiche Säulenzahl zurückliefern.
  • Die Daten in den entsprechenden Säulen der beiden SELECT-Anweisungen müssen vom gleichen oder zumindest einem kompatiblen Typ sein.
  • Die erste Abfrage besteht aus dem mehrfachen Einspeisen der zweiten Abfrage, wobei die Anzahl der Säulen sukzessive erhöht wird, bis die Abfrage korrekt ausgeführt wird.

Beispiel 6:

66.63.65.137:80/ask/forum_answer.php?que_id=-1/**/UNION/**/ALL/**/SELECT/**/1,2,3,4,0x4f70656e5641532d53514c2d496e6a656374696f6e2d54657374,6,7,8,9,10/**/FROM/**/expert/*

7: Verschleierungstechniken - verschleiern Teil des Injection-Versuchs, um ihn vor dem Abwehrmechanismus zu verbergen. Der Angreifer kann die Nutzung eines Tools für automatisierte SQL-Injection oder Schwachstellen-Scans verschleiern oder verbergen. Beispiel 6 stellt den hexadezimalen Vektor als „OpenVas-SQL-Injection-Test“ in ASCII dar. Diese Verschleierung soll die Aktivitäten von Openvas, einem bekannten Schwachstellen-Scanner, verbergen.

8: Time Based Attacks – SQL-Abfrage, die die Unfähigkeit des SQL-Servers ausnutzt, zeitbezogene Abfragen zu ignorieren. Zeitverzögerungen sind eine sehr leistungsstarke Technik, da der Webserver Fehler oder Daten verbergen kann, er kann jedoch nicht verhindern, darauf warten zu müssen, dass die Datenbank ein Ergebnis liefert. Die SQL-Injection ist somit bestätigt.

Beispiel 7:

associazioneprimonebiolo.org/pagina.aspx?ID=182%3B if %281%3D1%29 waitfor delay ‘00%3A00%3A02’—

9: Stack Queries – eine Abfolge von Mehrfachabfragen, die in einer einzigen Verbindung auf der Datenbank ausgeführt wird.

Ein Punkt, der erhebliche Auswirkungen auf die Fähigkeit hat, eine SQL-Injection-Schwachstelle auszunutzen, ist die Frage, ob Stapelabfragen erlaubt sind. Beispiel 8 zeigt diesen Angriffsvektor.

Beispiel 8:

http:// (*trageted_site*) /search/(*trageted_site*).idq?CiMaxRecordsPerPage= 10&CiScope=%2F&TemplateName=(*trageted_site*)&CiSort=rank%5Bd%5D&HTMLQueryForm=%2Fsearch.htm&MyQuery=new&GO=GO%27%3B%20if%20%281%3D1%29%20waitfor%20delay%20%2700%3A00%3A06%27–

* Adi Kaplou und Eliran Goshen sind Forscher beim Check Point Threat Intelligence & Research Team.

(ID:43419136)