SQLite is a lightweight, self-contained database engine widely used in browsers, operating systems and mobile phones.
“SQLite is one of the most deployed software in the world. However, from a security perspective, it has only been examined through the lens of WebSQL and browser exploitation,” said Omer Gull, a vulnerability researcher at Check Point, at DEF CON on Saturday, adding that SQLite attack scenarios should be considered a “major cyber-threat.”
Check Point demonstrated at the show how an attack against SQLite could be used to bypass the iPhone’s secure boot mechanism in iOS by replacing the contacts database (AddressBook.sqlitedb) prior to reboot with a rogue database — leading to privilege escalation.
“We can gain administrative control of the device through the database engine that iOS uses (SQLite)… iPhone’s contacts are stored in SQLite databases and that is how a hacker gains entry,” said Gull. (See bottom of page for video demo of hack).
The overall attack technique targeting SQLite allows an attacker to take control of a SQLite database. “Any code, web or native, querying an attacker-controlled database might be in danger,” the researcher said.
While all SQLite issues were disclosed privately and patched (CVE-2019-8600, CVE-2019-8598, CVE-2019-8602, CVE-2019-8577) in the latest SQLite version along with iOS patches deployed in May by Apple (iOS 12.3), researchers said there are countless problematic scenarios that should give researchers pause.
Genesis of a SQLite Attack
The roots of Check Point’s unearthing of this new class of vulnerabilities traces back to work by researchers looking to backdoor password-stealing malware samples Azorult, Loki Bot and Pony.
“After the malware collects these SQLite files, it sends them to its [command-and-control] C2 server where they are parsed using PHP and stored in a collective database containing all of the stolen credentials,” researchers outlined in a technical paper. “Skimming through the leaked [malware] source code of such password-stealers, we started speculating about the attack surface described above.”
That attack surface was broken into two parts: “The load and initial parsing of our database, and the SELECT query performed against it,” wrote Check Point in a technical breakdown of its research.
Loading was straightforward enough. “Our surface is mainly the header parsing which is battle-tested against AFL,” researchers wrote.
The lightbulb over header parsing triggered insights into bytecode programming, in particular how sqlite3_prepare* routines and how Data Definition Language are used to describe an object. What Check Point calls this type of hack is “Query Hijacking and Query Oriented Programming” or simply a reliable way to exploit memory corruption issues in SQLite.
“Learning about this preparation process, we asked, can we simply replace the DDL that appears in plain-text within the file? If we could inject our own SQL to the file perhaps we can affect its behavior,” researchers noted.
The Exploit that Launched a Thousand Hacks
Fruits of that research including a host of hacks — including on iPhone.
“Persistency is hard to achieve on iOS as all executable files must be signed as part of Apple’s Secure Boot. Luckily for us, SQLite databases are not signed,” Check Point said. “Utilizing our new capabilities, we will replace one of the commonly used databases with a malicious version. After the device reboots and our malicious database is queried, we gain code execution.”
With that hack, disclosure and patches, researchers still insist they are barely scratching the tip of the iceberg when it comes to SQLite exploitation potential.
“We hope that the security community will take this innovative research and the tools released and push it even further,” they said.