rootkits. - udc

30
.RootKits. Pablo Iglesias Morales  - Máster en Informática - Facultad de Informática Universidad de A Coruña Junio 2008

Upload: others

Post on 15-Jul-2022

15 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: RootKits. - UDC

.RootKits.

Pablo Iglesias Morales ­ Máster en Informática ­

Facultad de InformáticaUniversidad de A Coruña

Junio 2008

Page 2: RootKits. - UDC

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 anti­rootkit..................................2710  Ejemplo práctico.....................................2711  Bibliografía.........................................30

Page 3: RootKits. - UDC
Page 4: RootKits. - UDC

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. 

Page 5: RootKits. - UDC

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]

Page 6: RootKits. - UDC

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,  Adware­Isearch 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 

Page 7: RootKits. - UDC

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]

Page 8: RootKits. - UDC

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.

Page 9: RootKits. - UDC

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   PWS­Progent   aparecieron   por primera   vez   en   2003.   HackerDefender   ha   mostrado   un 

Page 10: RootKits. - UDC

crecimiento importante en los últimos años, mientras que las variantes de AFXRootkit y PWS­Progent 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. Backdoor­BAC 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  Adware­Isearch. 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 

Page 11: RootKits. - UDC

esa   utilidad   instalaba   otros   programas   de   adware   en   el equipo. Por último, Adware­Isearch 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. 

Page 12: RootKits. - UDC

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  A­311   Death  y   la   edición   de   lujo   de HackerDefender. El éxito del fraude de tipo  phishing  de Backdoor­BAC  (alias  Haxdoor  y  A­311   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.

Page 13: RootKits. - UDC

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 

Page 14: RootKits. - UDC

"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 

Page 15: RootKits. - UDC

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 

Page 16: RootKits. - UDC

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.

Page 17: RootKits. - UDC

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)

Page 18: RootKits. - UDC

Gráfico 7: Rutina de interceptación por modificación de la tabla IAT

Page 19: RootKits. - UDC

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

Page 20: RootKits. - UDC

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 

Page 21: RootKits. - UDC

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.

Page 22: RootKits. - UDC

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, 

Page 23: RootKits. - UDC

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 

Page 24: RootKits. - UDC

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 

Page 25: RootKits. - UDC

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 

Page 26: RootKits. - UDC

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]

Page 27: RootKits. - UDC

9 Software anti­rootkit[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 X­Solve 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

&  wowocockF­Secure Blacklight Beta F­Secure Win 02/02/67Gmer Gmer 2K/XP/Vista 1.0.12Helios / Helios Lite MIEL e­Security 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 Anti­Rootkit (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.

Page 28: RootKits. - UDC

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.

Page 29: RootKits. - UDC

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

Page 30: RootKits. - UDC

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