El conocido científico de Google Job No, Ian Beer, acaba de publicar una publicación que está atrayendo mucha atención mediática.

El artículo en sí tiene un título muy preciso e intrigante: Una odisea para explotar la radio de proximidad sin clics en un iPhone.

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

La serie de usos que descubrió 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 inocente del dispositivo.

De hecho, el artículo de Beer concluye con un breve video que lo muestra robando una foto de su propio teléfono usando un programa de hacking. En el siguiente espacio:

• Toma una foto de un archivo secreto con el iPhone en una habitación.
• Deja al usuario del teléfono (un oso de peluche rosa gigante, por lo visto) descansando felizmente viendo un video de YouTube.
• Va a la casa de al lado y lanza un ataque inalámbrico automatizado que explota un pequeño fallo del teléfono.
• El usuario introduce sigilosamente código malicioso en el teléfono, accede al directorio de archivos de la aplicación Fotos y lee el archivo. Los documentos de imagen “secretos” los envía de forma invisible 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.

leer más acceder a fotos de otro móvil a distancia En la página de 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 explotar su propio fallo.

Para que te hagas una idea del esfuerzo invertido en los 5 minutos de “;” El vídeo del picnic de robo de información del osito de peluche que aparece arriba. Como advertencia, si está considerando examinar detenidamente el excepcional artículo de Beer, recuerde que su artículo tiene más de 30 000 palabras, más extenso que el original “Pet Farm” de George Orwell o “Un cuento de Navidad” de Charles Dickens.

Seguramente se estará preguntando por qué Beer se molestó en tomar un fallo que ya había encontrado y reportado, pero se esforzó tanto en convertirlo en un arma, por usar la jerga paramilitar habitual en ciberseguridad.

Bueno, Beer mismo ofrece la solución, 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.

Más bien, debería ser: alguien, trabajando solo en su habitación, pudo desarrollar una habilidad que le permitiría comprometer seriamente a los usuarios de iPhone con los que entraría en contacto cercano. con.

Para ser claros: Beer, usando Google, reportó rápidamente el error inicial, y como sabemos, nadie más lo había descubierto antes que él, por lo que no hay indicios de que alguien en el mundo real lo haya usado.

Sin embargo, es razonable suponer que una vez que se descubre un desbordamiento de búfer a nivel de kernel, incluso con las reducciones de uso actuales y óptimas, un enemigo identificado puede crear un ataque 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 claves, mejoran enormemente nuestra ciberseguridad, no son soluciones milagrosas por sí solos.

Como Mozilla, en cambio, lo expresa secamente al abordar cualquier fallo de gestión de memoria en Firefox, incluso errores aparentemente leves o arcanos que el equipo no pudo o no supo cómo explotar: ‘; Algunos de estos errores mostraron evidencia de corrupción de memoria y asumimos que, con la iniciativa adecuada, varios de ellos podrían haber sido manipulados para ejecutar código arbitrario.

En pocas palabras, encontrar errores es vital; corregirlos es crucial; aprender de nuestros errores es importante; sin embargo, debemos seguir mejorando nuestras soluciones 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 (posiblemente demasiado simplificado) de algunas de las habilidades de hacking que utilizó:

• Detectar un nombre variable que parecía de alto riesgo. El nombre peculiar que lo originó todo fue IO80211AWDLPeer:: parseAwdlSyncTreeTLV, donde TLV describe 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 indica la existencia 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 programación peligrosos.
• Encontrando un problema en el código de manejo de datos de TLV. Beer observó un punto en el que un objeto de datos de TLV, restringido a un búfer de memoria de solo 60 bytes (10 direcciones MAC como máximo), se configuraba 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.
• Desarrollar una pila de controladores de red AWDL para producir paquetes sospechosos. 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 un método para que los paquetes que superan el búfer superen las comprobaciones de seguridad existentes en otros lugares. Aunque el código de bits principal era defectuoso y no realizó correctamente su comprobación final de errores, hubo varias comprobaciones preliminares parciales que dificultaron mucho el ataque. Por cierto, como explica Beer, es tentador, en código de bajo nivel, especialmente si es esencial para el rendimiento, pensar que los datos no confiables ya se habrán desinfectado y, en consecuencia, escatimar en código de control de errores justo cuando más importa. ¡No lo hagas, especialmente si ese código vital permanece en el kernel!
• Saber cómo convertir el desbordamiento de búfer en una corrupción controlada de la pila. Esto proporcionó un enfoque previsible y explotable para usar paquetes AWDL para forzar la salida de comprobaciones no autorizadas y la creación de nuevas en la memoria de bits.
• Análisis de 13 adaptadores Wi-Fi diferentes para descubrir un método para instalar el ataque. Beer pretendía enviar paquetes AWDL envenenados a través de los canales Wi-Fi de 5 GHz, ampliamente utilizados 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 habríamos fracasado.

Con las capacidades de lectura y escritura del kernel, podía, desde otra ubicación, requerir que la aplicación Calc apareciera 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 documentos por AirDrop.

Sin embargo, estaba decidido a convertir esto en un supuesto ataque sin clic, donde el objetivo no necesita hacer nada más específico que simplemente “;” Utilizando su teléfono en ese momento.

Como puede imaginar, un ataque sin hacer clic es mucho más dañino, ya que incluso un usuario informado no vería ninguna señal de alerta que advirtiera de un problema de riesgo.

• Hacerse pasar por un dispositivo vecino que ofrece datos para compartir a través de AirDrop. Si su teléfono sospecha que un dispositivo vecino puede estar entre sus contactos, basándose en los datos de Bluetooth que envía, iniciará temporalmente AWDL para identificarlo. Si no es uno de sus contactos, no verá ninguna ventana emergente ni ninguna otra advertencia, pero el virus AWDL explotable será expuesto brevemente mediante el subsistema AWDL activado automáticamente.
• Extender el ataque para que haga más que simplemente iniciar una aplicación existente como Calc. Beer descubrió exactamente cómo usar su primer control en una cadena de ataques exhaustiva que permite acceder a archivos arbitrarios del dispositivo y robarlos.

En el video de arriba, el ataque tomó el control de una aplicación que se estaba ejecutando (el osito de peluche estaba viendo YouTube, por si recuerdan); liberó la aplicación del kernel para que no se limitara a ver su propia información; usó la aplicación para acceder al directorio DCIM (cámara) de la aplicación Fotos; robó el archivo de foto más reciente; y luego lo exfiltró mediante una conexión TCP de apariencia inocente.
¡Guau!

¿Qué hacer?

Consejo 1: Asegúrate de contar con soluciones de seguridad actualizadas, ya que la plaga en el núcleo de la cadena de ataques de Beer fue descubierta y divulgada por él mismo, por lo que ya ha sido parcheada. Vaya a Configuración, Actualización General del Programa de Software.

Sugerencia 2. Desactive el Bluetooth cuando no lo necesite. El ataque de Beer es un gran consejo: “menos es más”, ya que necesitaba Bluetooth para transformarlo en un verdadero ataque sin clics.

Consejo 3. Nunca piense que porque una plaga suene “difícil” nunca será explotada. Beer confiesa que esto fue difícil, muy difícil, de manipular, pero finalmente posible.

Sugerencia 4. Si es diseñador, sea riguroso con los datos. Nunca está de más realizar un buen seguimiento de errores.

Para todos los programadores: anticípese a lo mejor; es decir, desee que todos los que accedan a su código hayan buscado errores al menos una vez; pero prepárese para lo peor; es decir, asuma que no lo han hecho.

Comments

comments