Hace un par de semanas, el club alemán de computación Chaos Computer Club (CCC) publicó un informe del análisis de un troyano puerta-trasera que al parecer había usado la policía alemana durante las investigaciones para capturar la comunicación VoIP e IM del ordenador de un sospechoso. Nuestros amigos de F-Secure publicaron una entrada de blog la pasada semana en la que escriben sobre otro archivo que, según ellos, parecía el componente instalador (dropper) del troyano. Nuestros amigos fueron muy amables al compartir el hash MD5 del archivo con nosotros, para que podamos extraerlo de nuestra propia colección. Stefan y yo lo analizamos en detalle.
El instalador lleva otros cinco binarios entre sus recursos, lo que suma seis componentes en total, cada uno con un propósito distinto, y los analizamos todos. Entre las novedades que encontramos, hay dos que resaltan: en primer lugar, esta versión no sólo es capaz de ejecutarse en sistemas de 32 bit, sino que también es compatible con versiones de 64 bit de Windows. En segundo lugar, la lista de procesos meta a monitorear es más extensa que la mencionada en el informe del CCC. La cantidad de aplicaciones infectadas por los distintos componentes asciende a un total de 15.
Aplicaciones meta
Las anteriores discusiones de R2D2 mencionan a Skype como aplicación meta monitoreada por el troyano. La versión que nosotros hemos analizado también indica que Skype es una aplicación meta, así como conocidos navegadores de Internet, varias aplicaciones de mensajería instantánea y software voice-over-ip, como ICQ, MSN Messenger, Low-Rate Voip, Paltalk, SimpPro, Sipgate X-Lite, VoipBuster y Yahoo! Messenger. Esta es la lista de nombres de los procesos:
- explorer.exe
- firefox.exe
- icqlite.exe
- lowratevoip.exe
- msnmsgr.exe
- opera.exe
- paltalk.exe
- simplite-icq-aim.exe
- simppro.exe
- sipgatexlite.exe
- skype.exe
- skypepm.exe
- voipbuster.exe
- x-lite.exe
- yahoomessenger.exe
La inyección de códigos en los procesos meta la realiza el instalador, dos componentes modo-usuario y un controlador de núcleo de 32 bit con funcionalidad ampliada en comparación con la versión que analizamos anteriormente, que sólo ofrecía una interfaz para registro y modificaciones en el sistema de archivos. Este nuevo controlador inicia un hilo adicional que constantemente se enlaza con la lista vigente de procesos en ejecución e inyecta una DLL en aquellos cuyo nombre de imagen coincida con una entrada de la siguiente lista:
Figura 1: Lista de nombres de procesos meta en el controlador de núcleo de 32 bit
Todos los procesos meta que hemos detectado en los distintos componentes modo-usuario también están incluidos en el controlador.
Se han implementado dos métodos diferentes de inyección de DLL. Uno funciona registrando la biblioteca de modo-usuario en el registro de Windows como una DLL AppInit, de manera que se cargue durante el proceso de creación. El segundo crea un hilo remoto en procesos ya en ejecución e inyecta una porción de código de posición independiente (PIC) que mapea el archivo mfc42ul.dll en la memoria del proceso meta. La siguiente captura de pantalla muestra el primer par de instrucciones:
Figura 2: Código de posición independiente que carga una DLL en un proceso meta
Controlador de núcleo de 64 bit
Cuando el instalador instala el componente de modo núcleo, obtiene el nombre del recurso desde la arquitectura (32 o 64 bit) e instala el archivo apropiado:
Figura 3: Código para determinar y cargar el controlador de núcleo apropiado para la arquitectura
Al contrario de la versión de 32 bit, el controlador de 64 bit no contiene ninguna funcionalidad de infección de procesos, y sólo proporciona una rudimentaria interfaz de elevación de privilegios a través del sistema de archivos y el acceso al registro. Al igual que su par, crea un dispositivo e implementa un protocolo básico para comunicación con las aplicaciones de modo usuario.
Figura 4: Rutina de creación de dispositivos en el controlador de 64 bit
Se sabe que los módulos de núcleo de 64 bit deben llevar una firma digital válida que el sistema operativo pueda verificar, de lo contrario no se podrá cargar el controlador. El controlador que viene con el rootkit tiene un certificado1024 bit RSA (huella digital e5445e4a 9c7d24c8 43f0c669 e2a8d3a1 78cf7fa8)), emitido por Goose Cert el 11 de abril de 2010. Sin embargo, el certificado debe instalarse y la confiabilidad debe confirmarse para que el instalador funcione.
Figura 5: Certificado de controlador 64 bit
Kaspersky Lab detecta todos los componentes como variantes del troyano/rootkit R2D2 y ya antes detectábamos eurísticamente el instalador como un programa invasor y lo bloqueábamos.
El troyano Federal tiene un “hermano mayor”