Ny teknik för utnyttjande av sårbarheter i SQLite har presenterats

Forskare från Check Point koden vid DEF CON-konferensen detaljerade en ny metod för attacker mot applikationer som använder sårbara versioner av SQLite. Check Points metod betraktar databasfiler som en möjlighet för integration av exploateringsscenarier i olika interna SQLite-underhållssystem, som inte kan utnyttjas direkt. Forskare har även förberett en exploateringsteknik med kodning av exploiten i form av en kedja av SELECT-frågor i SQLite-databasen, vilket möjliggör omväg kring ASLR.

För en framgångsrik attack behöver det finnas möjlighet att modifiera databaserna i de attackerade applikationerna, vilket begränsar metoden till attacker mot applikationer som använder SQLite-databasen som format för transit- och indata. Metoden kan också tillämpas för att utöka redan upparbetad lokal åtkomst, till exempel för att integrera dolda bakdörrar i använda applikationer, samt för att kringgå säkerhetsmekanismer vid analys av skadlig kod. Utnyttjandet efter filmodifikation sker vid applikationens första SELECT-fråga mot tabellen i den modifierade databasen.

Som exempel visades möjligheten att köra kod i iOS när kontaktboken öppnades, där filen 'AddressBook.sqlitedb' hade ändrats med hjälp av den föreslagna metoden. En sårbarhet i funktionen fts3_tokenizer (CVE-2019-8602, möjlighet till pekaromväxling) utnyttjades för attacken, som åtgärdades i apriluppdateringen av SQLite 2.28, tillsammans med en annan sårbarhet i implementeringen av fönsterfunktioner. Dessutom demonstrerades metodens tillämpning för att på distans få kontroll över en PHP-baserad backend-server som angriparna använder för att samla in lösenord, som fångats under körning av skadlig kod (de fångade lösenorden skickades i form av SQLite-databas).

Attacken baseras på användningen av två tekniker: "Query Hijacking" och "Query Oriented Programming", som gör det möjligt att utnyttja olika problem som leder till minneskorruption i SQLite-motorn. Kärnan i "Query Hijacking" är att ersätta innehållet i fältet "sql" i den systemtabell som heter sqlite_master, vilket definierar strukturen för databasen. Det angivna fältet innehåller en DDL-block (Data Definition Language) som används för att beskriva strukturen på objekten i databasen. Beskrivningen görs med den vanliga SQL-syntaxen, dvs. konstruktionen "CREATE TABLE".
som exekveras vid initialiseringen av databasen (vid första start
funktionen sqlite3LocateTable) för att skapa interna strukturer i minnet kopplade till tabellen.

Idén är att, genom att byta ut "CREATE TABLE" mot "CREATE VIEW", skapa möjlighet att, genom definitionen av sin egen vy, kontrollera alla anrop till databasen. Genom "CREATE VIEW" kopplas en "SELECT"-operation till tabellen, som kommer att anropas istället för "CREATE TABLE" och gör det möjligt att komma åt olika delar av SQLite-tolkaren. Det enklaste sättet att attackera skulle vara att anropa funktionen "load_extension", som gör att en godtycklig utvidgningsbibliotek kan laddas, men denna funktion är som standard avstängd.

För att genomföra attacken med möjlighet att utföra operationen "SELECT" föreslås tekniken "Query Oriented Programming", vilket möjliggör att utnyttja problem i SQLite som leder till minneskorruption. Tekniken påminner om återvändorienterad programmering (ROP, Return-Oriented Programming), men använder för att bygga kedjor av anrop ("gadgets") icke-existerande fragment av maskinkod, utan insättningar i en uppsättning underfrågor inom SELECT.

Källa: opennet.ru