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

El conocido investigador de Google Job No, Ian Beer, acaba de publicar una publicación que está atrayendo mucha atención.

El artículo tiene un título fascinante y preciso: Odisea del uso de la radio de proximidad sin clics para iPhone.

Sin embargo, titulares como el que hemos visto hasta ahora son los que describen la esencia práctica del ataque de Beer.

La serie de usos que descubrió permite a un asaltante robar un iPhone cercano y robar información personal, utilizando únicamente conexiones inalámbricas, sin necesidad de clics ni advertencias por parte del usuario inocente del dispositivo.

De hecho, el artículo de Beer termina con un breve vídeo que lo muestra tomando una foto automáticamente desde su propio teléfono utilizando un kit de hackeo instalado a continuación. Espacio:

• Toma una foto de un documento secreto con el iPhone en una habitación.
• Deja al usuario del teléfono (un oso de peluche rosa gigante, por cierto) sentado, disfrutando alegremente de un video de YouTube.
• Va a la casa de al lado e inicia un ataque automatizado por aire que utiliza un virus de kernel en el teléfono.
• El controlador introduce sigilosamente código malicioso en el teléfono, se otorga acceso al directorio de datos de la aplicación Fotos y revisa el archivo. Key’ documenta la foto y la publica discretamente en su portátil de al lado.
• El teléfono sigue funcionando con normalidad, sin advertencias, ventanas emergentes ni nada que pueda advertir al usuario del hackeo.

En la ubicación señales de keylogger en el móvil de nuestros artículos

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

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

Para que te hagas una idea de cuánto esfuerzo se invirtió en los 5 minutos de ‘; El videoclip de arriba sobre el robo de información de un oso de peluche. Como advertencia, si piensas examinar a fondo el excelente artículo de Beer, recuerda que su entrada de blog tiene más de 30 000 palabras, más extensa que el original Rebelión en el Rancho de George Orwell o Cuento de Navidad de Charles Dickens.

Seguro que te preguntas por qué Beer se molestó en usar un insecto que había descubierto y del que ya había informado, pero se esforzó tanto en convertirlo en un arma, usando la jerga paramilitar típica de la ciberseguridad.

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

Sino que debería ser: alguien, trabajando solo en su habitación, pudo desarrollar una habilidad que le permitiera poner en grave peligro a los usuarios de iPhone a los que accediera. En estrecho contacto con.

Para ser claros: Beer, a través de Google, reportó el error inicial sin demora, y sabemos que nadie más lo había descubierto antes que él, por lo que no hay indicios de que esta plaga haya sido manipulada por alguien en realidad.

Sin embargo, la cuestión es que es razonable asumir que una vez descubierto un desbordamiento de búfer a nivel de kernel, incluso con las reducciones de uso más recientes y óptimas, un enemigo identificado podría generar un exploit peligroso a partir de él.

Aunque los controles de seguridad, como la aleatorización del diseño de la sala de direcciones y los códigos de verificación de puntero, mejoran enormemente nuestra ciberseguridad, no son soluciones milagrosas por sí mismos.

Como lo expresa Mozilla con cierta ironía al abordar cualquier falla de administración de memoria en Firefox, también errores evidentemente moderados o arcanos que el equipo no pudo o no supo cómo explotar: ‘; Algunos de estos errores revelaron evidencia de corrupción de memoria y asumimos que, con el esfuerzo suficiente, varios de ellos podrían haber sido manipulados para ejecutar código aproximado.

En pocas palabras, descubrir errores es esencial; parchearlos es vital; aprender de nuestros errores es necesario; pero, aun así, debemos seguir desarrollando nuestras defensas 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 a continuación se presenta un resumen (probablemente demasiado simplificado) de solo algunas de las habilidades de hacking que utilizó:

• Encontrar un nombre de variable del kernel que sonaba peligroso. El nombre peculiar que lo originó todo fue IO80211AWDLPeer:: parseAwdlSyncTreeTLV, donde TLV describe tipo-longitud-valor, una forma de empaquetar datos complejos en un extremo para su deconstrucción (análisis) en el otro, y AWDL es la abreviatura de Apple Wireless Direct Web Link, la red inalámbrica en malla exclusiva utilizada para funciones de Apple como AirDrop. Este nombre de función indica la presencia de código complejo a nivel de kernel que está directamente expuesto a datos no confiables enviados desde otros dispositivos. Este tipo de código suele ser una fuente de errores de visualización insegura.
• Encontrando un problema en el código de manejo de datos TLV. Beer observó un problema en el que un objeto de datos TLV, restringido a un búfer de memoria de solo 60 bytes (10 direcciones MAC como máximo), se configuraba incorrectamente. Comprobado con una limitación de seguridad común de 1024 bytes, en lugar de con la dimensión real del búfer disponible.
• Construir una pila de controlador de red AWDL para crear paquetes dudosos. De hecho, Beer comenzó con un proyecto de código abierto existente que pretendía ser compatible con el código exclusivo de Apple, pero no logró que funcionara como necesitaba. Así que terminó creando el suyo propio.
• Encontrar una manera de que los paquetes que superan 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 varias comprobaciones preliminares parciales que dificultaron aún más el ataque. Por cierto, como señala Beer, es tentador, en código de bajo nivel, especialmente si es crucial para el rendimiento, asumir que la información no confiable ya se habrá depurado y, por lo tanto, limitar la comprobación de errores del código justo cuando más importa. ¡No lo hagas, sobre todo si ese código crucial permanece en el kernel!
• Descubriendo cómo convertir el desbordamiento del búfer en una corrupción de carga manejable. Esto proporcionó un método predecible y explotable para usar paquetes AWDL y forzar revisiones no autorizadas desde y hacia la memoria del kernel.
• Probando un total de 13 adaptadores Wi-Fi diferentes para encontrar una manera de colocar el ataque. Beer pretendía poder enviar paquetes AWDL contaminados en las redes Wi-Fi de 5 GHz ampliamente utilizadas hoy en día, por lo que necesitaba 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 sin éxito.

Con capacidades de lectura y escritura de bits, podía forzar remotamente la aplicación Calc para que apareciera en tu teléfono, siempre que tuvieras habilitada la red AWDL, por ejemplo, al usar el ‘;’ El símbolo “Compartir” en la app Fotos permite enviar tus datos por AirDrop.

Sin embargo, estaba decidido a convertir esto en un ataque sin clic, donde la víctima solo tiene que estar usando su teléfono en ese momento.

Como puedes imaginar, un ataque sin clic es mucho más dañino, ya que una persona informada no vería ninguna señal que advirtiera de un problema inminente.

• Aparentar ser un dispositivo cercano que ofrece archivos para compartir mediante AirDrop. Si tu teléfono cree que un dispositivo cercano podría ser uno de tus contactos, basándose en la información Bluetooth que transmite, iniciará temporalmente AWDL para confirmarlo. Si no está entre tus contactos, no verás ninguna ventana emergente ni ninguna otra advertencia, pero la plaga AWDL explotable quedará expuesta brevemente a través del subsistema AWDL activado inmediatamente.
• Al extender el ataque para que haga más que simplemente abrir una aplicación existente como Calc, Beer descubrió cómo usar su control inicial en una cadena de ataques completa que podría acceder a archivos arbitrarios en el dispositivo y robarlos.

En el video anterior, el ataque se apoderó de una aplicación que ya estaba ejecutándose (el oso de peluche estaba viendo YouTube, si recuerdas); liberó la aplicación de su entorno protegido para que ya no se limitara a ver su propia información; usó la aplicación para acceder al directorio DCIM (cámara) desde la aplicación Fotos; robó los datos de las fotos más recientes. Y después lo exfiltró utilizando una conexión TCP de apariencia inocente.

¡Guau!

¿Qué hacer?

Consejo 1. Asegúrate de contar con actualizaciones de seguridad actualizadas, ya que el virus en el centro de la cadena de ataques de Beer fue detectado y revelado por él mismo, por lo que ya está parcheado. Probablemente debas configurar la actualización general del software.

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

Idea 3. Nunca supongas que porque una plaga parezca “difícil” nunca será utilizada. Beer admite que esta fue difícil, realmente difícil, de usar, pero finalmente posible.

Idea 4. Si eres desarrollador, sé estricto con los datos. Nunca está de más realizar un buen seguimiento de errores.

Para todos los programadores: anticipen lo mejor; es decir, deseen que todos los que llamen a su código hayan comprobado si hay errores al menos una vez; pero prepárense para lo peor; es decir, asuman que no lo han hecho.