I ricercatori dell'azienda Check Point hanno fornito dettagli sulla nuova tecnica di attacco alle applicazioni che utilizzano versioni vulnerabili di SQLite durante la conferenza DEF CON. Il metodo di Check Point considera i file del database come un'opportunità per integrare script di sfruttamento delle vulnerabilità in vari sottosistemi interni di SQLite, inaccessibili per sfruttamento diretto. I ricercatori hanno inoltre sviluppato una tecnica di sfruttamento delle vulnerabilità mediante la codifica dell'exploit in forma di catena di query SELECT nel database SQLite, permettendo di bypassare ASLR.
Per un attacco di successo è necessaria la capacità di modificare i file del database delle applicazioni bersaglio, il che limita il metodo agli attacchi su applicazioni che utilizzano SQLite come formato per i dati transitori e in ingresso. Questo metodo può anche essere utilizzato per ampliare l'accesso locale già ottenuto, ad esempio, per integrare backdoor nascoste nelle applicazioni utilizzate, nonché per eludere i meccanismi di protezione durante l'analisi del malware. L'esecuzione dopo la sostituzione del file avviene nel momento in cui l'applicazione esegue la prima SELECT query sulla tabella nel database modificato.
Come esempio, è stata dimostrata la possibilità di eseguire codice su iOS aprendo la rubrica, il cui file del database "AddressBook.sqlitedb" è stato modificato utilizzando il metodo proposto. Per l'attacco è stata sfruttata una vulnerabilità nella funzione fts3_tokenizer (CVE-2019-8602, possibilità di dereferenziare un puntatore), corretta nell'aggiornamento di aprile di SQLite 2.28, insieme a un'altra nella realizzazione delle funzioni di finestra. Inoltre, è stata dimostrata l'applicazione del metodo per il controllo remoto del backend server PHP da parte di malintenzionati, che accumulano password intercettate durante l'esecuzione di codice dannoso (le password intercettate venivano trasmesse in forma di database SQLite).
Il metodo d'attacco si basa sull'uso di due tecniche, "Query Hijacking" e "Query Oriented Programming", che consentono di sfruttare vulnerabilità arbitrarie che portano a problemi di corruzione della memoria nel motore SQLite. La natura del "Query Hijacking" consiste nella sostituzione del contenuto del campo "sql" nella tabella di sistema sqlite_master, che definisce la struttura del database. Il campo specificato contiene un blocco DDL (Data Definition Language), utilizzato per descrivere la struttura degli oggetti nel database. La descrizione è fornita utilizzando la sintassi SQL standard, ad esempio viene utilizzata la costruttiva "CREATE TABLE",
che viene eseguita durante l'inizializzazione del database (al momento del primo avvio
della funzione sqlite3LocateTable) per creare strutture interne associate alla tabella nella memoria.
L'idea è che, sostituendo "CREATE TABLE" con "CREATE VIEW", si possa controllare qualsiasi accesso al database definendo la propria vista. Con "CREATE VIEW" si associa un'operazione di "SELECT" alla tabella, che sarà invocata al posto di "CREATE TABLE", permettendo di accedere a diverse parti dell'interprete SQLite. Il modo più semplice per attaccare sarebbe chiamare la funzione "load_extension", che consente di caricare una libreria arbitraria con estensione, ma questa funzione è disabilitata per impostazione predefinita.
Per attuare un attacco nel contesto della possibilità di eseguire l'operazione "SELECT", è stata proposta la tecnica "Query Oriented Programming" che consente di sfruttare i problemi in SQLite, portando a danni alla memoria. La tecnica assomiglia alla programmazione orientata ai ritorni (, Return-Oriented Programming), ma utilizza, per costruire una catena di chiamate ("gadget"), frammenti di codice macchina non esistenti, ma inserti in un insieme di sottoquery all'interno di SELECT.
Fonte: opennet.ru
