rootkits. - udc
TRANSCRIPT
.RootKits.
Pablo Iglesias Morales Máster en Informática
Facultad de InformáticaUniversidad de A Coruña
Junio 2008
1 Introducción............................................42 Historia de las Rootkits................................43 Rootkits && Malware.....................................64 Objetivos de los rootkits...............................85 Tendencias en tecnología de rootkit.....................85.1 Tendencia 1: Además de a los troyanos, los rootkits afectan a otras formas de malware y PUP.................85.2 Tendencia 2: Los rootkits son cada vez más sofisticados............................................95.3 Tendencia 3: Los rootkits incorporados en Windows ganan ventaja...........................................95.4 Tendencia 4: Se han encontrado vectores de ataque de rootkits en software legal e ilegal.................105.5 Tendencia 5: La incorporación de tecnologías de ocultación es cada vez más fácil.......................11
6 Tipos de Rootkits en la plataforma Windows.............136.1 Rootkits en modo de usuario......................146.1.1 Vectores de instalación......................146.1.2 Inyección a través de extensiones de aplicaciones.........................................156.1.3 Inyección a través de filtros de mensajes de Windows..............................................156.1.4 Inyección a través del subsistema de depuración.....................................................166.1.5 Inyección a través de vulnerabilidades en aplicaciones.........................................16
6.2 Técnicas de carga destructiva....................166.3 Interceptación de la tabla de direcciones de importación............................................176.3.1 Interceptación de funciones en línea.........19
6.4 Rootkits en modo kernel..........................206.4.1 Técnicas destructivas de rootkits en modo kernel...............................................20
6.4.1.1 Modificación de la tabla de descriptores de servicios del sistema (SSDT).......................206.4.1.1.1 Desventajas..........................216.4.1.1.2 Contramedidas........................22
6.4.1.2 Modificación directa de objetos del kernel...................................................226.4.1.3 Controladores de dispositivos de filtrado226.4.1.4 Modificación del gestor de servicios del sistema en modo de kernel..........................236.4.1.5 Ataque por desvío de código en tiempo de ejecución..........................................236.4.1.6 Modificación de la tabla de funciones IRP23
7 Detección .............................................247.1 Monitorización externa...........................247.1.1 Ejemplo:.....................................24
7.2 Análisis forense.................................257.3 Métodos de análisis estadístico..................257.4 Análisis de fallos de rootkits y comparación de resultados.............................................25
8 Protección.............................................269 Software antirootkit..................................2710 Ejemplo práctico.....................................2711 Bibliografía.........................................30
1 IntroducciónLos rootkits suponen una amenaza para los sistemas actuales. Las tecnologías de ocultación son cada día más sofisticadas y detectar los rootkits e impedir el daño que provocan es un gran reto. En este documento, distinguimos entre técnicas de ocultación, que son estrategias simples para ocultar archivos, procesos y actividades, y rootkit, término que se asocia a malware que oculta sus actividades.El término viene de la unión de "root" y de "kit". "Root" se refiere al usuario con máximos derechos en sistemas tipo *Nix (puede ser Unix, AIX, Linux, BSD, etc), es decir, el superusuario. Por su parte, "kit" se refiere a un conjunto de herramientas; por lo que un rootkit se puede entender como un conjunto de herramientas que se ejecutan con privilegios de root. [MCA06] [PAN08]
2 Historia de las RootkitsOriginalmente, un rootkit era simplemente un conjunto de herramientas que permitían el acceso a un equipo o red a nivel de administrador, también conocido como acceso raíz (root en inglés) en el entorno Unix. El término hacía referencia a un conjunto de herramientas Unix, como ps, netstat, ls y passwd. Un atacante informático podía utilizar estas mismas herramientas para ocultar todo rastro de intrusión, por lo que el término rootkit comenzó a asociarse a la ocultación. Cuando estas estrategias se aplicaron al entorno Windows, el nombre rootkit se transfirió con ellas. En la actualidad, rootkit es un término ampliamente utilizado para describir malware como troyanos, gusanos y virus que oculta, de forma activa, su existencia y sus acciones a usuarios y a otros procesos del sistema. La práctica de ocultar el malware de los usuarios y productos de seguridad se remonta al primer virus para PC, Brain, que apareció en 1986. Para evitar ser detectado, Brain interceptaba las interrupciones del sector de arranque del PC y redirigía las operaciones de lectura a otro sector del disco. Los autores de virus pronto se dieron cuenta de que la longevidad de un virus dependía esencialmente de las técnicas de ocultación cuando, en 1987, el virus Lehigh pudo neutralizarse rápidamente tras su lanzamiento debido a que no utilizaba estas técnicas. Los autores de malware siguieron desarrollando virus DOS cada vez más complejos hasta finales de los 80, principios de los 90, incorporando innovadoras técnicas de ocultación para impedir su detección. Dos de los métodos más habituales eran interceptar las interrupciones de E/S de disco en la BIOS para llamadas de lectura (INT 13) y sustituirlas por resultados modificados, y desinfectar continuamente un sector del disco cada vez que se iniciara un programa, incluido un analizador antivirus, volviendo a infectar el sector del disco una vez que éste se hubiera cerrado.
El virus de sector de arranque Tequila, que surgió en 1991, y el virus infector de archivos 1689 Stealth, introducido en 1993, empleaban estas técnicas para ocultar el aumento de tamaño de los archivos, indicio claro de infección. Otros virus DOS posteriores interceptan funciones de más alto nivel, como llamadas a controladores DOS, para ocultar su presencia o mantener la infección.La aparición de Windows a mediados de los 90 trajo consigo la inmunidad a los virus DOS y un breve período de inactividad en cuanto a innovación de técnicas de ocultación. Antes de idear nuevas formas de burlar la protección, los autores de virus tuvieron que aprender a utilizar las interfaces de programación de aplicaciones de Windows y la arquitectura de memoria protegida. La aparición de los troyanos NTRootkit, a finales de 2001, y HackerDefender, en 2003, marcó el final de la tregua. Estos troyanos se "enganchaban" al sistema operativo en un nivel muy bajo de llamadas a funciones, lo que les permitía ocultar su presencia.A medida que han evolucionado los entornos informáticos, también lo han hecho las tecnologías de ocultación. Se han desarrollado diversas técnicas, como el uso de convenciones de denominación engañosas o la manipulación de la red, entre otras, con el fin de ocultar el malware a simple vista. Una de las más simples y más efectivas es cambiar el nombre de un archivo infectado de forma que parezca un archivo legítimo del sistema o del usuario. El troyano scvhost.exe o svehost.exe puede residir en el directorio system32 de Windows junto al archivo original llamado svchost.exe. Del mismo modo, puede ejecutarse un troyano llamado svchost.exe desde los directoriosWindows o WINNT. El gran parecido con los nombres de archivo reales, en el primer caso, y el hecho de que el usuario ignore que el archivo original debería estar en el directorio system32 de Windows, en el segundo, confunden al usuario, que cree que los archivos troyanos son de confianza. La llegada de Internet trajo nuevas oportunidades y facilidades tanto para agresores como para defensores de la seguridad. Para los autores de malware, introdujo nuevas vías de propagación y proporcionó millones de víctimas potenciales. Para los defensores de sistemas, ofreció nuevos métodos de detección a través de la red en tiempo real con sistemas de prevención de intrusiones (IPS, Intrusión Prevention System) y otros dispositivos de supervisión del tráfico para vigilar los síntomas que revelan la presencia de actividad maligna. Hoy día, una tecnología de ocultación eficaz debe ocultar o proteger los archivos, los procesos y las entradas del registro. Cada vez más, el malware se ve obligado a ocultar su rastro mediante la manipulación de paquetes sin procesar en la red, la pila TCP/IP, el protocolo TCP/IP y la BIOS con el fin de eludir algunas de las tecnologías de seguridad más avanzadas. [MCA06]
3 Rootkits && MalwareEl malware o software maligno se presenta de formas distintas. Sin embargo, hay diferencias claras entre virus, troyanos, gusanos y programas potencialmente no deseados (PUP, Potentially Unwanted Programs). Los virus, como sus análogos biológicos, son programas que se replican automáticamente y que pueden ocultar información confidencial, bloquear los recursos del sistema, destruir información o realizar otros actos malignos. Los troyanos son programas que parecen aplicaciones de software inofensivas o incluso útiles a simple vista, pero que en su interior albergan código malintencionado. Aunque los troyanos no se auto replican, pueden hacer que un equipo infectado descargue otro malware que sí lo haga. Los gusanos son malware que se replica mediante la distribución de copias a través de una red compartida, una unidad de disquetes o incluso una unidad USB, a menudo de forma autónoma sin necesidad de intervención humana. Aunque se parecen a los troyanos y a otro software maligno en que suelen apoderarse de información confidencial y privada, los PUP son diferentes, ya que se instalan y ejecutan con la aprobación tácita del usuario.No obstante, la tecnología de ocultación no es de dominio exclusivo del malware. Su empleo ha aumentado en aplicaciones de software comercial y PUP que pretenden impedir ser eliminados. En abril de 2005, AdwareIsearch fue uno de los primeros programas de publicidad no deseada o adware que, según se descubrió, utilizaba tecnologías de ocultación. Desde entonces, se han descubierto otros, como Apropos, Qoolaidy DigitalNames, todos ellos clasificados como troyanos por suponer una amenaza importante para el usuario.La idea de clasificar todos los programas que emplean técnicas de ocultación como rootkits es tentadora, pero si lo hiciéramos se perdería la claridad y efectividad de la descripción. Existen proveedores que han optado por clasificar el software comercial que emplea técnicas de ocultación como PUP, en lugar de rootkits. Sin embargo, otros integrantes de la comunidad de seguridad consideran que cualquier uso de la ocultación está injustificado y por lo tanto merece el término rootkit y sus connotaciones negativas. Este debate puramente teórico se convirtió en una polémica con una gran repercusión mediática cuando Mark Russinovich publicó su hallazgo en su blog el 31 de octubre de 2005. El software de gestión de derechos digitales de Sony BMG, Extended Copy Protection (XCP), fue blanco de críticas debido al uso que hacía de tecnologías de ocultación que exponían a los equipos a posibles ataques. XCP incorpora una implementación de controlador de dispositivo que incluye privilegios a nivel de kernel. Este controlador oculta archivos y procesos de gestión de derechos digitales para que el usuario no pueda desactivarlos y realizar copias ilegales de archivos de música. Para conseguir esta
protección, se escribió código kernel que ocultaba cualquier archivo, carpeta o proceso que comenzara por la cadena "$sys$"Desgraciadamente, cualquier software maligno que tuviera esta cadena en su nombre también quedaría oculto para la mayoría de los analizadores de virus. Como cabría esperar, los autores de malware han aprovechado esta oportunidad y están escribiendo programas que utilizan el software instalado por Sony para ocultar sus archivos. Por ejemplo, se ha demostrado que las variantes del gusano W32/Brepibot, cuya presencia se comunicó en noviembre de 2005 y que se propaga a través de canales Internet Relay Chat (IRC), aprovechan esta vulnerabilidad. Esta aplicación comercial pone en duda la utilidad de denominar rootkits a todos los programas que emplean tecnologías de ocultación. Si la ocultación se está convirtiendo en una tendencia dominante en software, probablemente el término rootkit debería reservarse exclusivamente para el malware que emplea técnicas de ocultación.Pero la controversia acerca de las técnicas de ocultación sigue vigente en la actualidad. El 10 de enero de 2006, menos de dos meses después del escándalo de XCP, la comunidad antivirus se vio conmocionada por la revelación de que Symantec había utilizado técnicas de ocultación en uno de sus productos con el fin de ocultar un directorio denominado NProtect. Aunque el riesgo potencial para la seguridad es menor que el que presenta XCP, NProtect guarda archivos en un directorio que los analizadores antivirus no pueden detectar. En teoría, los autores de malware podrían proteger sus archivos colocándolos en el directorio NProtect. Symantec defiende el uso de las técnicas de ocultación como una herramienta importante en la lucha contra el malware, pero muchos miembros de la comunidad reprueban que haya adoptado y legitimado las mismas tecnologías que sus adversarios distribuyen y promocionan. El debate relacionado con las técnicas de ocultación en software comercial continuó al conocerse que el motor antivirus de Kaspersky (KAV) empleaba tecnología iStreams. La tecnología iStreams mejora el rendimiento del analizador KAV almacenando la suma de comprobación de los archivos que ya se han analizado en los flujos alternativos de datos (ADS, Alternate Data Streams) de NTFS. Kaspersky aseguró que ocultar los flujos de NTFS no suponía ninguna amenaza, ya que son datos internos del programa y se reconstruyen si algún código o dato malintencionado los sobrescribe. Aunque esta técnica no implicaba ningún riesgo de seguridad importante, también fue muy criticada en los medios de comunicación. [MCA06]
4 Objetivos de los rootkits1. Ocultar los rastros de la entrada de un intruso en el
ordenador.2. Ocultar la presencia de procesos o aplicaciones
maliciosas.3. Ocultar las actividades dañinas como si fueran
realizadas por programas legítimos.4. Ocultar la presencia de exploits, backdoors.5. Almacenar información a la que un intruso no podría
tener acceso de otra manera.6. Utilizar al sistema comprometido como intermediario
para llevar a cabo otras intrusiones y/o ataques maliciosos.
5 Tendencias en tecnología de rootkitEn esta sección trataremos las razones que justifican el aumento en la adopción y diversidad de rootkits, la motivación de los creadores de rootkits y las tendencias tecnológicas que conformarán el futuro de los mismos. [MCA06]
5.1 Tendencia 1: Además de a los troyanos, los rootkits afectan a otras formas de malware y PUP
En los últimos años, la incidencia de tecnologías de ocultación en malware, PUP y aplicaciones comerciales es más de seis veces mayor. Como muestra el Gráfico 1, en 2005 las tecnologías de ocultación ya no se utilizaban exclusivamente en troyanos; aparecieron en otras formas de malware, así como en PUP y aplicaciones comerciales.
Gráfico 1: Aumento de las técnicas de ocultación en software
El aumento repentino de las tecnologías de ocultación puede atribuirse a esfuerzos conjuntos de investigación en línea.Sitios Web como www.rootkit.com contienen cientos de líneas de código de rootkit que, junto con los ejecutables binarios, pueden utilizarse fácilmente para incluirlos en malware.Algunos rootkits que se han observado durante su propagación se han tomado o modificado directamente de tecnologías de ocultación encontradas en estos sitios Web. Y lo que es peor, se han encontrado comentarios en blogs en estos sitios que incluso enseñan a los lectores cómo eludir la detección antivirus mediante la compilación de código fuente.
5.2 Tendencia 2: Los rootkits son cada vez más sofisticados
La colaboración no sólo facilita la divulgación de las tecnologías de ocultación. También fomenta el desarrollo de nuevas técnicas de ocultación, todavía más sofisticadas. Un factor que permite medir la complejidad de un paquete de software es el número de archivos que lo componen. Por ejemplo, si un paquete de rootkit denominado a.exe instala los archivos b.exe, c.dll y d.sys, en el que d.sys instala el componente de ocultación del rootkit, se considera que el número total de componentes es de cuatro. Suponemos que d.sys oculta o protege los demás archivos del paquete. El Gráfico 2 muestra cómo ha aumentado la complejidad de los rootkits en los últimos seis años. La complejidad de los rootkits conocidos aumentó en casi un 200 por ciento en 2005.
Gráfico 2: Distribución de técnicas de ocultación por familias de software
5.3 Tendencia 3: Los rootkits incorporados en Windows ganan ventaja
La mayoría de la actividad de rootkits observada en la actualidad tiene como objetivo la plataforma Windows. Tras alcanzar su máxima incidencia (casi un 70 por ciento) en 2001, la actividad de ocultación basada en Linux es ahora insignificante. Aunque casi con toda seguridad los rootkits basados en Linux no van a desaparecer, los basados en Windows dominarán el escenario en un futuro cercano, debido principalmente a la popularidad de Windows y al desafío técnico que suponen las numerosas interfaces de programación de aplicaciones (API) no documentadas de Windows. El Gráfico 3 muestra el crecimiento de los rootkits "puros" en Windows, y la tendencia a incluirlos en otras categorías de malware. Observado por primera vez en 2001, NTRootkit y sus variantes siguieron propagándose hasta 2005. Los rootkits HackerDefender, AFXRootkit y PWSProgent aparecieron por primera vez en 2003. HackerDefender ha mostrado un
crecimiento importante en los últimos años, mientras que las variantes de AFXRootkit y PWSProgent fueron detectadas solamente a finales de 2005. Los rootkits relativamente avanzados, como FURootkit, están entre los más predominantes en este momento.
5.4 Tendencia 4: Se han encontrado vectores de ataque de rootkits en software legal e ilegal
La versatilidad de las tecnologías de ocultación ha propiciado su propagación a casi cualquier vector de ataque con malware conocido. Su popularidad ha convencido incluso a los proveedores de software comercial, que han comenzado a incorporarlas a sus productos. Como se puede observar en el gráfico, los vectores de inyección de tecnología de ocultación cubren ahora el espectro de métodos de distribución de software que abarca desde ataques que no requieren la intervención del usuario hasta las aplicaciones de confianza que instala el propio usuario. Algunos ejemplos de rootkits muy conocidos y sus vectores de ataque demuestran esta amplia cobertura. BackdoorBAC se ha distribuido a través de mensajes de spam, troyanos de descarga (downloader) y ataques directos que aprovechan vulnerabilidades (exploits). HackerDefender se distribuye generalmente a través de spam, bots, ataques directos que aprovechan vulnerabilidades y aplicaciones para compartir archivos. Se ha observado que algunos rootkits se descargan a través de gusanos de envío masivo para crear complejos ataques combinados. Otros, se propagan a través de archivos adjuntos de correo electrónico, redes p2p o mediante paquetes de software (como PUP).Un ejemplo de este tipo de software es el ejecutable build2.exe, que se detectó como AdwareIsearch. Agrupaba una utilidad de búsqueda en el equipo y un complemento de Firefox, y creaba iconos que promocionaban el programa antispyware spywareavenger (www.spywareavenger.com) y el programa antivirus VirusHunter (www.virushunter.com). Sin embargo, el paquete contenía también un programa de adware, aBetterIntrnt, que descargaba una utilidad. Posteriormente
esa utilidad instalaba otros programas de adware en el equipo. Por último, AdwareIsearch liberaba un rootkit a nivel de kernel para proteger todos los archivos que se habían instalado, de forma que no pudieran ser eliminados por el usuario, por un analizador antivirus o por un analizador antispyware.Últimamente, las tecnologías de ocultación se propagan a través de vectores de software comercial, es decir, programas de confianza, como ha sido el caso de la distribución de XCP. La mayoría de los usuarios permitieron, sin saberlo, la instalación en sus sistemas de la tecnología de ocultación de XCP porque se trataba de una aplicación de confianza y deseaban escuchar la música con derechos de autor de los CD de Sony, creando vulnerabilidades de seguridad graves durante el proceso.
Gráfico 3: Diversidad de vectores de ataque: canales que emplean los rootkits para propagarse
5.5 Tendencia 5: La incorporación de tecnologías de ocultación es cada vez más fácil
Gracias a la disponibilidad del código de los rootkits y los kits de creación de tecnologías de ocultación, los autores de malware pueden ocultar fácilmente procesos, archivos y registros, sin necesidad de tener conocimientos detallados del sistema operativo de su objetivo.
En figura puede apreciarse lo fácil que resulta: la interfaz de usuario del kit de creación de ocultación Nuclear Rootkit sólo requiere un nombre de archivo o directorio y con sólo hacer clic emplea distintas técnicas de ocultación para crear código binario personalizado que
oculta el archivo o directorio, así como los puertos, procesos y entradas del registro.
Aunque el kit de creación de ocultación descrito se puede descargar de forma gratuita, cualquiera puede comprar otros kits de creación de ocultación personalizados más complejos, como A311 Death y la edición de lujo de HackerDefender. El éxito del fraude de tipo phishing de BackdoorBAC (alias Haxdoor y A311 Death) puso de manifiesto las implicaciones de esta facilidad de acceso. El troyano le proporcionó al autor miles de números de identificación personal bancaria (PIN), contraseñas y otros datos confidenciales. Motivados por la recompensa financiera y los costes iniciales relativamente asequibles, los piratas informáticos y autores de malware siguen escribiendo nuevos rootkits que eluden la detección de los analizadores antivirus y otros productos de seguridad. La colaboración en línea de estos malhechores supone un reto importante para la comunidad de seguridad, ya que cada vez es más difícil prevenir, detectar y eliminar este malware cada día más sofisticado.
A continuación, analizaremos las tecnologías que hacen posible la ocultación en la plataforma Microsoft Windows. Tras una breve explicación de la arquitectura de seguridad básica de Windows, examinaremos la diversidad de métodos descubiertos para ocultar archivos, procesos y claves de registro. Comenzaremos por los rootkits en modo de usuario, que funcionan con el mismo nivel de privilegios que el usuario que los instaló. A esta categoría pertenecen la mayor parte de las tecnologías de ocultación conocidas hasta la fecha. Los rootkits que obtienen privilegios superiores, a nivel del sistema, no son tan comunes, sin embargo resultan muy difíciles de eliminar, ya que sus procesos disponen de privilegios de sistema. Para terminar, describiremos esta última tendencia en tecnologías de ocultación.
6 Tipos de Rootkits en la plataforma Windows[MCA06]
La arquitectura i386 admite cuatro anillos, o niveles de privilegios, (numerados del 0 al 3) para impedir que código con privilegios inferiores sobrescriba los datos y el código del sistema, ya sea de forma accidental o malintencionada. El anillo 0 es el nivel mas elevado de privilegios, y el anillo 3 es el más básico. Windows emplea dos niveles de privilegios (anillos 0 y 3) para la seguridad de los procesos y los datos. Gracias al uso de sólo dos niveles de privilegios, Windows puede ejecutarse en arquitecturas de CPU que no admiten los cuatro niveles.A continuación se muestra una vista general de una ruta de ejecución de una aplicación en modo de usuario sencilla. Las aplicaciones de usuario solicitan constantemente recursos del kernel de sistema operativo y de hardware; estas interacciones las gestiona el sistema operativo. Para comunicarse con el kernel, las aplicaciones en modo de usuario utilizan llamadas API Win32, que se exportan mediante el conjunto de bibliotecas de vínculos dinámicos (DLL) que forman el subsistema Win32.Cuando se realiza una llamada de función al subsistema Win32, éste a su vez tiene las siguientes cuatro posibilidades:
• Gestionar la solicitud de forma local, dentro del espacio de usuario, y no realizar la llamada al kernel.
• Realizar una llamada a un servicio en modo de usuario, como csrss.exe, responsable de mantener en ejecución el subsistema Win32. Este proceso mantiene la información de estado de los procesos Win32 y devuelve información a las API que efectúan la llamada.
• Enviar una llamada de procedimiento remoto (RPC) a uno de los servicios de Windows en ejecución que actúe como servidor para esa interfaz RPC en concreto.
• Llamar a una API que necesite los servicios del kernel. Esta categoría de llamada API llama en realidad a la función correspondiente en la biblioteca ntdll.dll.
Ntdll.dll asigna las solicitudes API entrantes a sus servicios de kernel correspondientes a través de un mecanismo llamado distribución de servicios del sistema. La transferencia del control desde el modo de usuario al modo de kernel se efectúa a través de una función especial del procesador que puede ser una interrupción (INT 02E para Windows 2000 y los sistemas Windows NT anteriores) o instrucciones SysEnter/SysExit (para Windows XP y Windows Vista).Un rootkit debe alterar este flujo de ruta de ejecución normal para conseguir que prospere su implementación de ocultación. Esta modificación se puede realizar a través de un proceso que se ejecuta a nivel del sistema denominado
"interceptación" (en inglés, hooking, que significa "enganche"). La propia arquitectura de Windows admite numerosos métodos de interceptación de fácil implementación que le permiten mantener su flexibilidad y su capacidad de ampliación. Por lo general, los rootkits modifican los datos que devuelven las llamadas de funciones del sistema de Windows para ocultar sus archivos binarios, procesos y entradas del registro.
Gráfico 4: Interacción entre el modo de usuario y el modo de kernel de Windows para sistemas Win32
En función de dónde se ejecutan y en qué área del sistema se interceptan, la tecnología de ocultación de los rootkits se presenta de dos maneras: en modo de usuario y en modo de kernel. Los rootkits en modo de usuario son relativamente fáciles de detectar y reparar, ya que se ejecutan con privilegios de usuario. Por el contrario, los rootkits en modo de kernel, se ejecutan con privilegios de sistema, lo que complica más su detección y reparación.
6.1 Rootkits en modo de usuario[MCA06]
Los rootkits en modo de usuario sencillos (por ejemplo, Qoolaid) pueden pasar desapercibidos en las herramientas de gestión de procesos, como el Administrador de tareas de Windows, y llegar incluso a hacerse con el control del propio proceso de la herramienta. Sin embargo, su efectividad depende de su habilidad para ocultarse de los analizadores de virus y otras herramientas de seguridad.
6.1.1 Vectores de instalaciónPara alterar la ruta de ejecución del API utilizadas habitualmente, los rootkits en modo de usuario pueden ejecutarse dentro de otro proceso mediante la carga de una DLL en el espacio de memoria del objetivo. Sin embargo, no es preciso que el rootkit se ejecute dentro de la memoria del proceso interceptado. Un método alternativo de interceptación para el autor de malware es escribir código
arbitrario utilizando la función WriteProcessMemory de la API de Windows. A continuación se muestran los vectores de ataque de inyección de código más utilizados.
Gráfico 5: Vectores de ataque de inyección de código
Ahora veremos, brevemente, la diversidad de vectores a través de los cuales puede inyectarse el código de ataque. Todas estas técnicas dependen de interfaces API de Windows documentadas que se emplean habitualmente en utilidades, herramientas de desarrollo, depuradores y herramientas de seguridad, entre otras. Por consiguiente, la mera detección del uso de estas técnicas no constituye prueba suficiente de la presencia de un rootkit.
6.1.2 Inyección a través de extensiones de aplicaciones
El diseño del sistema operativo Windows, el Explorador de Windows e Internet Explorer permite ampliarlos mediante programación. Por ejemplo, modificando claves del registro, de forma que apunten al rootkit. Así, cada proceso que haga uso de ésta dll, también cargará la dll de rootkit que tendrá acceso al espacio de direcciones del proceso y podrá aplicar distintos métodos de interceptación del código de proceso y las secciones de datos.
6.1.3 Inyección a través de filtros de mensajes de Windows
El sistema de mensajería de Windows permite la instalación de filtros de mensajes con el fin de admitir una amplia variedad de funciones. Para instalar un filtro, Windows proporciona una interfaz que puede situar una determinada biblioteca en el espacio de direcciones de cada proceso.
• Se puede llamar a SetWindowsHookEx para que intercepte uno o varios eventos del sistema. Las interceptaciones se pueden definir para cualquier método de entrada o para cualquier mensaje de Windows que se genera para una única aplicación. Son blancos frecuentes las aplicaciones que se ejecutan en el mismo equipo que el subproceso que realiza la llamada. Todos los eventos interceptados son oportunidades que
tiene el rootkit de alterar los resultados de posteriores llamadas API.
6.1.4 Inyección a través del subsistema de depuración
El sistema de depuración que incluye Windows permite depurar una aplicación e influir en la ejecución de otra. Suponiendo que el usuario que ejecuta el depurador dispone de suficientes privilegios, es posible crear nuevos subprocesos de ejecución en un proceso de destino, así como leer y escribir desde su espacio de direcciones de memoria.
6.1.5 Inyección a través de vulnerabilidades en aplicaciones
Las aplicaciones de Windows utilizan muchos métodos para las comunicaciones entre procesos, además de la posibilidad de recibir tráfico a través de conexiones de red y archivos locales compartidos con otras aplicaciones. En general, las aplicaciones locales no se limitan a comunicarse entre sí, lo que multiplica las posibles vías de ataque. Si una aplicación contiene una vulnerabilidad de desbordamiento de búfer o confía en un archivo local que puede modificar otra aplicación, el malware puede hacerse con el control del código que ejecuta dicha aplicación.
6.2 Técnicas de carga destructiva[MCA06]
Una vez que una DLL se carga en el espacio de direcciones de la víctima, el rootkit en modo de usuario intercepta y modifica el resultado de una función API para ocultar su existencia y la de los objetos que contiene.Para esta intercepción se emplea una de las siguientes técnicas: interceptación de la tabla de direcciones de importación (IAT, Import Address Table) o interceptación de funciones en línea.
6.3 Interceptación de la tabla de direcciones de importación
Vamos a analizar la estructura de un encabezado de un archivo ejecutable portátil.
Gráfico 6: Formato de archivo ejecutable portátil
La sección de datos de importación, idata, contiene direcciones de funciones importadas. Cuando se compila un programa, no todas las llamadas API que contiene se vinculan a los módulos de biblioteca en los que residen. Estas llamadas API se redirigen a través de la tabla de direcciones de importación (IAT) utilizando instrucciones de lenguaje ensamblador estándar. Cuando el proceso carga memoria binaria, resuelve las direcciones de la tabla IAT, de manera que las instrucciones se redirigen a las nuevas direcciones. Esta arquitectura permite la portabilidad del código binario a distintos sistemas operativos sin necesidad de recompilar.Una vez dentro del espacio de direcciones del proceso al que se dirige el ataque, la DLL del rootkit puede analizar el formato del archivo ejecutable portátil y encontrar la ubicación de la función de destino dentro de la tabla IAT. A partir de ahí, resulta muy fácil sustituir la función de destino por una de intercepción desde el código del rootkit. El resultado es que cada vez que se ejecuta una llamada a la API de destino, se ejecuta el rootkit y se alteran los datos que se transmiten a/o desde la función de destino. (Estas técnicas se pueden utilizar para interceptar cualquier API, no sólo kernel32.dll)
Gráfico 7: Rutina de interceptación por modificación de la tabla IAT
6.3.1 Interceptación de funciones en líneaLa interceptación de funciones en línea se distingue de la que afecta a la tabla IAT en que redirige la llamada al código del atacante, modificándolo una vez que el código real se encuentra en las DLL principales del sistema. El rootkit modifica solamente los primeros bytes de la función dentro de las DLL principales del sistema (kernel32.dll y ntdll.dll), incluyendo una instrucción de manera que las llamadas del proceso pasen primero por el rootkit. Como en el caso de la interceptación que emplea la tabla IAT, el código del rootkit comprueba si los parámetros indican la necesidad de falsificar los resultados y, a continuación, actúa en consecuencia.
Gráfico 8: Rutina de interceptación de funciones de línea
6.4 Rootkits en modo kernel[MCA06]
La programación en modo de kernel la utilizan habitualmente aplicaciones legítimas, como controladores de dispositivos del sistema y programas antivirus. Los controladores de dispositivos del sistema emplean programas de modo de kernel para acceder a objetos y funciones de kernel de nivel bajo, así como para controlar el hardware subyacente. Las herramientas antivirus emplean programas en modo de kernel para supervisar los cambios en todo el sistema y acceder a los permisos a nivel de kernel con el fin de proteger contra actividades malintencionadas que pueda desarrollar cualquier archivo. Para los productos de seguridad, la ejecución en modo de kernel presenta la ventaja añadida de que la mayoría de los procesos en modo de usuario no pueden eliminar el programa.El siguiente paso lógico de la tecnología de rootkit es operar en modo de kernel con privilegios de sistema. Operando al mismo nivel de privilegios que las herramientas de seguridad, los rootkits evitarán de manera más eficaz su detección y eliminación.Necesitan que su código se cargue en el espacio de direcciones del kernel, algo que por lo general consiguen mediante la instalación de un controlador de dispositivo en modo de kernel. Una vez que el mecanismo está en funcionamiento, los rootkits en modo de kernel pueden implementar varias interceptaciones de llamadas API. Este método es similar a la táctica empleada por los rootkits en modo de usuario, con la salvedad de que para las interceptaciones se utiliza un nivel de privilegios superior.
6.4.1 Técnicas destructivas de rootkits en modo kernel
Aunque hay muchos tipos de rootkits en modo de kernel, debido a su complejidad y su limitada compatibilidad no han conseguido más popularidad que los ataques en modo de usuario.
6.4.1.1 Modificación de la tabla de descriptores de servicios del sistema (SSDT)
Las API en modo de usuario, se implementan en kernel32.dll, que llama a la API nativa implementada en ntdll.dll. ntdll.dll llama a su vez a la instrucción del procesador INT 2e/SYSENTER para transferir el control al modo de kernel tras definir el índice de funciones de destino en un registro de procesador (EDX). En modo de kernel, el gestor de distribución de servicios del sistema, que reside en ntoskrnl.exe, emplea el índice de funciones del registro EDX para localizar la función de kernel del sistema correspondiente dentro de la tabla de descriptores de servicios del sistema (SSDT, System Service Descriptor Table). Dentro del kernel, los controladores de
dispositivos llaman a las funciones Zwxxx que residen en ntoskrnl.exe. Estas funciones definen el registro EDX con el índice de funciones de destino y, a continuación, llaman al gestor de distribución de servicios del sistema en modo de kernel, que a su vez busca la función de destino dentro de la tabla SSDT a través del índice de funciones de los registros EDX.
A través de la modificación del contenido de la tabla SSDT para que señale a una función de sustitución del rootkit , todas las llamadas API, con independencia de su procedencia (aplicación en modo de usuario o controlador de dispositivo en modo de kernel), se pueden redirigir para llamar primero al código del rootkit. Aproximadamente el 50% de los rootkits observados en circulación implementan este técnica.
6.4.1.1.1 DesventajasAunque relativamente más sofisticada que las técnicas de rootkit en modo de usuario, la modificación de la tabla SSDT presenta la desventaja de que puede ser detectada por la mayoría de los analizadores de memoria que emplean detección basada en firmas Un analizador puede realizar una búsqueda de patrones conocidos en la memoria para eliminar los rootkits.
6.4.1.1.2 ContramedidasCada proceso que se ejecuta en memoria tiene una entrada en una. Los procesos que se ocultan mediante las modificaciones de la tabla SSDT pueden ser descubiertos fácilmente ejecutando una consulta en los elementos de esta lista. Los resultados de la consulta pueden compararse con la lista de procesos en ejecución que se obtiene a través de aplicaciones en modo de usuario como el Administrador de tareas de Windows.
6.4.1.2 Modificación directa de objetos del kernel
Para superar las limitaciones de la técnica anterior, aparece un mecanismo más sofisticado llamado modificación directa de objetos del kernel (DKOM, Direct Kernel Object Modification). Esta idea ha complicado de nuevo la tarea de las herramientas de detección. Los rastros que deja un rootkit en ejecución, excepto los de archivos, pueden ocultarse directamente mediante la manipulación de los objetos del kernel que almacenan listas de procesos en ejecución, subprocesos, servicios, puertos, controladores y gestores. Es posible cortar y volver a componer las listas vinculadas sin que por ello se vea afectada su funcionalidad. El rootkit también puede modificar los objetos del kernel llamando directamente al Administrador de objetos de Windows. De esta forma, por ejemplo, este administrador puede modificar un objeto identificador, para que el rootkit pueda ocultar un proceso a los servicios de enumeración de procesos de sistemas estándar mediante la eliminación de la entrada del proceso de la lista PsActiveProcessHead. El autor del rootkit puede utilizar el mismo método en otras listas de objetos del sistema.
6.4.1.3 Controladores de dispositivos de filtrado
Un controlador de dispositivo de filtrado se sitúa en la parte superior de la pila de E/S de un controlador de dispositivo existente (Device Driver). Un controlador de dispositivo se puede conectar al controlador del sistema de archivos NT o al controlador de TCP/IP. Mediante esta técnica, se pueden interceptar y modificar todas las solicitudes de red o del sistema de archivos (procedentes de un proveedor de servicios por capas). Dado que, para poder ser eficaces, los productos de seguridad también se instalan como controladores de filtrado, los controladores de filtrado del rootkit deben conectarse a la pila de E/S por debajo del controlador de seguridad, de manera que reciban la llamada antes que cualquier controlador de filtro de producto de seguridad. La primera vez que se observaron controladores de filtro en circulación fue en septiembre de 2005, con el descubrimiento del troyano WinKRootkit. El controlador de filtro se carga al iniciar el sistema, antes de que se inicie el analizador antivirus,
por lo que es muy difícil eliminar los archivos que protege una vez que se ha reiniciado el sistema. Debido a que hay capas añadidas, el siguiente paso lógico para ocultarse de los analizadores tradicionales puede ser añadir un controlador de filtro delante de la capa del analizador antivirus. Esta técnica ofrece al analizador una visión irreal de los datos.
6.4.1.4 Modificación del gestor de servicios del sistema en modo de kernel
Una intercepción en el mecanismo de transición entre modo usuario y modo kernel permite al rootkit interceptar todas las llamadas a funciones que se realizan a través de la tabla SSDT. Por lo tanto, esta técnica puede interceptar el gestor INT 2E, o en el caso de versiones más recientes de Windows, el gestor SYSENTER.
6.4.1.5 Ataque por desvío de código en tiempo de ejecución
A diferencia de la técnica DKOM, el ataque por desvío de código en tiempo de ejecución modifica el código en lugar de las estructuras de los datos.Mediante la modificación de la memoria del kernel para que señale al código del rootkit en lugar del código normal, el rootkit puede interceptar funciones del kernel arbitrarias. De esta forma pueden interceptarse llamadas del sistema esenciales, como las comprobaciones de privilegios y autenticación, y sustituirse posteriormente por código que siempre devuelve privilegios de acceso total. Estas interceptaciones pueden sustituir, incluso, funciones del cargador, código BIOS y código de firmware.
6.4.1.6 Modificación de la tabla de funciones IRP
Los controladores de dispositivos interpretan los paquetes de E/S para ejecutar solicitudes específicas. Por ejemplo, los controladores del sistema de archivos utilizan estos paquetes en operaciones de lectura y escritura de archivos, y los controladores de red, para enviar y recibir paquetes de red. Cada controlador de dispositivo tiene un conjunto de rutinas de distribución, cada una de las cuales se encarga de un paquete IRP específico. Las rutinas de distribución se almacenan dentro de la estructura DEVICE_OBJECT que representa el controlador de dispositivo. El controlador de dispositivo del rootkit puede interceptar directamente sus rutinas de distribución de controladores dentro del sistema de archivos o en las estructuras DRIVER_OBJECT del controlador de dispositivo de la red. A continuación, puede hacerse con el control antes de que se produzca la llamada de las rutinas de controlador del dispositivo. DRIVER_OBJECT se puede localizar a través de las estructuras DEVICE_OBJECT, que se pueden localizar a su vez a través de la API IoGetDeviceObjectPointer. Mediante estas técnicas, el
código del rootkit se ejecuta antes de la llamada del controlador original, lo que permite al rootkit inspeccionar y modificar los resultados antes de devolverlos.
7 Detección [HAC04]
La detección de una rootkit deja de ser un trabajo virtual. En un sistema que pueda estar comprometido por una rootkit no se puede confiar en los resultados de las herramientas tradicionales de monitorización de recursos. Para esta tarea tenemos las siguientes opciones:
1. Monitorización externa: Mediante el uso de Sniffers y analizadores de paquetes en busca de tráfico sospechoso
2. Análisis forense: Extracción física del disco duro del sistema para su posterior análisis offline a fin de identificar recursos modificados.
3. Métodos de análisis estadísticos: Para determinar el número de instrucciones en ensamblador necesarias para la ejecución de determinadas API del sistema
4. Análisis de fallos de determinados rootkits: Fallos de programación o métodos no implementados que permitan su identificación
5. Comparación de resultados
Veamos estas técnicas un poco en detalle:
7.1 Monitorización externa[HAC04]
Partamos un escenario en el que existe una rootkit instalada en un sistema y que utiliza una serie de paquetes para comunicarse con el cliente. Una rootkit que no utilice la pila TCP/IP del sistema para realizar las conexiones no puede ser detectada por el tráfico que se genera localmente
7.1.1 Ejemplo:La rootkit NTROOTKIT se comunica y recibe tráfico de una IP que no existe. Entonces, cuando un atacante ha obtenido el acceso al sistema y la ha instalado, sólo necesita establecer una conexión de telnet contra la dirección IP especificada en la rootkit para tener un shell con privilegios de system y con acceso ilimitado a los recursos ocultos.Otras rootkits usan el protocolo ICMP encriptando los datos dentro de este paquete de tal forma que cuando un hacker intenta conectarse al sistema no aparece ninguna conexión activa. La monitorización de este tráfico por parte de la rootkit permite la comunicación bidireccional entre el atacante y la rootkit.La solución más habitual en rootkits que permiten la conexión de usuarios externos es la de permitir una conexión de telnet a un puerto específico del sistema
de tal forma que, al recibir la conexión de un atacante, éste envía una contraseña y se obtiene acceso al sistema. Estos puertos solo pueden ser detectados mediante herramientas como nmap ejecutadas desde direcciones externas para detectar la existencia de estos puertos abiertos dado que, de cara al administrador local del sistema, no hay nada fuera de lo normal.
7.2 Análisis forense[HAC04]
Mediante el acceso al dispositivo físico de almacenamiento de datos, como puede ser el disco duro, se puede analizar qué ficheros ocultos existen en el mismo y cuáles han sido las fechas de modificación y creación de los mismos. Actualmente existe un proyecto nuevo de rootkit para sistemas Windows que implementaría su propio sistema de ficheros utilizando como espacio de almacenamiento clusters de disco marcados como defectuosos y usando como clave de cifrado un chorro de bytes almacenados en un chip de memoria del sistema. En cualquiera de estas situaciones, un análisis forense muestra la existencia de archivos sospechosos de datos que pueden dar información sobre los atacantes.
7.3 Métodos de análisis estadístico[HAC04]
El mejor ejemplo de esta técnica es la herramienta PatchFinder2, de Joanna Rutkowska. Consiste en el análisis de un sistema “seguro” en busca de las instrucciones necesarias por el procesador para ejecutar una determinada API; por ejemplo, para enumerar los archivos de un directorio. Una vez que el sistema ha sido comprometido y existe una rootkit, éste necesitará ejecutar instrucciones extras en cada llamada para determinar si un recurso debe de ser mostrado o permanecer oculto. Estas diferencias en las instrucciones pueden significar que un sistema y una determinada llamada están comprometidas o se ha modificado su estado, por ejemplo, con la instalación de software o actualizaciones de seguridad.
7.4 Análisis de fallos de rootkits y comparación de resultados
[HAC04] La complejidad de las rootkits y la duplicidad de las API en Windows para obtener la misma información obliga a los programadores de rootkits a tener en cuenta múltiples escenarios que puedan ser utilizados para su deteción. Una de las formas más sencillas de hacerlo es comparando los resultados obtenidos a la hora de listar objetos como: procesos en ejecución, servicios del sistema, puertos abiertos, etc. Tras analizar detalladamente múltiples rootkits se puede llegar a identificar pautas que son el inicio de que algo no funciona bien en el sistema. Estas
técnicas no son fiables al 100 por cien dado que los programadores de rootkits pueden modificar el comportamiento de las mismas para evitar su detección, pero es una aproximación bastante fiable a un modelo de detección completo.
8 Protección[PAN08]
La lucha contra los rootkits es una carrera armamentística, en la cual sus creadores desarrollan medidas que tratan de evitar la detección, al mismo tiempo que las compañías de seguridad despliegan contramedidas que protejan a sus clientes.
Las técnicas que se emplean para detectar la existencia de rootkits dentro de un sistema son las siguientes:
• Instalar una buena solución antimalware en el ordenador, y mantenerla permanentemente activa y actualizada.
• Instalar un cortafuegos que proteja de accesos no autorizados al ordenador.
• Mantener las aplicaciones instaladas en el ordenador siempre actualizadas, instalando los parches de seguridad proporcionados por los fabricantes.
[PAN08]
9 Software antirootkit[ANT08]
A continuación se muestra una lista de software libre que proporciona soluciones para detectar y eliminar rootkits de un sistema infectado.
Nombre Compañía SO VersiónAries Sony Rootkit Remover Lavasoft Win 1Archon Scanner XSolve Win 2007AVG AntiRootkit Grisoft Win/V 1.1.0.42Avira Rootkit Detection Avira Win 1.0.1.17chkrootkit Murilo & Jessen Linux, BSD 0,48DarkSpy CardMagic 2K/XP/03 1,05
& wowocockFSecure Blacklight Beta FSecure Win 02/02/67Gmer Gmer 2K/XP/Vista 1.0.12Helios / Helios Lite MIEL eSecurity Win 1.1aHiddenFinder Wenpoint 2K/XP 1,4HookExplorer iDefense Win 1IceSword XFocus Win 1,22OS X Rootkit Hunter Christian Hornung Mac OS X 10.4 0,1Panda AntiRootkit (Tucan) Panda Software 2K/XP/03 1,08Process Master Backfaces 2K/XP/03 1,1Radix Anti RootKit USEC.at Win 1RootKit Detective McAfee Avert Labs Win 1RK Detector Andrés Tarascó Win 2.0RootKit Buster Trend Micro Win 01/06/01RootKit Hook Analyzer Resplendence Win 3Rootkit Hunter Boelen Linux, BSD. 01/03/00Rootkit Profiler LX Tobias Klein Linux 0,1RootkitRevealer Sysinternals Win 1,71RootKitShark Advances.com Win 3.11RootKit Uncover BitDefender Win 1.0b2RootKit Unhooker UG North 2K/XP/03 03/07/03SEEM AI, nunki Win 4.5RCSophos Antirootkit Sophos Win 01/03/01SysProt Antirootkit Swatkat Win 1.0.0.4System Virginity Verifier Joanna Rutkowska Win 2,3Unhackme Greatis Win 4,6Zeppoo Zeppoo Linux 0.0.4
10 Ejemplo práctico[HAC04]
En la actualidad existe una gran variedad de rotkits para sistemas operativos Windows. Vamos a realizar una prueba usando la rootkit Hacker Defender 1.00 [2004]. Esta rootkit opera en Windows 2000/XP/2003 y tiene la característica de permitir ocultar espacio libre utilizando en disco, conexiones TCP y UDP a determinados puertos, así como comunicarse con el atacante a través de un programa especial llamado bdclient en cualquier puerto abierto del sistema.Para su funcionamiento, únicamente se necesitan los ficheros hxdef100.exe y hxdef100.ini almacenados en el mismo directorio.
Es necesario que el fichero .ini tenga el mismo nombre que la rootkit, de lo contrario no funcionará. La configuración de esta rootkit es bastante sencilla:
1. Hidden table: Almacena la lista de ficheros ocultos por la rootkit.
2. Root proccess: Procesos que podrían acceder a todos los recursos, aunque estén ocultos.
3. Hidden services: Esntradas de servicios ocultas en el sistema.
4. Hidden Regkeys: Entradas de registro ocultas (claves de los programas que hemos instalado en el sistema)
5. Hidden regvalues: Como lo anterior, pero para valores.6. Startup run: Tiene la misma funcionalidad que la clave
run del registro. Inicia programas ocultos al ejecutarse la rootkit
7. Free space: Se puede configurar que cada unidad muestre un número de bytes extras en el espacio libre para que no sospeche de la falta de espacio en disco por nuestras herramientas.
8. Hidden ports: Oculta puertos locales abiertos para que no se detecten aplicaciones que están escuchando en puertos, como pueda ser un servicio ftp o un netcat.
9. Settings: Configuración del nombre de servicio y contraseña.
La instalación de esta rootkit en el sistema es muy sencilla y fácil. Una vez que haya copiado los dos ficheros de la rootkit, se ejecuta el comando hxdef100.exe :Installonly, tras lo cual se generará un servicio nuevo llamado Hacker defender100. Tras iniciarse el servicio, la rootkit estará funcional en el sistema, ocultándose a sí misma y todo lo configurado en el fichero .ini
11 BibliografíaLas siguientes referencias fueron usadas para la realización del trabajo:
• [HAC04]Hacking práctico. 2004. Ed.Anaya• [MCA06] McAfee. Libro blanco. Abril 2006• [PAN08] Panda Security 2008• [ANT08] www.antirootkit.com