masse Check Point-forskere afslørede for nylig på DEF-konferencen med detaljerne af en ny teknik, der blev opdaget, dette bruges sAt angribe applikationer, der bruger sårbare versioner af SQLite.
Metoden Check Point ser databasefiler som en mulighed for at integrere sårbarhedsudnyttelsesscenarier i forskellige interne SQLite-undersystemer, der ikke er tilgængelige til pandeudnyttelse. Forskerne udviklede også en teknik til at udnytte sårbarheder med udnyttelseskodning i form af en række SELECT-forespørgsler i en SQLite-database, som gør det muligt at undgå ASLR.
Om sårbarhed
Check Point-forskerne beskriver det for et vellykket angreb skal en angriber være i stand til at ændre databasefilerne for de angrebne applikationer, som begrænser metoden til at angribe applikationer, der bruger SQLite-databaser som format til transit- og inputdata.
Selvom de afslører også, at metoden også kan bruges til at udvide allerede opnået lokal adgang, for eksempel at integrere skjulte bagdøre i de anvendte applikationer samt at undgå sikkerhedsforskere, når de analyserer malware.
Handlingen efter filefterligning udføres på det tidspunkt, hvor applikationen udfører den første SELECT-anmodning til tabellen i den ændrede database.
Som et eksempel blev evnen til at køre kode på iOS ved åbning af adressebogen demonstreret, filen med databasen «Adressebog.sqlitedb»Som blev ændret ved hjælp af den foreslåede metode.
Til angrebet en sårbarhed blev brugt i funktionen fts3_tokenizer (CVE-2019-8602, muligheden for at afvige en markør), fast i opdateringen af SQLite 2.28 i april sammen med en anden sårbarhed i implementeringen af vinduesfunktioner.
Derudover demonstrerer brugen af metoden til fjernstyring af en backend-server fra angribere skrevet i PHP, som akkumulerer opfangede adgangskoder under ondsindet kodehandling (de aflyttede adgangskoder blev overført i form af en SQLite-database).
Angrebsmetoden er baseret på brugen af to teknikker, Query Hijacking og Query Oriented Programming, som gør det muligt at udnytte vilkårlige problemer, der fører til hukommelseskorruption i SQLite-motoren.
Essensen af "Forespørgselkapring" er at erstatte indholdet af feltet "sql" i servicetabellen sqlite_master, der definerer databasestrukturen. Det angivne felt indeholder DDL-blokken (Data Definition Language), der bruges til at beskrive strukturen af objekterne i databasen.
Beskrivelsen indstilles ved hjælp af normal SQL-syntaks, dvs. "CREATE TABLE" -konstruktionen, som udføres under databaseinitialisering (under den første udførelse af sqlite3LocateTable-funktionen), bruges til at oprette interne strukturer, der er knyttet til tabellen i hukommelsen.
Ideen er, at som et resultat af at erstatte "CREATE TABLE" og "CREATE VIEW, er det muligt at kontrollere enhver adgang til databasen gennem definitionen af dens visning.
På den anden side er der ved brug af kommandoen "CREATE VIEW" knyttet en "SELECT" -operation til tabellen, som kaldes i stedet for "CREATE TABLE" og giver angriberen adgang til forskellige dele af SQLite-tolken.
Udover dette er den nemmeste måde at angribe på at kalde "load_extension" -funktionen, som gør det muligt for angriberen at kunne indlæse et vilkårligt bibliotek med udvidelsen, men denne funktion er som standard deaktiveret.
For at udføre et angreb under betingelserne for evnen til at udføre SELECT-operationen blev den forespørgselsorienterede programmeringsteknik foreslået, som muliggør udnyttelse af problemer i SQLite, der fører til hukommelseskorruption.
Teknikken minder om Return Oriented Programming (ROP), men bruger ikke-eksisterende maskinkodestykker, men indsættes i et sæt underforespørgsler inden for SELECT for at oprette en kæde af opkald ("gadgets").
kilde: https://threatpost.com/