Memoria falsa para engañar al antimalware: nuevos desarrollos en rootkits

Rachit Mathur, investigador sénior de antivirus en McAfee, está investigando lo que él cree que es una variante del rootkit TDL3 conocido por ocultar el infame virus Google Redirect. Sin embargo, se comporta de manera extraña. Mathur explicó:

Es muy interesante ver que algunas herramientas anti-rootkit no muestran ganchos de programación que normalmente son fáciles de identificar. Además, el malware no permite que se rompa el depurador externo (WinDbg), lo cual es molesto.

Mathur agregó:

¡La razón por la que no se informa el gancho es que la memoria que está leyendo la herramienta no es memoria real!

Aparentemente, la motivación de los autores de malware para usar tales técnicas es evitar que las herramientas muestren sus ganchos para que los administradores no se alarmen por actividades sospechosas.

¿como puede ser?

Inmediatamente me pregunté: «¿Cómo diablos se le ocurrió esto?»

Su pasado proporciona pistas. El Sr. Mathur tiene una maestría en ciencias de la computación y se especializa en ingeniería inversa, transformación de programas y morphing de malware. Además, ha publicado en numerosas ocasiones: Journal of Computer Virology, Virus Bulletin, International Conference on Information Warfare y IEEE International Symposium on Source Code Analysis and Manipulation.

Esto también explica los detalles que cubrió en una publicación de blog de McAfee Labs: Rookit’s Memory Forging Attempts. Estoy tratando de entender. Sin embargo, los punteros, la configuración del registro y las rutinas de depuración me ayudaron mucho. Sabiendo que esto era demasiado importante como para arruinarlo, pedí la ayuda del Sr. Joris Evers de McAfee Corporate PR y del Sr. Ian Bain de H3O Communications para contactar al Sr. Mathur.

Casner: Lo admito. No entiendo cómo funciona la falsificación de memoria. En términos sencillos, ¿puedes describir lo que sucedió?
Mathur: Permítanme proporcionar algunos antecedentes. Los rootkits suelen modificar ciertas áreas de la memoria del sistema operativo (SO) en ejecución para secuestrar el control de ejecución del sistema operativo. Hacerlo obligaría al sistema operativo a proporcionar resultados inexactos al software de detección (antivirus, anti-rootkit).

Por ejemplo, un rootkit puede ocultar archivos, registros, procesos, etc. del software de detección. Por lo tanto, los rootkits suelen modificar la memoria. Las herramientas anti-rootkit examinan las regiones de la memoria para identificar dichas modificaciones sospechosas y advertir a los usuarios.

Este rootkit en particular también modifica las ubicaciones de la memoria (ganchos de montaje) para evitar que el software de detección acceda correctamente al disco. Digamos que la posición es X. Vale la pena señalar que se sabe que esta ubicación X ha sido modificada por otras familias de rootkits y no es exclusiva de este rootkit en particular.

Ahora, dado que se sabe que los rootkits suelen cambiar el contenido de la ubicación X, la mayoría de las herramientas anti-rootkit verifican el contenido de la ubicación de memoria X para ver si se ha modificado.

Casner: Siento interrumpir, pero quería mencionar que aquí es donde se cuela el rootkit.
Mathur continúa: En el caso de este rootkit en particular, el rootkit movió el contenido original (esperado) de la ubicación X a una ubicación Y diferente. Cuando una herramienta anti-rootkit intenta leer el contenido de la ubicación X, siempre que el contenido sea de la ubicación Y. Por lo tanto, las herramientas anti-rootkit piensan que todo es como debe ser y no advierten a los usuarios sobre actividades sospechosas.
Casner: Usted mencionó las posiciones X e Y. Mi pensamiento inmediato es: si el antimalware verifica la ubicación X, ¿por qué coloca información de malware allí?
Mathur: El malware cambia el contenido de la ubicación X porque el sistema operativo (SO) usa la ubicación X para llamar al código específico del sistema operativo para manejar el acceso al disco. De esta forma, durante un acceso al disco, el malware puede decidir si permitir el acceso a un archivo solicitado por el programa o implantar un código malicioso. Esto se denomina gancho de programación o gancho IRP.
Casner: ¿Está diciendo que el malware es lo suficientemente inteligente como para saber qué programa quiere acceder a la ubicación X? Guau. No me atrevo a preguntar, pero ¿cómo lo hace?
Mathur: El malware definitivamente necesita determinar el origen de la consulta de lectura. Solo entonces se asegura de que el sistema operativo lea el contenido «real» de la ubicación X y eventualmente invoque un código de malware que verifique el acceso al disco. Mientras que otros programas (incluidos los programas antivirus) leen el contenido «falso» de la ubicación Y.

Cuando se produce un acceso de lectura en la ubicación X, se activa una excepción porque se establece un punto de interrupción del hardware de la CPU. Dado que el malware también modifica una variable del sistema operativo llamada KiDebugRoutine, el código del malware obtiene el control cuando se activa dicha excepción.

Aquí, el malware pudo determinar la dirección de la instrucción que estaba tratando de leer. El malware compara esta dirección con una lista de direcciones predefinidas a las que el malware desea permitir el acceso. Estas direcciones pertenecen al sistema operativo o al propio malware.

Si la dirección de la instrucción que ejecuta la lectura coincide con una de las direcciones predefinidas, el malware no falsifica la memoria. El código para hacer esto se puede ver en el blog en la figura «KiDebugRoutine Handler: Snippet 3».

El siguiente código se compara con una de esas direcciones predefinidas. Si coincide, la excepción se establece como manejada sin falsificar la memoria y la ejecución continúa leyendo el contenido «real»:

cmp eax, dword_41D810; compare EIP con una ubicación predefinida que permita leer la memoria correcta

jz loc_403BC5; establecer en procesado y devolver

Casner: ¿Este rootkit tiene un nombre?
Mathur: McAfee lo detectó como TDSS.e!rootkit.
Casner: Estoy realmente curioso. ¿Cómo puede estar seguro de que un rootkit está falsificando la memoria?
Mathur: Al analizar esta muestra de malware, algunas herramientas comunes no informaron ninguna actividad sospechosa similar a la de un rootkit. Sin embargo, un análisis y una depuración posteriores revelaron que, de hecho, hay un gancho. Además, está en una ubicación de memoria que estas herramientas suelen comprobar. Sin embargo, no reportaron haber encontrado un anzuelo. Es raro y me llamó mucho la atención.

Afortunadamente, la implementación del malware no es perfecta. Esto se hizo evidente en mi investigación. He observado que dos métodos diferentes para verificar la misma región de memoria devuelven resultados diferentes. Esta es una pista inesperada.

Como sabíamos lo que buscábamos, rápidamente nos dimos cuenta de que un punto de interrupción de hardware (registro DR0) estaba configurado en la posición X y el malware estaba tratando de protegerlo. El resto es la típica ingeniería inversa para conocer los detalles de su funcionamiento.

Casner: ¿Es esto lo que podemos esperar? ¿O los desarrolladores de malware recurrirán a algo diferente ahora que sabe que está «furioso» ahora?
Mathur: Buena pregunta. Ahora que se sabe que esta técnica tiene un uso generalizado, estamos seguros de que las herramientas anti-rootkit agregan funciones para abordar esto, como buscar puntos de interrupción de hardware o encontrar ganchos KiDebugRoutine antes de acceder a la memoria.

Debido a la necesidad de establecer puntos de interrupción de hardware, uno no esperaría que esta técnica se pusiera al día con muchas familias de malware diferentes. Porque, una vez que lo sabes, es fácil evitar caer en esta trampa.

Sin embargo, la actualización de la funcionalidad anti-rootkit lleva tiempo. Así que podríamos ver algunas versiones de malware usándolo. Además, nos gustaría ver cambios en los detalles de implementación.

Curiosamente, el malware sofisticado puede ser el primero en adoptar este enfoque. Si bien el malware menos sofisticado lo contiene, su uso se ha expandido más lentamente. Lo que realmente sucedió es una incógnita, pero estas parecen posibilidades plausibles.

Casner: Como usuarios, ¿cómo podemos evitar el malware que falsifica la memoria?
Mathur: desde la perspectiva del usuario, las precauciones generales, como la navegación segura y el mantenimiento del software actualizado, pueden ayudar. Además, es posible que sea necesario actualizar el software de detección para tener en cuenta esta situación. Por lo tanto, los usuarios deben obtener la última versión y tener siempre las últimas definiciones de antivirus.
Casner: En su blog mencionó que esta es una técnica conocida pero que no se usa activamente. ¿Hay otras tecnologías nuevas y astutas inminentes?
Mathur: Esta técnica se ha mencionado en el pasado, pero hasta ahora no ha habido informes de que sea utilizada por malware. Desafortunadamente, todavía tenemos que ver la última tecnología de este tipo. Esperamos que los autores de malware continúen adoptando e innovando mejores formas de ocultarse.

Esto es lo que tenemos la intención de discutir en la reunión de anuncios de virus de este año y nuestras predicciones sobre lo que podría suceder.

pensamientos finales

El juego del gato y el ratón continúa. Gracias a personas como el Sr. Mather, tenemos la oportunidad de luchar.