Une nouvelle technique d'exploitation des vulnérabilités dans SQLite a été présentée

Les chercheurs de la société Check Point ont révélé ont présenté lors de la conférence DEF CON des détails sur une nouvelle technique d'attaque visant des applications utilisant des versions vulnérables de SQLite. La méthode de Check Point considère les fichiers de base de données comme une opportunité d'intégration de scénarios d'exploitation des vulnérabilités dans diverses sous-systèmes internes de SQLite, qui ne sont pas accessibles à l'exploitation directe. Les chercheurs ont également développé une technique d'exploitation des vulnérabilités en codant l'exploit sous forme de chaînes de requêtes SELECT dans une base de données SQLite, permettant de contourner l'ASLR.

Pour réussir une attaque, il est nécessaire d'avoir la possibilité de modifier les fichiers de base de données des applications ciblées, ce qui limite la méthode aux applications utilisant SQLite comme format pour les données transitaires et d'entrée. Cette méthode peut également être utilisée pour élargir l'accès local déjà obtenu, par exemple pour intégrer des implants cachés dans les applications utilisées, ainsi que pour contourner les mécanismes de protection lors de l'analyse de logiciels malveillants par les chercheurs en sécurité. L'exploitation après la substitution du fichier se produit au moment où l'application effectue la première requête SELECT sur la table dans la base de données modifiée.

À titre d'exemple, il a été démontré qu'il était possible d'exécuter du code sur iOS en ouvrant le carnet d'adresses dont le fichier de base de données « AddressBook.sqlitedb » avait été modifié à l'aide de la méthode proposée. Pour l'attaque, une vulnérabilité dans la fonction fts3_tokenizer (CVE-2019-8602, possibilité de déréférencement de pointeur) a été exploitée, corrigée dans la mise à jour d'avril de SQLite 2.28, ainsi qu'une autre vulnérabilité dans l'implémentation des fonctions de fenêtres. De plus, l'utilisation de la méthode a été démontrée pour le contrôle à distance d'un serveur backend écrit en PHP par des attaquants, destiné à accumuler des mots de passe interceptés lors de l'exécution de code malveillant (les mots de passe interceptés étaient transmis sous forme de base de données SQLite).

La méthode d'attaque repose sur l'utilisation de deux techniques, « Query Hijacking » et « Query Oriented Programming », qui permettent d'exploiter des problèmes aléatoires conduisant à des corruptions de mémoire dans le moteur SQLite. L'essence du « Query Hijacking » réside dans le remplacement du contenu du champ « sql » dans la table système sqlite_master, qui définit la structure de la base de données. Ce champ contient un bloc DDL (Data Definition Language), utilisé pour décrire la structure des objets dans la base de données. La description est donnée en utilisant la syntaxe SQL standard, c'est-à-dire en utilisant la construction « CREATE TABLE »,
qui est exécutée lors de l'initialisation de la base de données (lors de la première exécution
de la fonction sqlite3LocateTable) pour créer les structures internes liées à la table en mémoire.

L'idée est qu'en remplaçant « CREATE TABLE » par « CREATE VIEW », il est possible de contrôler n'importe quel accès à la base de données via la définition de sa propre vue. Avec « CREATE VIEW », une opération « SELECT » est attachée à la table, qui sera appelée à la place de « CREATE TABLE » et permet d'accéder à différentes parties de l'interpréteur SQLite. Ensuite, le moyen le plus simple d'attaquer serait d'appeler la fonction « load_extension », qui permet de charger une bibliothèque arbitraire avec une extension, mais cette fonction est désactivée par défaut.

Pour effectuer une attaque dans un contexte où l'opération « SELECT » peut être exécutée, la technique « Query Oriented Programming » est proposée, permettant d'exploiter des problèmes dans SQLite qui mènent à des corruptions de mémoire. La technique ressemble à la programmation orientée retour (ROP, Return-Oriented Programming), mais utilise pour construire une chaîne d'appels (« gadgets ») non pas des extraits de code machine existants, mais des insertions dans un ensemble de sous-requêtes à l'intérieur du SELECT.

Source : opennet.ru