den Check Point-forskere avslørte nylig i DEF-konferansen med detaljene av en ny teknikk som ble oppdaget, dette brukes sÅ angripe applikasjoner som bruker sårbare versjoner av SQLite.
Metoden Check Point anser databasefiler som en mulighet til å integrere sårbarhetsutnyttelsesscenarier i forskjellige interne SQLite-delsystemer som ikke er tilgjengelige for utnyttelse av pannen. Forskerne utviklet også en teknikk for å utnytte sårbarheter med utnytte koding i form av en streng med SELECT-spørsmål i en SQLite-database, som gjør at ASLR kan unngås.
Om sårbarhet
Check Point-forskerne detaljerer det For et vellykket angrep, må en angriper kunne endre databasefilene til de angrepne applikasjonene, som begrenser metoden for å angripe applikasjoner som bruker SQLite-databaser som format for transitt- og inndata.
Selv om de avslører også at metoden også kan brukes til å utvide den allerede oppnådde lokale tilgangen, for eksempel å integrere skjulte bakdører i applikasjonene som brukes, samt å unngå sikkerhetsforskere når de analyserer skadelig programvare.
Operasjonen etter filimitasjon utføres på det tidspunktet applikasjonen utfører den første SELECT-forespørselen til tabellen i den modifiserte databasen.
Som et eksempel ble evnen til å kjøre kode på iOS når du åpner adresseboken vist, filen med databasen «Adressebok.sqlitedb»Som ble modifisert ved hjelp av den foreslåtte metoden.
For angrepet, en sårbarhet ble brukt i funksjonen fts3_tokenizer (CVE-2019-8602, muligheten til å referere en peker), løst i oppdateringen av SQLite 2.28 i april, sammen med en annen sårbarhet i implementeringen av vindusfunksjoner.
Videre demonstrerer bruken av metoden for fjernkontrollbeslag av en backend-server fra angripere skrevet i PHP, som samler opp passord som er fanget opp under skadelig kodedrift (passordene som ble fanget opp, ble overført i form av en SQLite-database).
Angrepsmetoden er basert på bruk av to teknikker, Query Hijacking og Query Oriented Programming, som tillater vilkårlige problemer som fører til minnekorrupsjon i SQLite-motoren.
Essensen av "Spørringskapring" er å erstatte innholdet i "sql" -feltet i sqlite_master-tjenestetabellen som definerer databasestrukturen. Det angitte feltet inneholder DDL-blokken (Data Definition Language) som brukes til å beskrive strukturen til objektene i databasen.
Beskrivelsen er satt med vanlig SQL-syntaks, dvs. "CREATE TABLE" -konstruksjonen, som utføres under databaseinitialisering (under den første utførelsen av sqlite3LocateTable-funksjonen), brukes til å lage interne strukturer tilknyttet tabellen i minnet.
Tanken er at som et resultat av å erstatte "CREATE TABLE" og "CREATE VIEW, er det mulig å kontrollere tilgang til databasen gjennom definisjonen av dens syn.
På den annen side, ved bruk av "CREATE VIEW" -kommandoen, er en "SELECT" -operasjon festet til bordet, som vil bli kalt i stedet for "CREATE TABLE" og lar angriperen få tilgang til forskjellige deler av SQLite-tolken.
Foruten dette, vil den enkleste måten å angripe være å ringe "load_extension" -funksjonen, som gjør at angriperen kan laste et vilkårlig bibliotek med utvidelsen, men denne funksjonen er deaktivert som standard.
For å utføre et angrep under betingelsene for muligheten til å utføre SELECT-operasjonen, ble den spørreorienterte programmeringsteknikken foreslått, som tillater å utnytte problemer i SQLite som fører til minnekorrupsjon.
Teknikken minner om Return Oriented Programming (ROP), men bruker ikke-eksisterende maskinkodebiter, men settes inn i et sett med underspørsmål innen SELECT for å bygge en kjede av samtaler ("gadgets").
Fuente: https://threatpost.com/