El siguiente post es una traducción (con algunas adaptaciones idiomáticas) del texto realizado por Alexis Dorais-Joncas, publicado en el blog de ESET en inglés donde se realiza un estudio sobre un nuevo payload para sistemas OS X.

Este mes, investigadores de AlienVault e Intego reportaron sobre un nuevo tipo de ataque de malware que tuvo como objetivo al NGO tibetano (organización no gubernamental). El ataque consistía en inducir a la víctima a visitar un sitio web, el cual inyectaba un payload malicioso en su computadora utilizando la vulnerabilidad en Java CVE-2011-3544. El servidor web contenía un archivo JAR (archivo Java) para una plataforma específica el cuál se ejecutaba de acuerdo al UserAgent para infectar a usuarios de sistemas Windows o de sistemas OS X.

Si bien el archivo también se entregaba a clientes de sistemas Linux, al ser un payload específico para OS X, estos primeros no se vieron afectados. El análisis se focalizó en el propio payload y en el protocolo de red que utiliza para comunicarse con el centro de comando y control (C&C).

OS X utiliza archivos de formato Mach-O como ejecutables y en el caso del payload el Mach-O solo fue compilado para 64 bits, lo cual es inusual debido a que la mayoría de este tipo de archivos contienen ambas arquitecturas, des decir, tanto 32 bits como 64 bits.

Comenzando la investigación con la ejecución del payload, la amenaza se autocopia a "/Library/Audio/Plug-Ins/AudioServer" y a continuación se lanza un script nombrado "~/Library/LaunchAgents /com.apple.DockActions.plist" el cual apunta al archivo copiado para asegurar la ejecución cuando el usuario accede a su cuenta.

Cabe destacar que la configuración por defecto en OS X 10.7.3 no brinda a los usuarios regulares (sin permiso de administrador) permisos de ejecución en la ruta "/Library/Audio/Plug-Ins/AudioServer", por lo que esta amenaza no es de tipo persistente ya que no sobrevivirá a un reinicio del sistema. No estamos del todo seguros si versiones anteriores de OS X tienen diferentes permisos de archivos.

Continuando con el análisis, la amenaza intenta comunicarse con el centro de comando y control (C&C) y establece una conexión mediante el protocolo TCP a un puerto específico. El servidor responde con un TCP RST a menos que envíe alguna instrucción. Luego de esto el sistema infectado cae en un ciclo de espera, intentando reconectarse al servidor en intervalos aleatorios que van desde los 0 a los 10 segundos.

El servidor puede enviar alguna de las siguientes tres instrucciones al servidor:

  • Subir un archivo: El centro de comando y control envía la ruta del archivo y el cliente responde con el contenido del archivo
  • Descargar un archivo: el centro de comando y control envía la ruta y el contenido del archivo, y el cliente crea el archivo con los permisos establecidos en 777 (-rwxrwxrwx).
  • Iniciar una shell remota: el centro de comando y control envía un comando arbitrario para la Shell y el cliente responde con la salida obtenida por dicho comando.

Otro aspecto para destacar, es que toda la comunicación entre el cliente y el servidor está cifrada con AES y XOR.  La llave de cifrado AES es recibida del centro de comando y control. A pesar de que estas llaves se mantienen constantes durante la comunicación, se utilizan dos llaves XOR distintas, una para el tráfico entrante y otra para el saliente.

El malware no ejecutará ninguna instrucción a menos que el primer paquete enviado por el centro de comando y control coincida con la llave de 16 bytes de longitud. El cliente, además, envía la llave junto con la primer respuesta al centro de control. Esto puede apreciarse en la siguiente figura.

Captura hexadecimal

Finalmente, un hash personalizado basado en SHA1 es agregado a cada paquete de información que se envía entre el cliente y el centro de comando y control. La finalidad de esto es el chequeo de la autenticación y la integridad.

hash = SHA1(key1 + sha1(key2 + encrypted_packet_content + packet_number)) where key1 and key2 are two 64-byte strings derived from the first XOR key

Durante la investigación, se observó un diálogo en directo entre el centro de comando y una computadora de testeo. La velocidad y la naturaleza de las instrucciones recibidas desde el centro de comando y control nos hicieron creer que dichas instrucciones eran ingresadas por un humano. A continuación se exponen algunos fragmentos interesantes:

Comando Cookie

Comando Keychain

Comando ls

Luego de recorrer algunos archivos del sistema, el centro de comando y control se enfocó en dos objetivos: un archivo de Keychain y las cookies de Safari. Evidentemente, se buscaba robar información.

Un gran esfuerzo fue puesto en el diseño del protocolo de red. Los operadores de esta amenaza tuvieron un interés muy grande en ocultar la forma de comunicación para dificultar la ingeniería reversa. Sin embargo el método de cifrado simétrico que se utilizó permite reproducir diálogo de forma directa.

Este tipo de ataque nos permite recordar que se debe mantener actualizado el sistema operativo ya que Apple liberó el parche para esta vulnerabilidad en Java para los sistemas Mac OS X 10.7 and Mac OS X 10.6 en Noviembre del 2011.

Todos los productos de ESET (incluido ESET Cybersecurity para Mac) a partir de la firma 7001 detectan esta amenaza como OSX/Lamadai.A.