I ricercatori dell'azienda Check Point alla conferenza DEF CON hanno fornito dettagli su una nuova tecnica di attacco alle applicazioni che utilizzano versioni vulnerabili di SQLite. 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, non accessibili per sfruttamenti diretti. I ricercatori hanno anche sviluppato una tecnica di sfruttamento delle vulnerabilità, codificando l'exploit sotto forma di una catena di query SELECT nel database SQLite, permettendo di eludere l'ASLR.
Per un attacco di successo è necessaria la possibilità di modificare i file del database delle applicazioni attaccate, il che limita il metodo agli attacchi su applicazioni che utilizzano SQLite come formato per i dati transitivi e in ingresso. Il metodo può anche essere applicato per estendere l'accesso locale già ottenuto, ad esempio per integrare backdoor nascoste nelle applicazioni in uso, così come per eludere i meccanismi di protezione durante l'analisi del malware. Lo sfruttamento dopo la sostituzione del file avviene al momento dell'esecuzione del primo SELECT da parte dell'applicazione sulla tabella nel database modificato.
Come esempio è stata dimostrata la possibilità di eseguire codice su iOS all'apertura della rubrica, il file del database "AddressBook.sqlitedb" del quale è stato modificato utilizzando il metodo proposto. Per l'attacco è stata utilizzata 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 nell'implementazione delle funzioni di finestra. Inoltre, è stata dimostrata l'applicazione del metodo per il controllo remoto di un server back-end scritto in PHP da parte degli aggressori, che accumulano password catturate durante il funzionamento del codice malevolo (le password catturate venivano trasmesse sotto forma di database SQLite).
Il metodo di attacco si basa sull'uso di due tecniche: «Query Hijacking» e «Query Oriented Programming», che consentono di sfruttare problemi arbitrari che portano a una corruzione della memoria nel motore SQLite. La sostanza del «Query Hijacking» consiste nella sostituzione del contenuto del campo «sql» nella tabella di sistema sqlite_master, che definisce la struttura del database. Questo campo contiene un blocco DDL (Data Definition Language) utilizzato per descrivere la struttura degli oggetti nel database. La descrizione è fornita utilizzando la sintassi SQL standard, ossia si impiega la costruzione «CREATE TABLE»,
che viene eseguita durante il processo di inizializzazione del database (al primo avvio
della funzione sqlite3LocateTable) per creare strutture interne collegate alla tabella in memoria.
L'idea è che, sostituendo «CREATE TABLE» con «CREATE VIEW», diventa possibile controllare qualsiasi accesso al database attraverso la definizione della propria vista. Con «CREATE VIEW», un'operazione «SELECT» viene associata alla tabella, che verrà invocata al posto di «CREATE TABLE» e consente di accedere a diverse parti dell'interprete SQLite. Un modo molto semplice per attaccare sarebbe invocare la funzione «load_extension», che consente di caricare una libreria arbitraria con un'estensione, ma questa funzione è disabilitata per impostazione predefinita.
Per eseguire l'attacco nelle condizioni di possibilità di eseguire l'operazione «SELECT» è stata proposta la tecnica «Query Oriented Programming», che offre la possibilità di sfruttare problemi in SQLite che portano a una corruzione della memoria. La tecnica assomiglia alla programmazione orientata al ritorno (, Return-Oriented Programming), ma utilizza per costruire una catena di chiamate (« Gadget ») frammenti di codice macchina non esistenti, ma inserimenti in un insieme di sottoquery all'interno di SELECT.
Fonte: opennet.ru
