Proyecto popular de Google. El investigador Ian Beer ha publicado una entrada de blog que está atrayendo mucha atención.
La entrada tiene un título muy preciso e intrigante: Una odisea de exploit de radio a distancia sin clics para iOS.
Sin embargo, son títulos como el que hemos usado anteriormente los que captan la esencia del ataque de Beer.
La serie de manipulaciones que descubrió permite a un atacante 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 robando una foto de su teléfono usando el siguiente truco de hackeo. Espacio:
- Toma una foto de un archivo secreto con el iPhone en una zona.
- Deja a la persona del teléfono (un oso de peluche rosa gigante, por lo visto) sentada disfrutando alegremente de un vídeo de YouTube.
- Va a la casa de al lado y lanza un ataque inalámbrico automatizado que utiliza un pequeño fallo del teléfono.
- El usuario introduce sigilosamente código malicioso en el teléfono, se concede acceso al directorio de datos de la aplicación Fotos y revisa el archivo. clave’ y los publica secretamente en 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í eliminar keylogger de tu móvil En nuestra página web
Así que, si has cambiado de 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 exhaustivo y dedicado en descubrir cómo explotar su propio virus.
Para que te hagas una idea de la cantidad de esfuerzo invertido en los 5 minutos de ‘; El videoclip del picnic de robo de datos del oso de peluche ha terminado. Como advertencia, si piensas estudiar a fondo la excepcional publicación de Beer, recuerda que su blog tiene más de 30 000 palabras, más extensa que la original Rebelión en la granja de George Orwell o Un cuento de Navidad de Charles Dickens.
Obviamente, te estarás preguntando por qué Beer se molestó en tomar un insecto que ya había encontrado y denunciado, pero se esforzó tanto en convertirlo en un arma, por usar la jerga paramilitar común en ciberseguridad.
Bueno, Beer da la respuesta él mismo, justo al principio de su artículo: La conclusión de este proyecto no debería ser: nadie invertirá seis meses de su vida solo para hackear mi teléfono, estoy bien.
En cambio, debería ser: una sola persona, trabajando sola en su habitación, fue capaz de desarrollar una habilidad que le permitiría comprometer seriamente a los usuarios de iPhone con los que entrara en contacto. con.
Para que quede claro: Beer, a través de Google, reportó la plaga original sin demora, y sabemos que nadie más la había descubierto antes que él, por lo que no hay indicios de que alguien la haya usado en la vida real.
Sin embargo, es razonable pensar que una vez que se descubre un desbordamiento de la barrera a nivel de kernel, incluso ante las reducciones de uso más recientes y mayores, un enemigo decidido podría crear 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 autenticación de las directrices, mejoran enormemente nuestra ciberseguridad, no son soluciones milagrosas por sí solos.
Como Mozilla, en cambio, lo expresa secamente al reparar cualquier fallo de gestión de memoria en Firefox, incluyendo errores aparentemente leves o misteriosos que el equipo no pudo o no supo cómo solucionar: ‘; Varias de estas plagas revelaron evidencia de corrupción de memoria y presumimos que, con la iniciativa adecuada, varias de ellas podrían haber sido explotadas para ejecutar código arbitrario.
Básicamente, encontrar errores es esencial; parchearlos es importante; aprender de nuestros errores es necesario; sin embargo, debemos seguir mejorando nuestras protecciones de ciberseguridad en todo momento.
El camino hacia el éxito operativo de Beer
Es difícil hacer justicia a la obra maestra de Beer en un resumen breve 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 parecía de alto riesgo. El nombre de moda que lo inició todo fue IO80211AWDLPeer:: parseAwdlSyncTreeTLV, donde TLV se refiere a tipo-longitud-valor, un método para 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 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, directamente expuesto a información no confiable enviada desde otros dispositivos. Este tipo de código suele ser una fuente de errores de visualización insegura.
- Descubrimiento de un error en el código de procesamiento de datos TLV. Beer observó un problema en el que un objeto de información TLV, limitado a una barrera de memoria de tan solo 60 bytes (10 direcciones MAC como máximo), se configuraba incorrectamente. Comprobado por longitud frente a una restricción de seguridad común de 1024 bytes, en lugar de compararlo con el tamaño real del búfer disponible.
- Construir una pila de controladores de red AWDL para desarrollar paquetes dudosos. De hecho, Beer comenzó con un proyecto de código abierto existente que pretendía ser compatible con el código propietario 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, en consecuencia, limitar el código de monitorización de errores justo cuando más importa. ¡No lo hagas, sobre todo si ese código crítico permanece en la memoria de bits!
- Comprender cómo transformar el desbordamiento del búfer en una corrupción controlada de la pila. Esto proporcionó un enfoque predecible y explotable para usar paquetes AWDL y forzar comprobaciones y escrituras no autorizadas en la memoria de bits.
- Probar un total de 13 adaptadores Wi-Fi diferentes para encontrar una manera de evitar el ataque. Beer querí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 muchos de nosotros nos habríamos quedado sin éxito.
Con capacidades de lectura y escritura de bits, puede forzar remotamente la aplicación Calc para que se inicie en tu teléfono, siempre que tengas habilitada la red AWDL, por ejemplo, al usar el ‘;’ El icono “Compartir” en la app Fotos permite enviar tus archivos por AirDrop.
Sin embargo, se descubrió que lo convertía en un supuesto ataque sin clic, donde la víctima solo tiene que estar usando su teléfono.
Como puedes imaginar, un ataque sin clic es mucho más peligroso, ya que incluso una persona bien informada no detectaría ninguna señal que advirtiera de un problema grave.
- Hacerse pasar por un dispositivo cercano que ofrece archivos para compartir mediante AirDrop. Si tu teléfono detecta que un dispositivo cercano podría estar entre tus contactos, basándose en la información Bluetooth que transmite, iniciará temporalmente AWDL para confirmarlo. Si no es uno de tus contactos, no verás ninguna ventana emergente ni advertencia, pero la plaga AWDL explotable se expondrá brevemente a través del subsistema AWDL activado inmediatamente.
- Extendiendo el ataque para que hiciera más que simplemente activar una aplicación existente como Calc, Beer descubrió cómo usar su control inicial en una cadena de ataque exhaustiva que podría acceder a documentos duplicados 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 desde el kernel para que ya no se limitara a ver sus propios datos; usó la aplicación para acceder al directorio DCIM (cámara) desde la aplicación Fotos; tomó el archivo de imagen actual. Y luego lo exfiltró usando una conexión TCP aparentemente inocente.
¡Guau!
¿Qué hacer?
Sugerencia 1. Asegúrate de estar al día con las soluciones de seguridad, 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. Ve a Configuración de Actualización General del Software.
Consejo 2. Desactiva el Bluetooth cuando no lo necesites. El ataque de Beer es un gran ejemplo de que “menos es más”, ya que necesitaba Bluetooth para convertirlo en un ataque real sin clics.
Consejo 3. Nunca asumas que porque una plaga parece “difícil” nunca será manipulada. Beer confiesa que esta era difícil, muy difícil, de manipular, pero inevitablemente posible.
Sugerencia 4. Si eres desarrollador, sé estricto con la información. Nunca es mala idea realizar un buen monitoreo de errores.
Para todos los programadores disponibles: esperen lo mejor, es decir, deseen que todos los que llaman a su código hayan revisado los errores al menos una vez; pero prepárense para lo peor, es decir, supongan que no lo han hecho.