The Check Point researchers recently revealed in the DEF conference with the details of a new technique that was discovered, this is used pTo attack applications that use vulnerable versions of SQLite.
The method Check Point sees database files as an opportunity to integrate vulnerability exploitation scenarios in various internal SQLite subsystems that are not accessible for forehead exploitation. The researchers also developed a technique to exploit vulnerabilities with exploit coding in the form of a string of SELECT queries in an SQLite database, which allows ASLR to be avoided.
About vulnerability
The Check Point researchers detail that for a successful attack, an attacker must be able to modify the database files of the attacked applications, which limits the method of attacking applications that use SQLite databases as the format for transit and input data.
Though they also disclose that the method can also be used to expand local access already obtained, for example, to integrate hidden back doors in the applications used, as well as to avoid security researchers when analyzing malware.
The operation after file impersonation is performed at the time the application executes the first SELECT request to the table in the modified database.
As an example, the ability to run code on iOS when opening the address book was demonstrated, the file with the database «AddressBook.sqlitedb»Which was modified using the proposed method.
For the attack, a vulnerability was used in the fts3_tokenizer function (CVE-2019-8602, the ability to dereference a pointer), fixed in the April SQLite 2.28 update, along with another vulnerability in the implementation of window functions.
In addition, demonstrates the use of the method for remote control seizure of a backend server from attackers written in PHP, which accumulates intercepted passwords during malicious code operation (the intercepted passwords were transferred in the form of an SQLite database).
The attack method is based on the use of two techniques, Query Hijacking and Query Oriented Programming, which allow arbitrary problems that lead to memory corruption in the SQLite engine to be exploited.
The essence of "Query hijacking" is to replace the content of the "sql" field in the sqlite_master service table that defines the database structure. The specified field contains the DDL (Data Definition Language) block used to describe the structure of objects in the database.
The description is set using normal SQL syntax, ie. The "CREATE TABLE" construct, which is performed during database initialization (during the first execution of the sqlite3LocateTable function) is used to create internal structures associated with the table in memory.
The idea is that as a result of replacing "CREATE TABLE" and "CREATE VIEW, it is possible to control any access to the database through the definition of its view.
On the other hand, using the "CREATE VIEW" command, a "SELECT" operation is attached to the table, which will be called instead of "CREATE TABLE" and allows the attacker to access various parts of the SQLite interpreter.
Besides this, the easiest way to attack would be to call the "load_extension" function, which allows the attacker to be able to load an arbitrary library with the extension, but this function is disabled by default.
To perform an attack under the conditions of the ability to perform the SELECT operation, the query-oriented programming technique was proposed, which allows exploiting problems in SQLite that lead to memory corruption.
The technique is reminiscent of Return Oriented Programming (ROP), but uses non-existent machine code snippets, but is inserted into a set of subqueries within SELECT to build a chain of calls ("gadgets").
Source: https://threatpost.com/