Vulnerabilidades 0-day explotadas por una empresa de vigilancia comercial en Egipto

• Google TAG y The Citizen Lab descubrieron una cadena de exploits 0-day para iPhone utilizada en ataques reales, y Intellexa la aprovechó para instalar en secreto el spyware Predator
• Apple corrigió CVE-2023-41991·41992·41993 en iOS 16.7 e iOS 17.0.1, y Google recomienda a los usuarios de iOS actualizar de inmediato
• El ataque interceptaba el tráfico mediante inyección MITM cuando el objetivo visitaba un sitio HTTP y lo redirigía a c.betly[.]me y sec-flare[.]com, por lo que no requería clics adicionales ni responder llamadas
• La cadena en iOS incluía ejecución remota de código en Safari, un problema de validación de certificados y escalamiento local de privilegios en el kernel XNU; después, un pequeño binario decidía si instalar el implante completo de Predator
• También se observaron ataques dirigidos a Android en Egipto; la vulnerabilidad inicial de ejecución remota de código en el renderer de Chrome, CVE-2023-4762, fue corregida el 5 de septiembre

---

Cadena de exploits para instalar Predator de Intellexa

• Google Threat Analysis Group(TAG), junto con The Citizen Lab, descubrió una cadena de exploits 0-day para iPhone que se estaba usando en ataques reales
• Esta cadena, desarrollada por la empresa de vigilancia comercial Intellexa, se utilizaba para instalar de forma encubierta el spyware Predator en los dispositivos
• Apple corrigió las siguientes vulnerabilidades en iOS 16.7 y iOS 17.0.1
  • CVE-2023-41991
  • CVE-2023-41992
  • CVE-2023-41993
• Con estos parches rápidos se reforzó la protección de los usuarios, y se recomienda a todos los usuarios de iOS instalarlos lo antes posible

Método de entrega mediante MITM

• La cadena de exploits de Intellexa se entregaba mediante un ataque man-in-the-middle (MITM)
• En un ataque MITM, el atacante se interpone entre el objetivo y el sitio web al que intenta acceder para interceptar el tráfico
• Si el objetivo visita un sitio http, el atacante puede devolver datos falsos para redirigirlo a otro sitio web
• En los sitios https, el tráfico está cifrado y los certificados permiten verificar si los datos recibidos provienen del sitio web previsto
• En esta campaña, sin importar qué sitio http visitara el objetivo, una inyección de tráfico lo redirigía silenciosamente al sitio de Intellexa c.betly[.]me
  • Si el usuario coincidía con el objetivo esperado, era redirigido de nuevo al servidor de exploits sec-flare[.]com
  • No se requería ninguna acción del usuario, como abrir un documento, hacer clic en un enlace específico o responder una llamada

Composición de la cadena de exploits en iOS

• Cuando el objetivo era redirigido al servidor de exploits, se ejecutaba la cadena de exploits de iOS
• La cadena estaba compuesta por tres vulnerabilidades
  • CVE-2023-41993: ejecución remota de código (RCE) inicial en Safari
  • CVE-2023-41991: problema de validación de certificados
  • CVE-2023-41992: escalamiento local de privilegios (LPE) en el kernel XNU
• Después se ejecutaba un pequeño binario para decidir si instalar el implante completo de Predator
• TAG no logró obtener el implante completo de Predator
• Google planea publicar un análisis técnico profundo de este exploit de acuerdo con la Google vulnerability disclosure policy

Ataques dirigidos a Android y vulnerabilidad de Chrome

• Los atacantes también contaban con una cadena de exploits para instalar Predator en dispositivos Android en Egipto
• TAG observó dos formas de entrega del exploit de Android
  • Inyección MITM
  • Enlace de un solo uso enviado directamente al objetivo
• Lo único que TAG consiguió obtener fue la vulnerabilidad inicial de ejecución remota de código en el renderer de Chrome, que explotaba CVE-2023-4762
• Ese bug ya había sido reportado por otro investigador de seguridad al Chrome Vulnerability Rewards Program y fue corregido el 5 de septiembre
• Google considera que Intellexa había estado usando previamente esta vulnerabilidad como 0-day

Defensa MITM en Chrome y respuesta de Google

• Chrome ha impulsado durante años la adopción generalizada de HTTPS en toda la web
• El “HTTPS-First Mode” de Chrome puede reducir la posibilidad de entrega de exploits mediante inyección de red MITM
  • Intenta cargar primero todas las páginas con HTTPS
  • Muestra una gran advertencia antes de volver a una solicitud HTTP
• Esta configuración está habilitada de forma predeterminada para los usuarios inscritos en el Advanced Protection Program y que han iniciado sesión en Chrome
• Google recomienda a todos los usuarios activar “HTTPS-First Mode” para defenderse de ataques MITM
• Esta campaña muestra que la expansión de las empresas de vigilancia comercial puede representar un grave riesgo para la seguridad de los usuarios en línea
• TAG continuará tomando medidas contra la industria del spyware comercial, publicando investigaciones y colaborando con los sectores público y privado para dar seguimiento a estas respuestas

[GN⁺]

Opiniones en Hacker News

• Está bien que haya más información, pero me inquieta un poco que solo mencionen el parche de Chrome. Me pregunto cuál fue el escape de sandbox en Android.
  Aunque se hubiera logrado ejecutar código dentro del proceso de Chrome en Android, eso no debería permitir obtener persistencia, así que claramente hay otra vulnerabilidad más.
  En este caso, el vector de ataque fue un ataque HTTP de intermediario y enlaces de un solo uso en una campaña dirigida, pero no veo qué impediría que alguien lo metiera en una campaña de anuncios o en spam por SMS/Discord/Matrix para distribuirlo masivamente y crear una botnet o robar credenciales de usuarios.

  • Esto es realmente lo central. Como esa información falta en el post del blog, hay que leer entre líneas, y suena como si hubiera un problema aún sin parchear del lado de Android.
  • Dicen que no pudieron capturar las etapas posteriores de la cadena de Android y que solo obtuvieron el componente de ejecución inicial.
    Es decir, faltan el escape de sandbox y el bug de escalamiento de privilegios.
    Además, aquí parece haberse entregado mediante un ataque de intermediario a nivel ISP usando capacidades de interceptación legal, pero no hay razón para que este exploit no pudiera entregarse también con un método de un clic mediante un enlace de phishing.
  • Como hay millones de dispositivos Android abandonados por sus fabricantes, quizá estén omitiendo algunos detalles porque se trata de una falla que todavía no está parcheada y probablemente nunca lo estará.
  • El foco del artículo es la cadena de exploits para iPhone: exploit de Safari → bypass de PAC → exploit de kernel.
    La versión para Android era bastante similar, pero parece que necesitaba dos exploits más para eludir las mitigaciones del kernel de Linux.
    Hay un buen análisis técnico en PZ.
  • No conozco muy bien el entorno móvil, pero pensaría que si sales del sandbox de Chrome entras al sistema operativo subyacente. ¿No se puede lograr persistencia ahí sin explotar vulnerabilidades adicionales?

• Es mejor que no tener HTTPS, y este ataque usa HTTP para inyectar la carga inicial, pero creo que algunos atacantes patrocinados por Estados podrían simplemente eludir o tomar control de la infraestructura de CA o CDN.

  • Si falsifican certificados de esa manera, es muy probable que todos los navegadores se den cuenta y eliminen esa CA, así que hay mecanismos de protección.
  • O también podrían hacer que hagas clic en un dominio suplantado certificado por el LetsEncrypt que todos amamos.
    Parece que lo único necesario es una respuesta de redirección HTTP 302/307 que envíe al cliente a c.betly[.]me. También podría funcionar una carga de redirección HTML, o quizá incluso DNS.
  • Lo importante es que, para comprometer el dispositivo, bastaba —o basta— con visitar una vez cualquier sitio HTTP.

• Hay un episodio reciente relacionado de Darknet Diaries sobre el spyware Predator: https://darknetdiaries.com/episode/137/

• Lo que enseñan estos 0-day es que, si eres objetivo de un adversario poderoso, tienes que actuar con paranoia extrema y reducir al máximo tu superficie de ataque.
  Si James Bond quiere comunicarse de forma segura con M, le conviene usar un dispositivo móvil de hardware personalizado que haga solo esa función. Debería dejar mensajes cifrados en un foro aleatorio desde dispositivos prepagos anónimos de terceros, siguiendo el orden de un libro de códigos rotativo con bloqueo geográfico acordado de antemano. Cualquier seguridad operativa apenas más débil que eso y estás acabado.
  Si una persona común usa de forma normal un dispositivo digital conectado, debe asumir que todo lo que puso en ese dispositivo ya fue robado. Si de verdad quieres mantener algo privado, no lo pongas en digital: déjalo en papel o en una cinta analógica a la antigua. Así al menos tendrían que robarlo físicamente, lo que según el caso puede ser mucho más difícil, aunque no necesariamente más seguro. Al final, de una forma u otra, pierdes.
  La única salida real es contar con gobiernos democráticos donde la transparencia y los controles y contrapesos funcionen con fuerza, leyes de privacidad aplicadas de manera estricta y un apoyo sólido a actividades como las de Citizen Lab.

• Es muy probable que las autoridades egipcias hayan usado esta vulnerabilidad para hackear el teléfono de Ahmed El Tantawy, candidato que compite en las elecciones presidenciales contra el presidente actual Abdel Fatah El Sisi.
  https://x.com/jsrailton/status/1705271600868692416?s=46&t=Kq...

• El artículo no lo menciona, pero el Lockdown Mode de iOS bloqueó esta cadena de exploits.

• Hay algo que no entiendo: tanto las empresas de spyware como los vendedores de 0-day tienen personal dedicado a encontrar 0-day. ¿Por qué Google y Apple no simplemente reclutan a esas personas?
  Google y Apple podrían ofrecer sueldos muy competitivos, así que me pregunto por qué no lo hacen. ¿Será que consideran que el costo de contratar prácticamente a todos los cazadores expertos de 0-day es mayor que el costo de sacar parches?

  • Soy alguien que hace exactamente ese tipo de trabajo. Trabajo como investigador de 0-day.
    Desde el punto de vista del empleado, los salarios son similares. El trabajo en Big Tech es menos interesante. Construyes grandes máquinas de detección de bugs que encuentran muchos errores, y luego subes los bugs encontrados a un bug tracker, donde tal vez los arreglen tres meses después. El trabajo en seguridad ofensiva es más interesante. Como Big Tech encuentra las vulnerabilidades superficiales, solo necesitas unas cuantas y debes conocer a fondo el sistema que investigas. También necesitas saber cómo pasar de una vulnerabilidad a ejecución de código. Escribir exploits no es fácil. Es difícil explicar por qué ingenieros trabajan en empresas que yo considero inmorales, pero quizá sea porque no lo sienten de la misma manera que yo.
    Desde el punto de vista del empleador, es una cuestión de “cuánto gastar por una tasa de X vulnerabilidades encontradas al año”. Si tu código tiene bugs pero aun así se considera el código más seguro del mercado, quizá no sea beneficioso para la empresa aumentar el presupuesto de seguridad. Si aumentas el presupuesto de seguridad, tienes que pensar de qué departamento se recorta y cuál es el efecto neto sobre la salud de la empresa.
    Si quieres corregir vulnerabilidades, tienes que elevar el precio de encontrarlas y explotarlas hasta que los compradores no puedan pagarlo. Y debes mantener ese precio cada vez más alto a medida que los avances en seguridad ofensiva reducen el costo de descubrirlas y explotarlas. Hay un desajuste porque las empresas defensivas no ganan dinero principalmente previniendo bugs, mientras que las empresas ofensivas sí ganan dinero principalmente encontrándolos. La vulnerabilidad última de cualquier empresa u organización son los recursos finitos.
  • Google tiene uno de los mejores equipos que el dinero y el prestigio pueden comprar: https://en.m.wikipedia.org/wiki/Project_Zero
    También tienen una excelente colaboración con investigadores independientes de todo el mundo. Pero, dada la cantidad de software que se escribe todos los días, aun así pueden pasar por alto algunos problemas.
  • Esto me parece similar a mirar el presupuesto del gobierno de Estados Unidos y preguntar: “¿por qué no compran a todos los delincuentes potenciales y reducen la mayor parte del crimen en EE. UU.?”
  • A algunos de ellos simplemente no les gustaría trabajar en Google o Apple, sin importar el salario.
    Aunque los reclutaras hoy, mañana aparecería un montón de gente nueva trabajando en esas empresas, así que sería un ciclo sin fin.
  • Es una buena idea, pero en cierto sentido es un dilema parecido a preguntar “¿por qué el país más rico del mundo no contrata a todos los mejores generales militares del mundo y no deja ninguno para los demás países?”.
    Hay muchas razones por las que es imposible, pero al final todo se reduce a que el mundo y la humanidad son demasiado grandes y complejos para que una sola entidad pueda tenerlo todo, o siquiera la mayor parte. Hay demasiada heterogeneidad incorporada en todo. También existen muchas visiones del mundo y lealtades que van más allá del dinero.

• Firefox también tiene Https First, pero parece que hay que activar la configuración dom.security.https_first.
  Si es posible, “HTTPS-Only Mode” definitivamente es lo mejor.

  • Aun así hay que resistir el impulso de hacer clic en “permitir de todos modos”. Francamente, aunque conozca el riesgo, creo que incluso yo lo haría. Simplemente porque quiero visitar ese sitio.
    A menos que el aviso se vea extremadamente sospechoso, por ejemplo si aparece en un sitio como Google.com, que sabes que sí soporta HTTPS, esto no resuelve nada.

• La publicación de Citizen Lab enlazada en este artículo tiene detalles del ataque de intermediario. Casi ni parece justo llamarlo ataque: la red está diseñada para inyectar contenido cuando sea necesario.