Welcome back, aspiring cyberwarriors!
SQLite is one of the most commonly used database engines, embedded in countless applications, mobile devices, and web services. Its compact design makes it a popular choice for developers, but it’s also an attractive target for hackers. Whether you’re a penetration tester, cyberwarrior, or security researcher, mastering SQLite can open up new vectors for exploitation. In this guide, we’ll delve into SQLite’s basic structure and explore how hackers leverage it during attacks.
How Notorious Hacker Groups Utilize SQLite Databases
Let’s look at some real-world examples of how sophisticated hacking groups have used SQLite databases in their operations:
APT Groups and SQLite Misuse: Advanced Persistent Threat (APT) groups often exploit SQLite databases embedded in software or firmware. They gain access to these databases during attacks on web servers, compromised applications, or mobile devices. For example, state-sponsored groups like APT28 (Fancy Bear) and Lazarus Group have leveraged SQLite as a reconnaissance tool:
They extract usernames, application secrets, and configurations to gather intelligence.
SQLite databases on compromised servers often store logs, enabling attackers to analyze and pivot deeper into the target environment.
Ransomware Operators: Ransomware groups, such as REvil or Conti, often seek SQLite files to extract credentials or escalate their attacks. Ransomware binaries are known to scan systems for .db or .sqlite files, stealing any unencrypted credentials, and even altering databases to corrupt application operations as part of the ransom demand strategy.
Credential Stealers and Data Exfiltration: Groups like Emotet and TrickBot – known for deploying malware that specifically targets browser SQLite databases – frequently extract saved usernames and passwords from browser SQLite files (Login Data, Cookies, etc.).
Understanding how SQLite databases are targeted in real-world attacks is important for acting proactively not reactivity, implementing countermeasures and strengthening security.
Using SQLite on Linux
Before using SQLite, you may need to install it. You can check if it’s installed by typing:
kali> sqlite3 –version
To create a new SQLite database (or open an existing one), use the following command:
kali> sqlite3 <db_name>
Inside the SQLite prompt, you can create a table using SQL commands. For example, to create a users table:
sqlite> CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL, age INTEGER);
This SQL statement creates a “users” table with three columns:
id: An integer that serves as the primary key, i.e. the identifier of this record in the database.
name: A text field that must have a value (not null).
age: An optional integer field that can be null.
Let’s add some data:
sqlite> INSERT INTO users (name, age) VALUES (‘Admin’, 30);
Now, let’s try to retrieve data from the table:
sqlite> SELECT * FROM users;
View the schema of a table:
sqlite> PRAGMA table_info(users);
This command displays the structure of a table named users, including column names, data types, and constraints.
sqlite> .tables
This command shows all tables present in the database, useful for initial reconnaissance.
Update data in a table:
sqlite> UPDATE users SET role=’admin’ WHERE username=’guest’;
This command escalates the guest user to an administrator role, allowing for unauthorized actions within the application.
If the SQLite database has a settings or config table, modifying entries like authentication_required can disable security features:
sqlite> UPDATE config SET value=’false’ WHERE key=’authentication_required’;
To capture a snapshot of the database, use:
sqlite> .dump
This command outputs the entire SQL structure and data, which can be saved for further offline analysis.
Attack Strategies
SQLite databases, despite their simplicity and widespread use, have been a target of numerous sophisticated attacks. Here’s an overview of notable attack vectors drawn from real-world hacks:
Memory Corruption and Remote Code Execution (RCE)
The infamous Magellan series of vulnerabilities (e.g., CVE-2019-5018, CVE-2019-13734) exploited weaknesses in SQLite’s implementation, allowing remote code execution. This type of attack often abuses SQLite’s handling of SQL queries to trigger memory corruption.
In these incidents, attackers created specially crafted SQL queries that, when processed, caused heap-based buffer overflows or out-of-bounds reads. For example, the fts3_tokenizer function in SQLite’s Full-Text Search (FTS) module was the root cause of Magellan. Attackers embedded malicious payloads in web pages that exploited these vulnerabilities in web browsers using SQLite internally, such as Chromium. When victims visited these pages, it enabled remote code execution on their machines.
Database File Manipulation and Malicious Trigger Injection
A distinct class of attack involves modifying SQLite database files directly, bypassing the application’s input restrictions. An attacker can manually insert SQL triggers, which are special commands that execute automatically in response to certain events like row inserts or updates.
In a documented case, researchers showed how an SQLite .db file could be tampered with to include triggers designed to execute arbitrary code when the file was opened by a vulnerable application. This tactic is powerful against mobile applications, which often store data as .db files on the device’s filesystem. Attackers gaining access to these files can inject triggers to exfiltrate data or modify the app’s behavior.
Arbitrary Code Execution via Query Parsing Bugs
In some attacks, flaws in the way SQLite parses nested queries were exploited to achieve arbitrary code execution. A good example is CVE-2020-15358, where complex WITH clause queries could manipulate memory in such a way that SQLite’s internal memory management routines were corrupted.
This type of attack is particularly dangerous when the attacker has some control over SQL statements being executed, such as in web applications that allow users to generate or customize queries. Here, attackers construct deeply nested queries that bypass typical sanitization, leading to memory safety violations.
Exploiting Privileges and Weak Encryption in Mobile Apps
Many mobile applications use SQLite databases to store user data, including sensitive information like login credentials or API tokens. Attackers often target these databases by leveraging weak encryption or no encryption at all. A notable case involved WhatsApp’s chat database, which was stored in unencrypted SQLite format.
Chat session extracted from WhatsApp:
Privilege Escalation through load_extension Abuse
SQLite allows dynamic loading of external modules via the load_extension function, which, if enabled, opens up a critical security gap. Attackers can abuse this functionality to load arbitrary shared libraries (.dll, .so files), enabling them to execute code at the same privilege level as the SQLite process.
In a real-world case, this was exploited in an IoT device running SQLite. The device’s firmware had enabled load_extension for debugging purposes. Attackers who managed to connect to the device could leverage this function to inject their custom modules, effectively taking full control of the system.
Summary
This article is a hacker’s guide to SQLite, covering both basics and attack strategies. It introduces SQLite commands and structure, then explores how various threat actors exploit SQLite vulnerabilities. The content is crucial for cybersecurity professionals and developers, as it provides essential knowledge about a widely used database system while highlighting its potential security risks.
