Forscher von Check Point präsentierten auf der DEF CON-Konferenz Einzelheiten zu einer neuen Angriffstechnik auf Anwendungen, die anfällige Versionen von SQLite verwenden. Die Methode von Check Point betrachtet Datenbankdateien als eine Möglichkeit zur Integration von Exploit-Skripten in verschiedene interne Subsysteme von SQLite, die nicht direkt angegriffen werden können. Die Forscher haben auch eine Techniken zur Ausnutzung von Sicherheitsanfälligkeiten entwickelt, bei der der Exploit in Form einer Kette von SELECT-Abfragen in der SQLite-Datenbank kodiert ist, wodurch ASLR umgangen wird.
Für einen erfolgreichen Angriff ist es notwendig, die Möglichkeit zur Modifikation der Datenbankdateien der angegriffenen Anwendungen zu haben, was die Methode auf Anwendungen mit SQLite-Datenbanken als Format für Transit- und Eingabedaten einschränkt. Die Methode kann auch verwendet werden, um bereits erlangten lokalen Zugriff zu erweitern, zum Beispiel um versteckte Backdoors in verwendete Anwendungen zu integrieren und Sicherheitsmechanismen bei der Analyse von Malware zu umgehen. Die Ausnutzung erfolgt nach dem Ersetzen der Datei, wenn die Anwendung die erste SELECT-Abfrage an die Tabelle in der modifizierten Datenbank ausführt.
Als Beispiel wird die Möglichkeit demonstriert, Code in iOS auszuführen, wenn das Adressbuch geöffnet wird. Die Datei mit der Datenbank „AddressBook.sqlitedb“ wurde dabei mit der vorgeschlagenen Methode verändert. Für den Angriff wurde eine Schwachstelle in der Funktion fts3_tokenizer (CVE-2019-8602, Dereferenzierung eines Zeigers), die im April-Update von SQLite 2.28 behoben wurde, sowie eine weitere Schwachstelle in der Implementierung von Fensterfunktionen ausgenutzt. Zusätzlich wurde die Methode gezeigt, um die Kontrolle über einen auf PHP basierenden Backend-Server zu übernehmen, der von Angreifern betrieben wird und Passwörter speichert, die im Verlauf der Schadsoftware erfasst wurden (die erfassten Passwörter wurden in Form einer SQLite-Datenbank übermittelt).
Die Angriffsmethode basiert auf der Nutzung zweier Techniken: „Query Hijacking“ und „Query Oriented Programming“. Diese ermöglichen das Ausnutzen beliebiger Probleme, die zu Speicherbeschädigungen im SQLite-Engine führen. Das Wesen von „Query Hijacking“ besteht darin, den Inhalt des Feldes „sql“ in der Systemtabelle sqlite_master, die die DB-Struktur definiert, zu ersetzen. Dieses Feld enthält einen DDL-Block (Data Definition Language), der zur Beschreibung der Struktur von Objekten in der Datenbank verwendet wird. Die Beschreibung erfolgt mittels der üblichen SQL-Syntax, also mit der Konstruktion „CREATE TABLE“.
dies geschieht während der Initialisierung der Datenbank (beim ersten Start
der Funktion sqlite3LocateTable), um interne Strukturen im Speicher zu erstellen, die mit der Tabelle verbunden sind.
Die Idee besteht darin, dass durch den Austausch von „CREATE TABLE“ gegen „CREATE VIEW“ die Möglichkeit entsteht, über die Definition einer eigenen Sicht jedes Zugriffs auf die Datenbank zu kontrollieren. Mit „CREATE VIEW“ wird eine „SELECT“-Operation an die Tabelle gebunden, die anstelle von „CREATE TABLE“ aufgerufen wird und es ermöglicht, auf verschiedene Teile des SQLite-Interpreters zuzugreifen. Der einfachste Angriff wäre dann der Aufruf der Funktion „load_extension“, die das Laden einer beliebigen Bibliothek mit einer Erweiterung erlaubt, jedoch ist diese Funktion standardmäßig deaktiviert.
Um einen Angriff unter den Bedingungen, die die Ausführung der „SELECT“-Operation ermöglichen, durchzuführen, wird die Technik „Query Oriented Programming“ vorgeschlagen, die es ermöglicht, Schwächen in SQLite auszunutzen, die zu Speicherbeschädigungen führen. Diese Technik ähnelt dem Return-Oriented Programming, aber statt existierender maschinencodete Fragmente verwendet sie Einspritzungen von Unteranfragen innerhalb des SELECT., Return-Oriented Programming), verwendet jedoch existierende Fragmente von Maschinen-Code nicht, sondern nutzt Insertions in einer Sub-Abfrage innerhalb von SELECT.
Quelle: opennet.ru
