mycket Check Point-forskare avslöjade nyligen på DEF CON-konferensen detaljerna av en ny teknik som upptäcktes, detta används sidAtt attackera applikationer som använder sårbara versioner av SQLite.
Metoden Check Point ser databasfiler som en möjlighet att integrera scenarier för sårbarhetsexploatering i olika interna SQLite-undersystem som inte är tillgängliga för front-end-exploatering. Forskarna förberedde också en teknik för att utnyttja sårbarheter med exploateringskodning i form av en SELECT-frågesträng på en SQLite-databas, vilket tillåter ASLR-bypass.
Om sårbarhet
Check Point-forskare beskriver det För en framgångsrik attack måste en angripare kunna modifiera databasfilerna för de attackerade programmen., vilket begränsar metoden för att attackera applikationer som använder SQLite-databaser som format för överföring och indata.
Fastän de avslöjar också att metoden också kan användas för att utöka lokal tillgång som redan erhållits, till exempel för att integrera dolda bakdörrar i de applikationer som används, samt att kringgå säkerhetsforskare när de skannar efter skadlig programvara.
Operationen efter personifiering utförs vid den tidpunkt då applikationen exekverar den första SELECT-begäran till tabellen i den ändrade databasen.
Som ett exempel visades möjligheten att köra kod på iOS när du öppnar adressboken, filen med databasen «Adressbok.sqlitedb» som modifierades med den föreslagna metoden.
För attacken, en sårbarhet användes i fts3_tokenizer-funktionen (CVE-2019-8602, möjligheten att avreferera en pekare), fixad i SQLite 2.28 April-uppdateringen, tillsammans med en annan sårbarhet i implementeringen av fönsterfunktioner.
Dessutom, demonstrerar användningen av metoden för fjärrkontroll av 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 definierar databasstrukturen. Det angivna fältet innehåller DDL-blocket (Data Definition Language) som används för att beskriva strukturen för objekten i databasen.
Beskrivningen ställs in med normal SQL-syntax, dvs. "CREATE TABLE"-konstruktionen, som utförs under databasinitiering (under den första exekveringen av sqlite3LocateTable-funktionen), används för att skapa interna strukturer associerade med tabellen i minnet.
Tanken är att som ett resultat av att ersätta "CREATE TABLE" och "CREATE VIEW, är det möjligt att kontrollera all åtkomst till databasen genom dess vydefinition.
För sin del genom att använda kommandot "CREATE VIEW" är en "SELECT"-operation kopplad till tabellen, som kommer att anropas istället för "CREATE TABLE" och låter angriparen komma åt olika delar av SQLite-tolken.
Förutom detta skulle det enklaste sättet att attackera vara att anropa funktionen "load_extension", som gör att angriparen kan ladda ett godtyckligt bibliotek med tillägget, men denna funktion är inaktiverad som standard.
För att utföra en attack under villkoren för möjligheten att utföra SELECT-operationen, föreslogs den frågeorienterade programmeringstekniken, som tillåter utnyttjande av problem i SQLite som leder till minneskorruption.
Tekniken påminner om Return Oriented Programming ( ROP ), men använder icke-existerande snippar av maskinkod, men infogas i en uppsättning delfrågor inom en SELECT för att bygga en kedja av anrop ("prylar").
Fuente: https://threatpost.com/