TriangleDB es un nuevo eslabón de diversos casos en los que dispositivos iOS se han visto infectados por spyware dirigido, como Pegasus, Predator, Reign y otros, convirtiéndose en una parte de una realidad comprobada.
A menudo, el proceso de infectar un dispositivo implica lanzar una cadena de diferentes exploits, por ejemplo, para escapar de la zona de pruebas de iMessage mientras se procesa un archivo adjunto malicioso y para obtener privilegios de root a través de una vulnerabilidad en el kernel.
Debido a esta granularidad, descubrir un exploit en la cadena a menudo no da como resultado recuperar el resto de la cadena y obtener la carga útil final del spyware.
Por ejemplo, en 2021, el análisis de las copias de seguridad de iTunes ayudó a descubrir un archivo adjunto que contenía FORCEDENTRYexplotar. Sin embargo, durante la explotación posterior, el código malicioso descargó una carga útil de un servidor remoto al que no se podía acceder en el momento del análisis.
En consecuencia, los analistas perdieron “la capacidad de seguir el exploit”.
“A medida que profundizamos en el ataque, descubrimos un complejo implante de iOS que mostraba numerosas rarezas intrigantes. Continuamos analizando la campaña y mantendremos a todos actualizados con más información sobre este complejo ataque. Hacemos un llamado a la comunidad de ciberseguridad para que se una, comparta conocimientos y colabore para obtener una imagen más clara de las amenazas que existen”, comenta Georgy Kucherin, experto en seguridad del Equipo de investigación y análisis global de Kaspersky (GReAT).
Al investigar la Operación Triangulación, nos fijamos el objetivo de recuperar tantas partes de la cadena de explotación como sea posible. Llevó alrededor de medio año lograr ese objetivo y, una vez que se completó la recopilación de la cadena, comenzamos un análisis en profundidad de las etapas descubiertas. A partir de ahora, hemos terminado de analizar el implante de spyware y estamos listos para compartir los detalles.
La cadena de infección de TriangleDB
El implante, que llamamos TriangleDB, se implementa después de que los atacantes obtienen privilegios de root en el dispositivo iOS de destino al explotar una vulnerabilidad del kernel.
Se implementa en la memoria, lo que significa que todos los rastros del implante se pierden cuando se reinicia el dispositivo. Por lo tanto, si la víctima reinicia su dispositivo, los atacantes deben volver a infectarlo enviando un iMessage con un archivo adjunto malicioso, iniciando así nuevamente toda la cadena de explotación. En caso de que no se reinicie, el implante se desinstala solo después de 30 días, a menos que los atacantes prolonguen este período.
Conoce a TriangleDB
El implante TriangleDB está codificado con Objective-C, un lenguaje de programación que conserva los nombres de los miembros y los métodos asignados por el desarrollador. En el binario del implante, los nombres de los métodos no están ofuscados; sin embargo, los nombres de los miembros de la clase son acrónimos poco informativos, lo que dificulta adivinar su significado:
|
Ejemplos de métodos de clase |
Ejemplos de miembros de clase |
|
-[CRConfig populateWithFieldsMacOSOnly] -[CRConfig poblarConSysInfo] -[CRConfig extenderPara:] -[CRConfig getCInfoForDump] +[CRConfig instancia compartida] +[CRConfig unmungeHexString:] -[iniciar CRConfig] -[CRConfig getBuildArchitecture] -[CRConfig CLS] -[CRConfig setVersion] -[CRConfig swapLpServerType] -[CRConfig setLpServerType:] |
NSString *pubKI; NSData *pubK; firmado __int64 iDa; firmado __int64 uD; NSString *deN; Cadena NSST *prT; NSString *seN; NSString *uDI; NSString *iME; NSString *meI; NSString *osV; CRPwrInfo *pwi; |
En algunos casos, es posible adivinar el significado de las siglas. Por ejemplo, osV es la versión de iOS e iME contiene el IMEI del dispositivo.
Las cadenas en el implante están codificadas en HEX y encriptadas con XOR variable:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
id +[CRConfig unmungeHexString:](id a1, SEL a2, id stringToDecrypt) {
// code omitted
while (1) {
hexByte[0] = stringBytes[i];
hexByte[1] = stringBytes[i + 1];
encryptedByte = strtoul(hexByte, &__endptr, 16);
if (__endptr == hexByte)
break;
i += 2LL;
if (j)
decryptedString[j] = encryptedByte ^ previousByte;
else
decryptedString[0] = encryptedByte;
++j;
previousByte = encryptedByte;
if (i >= stringLength)
break;
}
decryptedString[j] = 0;
// code omitted
}
|
El algoritmo rolling XOR implementado en el implante para el descifrado de cadenas
comunicaciones C2
Una vez que se lanza el implante, comienza a comunicarse con el servidor C2, utilizando la biblioteca Protobuf para intercambiar datos. La configuración del implante contiene dos servidores: el primario y el alternativo (contenido en los campos de configuración lS y lSf). Normalmente, el implante utiliza el servidor principal y, en caso de error, cambia al servidor alternativo invocando el método -[CRConfig swapLpServerType:].
Adicionalmente, los mensajes enviados y recibidos son encriptados con criptografía simétrica (3DES) y asimétrica (RSA). Todos los mensajes se intercambian a través del protocolo HTTPS en las solicitudes POST, y la cookie tiene la clave g y un valor que es una cadena de dígitos del parámetro de configuración pubKI.
El implante envía periódicamente balizas de latidos que contienen información del sistema, incluida la versión del implante, los identificadores del dispositivo (IMEI, MEID, número de serie, etc.) y la configuración del daemon de actualización (si están habilitadas las descargas e instalaciones automáticas de actualizaciones).
Comandos de TriangleDB
El servidor C2 responde a los mensajes de latido con comandos. Los comandos se transfieren como mensajes Protobuf que tienen nombres de tipo que comienzan con CRX. El significado de estos nombres es oscuro: por ejemplo, el comando que enumera los directorios se llama CRXShowTables, y el cambio de las direcciones del servidor C2 se maneja con el comando CRXConfigureDBServer. En total, el implante que analizamos tiene 24 comandos diseñados para:
- Interactuar con el sistema de archivos (creación, modificación, exfiltración y eliminación de archivos);
- Interactuar con procesos (listarlos y terminarlos);
- Deshacerse de los elementos del llavero de la víctima, que pueden ser útiles para recopilar las credenciales de la víctima;
- Seguimiento de la geolocalización de la víctima;
- Ejecutar módulos adicionales, que son ejecutables de Mach-O cargados por el implante. Estos ejecutables se cargan reflexivamente, con sus archivos binarios almacenados solo en la memoria.
Uno de los comandos interesantes que descubrimos se llama CRXPollRecords. Supervisa los cambios en las carpetas, buscando archivos modificados que tengan nombres que coincidan con las expresiones regulares especificadas. El monitoreo de cambios se maneja obteniendo un descriptor de archivo Unix del directorio y asignándole un controlador de eventos vnode . Cada vez que se notifica un cambio al implante, el controlador de eventos busca archivos modificados que coincidan con la expresión regular proporcionada por el atacante. Luego, dichos archivos se programan para cargarlos en el servidor C2.
Los parámetros de este comando son los siguientes:
| Nombre del parámetro | Descripción de parámetros |
| pag | Ruta de directorio |
| metro | Expresión regular de nombre de archivo |
| COSUDE | Especifica si el comando debe filtrar los archivos que se modificaron antes de que comenzara la supervisión. |
| eWo | Especifica si el contenido del archivo se debe filtrar solo a través de Wi-Fi. |
A continuación, describimos los comandos del implante, especificando los nombres de los comandos asignados por el desarrollador junto con sus identificadores numéricos cuando sea posible.
| ID de comando | Nombre asignado por el desarrollador | Descripción |
| 0xALIMENTAR | CRXEn blanco | No operacion |
| 0xF001 | N / A | Desinstala el implante finalizando su proceso. |
| 0xF301 | CRXPausa | Hace que el implante duerma durante un número específico de segundos. |
| 0xFE01 | N / A | Duerme durante un tiempo pseudoaleatorio definido por los parámetros de configuración caS y caP. El tiempo de sueño se elige entre cap – caS y cap + caS. |
| 0xFB01 | CRXAdelante | Cambia el valor de configuración de cap para el comando 0xFE01. |
| 0xFB02 | Avance rápido de CRX | Cambia el valor de configuración de caS para el comando 0xFE01. |
| 0xF201 | CRXConfigureDBServer | Cambia las direcciones de los servidores C2 principal y alternativo. |
| 0xF403 | CRXUpdateConfigInfo | Cambia los parámetros de configuración del implante. Los argumentos de este comando contienen el identificador del parámetro a cambiar y su nuevo valor. Tenga en cuenta que los identificadores de parámetros son cadenas de números, como “diecinueve” o “veintiuno”. |
| 0xF101 | CRXExtendTimeout | Prolonga la vida útil del implante en un número específico de segundos (la vida útil predeterminada del implante es de 30 días). |
| 0xF601 | CRXQueryShowTables | Obtiene una lista de un directorio especificado con la API fts . |
| 0xF801 | CRXFetchRecordInfo | Recupera metadatos (atributos, permisos, tamaño, creación, modificación y marcas de tiempo de acceso) de un archivo determinado. |
| 0xF501 | CRXFetchRecord | Recupera el contenido de un archivo especificado. |
| 0xFC10 | CRXPollRecords | Comienza a monitorear un directorio en busca de archivos cuyos nombres coincidan con una expresión regular especificada. |
| 0xFC11 | CRXStopPollingRecords | Detiene la ejecución del comando CRXPollRecords. |
| 0xFC01 | CRXFetchMatchingRecords | Recupera archivos que coinciden con una expresión regular especificada. |
| 0xF901 | Registro de actualización de CRX | Según el argumento iM del comando, escribe datos en un archivo o agrega un nuevo módulo al implante. |
| 0xFA02 | CRXRunRecord | Inicia un módulo con un nombre específico al cargar reflexivamente su ejecutable Mach-O. |
| 0xF902 | CRXActualizarEjecutarRegistro | Añade un nuevo módulo al implante y lo lanza. |
| 0xFA01 | CRXEliminar registro | Según los argumentos del comando, elimina un módulo de implante o elimina un archivo con un nombre específico. |
| 0xF402 | CRXGetSchemas | Recupera una lista de procesos en ejecución. |
| 0xFB44 | CRXPurgeRecord | Termina un proceso con un PID especificado, ya sea con SIGKILL o SIGSTOP, según los argumentos del comando. |
| 0xFD01 | N / A | Recupera información sobre las aplicaciones iOS instaladas |
| 0xFB03 | CRXGetIndexesV2 | Recupera las entradas del llavero del dispositivo infectado. Comienza a monitorear el estado de bloqueo de la pantalla y, cuando el dispositivo está desbloqueado, descarga los elementos del llavero de genp (contraseñas genéricas), inet (contraseñas de Internet), claves y tablas de certificados (certificados, claves e identidad digital) de /private/ Base de datos var/Keychains/keychain-2.db. Tenga en cuenta aquí que el código del implante puede funcionar con diferentes versiones de llavero, a partir de las que se utilizan en iOS 4. |
| 0xF401 | N / A | Recupera la información de ubicación de la víctima: coordenadas, altitud, rumbo (la dirección en la que se mueve el dispositivo) y velocidad. De forma predeterminada, este comando solo funciona si la pantalla del dispositivo está apagada. Sin embargo, el operador del implante puede anular esta restricción con un indicador de configuración. |
Hallazgos extraños
Mientras investigamos el implante TriangleDB, encontramos muchos detalles curiosos:
- Los desarrolladores se refieren al descifrado de cadenas como “descifrado” (ya que el método que realiza el descifrado de cadenas se llama +[CRConfig unmungeHexString:]);
- A lo largo del código, observamos que diferentes entidades recibieron nombres de la terminología de la base de datos, razón por la cual llamamos al implante TriangleDB:
Entidad Terminología utilizada por el desarrollador para la entidad Directorio Mesa Archivo Registro Módulo de implante Proceso Esquema Entrada de llavero índice, fila servidor C2 Servidor de base de datos Información de geolocalización Estado de la base de datos Latido del corazón Datos de diagnóstico Proceso de intercambio de datos con el servidor C2 Transacción Solicitud al servidor C2 Consulta aplicación iOS Operación - Al analizar TriangleDB, encontramos que la clase CRConfig (usada para almacenar la configuración del implante) tiene un método llamado populateWithFieldsMacOSOnly. Este método no se llama en ninguna parte del implante iOS; sin embargo, su existencia significa que los dispositivos macOS también se pueden usar con un implante similar;
- El implante solicita múltiples derechos (permisos) del sistema operativo. Algunos de ellos no se utilizan en el código, como el acceso a la cámara, el micrófono y la libreta de direcciones, o la interacción con dispositivos a través de Bluetooth. Por lo tanto, las funcionalidades otorgadas por estos derechos pueden implementarse en módulos.
Indicadores de compromiso de TriangleDB
MD5 063db86f015fe99fdd821b251f14446d
SHA-1 1a321b77be6a523ddde4661a5725043aba0f037f
SHA-256 fd9e97cfb55f9cfb5d3e1388f712edd952d902f23a583826 ebe55e9e322f730f
Por Marcelo Lozano – General Publisher IT CONNECT LATAM
Lea más sobre Ciberseguridad en;
ChatGPT 100.000 cuentas comprometidas a la venta en la Dark Web
ChamelGang en Linux: Una expansión de capacidades de amenazas 2023
NETSCOUT lanza nueva plataforma Visibilidad sin Fronteras 2023
CVE-2023-27997: actualice YA el firmware de Fortigate
Comisión Nacional de Valores: hackeo 2023 deja al descubierto su fragilidad digital
TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB, TriangleDB,