Forskere fra Check Point præsenterede detaljer om en ny angrebsteknik rettet mod applikationer, der bruger sårbare versioner af SQLite, på DEF CON-konferencen. Check Point's metode betragter databaser som en mulighed for at integrere udnyttelsesscenarier i forskellige interne systemer i SQLite, som ikke kan udnyttes direkte. Forskerne har også udviklet en teknik til at udnytte sårbarheder ved at kode exploiten som en kæde af SELECT-forespørgsler til SQLite-databasen, hvilket gør det muligt at omgå ASLR.
For et vellykket angreb er det nødvendigt at have mulighed for at modificere databasefilerne i de angrebne applikationer, hvilket begrænser metoden til angreb på applikationer, der bruger SQLite-databaseformatet til transit- og indsendelsesdata. Metoden kan også bruges til at udvide allerede opnået lokal adgang, f.eks. ved at integrere skjulte bagdøre i de anvendte applikationer samt for at omgå sikkerhedsmekanismen under analysen af malware. Udnyttelsen efter filendringen sker, når applikationen udfører sin første SELECT-forespørgsel til tabellen i den modificerede database.
Som eksempel blev muligheden for at køre kode i iOS demonstreret ved åbning af adressebogen, hvis databasefil 'AddressBook.sqlitedb' var ændret ved hjælp af den foreslåede metode. Angrebet udnyttede en sårbarhed i funktionen fts3_tokenizer (CVE-2019-8602, mulighed for pointerdereferering), der blev rettet i SQLite-opdateringen i april 2.28, sammen med en anden i implementeringen af vinduesfunktioner. Derudover blev det demonstreret, hvordan metoden kunne bruges til at overtage kontrol over en PHP-baseret backend-server fra angribere, der indsamlede adgangskoder, der blev opsnappet under udførelsen af malware (de opsnappede adgangskoder blev sendt i form af en SQLite-database).
Angrebsmetoden er baseret på brugen af to teknikker: «Query Hijacking» og «Query Oriented Programming», der muliggør udnyttelse af vilkårlige problemer, som fører til hukommelsesskader i SQLite-motoren. Essensen af «Query Hijacking» er at ændre indholdet af feltet «sql» i systemtabellen sqlite_master, som definerer databasens struktur. Det nævnte felt indeholder en DDL-blok (Data Definition Language), der bruges til at beskrive strukturen af objekter i databasen. Beskrivelsen angives ved hjælp af standard SQL-syntaks, dvs. konstruktionen «CREATE TABLE»,
som udføres under initialiseringen af databasen (ved første opstart,
funktionen sqlite3LocateTable) for at skabe tilknyttede interne strukturer i hukommelsen.
Ideen er, at ved at erstatte «CREATE TABLE» med «CREATE VIEW» opstår der mulighed for gennem definitionen af ens eget view at kontrollere enhver tilgang til databasen. Gennem «CREATE VIEW» knyttes en «SELECT»-operation til tabellen, som vil blive kaldt i stedet for «CREATE TABLE» og muliggør adgang til forskellige dele af SQLite-fortolkerens funktionalitet. Dernæst ville den enkleste angrebsmetode være at kalde funktionen «load_extension», som tillader indlæsning af en vilkårlig udvidelsesbibliotek, men denne funktion er som standard deaktiveret.
For at udføre angrebet under betingelserne for muligheden for at udføre «SELECT»-operationen er der blevet foreslået en teknik kaldet «Query Oriented Programming», der giver mulighed for at udnytte problemer i SQLite, der fører til hukommelsesskader. Teknikken ligner return-oriented programming (, Return-Oriented Programming), men bruger ikke eksisterende fragmenter af maskinkode til at opbygge kæder af kald («gadgets»), men i stedet indsættelser i et sæt underforespørgsler inden for SELECT.
Kilde: opennet.ru
