Bemutatásra került egy új sérülékenységkihasználási technika az SQLite-ban

A Check Point kutatói felfedték a DEF CON konferencián részletezték az új támadási technikákat, amelyek a sebezhető SQLite verziókat használó alkalmazásokat célozzák. A Check Point módszere a DB fájlokat potenciális lehetőségként kezeli a sebezhetőségek kihasználásához szükséges szkriptek integrálására a SQLite különböző belső alrendszereibe, amelyek nem érhetők el közvetlenül. A kutatók emellett kidolgozták a sebezhetőségek kihasználására szolgáló technikát, amely az exploitat SELECT lekérdezések láncának formájában kódolja a SQLite DB-ben, lehetővé téve az ASLR átugrását.

A sikeres támadáshoz szükséges, hogy a támadott alkalmazások DB fájljainak módosítására lehetőség legyen, ami korlátozza a módszert az SQLite DB-t tranzit- és bemeneti adatok formátumaként használó alkalmazások támadására. A módszer alkalmazható a már megszerzett helyi hozzáférés kiterjesztésére is, például rejtett hátsó bejáratok integrálására a használt alkalmazásokba, valamint a biztonsági kutatók által végzett ártalmas szoftverelemzés során a védelmi mechanizmusok megkerülésére. A fájl cseréje után a kihasználás a módosított DB táblához elsőként elküldött SELECT lekérdezés végrehajtásakor történik.

Példaként bemutatásra került, hogy lehetőség van kód futtatására iOS-en, amikor a címjegyzék megnyílik, és az AddressBook.sqlitedb fájlt a javasolt módszerrel módosították. A támadás egy sebezhetőséget használt ki az fts3_tokenizer funkcióban (CVE-2019-8602, pointer dereferálási lehetőség), amit a SQLite 2.28 áprilisi frissítésében javítottak ki, más sebezhetőségekkel együtt. sebezhetőség az ablakos funkciók megvalósításában. Ezen kívül bemutatásra került a módszer alkalmazása egy PHP backend szerver távoli átadásának megszerzésére, amely a kártevő kód végrehajtása során összegyűjtött jelszavakat tárolta (a lehallgatott jelszavakat SQLite DB formájában továbbították).

A támadási módszer két technikára, a „Query Hijackingra” és a „Query Oriented Programmingra” épül, amelyek lehetővé teszik önkényes problémák kihasználását, amelyek memória károsodást okoznak az SQLite motorjában. A „Query Hijacking” lényege a „sql” mező tartalmának megváltoztatása a sqlite_master segédtáblában, amely a DB struktúráját határozza meg. Az említett mező egy DDL (Data Definition Language) blokkot tartalmaz, amely az adatbázis objektumainak felépítését írja le. A leírás a szokásos SQL szintaxis használatával történik, azaz a „CREATE TABLE” konstrukciót alkalmazva.
amely a DB inicializálása során hajtódik végre (az első indításkor
a sqlite3LocateTable függvény) a táblához kapcsolódó belső struktúrák létrehozásához a memóriában.

Az ötlet az, hogy a „CREATE TABLE” kicserélésével „CREATE VIEW” -re lehetőséget teremt arra, hogy a saját nézet definícióján keresztül bármely adatbázisra vonatkozó hívást szabályozzunk. A „CREATE VIEW” a táblához kapcsol egy „SELECT” műveletet, amely a „CREATE TABLE” helyett hívódik meg, és lehetővé teszi a különböző SQLite értelmező részekhez való hozzáférést. A következő legegyszerűbb támadási módszer a „load_extension” függvény hívása lenne, amely lehetővé teszi egy tetszőleges kiterjesztésű könyvtár betöltését, de ez a funkció alapértelmezés szerint le van tiltva.

A támadás végrehajtásához, ahol engedélyezett a „SELECT” művelet végrehajtása, a „Query Oriented Programming” technikát javasolják, amely lehetővé teszi a SQLite-ban a memória károsodáshoz vezető problémák kihasználását. A technika hasonlít a visszakeresés-alapú programozásra (ROP, Return-Oriented Programming), de a hívási láncok („gadgetek”) felépítéséhez nem létező gépi kód darabokat használ, hanem beillesztéseket a SELECT belső lekérdezések halmazába.

Forrás: opennet.ru