Une nouvelle technique d'exploitation des vulnérabilités de SQLite a été introduite.

Des chercheurs de Check Point découvert lors de la conférence DEF CON, détails d'une nouvelle technique pour attaquer les applications utilisant des versions vulnérables de SQLite. La méthode Check Point considère les fichiers de base de données comme une opportunité d'intégrer des scénarios d'exploitation de vulnérabilités dans divers sous-systèmes internes de SQLite qui ne sont pas directement exploitables. Les chercheurs ont également préparé une technique pour exploiter les vulnérabilités en codant l'exploit sous la forme d'une chaîne de requêtes SELECT dans la base de données SQLite, ce qui permet de contourner l'ASLR.

Pour réussir une attaque, il est nécessaire de pouvoir modifier les fichiers de base de données des applications attaquées, ce qui limite la méthode aux attaques sur les applications qui utilisent la base de données SQLite comme format de transit et d'entrée des données. La méthode peut également être utilisée pour étendre l'accès local existant, par exemple pour intégrer des portes dérobées cachées dans les applications utilisées, ainsi que pour contourner les mécanismes de sécurité lors de l'analyse des logiciels malveillants par les chercheurs en sécurité. L'opération après la substitution de fichier est effectuée au moment où l'application exécute la première requête SELECT sur une table de la base de données modifiée.

A titre d'exemple, nous avons démontré la possibilité d'exécuter du code sous iOS lors de l'ouverture d'un carnet d'adresses, le fichier avec la base de données « AddressBook.sqlitedb » a été modifié à l'aide de la méthode proposée. L'attaque a utilisé une vulnérabilité dans la fonction fts3_tokenizer (CVE-2019-8602, capacité de déréférencement de pointeur), corrigée dans la mise à jour SQLite 2.28 d'avril, ainsi qu'une autre vulnérabilité dans l'implémentation des fonctions de fenêtre. De plus, l’utilisation d’une méthode de prise de contrôle à distance du serveur backend d’un attaquant écrite en PHP, qui accumule les mots de passe interceptés lors du fonctionnement d’un code malveillant (les mots de passe interceptés ont été transmis sous la forme d’une base de données SQLite), a été démontrée.

La méthode d'attaque est basée sur l'utilisation de deux techniques « Query Hijacking » et « Query Oriented Programming », qui permettent d'exploiter des problèmes arbitraires conduisant à une corruption de la mémoire dans le moteur SQLite. L'essence du « Query Hijacking » est de remplacer le contenu du champ « sql » dans la table de service sqlite_master, qui détermine la structure de la base de données. Le champ spécifié contient un bloc DDL (Data Definition Language) utilisé pour décrire la structure des objets dans la base de données. La description est spécifiée à l'aide de la syntaxe SQL standard, c'est-à-dire la construction « CREATE TABLE » est utilisée,
qui est exécuté lors du processus d'initialisation de la base de données (lors du premier lancement
Fonctions sqlite3LocateTable pour créer des structures internes liées aux tables en mémoire.

L'idée est qu'en remplaçant « CREATE TABLE » par « CREATE VIEW », il devient possible de contrôler tout accès à la base de données en définissant votre propre vue. En utilisant "CREATE VIEW", une opération "SELECT" est liée à la table, qui sera appelée à la place de "CREATE TABLE" et vous permettra d'accéder à différentes parties de l'interpréteur SQLite. Ensuite, la méthode d'attaque la plus simple 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 mener une attaque lorsqu'il est possible d'effectuer l'opération « SELECT », la technique « Query Oriented Programming » est proposée, qui permet d'exploiter des problèmes dans SQLite conduisant à une corruption de mémoire. La technique rappelle la programmation orientée retour (ROP, Programmation orientée retour), mais n'utilise pas d'extraits de code machine existants pour construire une chaîne d'appels (« gadgets »), mais les insère dans un ensemble de sous-requêtes à l'intérieur de SELECT.

Source: opennet.ru