Cómo robar fotos del iPhone de alguien del otro lado de la calle

El conocido proyecto de Google, el científico Ian Beer, acaba de publicar una publicación que está atrayendo mucha atención.

El artículo tiene un título muy preciso e intrigante: Una odisea de control remoto por radio sin clics para iOS.

Sin embargo, son títulos como el que hemos usado anteriormente los que captan la esencia práctica del ataque de Beer.

El sistema de control que ideó permite a un enemigo acceder a un iPhone cercano y robar información personal, utilizando únicamente conexiones inalámbricas, sin necesidad de clics ni advertencias por parte del usuario del dispositivo.

De hecho, el artículo de Beer concluye con un breve vídeo que lo muestra tomando automáticamente una foto de su teléfono. Paquete de hackeo instalado en la siguiente área:

• Toma una foto de un archivo secreto usando el iPhone en un espacio.
• Deja a la persona del teléfono (un oso de peluche rosa gigante, como se ve) sentada tranquilamente viendo un video de YouTube.
• Va a la casa de al lado e inicia un ataque automatizado por aire que usa un error del kernel del teléfono.
• El exploit publica sigilosamente código malicioso en el teléfono, le da acceso al directorio de datos de la aplicación Fotos y revisa el archivo. El archivo de imagen del truco y lo sube discretamente a su portátil de al lado.
• El teléfono sigue funcionando con normalidad, sin advertencias, ventanas emergentes ni nada que pueda alertar al usuario del ataque.

Más aquí cómo saber si la cámara del móvil está siendo usada En nuestra página web

Así que, si has actualizado tu iPhone en los últimos meses, deberías estar a salvo de este ataque en particular.

La otra buena noticia es que Beer, según él mismo admite, tardó seis meses de trabajo minucioso y dedicado en descubrir cómo explotar su propia plaga.

Para que te hagas una idea de cuánto esfuerzo se invirtió en los 5 minutos de ‘; El videoclip de la salida del oso de peluche para robar información ha terminado. Como advertencia, si piensas investigar a fondo la excelente publicación de Beer, ten en cuenta que su texto tiene más de 30 000 palabras, más extenso que el original Animal Ranch de George Orwell o Un cuento de Navidad de Charles Dickens.

Naturalmente, te preguntarás por qué Beer se molestó en usar un error que había descubierto y reportado, pero se tomó tanto esfuerzo para convertirlo en un arma, para usar la jerga paramilitar típica de la ciberseguridad.

Bueno, Beer da la respuesta él mismo, justo al principio de su artículo: La moraleja de este trabajo no debería ser: nadie dedicará seis meses de su vida solo para hackear mi teléfono, estoy bien.

Más bien, debería ser: alguien, trabajando solo en su habitación, pudo desarrollar una habilidad que le permitiría poner en grave peligro a los usuarios de iPhone que… Sin duda, han entrado en contacto cercano con ellos.

Para ser claros: Beer, a través de Google, reportó el error inicial inmediatamente, y, según entendemos, nadie más lo había descubierto antes que él, por lo que no hay indicios de que alguien lo haya explotado.

Sin embargo, la cuestión es que es razonable asumir que, una vez detectado un desbordamiento de búfer a nivel de kernel, incluso con las mejores y más actuales medidas de mitigación de errores, un atacante decidido podría generar un exploit peligroso a partir de él.

Aunque los controles de seguridad, como la aleatorización del diseño del espacio de direcciones y los códigos de verificación de punteros, aumentan enormemente nuestra ciberseguridad, no son soluciones milagrosas por sí solos.

Como Mozilla lo expresa con cierta ironía al reparar cualquier problema de gestión de memoria en Firefox, también errores aparentemente leves o arcanos que el grupo no pudo o no supo cómo explotar: ‘; Algunos de estos insectos mostraron evidencia de corrupción de memoria y presumimos que, con suficiente esfuerzo, algunos de ellos podrían haber sido manipulados para ejecutar código aproximado.

En pocas palabras, encontrar plagas es vital; ocultarlas es crucial; aprender de nuestros errores es esencial; sin embargo, debemos seguir mejorando nuestras herramientas de ciberseguridad en todo momento.

El camino hacia el ataque operativo de Beer

Es difícil hacer justicia a la obra maestra de Beer en un breve resumen como este, pero aquí hay una descripción (quizás demasiado simplificada) de algunas de las habilidades de hacking que utilizó:

• Encontrar un nombre de variable del kernel que sonaba de alto riesgo. El nombre original que lo inició todo fue IO80211AWDLPeer:: parseAwdlSyncTreeTLV, donde TLV describe tipo-longitud-valor, una forma de empaquetar información compleja en un extremo para su deconstrucción (análisis) en el otro, y AWDL es la abreviatura de Apple Wireless Direct Link, la red inalámbrica en malla propietaria utilizada para funciones de Apple como AirDrop. Este nombre de función implica la visibilidad de código complejo a nivel de kernel, directamente expuesto a información no confiable enviada desde otras herramientas. Este tipo de código suele ser fuente de descuidos peligrosos en programas.
• Descubrimiento de un error en el código de manejo de datos de TLV. Beer observó un punto en el que un objeto de información de TLV, restringido a una barrera de memoria de solo 60 bytes (10 direcciones MAC como máximo), se sincronizaba incorrectamente. Comprobado con un límite de seguridad común de 1024 bytes, en lugar de con el tamaño real del búfer disponible.
• Construir una pila de controlador de red AWDL para desarrollar paquetes dudosos. De hecho, Beer comenzó con una tarea de código abierto existente diseñada para ser compatible con el código propietario de Apple, pero no logró que funcionara como necesitaba. Así que terminó creando la suya propia.
• Encontrar una manera de que los paquetes que rompen el búfer superen las comprobaciones de seguridad existentes en otros lugares. Aunque el código del núcleo era defectuoso y no realizó correctamente su análisis de errores final, hubo numerosas comprobaciones preliminares parciales que dificultaron considerablemente el ataque. Por cierto, como explica Beer, es tentador, en código de bajo nivel, especialmente si es crítico para el rendimiento, asumir que la información no confiable ya se habrá depurado y, por lo tanto, escatimar en código de monitoreo de errores justo cuando más importa. ¡No lo hagas, sobre todo si ese código crítico está en el kernel!
• Saber cómo transformar el desbordamiento del búfer en una corrupción controlable de la pila. Esto proporcionó un enfoque predecible y explotable para usar paquetes AWDL para forzar accesos no autorizados desde y hacia la memoria del kernel.
• Probar un total de 13 adaptadores Wi-Fi diferentes para encontrar una forma de ubicar el ataque. Beer pretendía enviar paquetes AWDL envenenados en las redes Wi-Fi de 5 GHz que se usan comúnmente hoy en día, por lo que tuvo que encontrar un adaptador de red que pudiera reconfigurar para satisfacer sus necesidades.

Ahora, Beer ya había alcanzado un resultado de prueba de concepto donde la mayoría de nosotros nos habríamos quedado de brazos cruzados.

Con capacidades de lectura y escritura de bits, podía obligar remotamente a la aplicación Calc a iniciarse en el teléfono, siempre que se tuviera habilitada la red AWDL, por ejemplo, al usar el icono “Compartir” en la aplicación Fotos para enviar archivos por AirDrop.

Sin embargo, se sabía que lo convertía en un ataque sin clic, donde la víctima no tiene que hacer nada más que simplemente “;” Usando su teléfono en ese momento.

Como puede imaginar, un ataque sin clic es mucho más peligroso, ya que incluso un cliente bien informado no vería ninguna señal que advirtiera de un problema inminente.

• Hacerse pasar por un dispositivo cercano que ofrece archivos para compartir mediante AirDrop. Si su teléfono detecta que un dispositivo cercano podría estar entre sus llamadas, basándose en los datos de Bluetooth que está transfiriendo, iniciará brevemente AWDL para confirmarlo. Si no está entre sus llamadas, no verá ninguna ventana emergente ni advertencia, pero el subsistema AWDL activado automáticamente detectará brevemente el error explotable de AWDL.
• Extender el ataque para que haga más que simplemente abrir una aplicación existente como Calc. Beer identificó cómo usar su primer control en una extensa cadena de ataques que podría acceder a datos aproximados del dispositivo y robarlos.

En el video anterior, el ataque se apoderó de una aplicación que ya se estaba ejecutando (el oso de peluche estaba viendo YouTube, si recuerdan); liberó la aplicación del kernel para que ya no se limitara a ver sus propios datos; usó la aplicación para acceder al directorio DCIM (cámara) de la aplicación Fotos; robó el archivo de imagen actual; y luego lo exfiltró mediante un enlace TCP de apariencia inocente.
¡Guau!

¿Qué hacer?

Sugerencia 1: Asegúrese de contar con soluciones de seguridad actualizadas, ya que la plaga en el corazón de la cadena de ataques de Beer fue localizada y revelada por él mismo, por lo que ya está cubierta. Lo más probable es que se deba a la configuración de la actualización general del software.

Idea 2. Desactiva el Bluetooth cuando no lo necesites. El ataque de Beer es un buen ejemplo de que “menos es más”, ya que necesitaba Bluetooth para convertirlo en un ataque real sin clics.

Consejo 3. Nunca pienses que, porque un error parece “difícil”, nunca será explotado. Beer confiesa que este era difícil, muy difícil, de manipular, pero en última instancia no imposible.

Idea 4. Si eres desarrollador, sé estricto con los datos. Nunca está de más realizar una buena comprobación de errores.
Para todos los programadores: espera lo mejor, es decir, desea que todos los que llaman a tu código hayan buscado errores al menos una vez; pero prepárate para lo peor, es decir, asume que no lo han hecho.