Cómo robar fotos de un iPhone desde el otro lado de la calle

El conocido investigador de Google Project Zero, Ian Beer, ha publicado un informe que está atrayendo mucha atención de los medios.

El artículo en sí tiene un título perfectamente preciso e interesante, a saber: An iOS zero-click radio proximity exploit odyssey.

Pero son titulares como el que hemos utilizado los que capturan la esencia práctica del ataque de Beer.

La secuencia de explotación que descubrió realmente permite que un atacante entrar en un iPhone cercano y robar datos personales, utilizando solo conexiones inalámbricas, y sin necesidad de que la víctima haga clic, ni salta ninguna advertencia.

De hecho, el artículo de Beer concluye con un breve video que lo muestra robando automáticamente una foto de su propio teléfono usando un kit instalado en la habitación contigua:

• Saca una foto de un “documento secreto” usando el iPhone en una habitación.
• Deja al “usuario” del teléfono (un osito de peluche rosa gigante, en el ejemplo) sentado felizmente viendo un video de YouTube.
• Va a la puerta de al lado y lanza un ataque automático que explota un error del kernel en el teléfono.
• El exploit carga furtivamente el código de malware en el teléfono, se otorga a sí mismo acceso al directorio de datos de la aplicación Photo, lee el archivo de foto “secreto” y lo carga de manera invisible en su portátil.
• El teléfono sigue funcionando normalmente en todo momento, sin advertencias, ventanas emergentes ni nada que pueda alertar al usuario sobre el ataque.

Esa es la mala noticia.

La buena noticia es que la vulnerabilidad principal en la que se basó Beer es una que él mismo encontró hace muchos meses, informó a Apple, y que ya ha sido parcheada.

(Según el informe de Beer: “Este problema específico se solucionó antes del lanzamiento de Privacy-Preserving Contact Tracing en iOS 13.5 en mayo de 2020″).

Entonces, 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 a Beer, según él mismo lo admite, le llevó seis meses de trabajo minucioso y dedicado descubrir cómo explotar su propio error.

Para darte una idea de cuánto esfuerzo se invirtió en el video de 5 minutos anterior, y puedas estar advertido si estás pensando en estudiar el excelente artículo de Beer en detalle, ten en cuenta que su publicación tiene más de 30.000 palabras, más que la novela Rebelión en la granja de George Orwell o Un cuento de Navidad de Charles Dickens.

Por supuesto, es posible que te preguntes por qué Beer se molestó en un error que había encontrado y reportado, para convertirlo con tanto esfuerzo en un arma, por usar la jerga paramilitar común en la ciberseguridad.

Bueno, Beer da la respuesta él mismo, justo al comienzo de su artículo:

La conclusión de este proyecto no debería ser: nadie pasará seis meses de su vida solo para poder piratear mi teléfono, no hay problema.

Debería ser: una persona, trabajando sola en su habitación, pudo desarrollar una funcionalidad que le permitiría comprometer seriamente a los usuarios de iPhone que estuvieran cerca.

Que quede claro: Beer, a través de Google, informó del error original de inmediato, y hasta donde sabemos, nadie más lo había descubierto antes que él, por lo que no hay ningún indicio de que este error haya sido explotado por nadie.

Pero es razonable suponer que una vez que se ha descubierto un desbordamiento del búfer a nivel de kernel, incluso frente a las últimas y más grandes mitigaciones de exploits, un atacante determinado podría producir un exploit peligroso a partir de él.

Aunque los controles de seguridad, como la asignación al azar del diseño del espacio de direcciones y los códigos de autenticación de punteros, aumentan enormemente nuestra ciberseguridad, no son soluciones mágicas por sí solas.

Como Mozilla lo expresa con bastante sequedad cuando corrige vulnerabilidades de incorrecta gestión de memoria en Firefox, incluso errores aparentemente leves o arcanos que el equipo no pudo o no descubrió cómo explotar por sí mismos: “Algunos de estos errores mostraron evidencia de corrupción de memoria y suponemos que con suficiente esfuerzo algunos de estos podrían haber sido explotados para ejecutar código arbitrario”.

En resumen, encontrar errores es vital; parchearlos es fundamental; aprender de nuestros errores es importante; pero, no obstante, debemos seguir desarrollando nuestras defensas de ciberseguridad en todo momento.

Como desarrolló el ataque 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 excesivamente simplificada) de los pasos que dio para realizar el ataque:

• Detectar un nombre de variable del kernel que sonará peligroso. El nombre original con el que comenzó todo fue IO80211AWDLPeer :: parseAwdlSyncTreeTLV, donde TLV se refiere a tipo-longitud-valor, una forma de empaquetar datos complejos en un extremo para deconstruir (analizar) en el otro, y AWDL es la abreviatura de Apple Wireless Direct Link , la red inalámbrica patentada utilizada para funciones de Apple como AirDrop. El nombre de esta función implica la presencia de un código complejo a nivel de kernel que está expuesto directamente a datos que no son de confianza enviados desde otros dispositivos. Este tipo de código es a menudo una fuente de peligrosos errores de programación.
• Encontrar un error en el código de manejo de datos TLV. Beer detectó un punto en el que un objeto de datos TLV que estaba limitado a un búfer de memoria de solo 60 bytes (10 direcciones MAC como máximo) se “verificó en longitud” incorrectamente contra un límite de seguridad genérico de 1024 bytes, en lugar del tamaño real del búfer disponible.
• Crear de una pila de controladores de red AWDL para crear paquetes poco fiables. Irónicamente, Beer comenzó con un proyecto de código abierto existente destinado a ser compatible con el código propietario de Apple, pero no pudo hacer que funcionara como necesitaba. Así que terminó creando el suyo.
• Encontrar una manera de hacer que los paquetes que rompan el búfer superen las verificaciones de seguridad que existentes. Aunque el código del núcleo del kernel era defectuoso y no realizó correctamente la comprobación final de errores, hubo varias comprobaciones parciales de precursores que hicieron que el ataque fuera mucho más difícil. Por cierto, como señala Beer, es tentador, en código de bajo nivel, especialmente si es crítico para el rendimiento, asumir que los datos que no son de confianza ya se habrán desinfectado y, por lo tanto, escatimar en el código de verificación de errores en el punto que importa más. ¡No lo hagas, especialmente si ese código crítico está en el kernel!
• Aprender a convertir el desbordamiento del búfer en una corrupción de pila controlable. Esto proporcionó un método predecible y explotable para usar paquetes AWDL para forzar lecturas y escrituras no autorizadas en la memoria del kernel.
• Probar un total de 13 adaptadores Wi-Fi diferentes para encontrar la manera de montar el ataque. Beer quería poder enviar paquetes AWDL envenenados en los canales Wi-Fi de 5 GHz que se usan ampliamente en la actualidad, por lo que tuvo que encontrar un adaptador de red que pudiera reconfigurar para satisfacer sus necesidades.

En este punto, Beer ya había alcanzado un resultado de prueba de concepto en el que la mayoría de nosotros nos hubiéramos detenido considerándolo un triunfo.

Con los poderes de lectura y escritura del kernel, podía forzar de forma remota que la aplicación Calc se abriera en su teléfono, siempre que tuviera la red AWDL habilitada, por ejemplo, mientras usaba el icono “Compartir” en la aplicación Fotos para enviar sus propios archivos a través de AirDrop.

Sin embargo, estaba decidido a convertir esto en un llamado ataque de cero clic, donde la víctima no tiene que estar haciendo específico, simplemente “usar su teléfono” en ese momento.

Como puedes imaginar, un ataque de cero clics es mucho más peligroso, porque incluso un usuario bien informado no vería ningún signo revelador de antemano que advirtiera de problemas inminentes.

Así que Beer también descubrió técnicas para:

• Fingir ser un dispositivo cercano que ofrece archivos para compartir a través de AirDrop. Si tu teléfono cree que un dispositivo cercano podría ser uno de sus contactos, según los datos de Bluetooth que está transmitiendo, activará temporalmente AWDL para ver quién es. Si no es uno de sus contactos, no verás ninguna ventana emergente u otra advertencia, pero el error AWDL explotable se expondrá brevemente a través del subsistema AWDL activado automáticamente.
• Extender el ataque para hacer más que simplemente hacer aparecer una aplicación existente como Calc. Beer descubrió cómo usar su exploit inicial en una cadena de ataque detallada que podría acceder a archivos arbitrarios en el dispositivo y robarlos.

En el video de arriba, el ataque se apoderó de una aplicación que ya se estaba ejecutando (el oso de peluche estaba mirando YouTube, si recuerdas); “Eliminó la sandbox” de la aplicación desde el interior del kernel para que ya no se limitara a ver sus propios datos; usó la aplicación para acceder al directorio DCIM (cámara) que pertenece a la aplicación Fotos; robó el último archivo de imagen; y luego lo exfiltró usando una conexión TCP de apariencia inocente.

¿Qué hacer?

Consejo 1. Asegúrate de estar al día con las actualizaciones de seguridad, porque el error en el corazón de la cadena de ataque de Beer fue encontrado y revelado por él en primer lugar, por lo que ya ha sido parcheado. Ve a Configuración> General> Actualización de software.

Consejo 2. Apaga el Bluetooth cuando no lo necesites. El ataque de Beer es un buen recordatorio de que “menos es más”, el Bluetooth fue necesario para convertir esto en un verdadero ataque sin clics.

Consejo 3. Nunca asumas que, debido a que un error parece “difícil”, nunca será explotado. Beer admite que éste fue difícil, muy difícil de explotar, pero al final no imposible.

Consejo 4. Si eres un programador, se estricto con los datos. Nunca es mala idea hacer una buena verificación de errores.

Para todos los programadores: espera lo mejor, es decir, espera que todos los que llaman a tu código ya han verificado errores al menos una vez; pero prepárate para lo peor, es decir, supón que no es así.