Malicious SQLite Databases Used to Compromise Applications

Databases, designed to make it easy to store and access data, use a set structure for data storage. The Structured Query Language (SQL) allows a user to query the database and extract information.

And SQL is a compelling language. It is Turing complete, meaning that any computer program could potentially be implemented in SQL. However, the SQL language power and its access to potentially sensitive information make it a common attack target.

SQL injection attacks are one way of targeting databases via SQL. SQL queries commonly intermingle commands with input provided by the user.

SQL injection attacks take advantage of this by providing input that is deliberately formatted to make data be interpreted as SQL commands. A recent talk at theDEF CON cybersecurity conference demonstrates another way in which SQL databases can be abused.

By using a malicious SQLite database, a hacker can take a variety of different actions, including compromising the legitimate applications that rely on these databases.

Introduction to SQLite

Several implementations of databases compliant with the SQL language exist.

However, SQLite is a prevalent one due to its “lightness”. Unlike most SQL databases, SQLite databases are completely self-contained within a single file on disk. Furthermore, SQLite is implemented as a C library and does its job very well.

As a result, it is built into many different applications, including all mobile phones and many different computers. However, the heavy reliance of applications on the data stored within SQLite databases makes them a promising target for hackers.

Exploiting Apps Through SQLite

While SQL injection attacks exist, some applications may assume that data in a database is valid. However, this assumption makes them vulnerable to attack.

In his DEF CON talk, Omer Gull provided a couple of case studies in how a malicious SQL database could be used to compromise applications. One example dealt with the fact that SQLite is embedded in all mobile phones and is commonly used by iOS applications.

Apple is well-known for its strict security model when it comes to applications. For example, to run on an iOS device, an application has to be digitally signed. However, the same is not true of all files on iOS. For example, SQLite databases, which are used by various applications, do not require digital signatures.

Gull took advantage of this by modifying the Contacts database on iOS to contain malicious code. When the Contacts process tries to query the SQL database, it runs the code injected by the attacker.

This ability to run malicious code on the device has multiple different applications for a hacker.

Beyond the ability to steal sensitive data from the device (the code is present in a database), the code can be used to add persistence to malware or even to elevate its privileges. If the user identified and deleted malware running on the device, the malicious SQL code could reinstall it.

Privilege escalation can occur since multiple processes use the Contacts database, and they have varying levels of privileges. For example, an attacker may manage to modify the database through access to the Contacts application. However, Facetime and WhatsApp also use this database. When they query the database and execute the malicious code, it may give the attacker access to the device’s camera and
microphone.

Protecting Applications from Malicious Databases

SQLite databases are a common feature in many platforms and applications – iOS and Android use them and a host of different desktop applications.

As demonstrated by Gull, iOS Contacts, WhatsApp, FaceTime, Springboard, and Telegram all depend on a single database. They could be targeted by this attack and that’s why it’s so important to know the internals of a SQL server.

The use of a malicious SQL database to compromise legitimate applications is a significant security concern. The proof of concept created by Omer Gull clearly demonstrated that an attacker could bypass the security protections put in place by Apple to protect iOS products. While Apple has fixed the issues identified by Gull, the same is not necessarily true of various software products.

Applications that rely upon SQLite databases need to have the ability to monitor these databases and ensure that they have not been corrupted by hackers. Accomplishing this is an important component of a data security solution. By monitoring access to the database and scanning for any anomalous inputs, the solution can alert the organization if an attempt to corrupt an SQLite database (through SQL injection or other means) has been made.

Organizations may also want to consider using runtime application self-protection (RASP) to protect applications that rely on external sources of data (like SQLite databases).

RASP is designed to provide individualized protection of an application, monitoring its inputs, outputs, and behavior to identify any anomalies that could indicate an attack. For example, the malicious input stored in SQLite databases and used in this attack would definitely be anomalous and could be prevented using a RASP solution.

Databases have become a core component of many applications, and the power of the SQL language and the trust placed in these databases is often overlooked from a security perspective.

However, the new techniques described by Gull are only a taste of what is possible when misusing SQL, and organizations need to take the appropriate steps to secure their software and systems against these new types of attacks.