La vulnerabilidad fue descubierta por un investigador del equipo de Google Project Zero, Ian Beer. Publicó un extenso artículo el 1 de diciembre , en el que describió en detalle tanto la vulnerabilidad en sí como la historia de su descubrimiento. La simple descripción de la vulnerabilidad la diferencia un poco de las demás: se establece una conexión con el dispositivo de la víctima a través de AWDL, se envían una serie de paquetes preparados, lo que provoca un desbordamiento del búfer y la ejecución de código arbitrario. La publicación de blog de varias páginas muestra que la realidad es mucho más complicada. El investigador muchas veces podría dar un paso atrás y limitarse a demostrar un ataque DoS, una caída de un dispositivo basado en iOS o macOS. Pero aún así, llevó el asunto al final: en el video del ataque, piratea su propio iPhone en dos minutos y le roba datos personales en tres minutos más.
Beer tuvo la idea de "excavar" exactamente en la dirección de la comunicación inalámbrica en 2018, después de que Apple lanzara accidentalmente la versión beta de iOS sin eliminar los nombres de las funciones del módulo kernelcache (que contiene el kernel en sí y algunos otros módulos). Este error simplificó un poco la vida de los investigadores, ya que apareció información textual más significativa sobre los principios del funcionamiento del kernel. Allí Beer encontró referencias a AWDL en la función de procesamiento de entrada. El primer resultado fue un informe de error que indicaba que el sistema operativo se bloqueaba después de enviar paquetes incorrectos por aire; este error se corrigió en la versión macOS 10.15.3 e iOS 13.1.1. Es decir, allá por enero de 2020, se cerró el problema.
Pero Bier pasó otros seis meses invirtiendo en su propio conocimiento y la ciencia para encontrar vulnerabilidades, además de protegerse contra ellas. Perfeccionó su exploit original implementando un ataque de robo de datos sin la intervención del usuario. A diferencia de muchos otros ataques que implican estar cerca de la víctima, el atacante y la víctima ni siquiera necesitan estar en la misma red Wi-Fi. La tecnología de Apple implica la creación de una red en malla entre dispositivos y funciona en paralelo con la conexión principal al punto de acceso. El investigador necesitaba desensamblar el protocolo de comunicación para descubrir al menos cómo enviar paquetes para que cumplieran con sus requisitos. Luego se requería activar el modo de comunicación requerido, seleccionar un conjunto de datos enviados para que causara una falla e implementar la ejecución de código arbitrario.El video de arriba muestra todo el proceso de ataque, que usa una computadora Raspberry Pi con un módulo Wi-Fi.
Lo notable de este estudio es que Beer encontró el problema solo. Sí, tomó mucho tiempo. Sí, lo más probable es que nadie haya aprovechado la vulnerabilidad. Teniendo en cuenta el ritmo relativamente rápido de instalación de actualizaciones en iPhone / iPad, es poco probable que los atacantes tengan tiempo para explotar el error. Pero existe la posibilidad de que otros también puedan llegar al fondo de esta vulnerabilidad y explotarla para fines que no sean pacíficos. El artículo proporciona enlaces a tweets que demuestran que al menos otro especialista en seguridad de la información conocía el problema descubierto durante la investigación y notó que estaba cerrado en una versión reciente de iOS.
Que mas paso
El ataque a la red de puntos de control de PickPoint el 4 de diciembre ( noticias , mensaje de la empresa, discusión sobre Habré) se convirtió en un raro (afortunadamente) ejemplo claro de un ataque a la infraestructura física. Un informe técnico detallado sobre los métodos de tales ataques y cómo defenderse de ellos es útil para la comunidad de seguridad de la información. Sin embargo, no es un hecho que esperemos a tal divulgación de datos; las empresas no están obligadas a hacerlo, y solo en el ámbito de las TI, la divulgación de información se considera de "buena forma".
Una vulnerabilidad cerrada el 6 de abril en la biblioteca principal de Google Play (está incrustada en aplicaciones de Android para interactuar con la tienda en línea de Google) aún no está cerradaen una variedad de aplicaciones de Android, incluida la versión móvil del navegador Microsoft Edge. Un rastreo de la tienda de Google mostró que el 13% de las aplicaciones usan esta biblioteca. De estos, el 8% nunca lo actualizó después del lanzamiento del parche.
Más parches para vulnerabilidades en Google Chrome. Cerró tres agujeros importantes en el navegador, uno de ellos en el motor V8 (CVE-2020-16040). En particular, esta vulnerabilidad se puede aprovechar para aumentar los privilegios en Linux.