El popular científico de Google Ian Beer acaba de publicar una entrada de blog que está atrayendo mucha atención mediática.
La entrada tiene un título muy preciso e interesante: Odisea de un iPhone con radio de proximidad sin clic.
Pero son titulares como el que hemos usado anteriormente los que reflejan la importancia del ataque de Beer.
La secuencia de control que identificó permite a un atacante acceder a un iPhone cercano y robar datos personales, utilizando únicamente conexiones inalámbricas, sin necesidad de clics ni advertencias por parte del usuario inocente del dispositivo.
Sin duda, el artículo de Beer termina con un breve vídeo que lo muestra tomando una foto de su propio teléfono utilizando un kit de hackeo instalado en la siguiente imagen. Espacio:
- Toma una foto de un archivo secreto usando el iPhone en una zona.
- Deja al usuario del teléfono (un oso de peluche rosa gigante, por cierto) descansando felizmente mientras ve un video de YouTube.
- Va a la casa de al lado y lanza un ataque automatizado por aire que manipula un error del kernel del teléfono.
- El usuario introduce sigilosamente código malicioso en el teléfono, se otorga acceso al directorio de datos de la aplicación de imágenes y revisa el archivo. Key’ documenta la foto y la sube secretamente a su computadora portátil de al lado.
- El teléfono sigue funcionando con normalidad, sin advertencias, ventanas emergentes ni nada que pueda alertar al usuario del hackeo.
Siga este enlace señales de keylogger en el móvil 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ó 6 meses de trabajo exhaustivo y especializado en descubrir cómo manipular su propio virus.
Para que te hagas una idea de cuánto esfuerzo se invirtió en los 5 minutos de ‘; El videoclip del picnic de robo de datos del oso de peluche ha terminado. Como advertencia, si está considerando examinar el excepcional artículo de Beer en detalle, recuerde que su entrada de blog tiene más de 30 000 palabras, más extensa que la original Rebelión en el Rancho de George Orwell o Un Cuento de Navidad de Charles Dickens.
Claro que se estará preguntando por qué Beer se molestó en tomar un insecto que ya había localizado y reportado, pero se tomó la molestia de convertirlo en un arma, de usar la jerga paramilitar típica de la ciberseguridad.
Bueno, Beer da la respuesta él mismo, justo al comienzo de su artículo: La moraleja de este trabajo no debería ser: nadie invertirá seis meses de su vida solo para hackear mi teléfono, estoy bien.
En cambio, debería ser: alguien, trabajando solo en su habitación, fue capaz de desarrollar una habilidad que le permitiría poner en grave peligro a los usuarios de iPhone con los que entraría en contacto. con.
Para ser claros: Beer, a través de Google, reportó el error inicial rápidamente y, según sabemos, nadie más lo había descubierto antes que él, por lo que no hay indicios de que este error haya sido explotado por nadie en el mundo real.
Sin embargo, es razonable asumir que, una vez detectado un desbordamiento de búfer a nivel de kernel, incluso a pesar de las reducciones de control más recientes y significativas, un atacante establecido podría hacer un uso dañino de él.
Aunque los controles de seguridad como la aleatorización del diseño de la sala de direcciones y los códigos de autenticación de recordatorio mejoran enormemente nuestra ciberseguridad, no son soluciones milagrosas por sí solos.
Como lo expresa secamente Mozilla al abordar cualquier falla de administración de memoria en Firefox, incluso errores aparentemente leves o misteriosos que el equipo no pudo o no supo cómo explotar: ‘; Algunas de estas plagas revelaron evidencia de corrupción de memoria y presumimos que, con la iniciativa adecuada, algunas de ellas podrían haber sido explotadas para ejecutar código aproximado.
En otras palabras, descubrir errores es importante; corregirlos 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 resumen tan breve como este, pero aquí hay un resumen (quizás demasiado simplificado) de algunas de las habilidades de hacking que utilizó:
- Detectar un nombre de variable del kernel que sonaba arriesgado. El nombre original que lo originó todo fue IO80211AWDLPeer:: parseAwdlSyncTreeTLV, donde TLV se refiere a tipo-longitud-valor, un método para 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 implica la presencia de código complejo a nivel de kernel que está directamente sujeto a información no confiable enviada desde otras herramientas. Este tipo de código suele ser una fuente de errores de programas dañinos.
- Encontrando una plaga en el código que maneja datos TLV. Beer observó un punto en el que un objeto de datos TLV, restringido a una barrera de memoria de solo 60 bytes (10 direcciones MAC como máximo), se clasificaba incorrectamente. “Longitud comprobada” frente a una restricción de seguridad genérica de 1024 bytes, en lugar de frente al tamaño real del búfer ofrecido.
- Construir una pila de controladores de red AWDL para desarrollar paquetes dudosos. Paradójicamente, 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 los controles de seguridad existentes en otros lugares superen los controles de seguridad existentes. Aunque el código de bits principal era defectuoso y no realizó correctamente su inspección final de errores, hubo numerosas comprobaciones preliminares parciales que dificultaron aún más el ataque. Por cierto, como señala Beer, es atractivo, en código de bajo nivel, especialmente si es esencial para la eficiencia, pensar que la información no confiable ya se habrá depurado y, por lo tanto, limitar el código de monitoreo de errores justo donde más importa. ¡No lo hagas, especialmente si ese código esencial está en el kernel!
- Saber cómo convertir el desbordamiento del búfer en una corrupción de carga controlada. Esto proporcionó un método predecible y explotable para usar paquetes AWDL y forzar lecturas y escrituras no autorizadas en la memoria del kernel.
- Analizando un total de 13 adaptadores Wi-Fi diferentes para encontrar la manera de ejecutar 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 tuvo que encontrar un adaptador de red que pudiera reconfigurar para satisfacer sus necesidades.
En ese momento, Beer ya había alcanzado un resultado de prueba de concepto donde la mayoría de nosotros nos habríamos dado por vencidos.
Con las capacidades de lectura y escritura del kernel, puede forzar la aparición de la aplicación Calc en el teléfono desde otra ubicación, siempre que se tuviera habilitada la red AWDL, por ejemplo, al usar el ‘;’ El icono “Compartir” en la aplicación Fotos permite enviar tus datos por AirDrop.
Sin embargo, se descubrió que lo convertía en un supuesto ataque sin hacer clic, donde la víctima no necesita estar haciendo nada más que simplemente usar su teléfono en ese momento.
Como puedes imaginar, un ataque sin hacer clic es mucho más peligroso, ya que incluso un usuario bien informado no detectaría ninguna señal que indicara un problema.
- Aparentar ser un dispositivo cercano que ofrece datos para compartir mediante AirDrop. Si tu teléfono asume que un dispositivo cercano puede estar entre tus llamadas, basándose en la información Bluetooth que transmite, activará temporalmente AWDL para confirmarlo. Si no es uno de tus contactos, no verás ninguna ventana emergente ni ninguna otra advertencia, pero el virus AWDL explotable quedará expuesto brevemente a través del subsistema AWDL activado automáticamente.
- Al prolongar el ataque para que hiciera más que simplemente abrir una aplicación existente como Calc, Beer descubrió cómo usar su uso preliminar en una cadena de ataque compleja que podía acceder a archivos aproximados en el dispositivo y robarlos.
En el video de arriba, el ataque tomó el control de una aplicación que ya estaba ejecutándose (el osito de peluche estaba viendo YouTube, si recuerdas); la desactivó desde dentro del bit para que ya no se limitara a ver sus propios datos; la usó para acceder al directorio DCIM (cámara) de la aplicación Fotos; y robó el archivo de imagen actual. Y luego lo exfiltró usando una conexión TCP de apariencia inocente.
¡Guau!
¿Qué hacer?
Consejo 1. Asegúrate de contar con las reparaciones de seguridad actualizadas, ya que la plaga en el corazón de la cadena de ataques de Beer fue encontrada y revelada por él mismo, por lo que ya está cubierta. Ve a Configuración > Actualización General del Software.
Consejo 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 verdadero ataque sin clics.
Consejo 3. Nunca asumas que porque un error parezca “difícil” nunca se usará. Beer admite que este conjunto era difícil, extremadamente difícil, de usar, pero inevitablemente posible.
Consejo 4: Si eres diseñador, sé estricto con los datos. Nunca está de más hacer un buen seguimiento de errores.
Para todos los programadores: esperen lo mejor, es decir, esperen que todos los que llamen 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.
