Investigadores de Check Point presentaron en la conferencia DEF CON detalles de una nueva técnica de ataque a aplicaciones que utilizan versiones vulnerables de SQLite. El método de Check Point considera los archivos de base de datos como una oportunidad para integrar scripts de explotación de vulnerabilidades en varias subsistemas internos de SQLite, inaccesibles a ataques directos. Los investigadores también han desarrollado una técnica de explotación con el exploit codificado en forma de cadenas de consultas SELECT en una base de datos SQLite, permitiendo evadir ASLR.
Para un ataque exitoso, es necesario tener la capacidad de modificar los archivos de base de datos de las aplicaciones atacadas, lo que limita el método a aplicaciones que utilizan SQLite como formato para datos de tránsito y entrada. Este método también puede ser utilizado para ampliar el acceso local ya obtenido, por ejemplo, para integrar puertas traseras ocultas en las aplicaciones utilizadas, así como para eludir los mecanismos de protección durante el análisis de malware. La explotación después de reemplazar el archivo se lleva a cabo en el momento en que la aplicación ejecuta la primera consulta SELECT a la tabla en la base de datos modificada.
Como ejemplo, se demostró la posibilidad de ejecutar código en iOS al abrir la libreta de direcciones, cuyo archivo de base de datos 'AddressBook.sqlitedb' se había modificado utilizando el método propuesto. Para el ataque se utilizó una vulnerabilidad en la función fts3_tokenizer (CVE-2019-8602, posibilidad de desreferenciar un puntero), corregida en la actualización de abril de SQLite 2.28, junto con otra en la implementación de funciones de ventana. Además, se demostró la aplicación del método para la toma de control remoto de un backend de servidor PHP por parte de atacantes, que acumulaban contraseñas interceptadas durante la ejecución de código malicioso (las contraseñas interceptadas se transmitían en forma de base de datos SQLite).
El método de ataque se basa en el uso de dos técnicas, «Query Hijacking» y «Query Oriented Programming», que permiten explotar problemas arbitrarios que llevan a la corrupción de memoria en el motor SQLite. La esencia de «Query Hijacking» radica en la sustitución del contenido del campo «sql» en la tabla de sistema sqlite_master, que define la estructura de la base de datos. Este campo contiene un bloque DDL (Data Definition Language), utilizado para describir la estructura de los objetos en la base de datos. La descripción se establece utilizando la sintaxis SQL estándar, es decir, se utiliza la construcción «CREATE TABLE»,
que se ejecuta durante la inicialización de la base de datos (en el primer arranque
de la función sqlite3LocateTable) para crear estructuras internas relacionadas con la tabla en la memoria.
La idea es que, como resultado de reemplazar «CREATE TABLE» por «CREATE VIEW», se crea la posibilidad de controlar cualquier acceso a la base de datos a través de la definición de su propia vista. Mediante «CREATE VIEW», a la tabla se le asocia una operación «SELECT», que será llamada en lugar de «CREATE TABLE» y permite acceder a varias partes del intérprete de SQLite. Luego, la forma más simple de ataque sería invocar la función «load_extension», que permite cargar una biblioteca arbitraria con una extensión, pero esta función está desactivada por defecto.
Para llevar a cabo el ataque en condiciones de poder ejecutar la operación «SELECT», se propone la técnica «Query Oriented Programming», que permite explotar problemas en SQLite que conducen a la corrupción de memoria. La técnica se asemeja a la programación orientada a retornos (, Return-Oriented Programming), pero utiliza para construir la cadena de llamadas («gadgets») fragmentos no existentes de código máquina, sino inserciones en un conjunto de subconsultas dentro de SELECT.
Fuente: opennet.ru
