NoSQL-Injection (NoSQLi): Wie sie funktionieren und wie man sich verteidigt

NoSQL-Injektionen (NoSQLi)

NoSQL-Datenbanken sind Datenspeichersysteme, die entwickelt wurden, um große Mengen unstrukturierter (oder semi-strukturierter) Informationen zu verwalten, im Gegensatz zu den Informationen, die von traditionellen relationalen Datenbanken (SQL oder Structured Query Language) verarbeitet werden.

Häufigste Arten von NoSQL-Datenbanken

Gemäß den verschiedenen Nutzen der Informationen werden die Datenbanken in folgende Kategorien eingeteilt:

• Dokumentendatenbanken: Die Informationen werden in Form von JSON-Dokumenten - JavaScript Object Notation, einem leichten Format zur Serialisierung und zum Austausch von Daten - oder BSON - Binary JSON, einem binären JSON-Format, das binär codiert ist anstelle von im Textformat, wie das erste. In dieser Kategorie wären CouchDB (JSON) oder MongoDB (BSON) hervorzuheben.

• Schlüssel-Wert-Datenbanken: Die Daten werden als Schlüssel-Wert-Paare gespeichert. In diesem Sinne sind sie Referenzen wie Redis oder DynamoDB.

• Graphdatenbanken: Sie zeichnen sich dadurch aus, dass die Informationen verwendet werden, um die Modellierung von Beziehungen zwischen den Daten zu priorisieren. Die am häufigsten verwendeten für diesen Typ sind Neo4j oder ArangoDB.

• Spaltenorientierte Datenbanken: Die Speicherung von Informationen im Spaltenformat hat Priorität. Beispiele für diesen Typ wären Apache Cassandra oder HBase.

Was ist NoSQL-Injection (NoSQLi)?

Eine NoSQL-Injection tritt auf, wenn ein Angreifer NoSQL-Abfragen manipuliert, indem er sich eine fehlerhafte Validierung der Eingaben oder Benutzerparameter zunutze macht, wodurch die Ausführung unerwünschter Anweisungen ermöglicht wird, die von den spezifischen Funktionen abweichen, für die die ausgenutzte Funktionalität erstellt wurde, ähnlich wie bei SQL-Injection. Der Hauptunterschied zu diesen typischen Strukturen relationaler Modelle besteht darin, dass hier nicht mit Tabellenstrukturen gearbeitet wird, die in Zeilen und Spalten organisiert sind, wie im vorherigen Abschnitt gesehen, noch mit der SQL-Sprache, sondern mit spezifischen Sprachen jedes NoSQL-Datenbanksystems (JSON, BSON, CQL usw.). In der Regel wird mit unterschiedlichen Formaten interagiert, meist durch den Einsatz dynamischer, weniger starrer Abfragen, die es ermöglichen, die Informationen zu manipulieren, um die in der Anwendung vorhandene Schwachstelle auszunutzen.

Beispiele für NoSQLi-Angriffe in verschiedenen NoSQL-Datenbanksystemen

Im Folgenden werden mögliche typische Ausbeutungsszenarien analysiert, abhängig von den verschiedenen Konfigurationen in den Datenbankmanagementsystemen oder verwendeten NoSQL-Datenbankmanagern.

1. MongoDB

MongoDB verwendet JSON für Abfragen. Beim Speichern des JSON-Dokuments wird es in das entsprechende BSON-Format (binär) konvertiert. Eine typische Abfrage zur Überprüfung von Anmeldeinformationen könnte sein:

db.users.find({ username: "admin", password: "Passw0rd!"});

Grundangriff

Wenn der Eingang nicht sanitisiert ist, könnte ein Angreifer senden:

{ "benutzername": { "$ne": null }, "passwort": { "$ne": null } }

Das erzeugt die Abfrage:

db.users.find({ username: { $ne: null }, password: { $ne: null } })

So wird das Ergebnis die Validierung der Anmeldeinformationen überspringen und der Angreifer erhält Zugang zum System, ähnlich wie man mit einer traditionellen SQLi die Authentifizierungsmechanismen eines Formulars mit der klassischen Injektion ' OR 1=1 -- oder ähnlich' umgehen könnte.

Beachten Sie, dass wenn db.users.findOne verwendet wird, der erste Benutzer aus der Datenbank abgerufen wird, der normalerweise der Administrator ist.

2. Redis

Redis ist eine Schlüssel-Wert-Datenbank, die Befehle wie GET und SET ermöglicht. Ein typischer Angriff könnte die Manipulation von Schlüsseln beinhalten, um andere Informationen zu erhalten, als die, die beabsichtigt ist abzurufen.

Angenommen, eine Anwendung fragt Schlüssel ab mit:

GET Benutzer:Administrator

Grundangriff

Ein Angreifer könnte injizieren:

GET-Benutzer:*

Durch die Verwendung des Platzhalters oder Wildcard '*' werden alle Schlüssel zurückgegeben, die mit dem Muster übereinstimmen, und somit werden alle Benutzer der Anwendung aufgelistet.

3. Apache Cassandra

Cassandra verwendet CQL (Cassandra Query Language), das ähnlich wie SQL ist, aber an ihr Spaltenmodell angepasst ist. Aus diesem Grund erinnern die mit diesem Abfragesystem verbundenen NoSQLi-Angriffe möglicherweise mehr an das traditionelle SQLi als an die anderen in diesem Beitrag analysierten.

Eine typische Abfrage zur Suche nach Benutzern könnte sein:

SELECT * FROM users WHERE username = 'admin' AND password = 'Passw0rd!';

Grundangriff

Auf diese Weise könnte ein Angreifer injizieren:

' ODER '1'='1

 Was Folgendes generieren würde:

WÄHLEN SIE * AUS benutzern WO benutzername = '**' ODER '1'='1**' UND passwort = ''

... auf diese Weise auf alle Benutzer des Systems zugreifen.

4. Neo4j

Neo4j verwendet Cypher als Abfragesprache. Eine typische Abfrage zum Suchen von Knoten könnte sein:

MATCH (u:User {username: 'admin', password: 'Passw0rd!'}) RETURN u;

Grundangriff

Ein Angreifer könnte injizieren:

MATCH (u) RETURN u //

... und folglich könnten alle Knoten der Datenbank zurückgegeben werden.

 

Techniken der Obfuskation und Umgehung

Die Erkennungssysteme wie WAF (Web Application Firewall) blockieren häufig gängige Muster von Injektionen. Angreifer können jedoch fortgeschrittene Techniken verwenden, um diese zu umgehen, wie bereits bei SQLi-Angriffen und anderen Arten von Injektionen zu sehen war. Analog zu SQL-Datenbanken, aber auf diese Art von Datenbanken angewendet, können die folgenden Techniken eingesetzt werden:

1. Codierung

Das Kodieren von Sonderzeichen kann helfen, dass WAF verdächtige Muster nicht erkennt.

Hexadezimale Codierung

Zeichen in ihre hexadezimale Darstellung umwandeln:

{ "$ne": null } → %7B%20%22%24ne%22%3A%20null%20%7D

Base64-Kodierung

Den gesamten Payload in base64 codieren (und später im Client decodieren):

{ "$ne": null } → eyAiJG5lIjogbnVsbCB9Cg==

2. Kommentare

Diese Technik besteht darin, Kommentare einzufügen, um Erkennungsregeln zu umgehen. Zum Beispiel kann man in Neo4j den zuvor gesehenen Code injizieren, um alle Benutzer abzurufen, indem man vorher einen Kommentar einfügt:

MATCH /* loquesea */ (u) RETURN u

3. Verkettung

Durch die Verwendung der Verkettung (+), ähnlich wie bei der SQLi-Evasion, können Zeichenfolgen fragmentiert werden, um den Payload zu trennen und so direkte Erkennungen zu vermeiden. Zum Beispiel im Fall von MongoDB:

{ "benutzername": { "$n" + "e": null } }

4. Verwendung von Steuerzeichen oder Unicode-Räumen (unsichtbare Zeichen)

Manchmal können bestimmte Zeichen, die die Abfrage nicht wirklich ändern, in Injektionen verwendet werden, um die Erkennungsalgorithmen von WAF zu umgehen. Zum Beispiel, im Fall von Redis, kann man vor der Verwendung des Platzhalters (*) das Unicode-Zeichen, das dem "Nullbreitraum" entspricht (Unicode-Zeichen 200B), einfügen.

GET-Benutzer:\\u200B*

Präventionsmaßnahmen

1. Validierung und Bereinigung

• Verwendung strenger Validierungen auf der Serverseite.

• Ablehnung von Sonderzeichen oder unerwarteten Strukturen zur Durchführung der spezifischen Funktionalität. Es ist besser, die gewünschten Werte, die man erwartet zu erhalten, einzugrenzen, als offenere Werte zuzulassen, die von einem Angreifer ausgenutzt werden könnten, oder unvollständige Escape-Funktionen zu verwenden. In letzterem Fall, und falls notwendig, den Einsatz von vorhandenen Bibliotheken und Funktionen in Betracht ziehen. Man sollte immer versuchen, in diesem Sinne "das Rad nicht neu zu erfinden".

2. Verwendung sicherer Bibliotheken

Sichere Operatoren festlegen. Zum Beispiel $eq in MongoDB verwenden:

db.users.find({ username: { $eq: "admin" }, password: { $eq: "Passw0rd!" } });

Auf diese Weise würde der Bau von dynamischen, zu "offenen" Abfragen vermieden. Dies sollte auch für die Fälle berücksichtigt werden, in denen reguläre Ausdrücke verwendet werden.

3. Prinzip der minimalen Berechtigungen oder Einschränkung der Benutzerrechte.

Es wird immer empfohlen, die Berechtigungen des Benutzerangestellten so zu beschränken, dass er nur auf die Informationen zugreifen kann, auf die er zugreifen muss, und auf keine anderen, wobei er auf den Bereich der betreffenden Datenbank beschränkt ist.

4. Verwendung von WAF (Webanwendungsfirewall)

"Das WAF sollte eingesetzt werden, um spezifische Muster von NoSQLi zu blockieren, aber man sollte niemals vergessen, gute Praktiken für sichere Entwicklung zu befolgen, um zu verhindern, dass die Umgehung dieser Muster zu einem erfolgreichen Angriff auf die Anwendung führt." 

Abschluss

"Bei der Betrachtung von NoSQL-Datenbanken aufgrund des Wettbewerbsvorteils, den sie in Bezug auf Flexibilität, Skalierbarkeit und den Umgang mit großen Informationsmengen bieten, öffnet sich auch die Tür zu neuen Angriffsflächen, mit Methoden, die den traditionellen SQLi ähnlich sind, wie im Fall von NoSQLi. Im Gegensatz zu diesen traditionellen Angriffen wird hier die unstrukturierte Natur der Informationen ausgenutzt, in der Regel durch die Manipulation der zugehörigen JSON/BSON-Dateien."

Es ist entscheidend, dass sowohl Entwickler als auch Systemadministratoren und Datenbankadministratoren einen mehrschichtigen Sicherheitsansatz verfolgen, der von einer korrekten Validierung und Bereinigung der Eingabeparameter (angepasst an die neuen verwendeten Verwaltungssysteme) über die Verwendung sicherer Bibliotheken bis hin zu einer angemessenen (und eingeschränkten) Konfiguration des Systems und der verwendeten Berechtigungen reicht.

Darüber hinaus kann die Kompression der von Angreifern verwendeten Umgehungstechniken und die Durchführung regelmäßiger Sicherheitstests dazu beitragen, die Abwehrkräfte gegen diese Art von Bedrohung zu verbessern.

Schließlich, obwohl NoSQLi Ähnlichkeiten mit SQLi aufweist, erfordern die Unterschiede zwischen den verwendeten NoSQL-Sprachen und -Strukturen unterschiedliche und einzigartige Ansätze, um diese Systeme gegen verschiedene Angriffe abzusichern.

Roberto Trigo, Cybersecurity-Consultant bei Zerolynx.