En ny teknik för att utnyttja sårbarheter i SQLite har introducerats.

Forskare från Check Point avslöjats på DEF CON-konferensen, detaljer om en ny attackteknik på applikationer som använder sårbara versioner av SQLite. Check Point-metoden betraktar databasfiler som en möjlighet att integrera scenarier för att utnyttja sårbarheter i olika interna SQLite-undersystem som inte är direkt exploaterbara. Forskare har också förberett en teknik för att utnyttja sårbarheter genom att koda exploateringen i form av en kedja av SELECT-frågor i SQLite-databasen, vilket gör att du kan kringgå ASLR.

För en framgångsrik attack är det nödvändigt att kunna modifiera databasfilerna för de attackerade applikationerna, vilket begränsar metoden till attacker på applikationer som använder SQLite-databasen som ett format för överföring och indata. Metoden kan också användas för att utöka befintlig 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 programvara av säkerhetsforskare. Operation efter filsubstitution utförs i det ögonblick som applikationen kör den första SELECT-frågan mot en tabell i den modifierade databasen.

Som ett exempel visade vi möjligheten att köra kod i iOS när du öppnade en adressbok, filen med databasen "AddressBook.sqlitedb" modifierades med den föreslagna metoden. Attacken använde en sårbarhet i fts3_tokenizer-funktionen (CVE-2019-8602, pekarereferensmöjlighet), fixad i April SQLite 2.28-uppdateringen, tillsammans med en annan sårbarhet vid implementering av fönsterfunktioner. Dessutom demonstrerades användningen av en metod för att på distans ta kontroll över en angripares backend-server skriven i PHP, som ackumulerar lösenord som fångas upp under driften av skadlig kod (de fångade lösenorden överfördes i form av en SQLite-databas).

Attackmetoden är baserad på användningen av två tekniker "Query Hijacking" och "Query Oriented Programming", som tillåter utnyttjande av godtyckliga problem som leder till minneskorruption i SQLite-motorn. Kärnan i "Query Hijacking" är att ersätta innehållet i "sql"-fältet i sqlite_master-tjänsttabellen, som bestämmer strukturen på databasen. Det angivna fältet innehåller ett DDL-block (Data Definition Language) som används för att beskriva strukturen för objekt i databasen. Beskrivningen specificeras med standard SQL-syntax, dvs. konstruktionen "CREATE TABLE" används,
som exekveras under databasinitieringsprocessen (under den första lanseringen
sqlite3LocateTable-funktioner för att skapa tabellrelaterade interna strukturer i minnet.

Tanken är att, som ett resultat av att ersätta “CREATE TABLE” med “CREATE VIEW”, blir det möjligt att kontrollera all åtkomst till databasen genom att definiera din egen vy. Genom att använda "CREATE VIEW" binds en "SELECT"-operation till tabellen, som kommer att anropas istället för "CREATE TABLE" och låter dig komma åt olika delar av SQLite-tolken. Därefter skulle den enklaste attackmetoden vara att anropa funktionen "load_extension", som låter dig ladda ett godtyckligt bibliotek med en tillägg, men denna funktion är inaktiverad som standard.

För att utföra en attack när det är möjligt att utföra "SELECT"-operationen, föreslås tekniken "Query Oriented Programming", som gör det möjligt att utnyttja problem i SQLite som leder till minneskorruption. Tekniken påminner om returorienterad programmering (R.O.P., returorienterad programmering), men använder inte befintliga fragment av maskinkod för att bygga en kedja av anrop ("prylar"), utan infogar i en uppsättning underfrågor i SELECT.

Källa: opennet.ru