3.3 ROOTKITS ¿La raiz de todos los males?

Antes un  poco de hostoria.

Antes de comenzar con los detalles técnicos, es apropiado realizar una síntesis de la evolución de los rootkits y más precisamente, del por qué de su denominación y un detalle de sus funcionalidades.

Típicamente, se llama root al usuario con mayores privilegios dentro del sistema operativo Unix o derivados. Cualquier usuario distinto de root tiene menores privilegios. Por este motivo, los permisos de este usuario son los que cualquier persona o proceso ajeno al sistema desea poder obtener para realizar acciones no deseadas.

Por esto, originalmente el término root-kit correspondía a un conjunto de herramientas que permiten el control del usuario root y de los procesos del sistema operativo, a la vez que estas aplicaciones permanecen indetectables para el mismo y por ende, para el usuario.

¿La raíz de todos los males? – Rootkits revelados

Autores: David Harley y Andrew Lee (*)

¿Son los rootkits la raíz de todos los males, o sólo otra rama del árbol de amenazas? Todo lo que necesita saber acerca de los rootkits lo encontrará en este documento.

En los últimos años, se ha incrementado la toma de conciencia pública acerca de los rootkits, pero así como con los gusanos, virus y otros códigos maliciosos, el término rootkit es aplicado indistintamente a un amplio rango de tecnologías y ha traído un número de definiciones poco apropiadas.

Mientras que varias de estas tecnologías y definiciones son explicadas en el presente trabajo, nuestra intención es clarificar usos comunes, y no suministrar una única definición final. No obstante, hay algunas explicaciones breves en el glosario al final del presente.

Los rootkits se encuentran en peligro de convertirse en lo último de una larga línea de amenazas pobremente entendidas y falsamente promocionadas como “el fin de la computación tal y como la conocemos”.

Al haber recibido descripciones [1] tales como “el ataque más pernicioso y sofisticado que actualmente puede efectuarse contra el sistema Windows”, han adquirido algunas de las temerosas supersticiones que anteriormente inspiraron términos como stealth y polimórfico en la historia de los códigos maliciosos.

Sin duda, los conceptos de rootkit y stealth (o aquello a lo que actualmente se lo conoce como “stealthware”) se encuentran estrechamente relacionados y superpuestos, si es que no son sinónimos.

Este artículo intenta evaluar la realidad de la amenaza rootkit y también examinar el estado de las soluciones disponibles. Es sencillo comprender los motivos sobre la preocupación ante esta amenaza, ya que las aplicaciones que utilizan técnicas de ocultamiento están diseñadas para que los antivirus no detecten su presencia, ni tampoco lo hagan otros programas de seguridad, el sistema operativo y el sistema de archivos.

Los rootkits eran, hasta hace poco, una preocupación para los especialistas de seguridad, principalmente en las comunidades UNIX/Linux, en cambio, la utilización del modo oculto no es ninguna novedad para la industria antivirus.

* ¿Tiene root?

En un sistema basado en Unix, el usuario más privilegiado tiene el nombre de root, posee el máximo control sobre el sistema, y es por ello el más deseado por un atacante.

El root o directorio raíz también se refiere al primer directorio en la estructura del sistema de archivos de Unix: el directorio único de primer nivel en el árbol de directorios convencionales (¿por qué el árbol de directorios crece hacia abajo?, es lo que uno se pregunta).

El directorio root, frecuentemente referido por medio de la barra “/” (casi equivalente al “C:\” en DOS o Windows) es el que permite el acceso a todos los restantes.

Comúnmente, los usuarios no privilegiados del sistema deberían ser incapaces de alterar los archivos de este directorio o bien, aquellos que no corresponden a su propio entorno. De modo que “rootear” un sistema significa comprometer la cuenta root, logrando así, el acceso root al sistema y a todos los archivos y directorios del mismo.

* Rootkits y Stealth

En los inicios de la detección de códigos maliciosos, la tecnología stealth (oculto) fue definida según los siguientes lineamientos:

– Modo oculto negativo (nivel -1): los daños provocados por la infección afectan el funcionamiento del objeto atacado de manera tan evidente, que hacen inevitable su detección.

– Sin modo oculto (nivel 0): No se toman medidas específicas para disimular la presencia de la infección.

– Modo oculto elemental (nivel 1): No aparecen características que llamen la atención. Se toman recaudos básicos para no ser detectados, por ejemplo preservar los registros de fecha y hora.

– Modo oculto intermedio (nivel 2): Se mantiene una imagen parcial o total del objeto en el estado anterior a la infección para mostrarle al sistema, con el fin de ocultar las huellas del virus.

– Modo oculto avanzado (nivel 3): Los métodos de invisibilidad se utilizan específicamente para ocultar la infección ante las aplicaciones de seguridad.

Actualmente, esta clasificación no se utiliza mucho fuera de la comunidad antivirus. Sin embargo, es válida, no sólo en el contexto de los virus, sino también al referirse a otros códigos maliciosos que utilizan modo oculto, incluyendo rootkits.

Si consideramos que tales mecanismos fueron conocidos y tratados con perfecta adecuación por el software antivirus durante muchos años, uno se puede quedar tranquilo frente a las afirmaciones de que la tecnología rootkit se haya actualmente tan avanzada que sólo puede ser detectada por herramientas especiales y que la única manera de lidiar con ella es formateando el disco infectado y reinstalando el sistema operativo.

El software antivirus puede detectar con igual facilidad tanto a rootkits como cualquier otro programa dañino, antes de que el mismo tenga la oportunidad de instalarse, pero también en muchas circunstancias, luego de la instalación.

Por supuesto, esto no implica que no haya problemas de rootkits. Tampoco significa que todos los programas antivirus lidien con el problema en un mismo nivel de efectividad, o bien que trabajen con todos los tipos de rootkits con igual éxito. Sin embargo, el problema es controlable: el cielo no se está cayendo.

* Definiciones de Rootkit

Según Hoglund [4], un rootkit es “un conjunto de programas y código que permite una presencia permanente o consistente, no detectable en un ordenador”.

Esta es una definición de alto nivel, razonable, pero no disminuye la confusión existente entre la antigua técnica de modo oculto (Stealthing), los nuevos conjuntos de herramientas para modo oculto (Stealthkits), y los rootkits.

Consideremos entonces, una definición básica [5] de un conjunto de herramientas maliciosas: “Un paquete que contiene instrucciones, programas, o agentes autónomos que se aprovechan de las vulnerabilidades existentes”.

Un rootkit es un conjunto de herramientas usualmente asociado con el intento de obtener o mantener acceso privilegiado, manteniendo oculto el hecho de que el sistema ha sido comprometido.

Podría entonces definirse como un grupo de herramientas informáticas maliciosas, que permiten que un intruso, que logró acceder y permanecer en el sistema, oculte esta situación.

En realidad, el hecho es un poco más complicado, pero antes de avanzar en ese sentido, necesitamos comprender ciertos conceptos acerca de la administración de las cuentas de usuario y sus privilegios. Después de aclarar esto, podremos considerar conjuntos de herramientas específicos, en determinados entornos.

Por el momento, una definición práctica de un rootkit sería una clase de conjunto de herramientas instalado en un sistema con privilegios de usuario con el fin de:

– Mantener acceso y control privilegiado.

– Permitir al individuo y/o software hacer uso de dicho acceso del modo que prefiera.

– Ocultar o restringir el acceso a objetos tales como:

Procesos
Hilos de ejecución (threads)
Archivos
Carpetas / Directorios / Subdirectorios
Entradas de registro
Puertos abiertos
Controladores

Debemos tener en cuenta que estas definiciones no presuponen:

– Intrusión, es decir acceso no autorizado.

– Acciones o intentos maliciosos.

– “Rooting” o administración del directorio raíz (ganando un nivel de acceso y privilegio inapropiado y no autorizado). Analizaremos este concepto más adelante.

La mayoría de los sistemas operativos multiusuarios aplican alguna forma de ocultamiento y/o acceso restringido a los datos sensibles y a los sistemas de archivos críticos, sobre todo a los usuarios no privilegiados.

Esto se hace enteramente, por razones legítimas de seguridad: por ejemplo, para restringir a los usuarios finales el acceso a datos que no les corresponden, o para prevenir que borren o modifiquen archivos y programas que dañen al sistema o a la integridad de los datos.

En este sentido, la seguridad no presupone malicia en la parte del usuario final y podría fácilmente caer dentro de una versión ligeramente modificada del modelo de clasificación de stealth, citado anteriormente. Sin embargo, esta definición cubre el uso de técnicas stealth/rootkit más avanzadas, también debido a razones legítimas (leerá más adelante acerca del rootkit de Sony).

* Guía de 60 segundos para el manejo de cuentas

Incluso la más modesta de las PC contemporáneas tiene recursos y poder de procesamiento equivalentes o superiores a muchos de las supercomputadoras (mainframes) y mini-computadoras del pasado.

Algo que no es tan obvio, es que las computadoras personales actuales, han evolucionado desde el modelo de los sistemas autónomos, monousuarios, cuyas capacidades de trabajar en red es apenas equivalente a la de una terminal “tonta”, a ser máquinas con las características de un servidor.

Las PC y sistemas operativos modernos son capaces de soportar no sólo múltiples procesamientos y áreas de usuarios sino también procesamientos múltiples de usuarios concurrentes, a pesar de que la mayoría de las PC de escritorio y portátiles son generalmente utilizadas por una única persona y, consecuentemente, por una sola cuenta por vez, a menos que estén ofreciendo un servicio en línea a usuarios remotos  (literalmente, para actuar como servidor al mismo tiempo en que está siendo utilizada como una estación de trabajo).

Una cuenta de usuario no sólo permite acceso al sistema sino que además define lo que puede hacer un usuario en el sistema. La mayoría de los usuarios poseen administración limitada, así como derechos o privilegios de acceso diferentes.

Los privilegios pueden ser destinados o bien quitados a los usuarios según su perfil y las tareas individuales que les correspondan, pero también en función de su membresía a grupos particulares. Los grupos pueden definirse según intereses o tareas compartidas, según la ubicación geográfica, o bien según la distribución de redes o subredes de trabajo.

Generalmente, los administradores tienen acceso a instalar o modificar programas, acceder a las cuentas de otros usuarios y otros derechos que los usuarios estándares no tienen. Asimismo sus derechos pueden ser obligatorios según la jerarquía: por ejemplo, un administrador puede tener privilegios totales en algunos servidores o dominios pero no en otros.

Normalmente, la cuenta “root” posee todos los privilegios del administrador (superusuario) en Unix/Linux y sistemas no-Unix.

La cuenta del administrador en los sistemas Windows es más o menos equivalente a la cuenta root de Unix. Mientras que en los sistemas OS X de Macintosh, basado en BSD Unix, el sistema de cuenta al cual se accede por medio de la interfase gráfica es algo diferente al Unix estándar. Sin embargo, el principio es el mismo.

* Privilegios del Usuario y Rooting

“Rooting” es un término aplicado a ganar acceso root y, consecuentemente, un control total sobre el sistema Unix (o Linux). Esto puede hacerse mediante el escalamiento de privilegios directos: esto es, explotación de las vulnerabilidades del sistema para lograr un nivel más elevado de privilegios.

Sin embargo, esto también puede hacerse por medio de la acción de un virus, tal y como lo reportó Cohen [6] a principios de la investigación sobre códigos maliciosos.

El uso del término “root” suena extraño en el contexto de PC/Windows, donde el nombre de la cuenta root no tiene una significación particular. Aún así puede utilizarse como término genérico para lo que es ganar acceso privilegiado tanto a Unix/Linux como a sistemas no-Unix.

* Objetivos de los rootkits

El objetivo principal de un rootkit no es necesariamente acceder al directorio raíz del sistema anfitrión, si bien pueden incluir programas diseñados para obtener ese tipo de acceso administrativo. Preferentemente, su objetivo es habilitar al intruso para mantener y aprovechar un punto débil no detectado en el sistema.

Sin embargo, algunos autores hacen una distinción entre rootkits y conjuntos de herramientas para modo oculto (Stealthkits). Según ellos, un rootkit podría definirse como un conjunto de herramientas con funcionalidades que incluyen instrumentos para administrar el directorio principal del sistema [7].

Sin embargo, este trabajo se dirige a un determinado número de componentes y tipos de rootkits, en vez de aferrarse a una única y pura mirada de lo que es y no es un rootkit. Este acercamiento está basado no sólo en mantener claridad sino también las realidades y multiplicidades de las amenazas vistas en el mundo real.

Los objetivos secundarios de un rootkit pueden ser:

– Ocultar los rastros de un intruso en una computadora “rooteada” (comprometida).

– Ocultar la presencia de procesos o aplicaciones maliciosas.

– Cubrir las actividades dañinas como si fueran realizadas por programas legítimos.

– Ocultar la presencia de códigos que se aprovechan de las vulnerabilidades del sistema: modificación de parches, retorno a versiones anteriores, puertas traseras, entradas clandestinas.

– Recolección de información a la que un intruso no podría tener acceso o acceso total de otra manera. Esto podría incluir datos acerca del sistema comprometido, del tráfico de la red y cualquier otro.

– Utilizar al sistema comprometido como intermediario para llevar a cabo otras intrusiones y/o ataques maliciosos.

– Guardar otras aplicaciones nocivas y actuar como servidor de recursos para actualizaciones de botnets (una colección de robots, o bots, que se ejecutan de manera autónoma, formando verdaderas redes de máquinas zombis).

* Componentes tradicionales de los Rootkits de Unix

Los programas de utilidades troyanizadas son utilidades legítimas del sistema sustituidas de modo que esconden la presencia o huellas del intruso, permiten que el intruso acceda al sistema como guste, o bien reúnen información a la que el intruso no debería poder acceder.

En un ambiente Unix, las utilidades como “top”, “ps”, “login” y “passwd” son blancos comunes para esta sustitución [8], pero cualquier programa que pueda explotarse para lograr una root shell (ver “shell” en el glosario) es un blanco para un rootkit, ya que esto colabora con el intruso para que logre acceder al sistema comprometido o bien, a que mantenga un acceso privilegiado.

Estos no son, necesariamente, los medios utilizados para acceder al sistema comprometido, pero pueden tener una serie de otros usos posibles incluyendo el de comprometer otras cuentas y sistemas o bien, retomar el acceso privilegiado a pesar de los intentos por reparar una intrusión conocida.

Los programas que pueden ayudar al administrador a detectar la presencia de un intruso (por ejemplo, “last”, “ls”, “netstat” e “ifconfig”) [9] son, asimismo, el blanco para una sustitución. Los daemons o demonios (programas como “inetd.”, “rshd” y “syslogd”, que se ejecutan como servidores o como procesos del sistema -véase el glosario- en vez de ser llamados directamente por el usuario final) también pueden ser blancos, tanto para el ocultamiento como para los propósitos de recolección de información.

Las utilidades de borrado de registros (logs) y otras herramientas similares cubren las huellas del intruso, por ejemplo, borrando las entradas relacionadas con una intrusión desde el sistema de archivos log.

Otras formas de troyanos también pueden encontrarse en los rootkits clásicos, tales como aquellos utilizados para la recolección de información, como los capturadores de teclado (keyloggers) y de paquetes (packet sniffers) y aquellos que permiten un acceso futuro a voluntad (backdoors).

Un rootkit típico de UNIX o Linux seguramente tendrá sustitutos de comandos para aplicaciones de servidor, instrucciones para aumentar los privilegios del usuario, recursos para monitorizar el uso de comandos (para ocultar archivos), capturadores de paquetes para controlar el tráfico de la red, y aplicaciones troyanizadas para esconder procesos, registros y conexiones.

* Rootkits de Windows

El término “Windows rootkit” es popularmente usado para describir programas que esconden procesos, archivos o claves de registro del sistema operativo. De hecho, los Windows rootkits pueden tener una funcionalidad muy similar a los tradicionales de Unix, pero con los mecanismos correspondientes a la plataforma afectada.

Las versiones derivadas de Windows NT, tales como XP, utilizan un modelo de seguridad para múltiples cuentas muy similar a los sistemas anteriores como VMS y UNIX, aunque la terminología y mecanismos exactos sean muy diferentes. Las versiones anteriores de Windows resultan muy dependientes de las aplicaciones de terceras partes para su seguridad.

Así como los sistemas Unix, las versiones derivadas de Windows NT poseen grados de acceso privilegiado. Esto no sólo es una cuestión de acceso del usuario a las áreas de datos, sino también de acceso a los procesos del kernel. Las plataformas de NT derivadas soportan dos modos de ejecución (o niveles de privilegio): modo usuario y modo kernel.

Los procesadores modernos x86 soportan cuatro anillos de privilegio, pero Windows sólo soporta dos, ya que NT fue diseñado con la intención de ser portable a procesadores que no son de Intel. Los anillos de privilegios están pensados para proteger al kernel (anillo 0) de modo que los datos del sistema no puedan ser modificados o sobrescritos mediante un proceso sin privilegios. Las aplicaciones normales en un sistema de tipo NT corren en el anillo 3, que es el proceso con menor privilegio.

* Modo Usuario vs. Modo Kernel

Mientras que la distinción entre usuarios privilegiados y administradores no equivale a la distinción entre el modo Kernel (nivel 0) y el modo Usuario, existe una estrecha relación entre ambos.

El kernel puede describirse como el núcleo literal del sistema operativo [10]: los servicios del sistema corren en modo kernel, de modo que un usuario sin privilegios no pueda introducir modificaciones inapropiadas sin autorización previa, tales como remover o agregar drivers, mecanismos y programas.

Generalmente, las aplicaciones del usuario se encuentran disponibles para todos los usuarios, y corren en modo Usuario, restringiendo la capacidad de una aplicación para causar un daño mediante modificaciones inapropiadas o inadvertidas a los procesos del sistema.

Los componentes de un rootkit en modo usuario se ejecutan como una aplicación, o dentro de otro programa, modificando las llamadas de los procesos correspondientes a las APIs (Application Programming Interface, Interfaz de programación de aplicaciones).

Cada aplicación del usuario se ejecuta dentro de su propio espacio de memoria, de modo que un rootkit del modo usuario debe modificar el espacio de memoria de cada aplicación que está ejecutándose para poder infiltrarse en cada “vista” de la aplicación y de lo que está sucediendo en el interior del sistema operativo.

Para lograr esto, debe monitorear al sistema para poder modificar el espacio de memoria antes de que una aplicación recientemente abierta esté completamente ejecutada. Uno de los medios comunes para lograr este objetivo es modificar las DLLs del sistema (Dynamic Link Libraries, bibliotecas de enlace dinámico), en el momento en que se encuentran en ejecución.

El modo kernel permite acceso privilegiado al sistema de memoria y a todo el conjunto de instrucciones del procesador. Un rootkit del modo kernel intercepta las API de este tipo, y de esta manera oculta procesos, archivos, entradas de registro y demás.

Así entonces, se ocultan procesos, archivos y claves de registro. Cuando una aplicación del modo usuario realiza un pedido de información, la información que es devuelta es filtrada para ocultar la evidencia.

Un rootkit del modo kernel posee un potencial casi irrestricto para dañar o manipular al sistema, en comparación con un rootkit del modo usuario, sin embargo, debido a su complejidad inherente, es más difícil de crear, instalar y de mantener.

Esconder datos en el espacio del núcleo es más confiable, y la tarea es más fácil ya que todos los procesos centrales comparten el mismo espacio en memoria, pero tiene que ser efectuada por un usuario privilegiado, no necesariamente con su conocimiento.

Debemos destacar que este método para ocultar información (ver la entrada “Hooking” en el glosario), no es el único que puede utilizar un rootkit. La manipulación directa de objetos del kernel (DKOM, Direct Kernel Object Manipulation), en vez de filtrar los datos que retorna el núcleo, directamente modifica los objetos creados con propósitos de auditoria por el sistema operativo.

Un rootkit que utilice este método, puede esconder un proceso desvinculando el objeto asociado con un proceso [11], para dificultar aún más a las aplicaciones de seguridad la detección de su presencia.

* Rootkits persistentes vs. Rootkits no-persistentes

Muchos rootkits son persistentes: esto es, son guardados en el disco y se enganchan en la secuencia de arranque del sistema, de modo que sobreviven cuando se reinicia el sistema.

Los rootkits no-persistentes o “en memoria” no hacen esto: instalan su código directamente en la memoria, y no sobreviven al reiniciarse el sistema.

Esto dificulta su detección al no dejar huellas en el sistema que puedan ser detectadas mediante la exploración realizada al iniciar. Sin embargo, su funcionalidad se encuentra restringida por el tiempo limitado en que el sistema infectado se mantiene en línea (ya que si el sistema se reinicia, desaparece el rootkit): esto es una cuestión menor para aquellos sistemas que normalmente no son reiniciados (por ejemplo, servidores).

Aparentemente existe una tendencia hacia la no persistencia entre los buscadores de vulnerabilidades y aquellos que publican PoC (pruebas de concepto), probablemente atraídos por las ventajas del ocultamiento del malware, que no realizan cambios permanentes en el sistema de archivos.

Algunos troyanos han utilizado estos rootkits no-persistentes (por ejemplo, el rootkit FU) que cargan en la memoria una vez que ellos se encuentran instalados. Así entonces, el rootkit es utilizado para ocultar los procesos y archivos del troyano.

* Rootkits de Macintosh

Existen algunas PoC de rootkits para OS X de Apple. Su impacto ha sido bajo y su significación tiende a ser subestimada por la comunidad Apple ya que requieren de acceso root para instalarse. Esto es, no pueden incrementar sus privilegios.

Comúnmente, se tiene la misma actitud en cuanto a los pocos ejemplos de malware Mac conocidos actualmente. Sin duda, los usuarios Mac suelen negar la existencia de virus para OS X porque aquellos que existen requieren de la acción del usuario para infectar y reproducirse (sin embargo, esto también es cierto para muchos de los virus para Windows).

Si bien es más difícil que un usuario Mac trabaje como usuario privilegiado (a menos que realmente quiera hacerlo) sería ingenuo pensar que ningún usuario de Mac podrá ser engañado para ejecutar su cuenta “root” temporalmente y permitir que un rootkit se instale.

Mientras que los usuarios de Mac comprenden bien la superioridad de la administración de privilegios, no es habitual que los rootkits de Windows puedan acceder al directorio raíz, es decir, obtener por su cuenta los privilegios del administrador, sin la ayuda de la víctima (psicológicamente manipulada).

Sin embargo, en Windows es más habitual permitir al usuario de Windows ejecutar procesos con privilegios de administrador por defecto.

* Buenas intenciones y la experiencia del Rootkit de Sony

El uso de tecnología stealth (de ocultamiento), o de tecnología similar a rootkit no se haya reducido a aquellos que irrumpen en los sistemas con propósitos de “hackeo”. Es claro que estas tecnologías pueden ser utilizadas por otras formas de malware, incluyendo virus, gusanos y troyanos como medios para ocultar la presencia de dicho malware.

“Greyware” (software que se encuentra en algún lugar entre el software legítimo y el malware) tales como adware, algunos tipos de spyware, “trackware”, etc., es cautelosamente referido por algunos de los proveedores de antivirus como “programas potencialmente indeseados”.

Esto es para evitar posibles contiendas legales en las que puede discutirse (por el fabricante) que dicho software es legítimo. En algunos casos, hasta puede incluso, ser legítimo aquel software capaz de ser, o bien que ha sido convertido para llevar a cabo propósitos maliciosos. También esto depende, generalmente, de un determinado grado de ocultamiento.

Mientras que su presencia resulta a veces muy obvia, debido a la inesperada aparición de ventanas emergentes (pop-ups), redirección de URLs, etc., debe prestarse una considerable atención para prevenir la detección y eliminación de los archivos de programa en cuestión.

Algunos comentaristas del campo [4] se entusiasman en señalar que la tecnología rootkit (o semejante a la de rootkit) puede utilizarse para propósitos legítimos, y ciertamente debe ser para superar las deficiencias del sistema operativo cuando se trata de ocultamiento de datos. Algunas de las áreas a veces citadas son:

– Gestión de Derechos de Propiedad Intelectual

– Protección de programas de la ingeniería inversa

– Calcular la amenaza de personas internas

– Rastreado de intrusiones

– Monitoreo del empleado

– Gestión de Derechos digitales

– Protección del software de seguridad de malware o de interferencias de usuarios inapropiados

– Backup de software y de datos

– Software de recuperación del sistema

– Codificación de datos y ocultamiento en sistemas de múltiples usuarios.

No todos están cómodos con la aplicación de la terminología vinculada al rootkit para dichas cuestiones, porque de alguna manera ensucia las definiciones. Después de todo, Windows emplea por si mismo y de forma efectiva, dichas técnicas por defecto para ocultar archivos importantes.

Sin embargo, otros proveedores se hayan claramente cómodos tanto con los términos como con los conceptos. En octubre del 2005, Mark Russinovich anunció en su blog de Sysinternals [12] el descubrimiento de lo que parecía ser un rootkit en su sistema.

Esto resultó ser el notorio rootkit de Sony, lo cual devino en una seria confusión para la opinión pública entre lo que es la Gestión de Derechos Digitales (DRM) y las tecnologías stealth/rootkit.

DRM puede definirse como la tecnología utilizada para controlar el acceso a los datos y los dispositivos físicos con la finalidad de mantener los derechos de los autores.

Sony utilizó tecnología XCP (Extended Copy Protection) de First 4 Internet Ltd para el control de acceso de ciertos CDs de música.

Los discos protegidos por XCP restringieron el número de copias de CDs o DVDs que podían hacerse y también controlaron la conversión del formato de codificación (ripping) de la música, para guardarla y escucharla en un reproductor digital.

Así, no fue posible reproducir un CD en una PC sin instalar previamente un software que luego esconde archivos, procesos y claves del registro modificando el camino de ejecución de las funciones API. Hizo esto utilizando una técnica propia de los rootkits, que modifica la tabla de servicio del sistema (SST, System Service Table).

El derecho de Sony de restringir la distribución ilícita de sus productos no esta en duda, y no sería apropiado considerar su similitud a un rootkit en un sentido malicioso.

Sin embargo, muchos se sienten incómodos con el hecho de que modificaron su sistema de usuario final sin dejar en claro qué fue lo que estaban haciendo o bien, sin aportar un medio para la desinstalación. O peor aún, su solución no fue del todo concebida o codificada correctamente y creó una vulnerabilidad que fue aprovechada para ocultar otro malware.

El problema real fue que el “rootkit” fue aprovechado para ocultar un troyano que no tenía nada que ver con Sony ni con el software de protección de copiado.

Esto demuestra una sutil diferencia entre los intentos maliciosos y las vulnerabilidades inadvertidas: ciertamente, Sony y First 4 no tenían intenciones ni esperaban que su esquema DRM pudiese abrir un agujero que permitiese ser aprovechado por un malware.

Tampoco Sony supo lidiar correctamente con la publicidad que surgió consecuentemente y su primer intento por corregir el problema resultó inadecuado. La desinstalación sólo estuvo disponible para aquellos que completaron un formulario, a quienes se les ofreció la elección de desinstalar el software sin la posibilidad de seguir utilizando los CDs protegidos por XCP o bien, deshabilitar la función de ocultamiento.

El parche inicial fue pobremente testeado y tenia una funcionalidad de “llamado a casa” que no fue mencionada explícitamente [13] en el Acuerdo de Licencia de Usuario Final (EULA – End User License Agreement).

La tecnología XCP no ha impresionado a la comunidad rootkit en demasía (aquellos que poseen un profundo interés técnico en el no necesariamente ilegítimo uso de tecnología stealth o similar a rootkit) aunque sí enfocó las mentes de algunos creadores de malware en la manera de utilizar la vulnerabilidad que había creado originalmente. Sin embargo, también tiene una cierta cantidad de implicaciones para la industria en general.

No es improbable que se realicen intentos por resolver el problema rootkit en términos legales [10]. Esto puede tomar la forma de una legislación específica contra ciertos tipos de rootkit maliciosos.

Si esto llegase a suceder, cualquier aplicación que utilice cualquier tipo de stealth para proteger código o datos propios o ajenos podría estar bajo riesgos legales. Esto tendría serias repercusiones en la Gestión de Derechos Digitales, que generalmente dependen de ciertos accesos ocultos o restringidos.

Aún si esas medidas no son llevadas a cabo, existen cuestiones referidas a cómo los productos son vistos por los usuarios potenciales.

Tomemos el ejemplo de la papelera de reciclaje protegida de Symantec (Symantec Protected Recycle Bin, una papelera de reciclaje segura que permite recuperar por completo los archivos eliminados que no podrían rescatarse con la papelera de Windows), una característica legítima, documentada, y potencialmente útil. No obstante esta aplicación fue fuertemente criticada luego de los titulares acerca del “Symantec Rootkit”.

Esto trae implicaciones para otras aplicaciones de seguridad, que tienen que esforzarse para jugar en primer lugar (por ejemplo, los programas de monitorización del comportamiento y de bloqueo, utilizan procesos que esconden los datos manipulando la API con técnicas similares a las de los rootkits).

Los programas de seguridad también usan otras funcionalidades ocultas, por ejemplo, para detener ingeniería inversa, desalentar la exposición del usuario a códigos maliciosos, (virus en cuarentena, etc.), interferir con la configuración del sistema, y demás.

* Metodología de detección de rootkit

Cada tanto alguien descubre que la detección de malware basada en firmas es defectuosa en tanto “no puede detectar nuevos virus”. Afortunadamente, por muchos años, los antivirus no se han confiado, únicamente, en la detección de virus conocidos.

Gran cantidad de tecnologías suplementarias (análisis heurístico, drivers genéricos, monitoreo de comportamientos, etc.) ya son utilizados para ampliar la detección de nuevas amenazas y sus variantes.

Así como con los virus stealth, el problema con los rootkits es el de “¿quién juega primero?”. Resulta difícil para un escáner detectar lo que ya está instalado y ocultando la evidencia de una infección.

Sin embargo, los desarrolladores de antivirus tienen muchos años de experiencia para encontrar maneras de eludir los últimos mecanismos de suplantación de identidad (spoofing) una vez que el código malicioso ha sido estudiado.

Generalmente, los rootkits pueden ser detectados por escaneado del sistema de archivos y de la memoria, mediante lo que se conoce como análisis de firmas.

Una aplicación característica de las tecnologías suplementarias para detectar heurísticamente las actividades posibles de rootkit, depende en gran medida, de chequear disparidades entre una vista del sistema confiable (y relativamente precisa) y la vista modificada que presenta el sistema cuando es filtrada a través de la tecnología rootkit.

Clásicamente, los sistemas operativos Unix y similares han sido debidamente protegidos por lo que se conoce como tripwire (programa que detecta e informa modificaciones en los archivos del sistema), o lo que la industria de antivirus denomina chequeo de integridad.

Aún puede utilizarse dentro del contexto de Windows, pero tiende a tener un alto grado de mantenimiento, ya que hay muchas instancias en las que los cambios de ambiente (ejecutables, ajustes de registro, archivos de configuración) pasan a ser rutina.

El crecimiento de los rootkits no-persistentes refuerza la necesidad del análisis de memoria y de la detección de los procesos de ocultamiento, en vez de confiarse en los cambios del sistema de archivos como indicadores de la infección.

También resulta deseable un acercamiento a una detección más proactiva. Cuanto más “inteligente” sea un producto para discriminar entre enganches maliciosos, ajustes del registro, etc. y los homólogos legítimos, más efectivo será en cuanto a su heurística.

Los antivirus, en años recientes, se han vuelto adeptos a la eliminación heurística de virus [16]. Sin embargo, las dificultades de este tipo de limpieza, cuando no es posible identificar exactamente el virus, permanecen, sobre todo cuando se trata de aplicaciones maliciosas no virales.

Resulta exagerado afirmar que un rootkit puede ser removido mediante la reinstalación completa del sistema, ya que podría ser más efectivo descargar las imágenes de ciertos archivos, particularmente en casos donde estos ejecutables han sido emparchados o bien, alterados.

Para poder hacer esto sin dañar los datos y afectar la productividad se requiere de una cuidadosa política de respaldos (de datos, del sistema y de las aplicaciones de usuarios).

* Medidas preventivas

Existen contramedidas que tienen sentido para cualquier plataforma. La buena práctica del backup es una defensa vital contra amenazas y desastres no planeados y debería ser el fundamento de toda política integral de datos.

Los administradores no deberían registrarse con su cuenta raíz, a menos que deban iniciar una sesión que necesite acceso privilegiado para que el trabajo se cumpla. Es preferible utilizar una cuenta no privilegiada para las tareas de rutina, cuando sea posible.

Todas las plataformas modernas brindan una forma de cambiar de una cuenta a otra, cuando se necesita acceso privilegiado, sin necesidad de reiniciar el sistema.

Puede ser peligroso confiarse en el software de seguridad de fuente abierta. Muchos trabajos comunitarios han hecho un excelente trabajo, pero a veces es difícil valorar la competencia (y a veces las buenas intenciones) de todos los involucrados en dicho proyecto.

Ciertamente, resulta inapropiado para una organización del sector comercial o público, confiar su seguridad a un producto donde no se evidencian las garantías o responsabilidades de sus programadores.

Los usuarios domésticos o de pequeñas empresas (PyMEs), pueden estar menos preocupados por estas cuestiones, pero no querrán ser abandonados a su suerte por las aplicaciones, que prueban, en cierto sentido, ser inadecuadas para sus propósitos.

También es importante la necesidad de conducir pruebas de vulnerabilidad, mantener políticas de actualizaciones de seguridad y evitar los engaños de la ingeniería social.

* Conclusión

A no entrar en pánico. El cielo no se está cayendo, ¿o si?

La tecnología “Blue Pill” de Joanna Rutkowska permite la creación de “aplicaciones maliciosas 100% no detectables, que no se basa en la oscuridad del concepto” [17] explotando la tecnología de virtualización de AMD SVP/Pacifica. A la fecha, no se ha publicado un detalle suficiente en lo que concierne a este descubrimiento y esto no es suficiente para evaluar correctamente los hechos. Aparentemente se basa en ejecutar un rootkit no-persistente dentro de una máquina virtual.

El rootkit SubVirt [18] también utiliza virtualización, pero es persistente (sobrevive al reiniciado). Es una prueba de concepto interesante, pero en ninguna medida es indetectable. Será interesante ver si “Blue Pill” es realmente “superior” en este aspecto.

No obstante, resulta seguro admitir que la carrera donde la ventaja suele pasar de las manos de los chicos malos a la de los chicos buenos y de nuevo a su inicio, continuará por un largo tiempo. Ni el pánico ni la autocomplacencia resultan apropiados, la vigilancia sí.

Muchos de los actuales autores de código malicioso están utilizando tecnología rootkit para esconder sus creaciones, pero la popularidad de dichos objetos todavía es baja, y la naturaleza esencial de estas aplicaciones maliciosas tiende a facilitar su detección, a causa de sus acciones.

Los reportes que alegan la muerte de los antivirus son muy exagerados: sin duda, el término “antivirus” genera, de alguna manera, confusiones cuando se habla acerca de las soluciones de seguridad actuales.

Hace tiempo que se acabaron los días de programas de antivirus que sólo detectan virus ignorando cualquier otra cosa.

Ahora, muchos productos son capaces de detectar una gran variedad de amenazas modernas de malware. Así como han evolucionado las amenazas, la industria antivirus no se ha quedado quieta, y algunos proveedores de AV han tenido un éxito significativo en la detección de rootkits.

No obstante, no es seguro cerrar los ojos y esperar que alguien se haga cargo de todo por usted.

Los antivirus basados puramente en firmas no pueden proteger contra nuevas amenazas que son substancialmente diferentes de las amenazas conocidas, aún asumiendo que sean actualizados con regularidad.

Los usuarios finales deben utilizar productos que tengan un largo camino recorrido y probado usando heurística avanzada y otros métodos genéricos de detección proactiva y estar alerta en sus evaluaciones de tecnología contra amenazas y de las capacidades del producto.

* Acerca de los Autores

(*) David Harley ha investigado y escrito sobre código malicioso y otros temas de seguridad desde fines de los ochenta.

A partir del año 2001, trabajó en el Servicio Nacional de Salud del Reino Unido, como Gerente de infraestructura de seguridad nacional. Allí se especializó en la administración de aplicaciones maliciosas y todas las variantes de abuso de correo electrónico, además de dirigir el Threat Assessment Centre (Centro de Evaluación de Amenazas).

Desde abril de 2006 ha trabajado como autor y consultor independiente. Fue coautor de “Virus Revealed”, y colaboró en capítulos de varios libros de seguridad y educación para grandes editoriales. También ha redactado una gran cantidad de artículos y discursos para conferencias.

(*) Andrew Lee, posee certificación CISSP (Certified Information Systems Security Professional, Profesional en seguridad de sistemas certificado), y es Director técnico de investigación en Eset LLC.

Fue miembro fundador de la Red de intercambio de información antivirus (AVIEN, Anti-Virus Information Exchange Network), y su organización hermana AVIEWS (una comunidad virtual en línea para compartir esfuerzos y reducir el impacto de la difusión de código malicioso).

También es miembro de la Asociación de Investigadores de Antivirus de Asia (AVAR, Association of anti Virus Asia Researchers), y periodista de la organización WildList.

Previamente trabajó en el área de mayor exigencia en defensa contra programas maliciosos, como administrador de seguridad en una gran organización gubernamental.

Andrew Lee es autor de varios artículos acerca de aplicaciones maliciosas, y es un orador frecuente en conferencias y eventos, incluyendo AVAR, Virus Bulletin y EICAR (European Institute for Computer Antivirus Research, Instituto Europeo para la Investigación de Antivirus Informáticos).

* Referencias

1. University of Minnesota ResNet FAQ:
http://www.resnet.umn.edu/html/rn_security.html

2. “Viruses Revealed”. David Harley, Robert Slade, and Urs Gattiker (Osborne).

3. “Dr. Solomon’s Virus Encyclopaedia”. Dr. Alan Solomon and Dmitry Gryaznov. (S&S International).

4. “Rootkits are not Malware”. Greg Hoglund.
http://www.rootkit.com/newsread.php?newsid=504;
http://www.sysinternals.com/Forum/forum_posts.asp?TID=5798

5. “Using a ‘common language’ for computer security incident information”. By John D. Howard & Pascal Meunier, in Computer Security Handbook (4th Edition) ed. Seymour Bosworth & M.E. Kabay (Wiley).

6. “A Short Course on Computer Viruses” 2nd Edition. Dr. Frederick B. Cohen, Wiley;
“Models of Practical Defenses Against Computer Viruses”. Dr. Frederick B. Cohen:
http://all.net/books/integ/vmodels.html

7. http://blogs.securiteam.com/index.php/archives/382

8. Chey Cobb, Stephen Cobb, M.E. Kabay: “Penetrating Computer Systems and Networks”. In “Computer Security Handbook 4th Edition”, ed. Bosworth & Kabay (Wiley).

9. “Trojans” David Harley. In “Maximum Security” (SAMS).

10. “Rootkit Threats Explained”. Andrew Lee. Eset, 2006.
http://www.eset.com/joomla/index.php?option=com_content&task=view&id=1401&Itemid=5

11. “Windows Rootkits of 2005” Parts 1-3. James Butler and Sherri Sparks.
http://www.securityfocus.com/infocus/

12. “Sony, Rootkits and Digital Rights Management Gone Too Far”. Mark Russinovich.
http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-rights.html;
The Root of All Evil? – Rootkits Revealed

15 “More on Sony: Dangerous Decloaking Patch, EULAs and Phoning Home”. Mark Russinovich. http://www.sysinternals.com/blog/2005/11/more-on-sony-dangerousdecloaking.html

13. http://cp.sonybmg.com/xcp/english/updates.html;
http://cp.sonybmg.com/xcp/english/form14.html

14. http://securityresponse.symantec.com/avcenter/security/Content/2006.01.10.html

15. “Hide ‘n Seek Revisited – Full Stealth is Back”. Kimmo Kasslin, Mika Stahlberg,
Samuli Larvala and Antti Tikkanen. In Proceedings of the 15th Virus Bulletin International Conference, 2005.

16. “The Art of Computer Virus Research and Defense”. Peter Szor (Addison-Wesley)

17. “Subverting Vista Kernel for Fun and Profit” Joanna Rutkowska.
http://theinvisiblethings.blogspot.com/.

18. “SubVirt: Implementing malware with virtual machines”. Samuel T. King, Peter M.
Chen, Yi-Min Wang, Chad Verbowski, Helen J. Wang, Jacob R. Lorch.
http://www.eecs.umich.edu/virtual/papers/king06.pdf

* Glosario

API hooking – En el contexto de los rootkits el hooking (enganche) describe al siguiente proceso: Cuando se hace un pedido al sistema de información, se llama a la función API que llama al kernel y devuelve la información requerida a la aplicación a través del mismo “camino de ejecución”. El enganche describe el proceso de ocultamiento de datos desviando el camino de ejecución a través de un filtro que modifica los datos devueltos.

AV – Antivirus

Backdoor-Ali (AKA ierk o slanret) – Un troyano de puerta trasera (backdoor), generalmente considerado rootkit.

Daemon (demonio) – En Unix, es un servidor o proceso del sistema que funciona en segundo plano, en oposición a ser ejecutado por el usuario. Por ejemplo, el programa ftpd es un daemon, un servicio del sistema que corre permanentemente. El programa ftp es un programa cliente, llamado por el usuario final, que utiliza los servicios de ftpd.

Deepdoor – Prueba de Concepto rootkit de Joanne Rutkowska.

Driver genérico o detección genérica – En antivirus, un término adecuado pero no universalmente utilizado, que describe una firma o definición de virus que ha sido generalizada, para detectar una familia de virus o variantes, antes que detectar una única variante simple. Esto es similar, pero no igual, a la distinción entre identificación exacta e identificación casi exacta, pues esta última está generalmente asociada con la desinfección genérica. Una discusión más detallada sobre estos conceptos está fuera del alcance de este artículo. Una buena fuente de información al respecto es “The Art of Computer Virus Research and Defense”, de Peter Szors.

Governance (Información de gobernabilidad) – Plataforma de administración de información, particularmente relacionada con cuestiones de política y acuerdos.

Grayware, Greyware – Una clase de software de alguna manera difusa que puede incluir adware, spyware, programas de acceso remoto, etc. Tiende a incluir una funcionalidad de presunto ocultamiento.

Hacker Defender – Un rootkit de aparición frecuente.

Hacktool – Un rootkit utilizado en Windows.

Heurística – Un término aplicado a una variedad de técnicas para detectar malware y variantes corrientemente desconocidas.

Keylogger – Software que usualmente monitorea el teclado (pero no necesariamente) para propósitos maliciosos (por ejemplo, robo de contraseñas).

LRK – Un Linux rootkit muy bien conocido y muy bien establecido. Descripto en: http://staff.washington.edu/dittrich/misc/faqs/lrk4.faq

Opener (AKA Renepo) – Aplicación maliciosa de Macintosh a veces considerado como rootkit.

OS X – El sistema operativo actual de Macintosh, basado en BSD UNIX pero con una interfaz que mantiene el entorno gráfico amigable, así como acceso a líneas de comando de UNIX más convencionales.

OSXrk – Rootkit del OS X de Macintosh.

Shadow Walker – Prueba de concepto de un rootkit de James Butler y Sherri Sparks, parcialmente basado en el rootkit FU de Butler.

Shell – Procesador que interpreta los comandos ingresados en una terminal y los traduce a un conjunto de instrucciones del sistema. Sin embargo, el término también se utiliza para describir un proceso o cadena de procesos ejecutados por el procesador de comandos. Un proceso que utiliza los privilegios de la cuenta raíz puede ser llamado “root shell”. Algunos programas pueden ejecutarse bajo la cuenta raíz, sin extender privilegios de esta cuenta a los usuarios. Donde existen vulnerabilidades como el desbordamiento de datos, este mecanismo puede ser utilizado por un intruso o programa malicioso para llegar a la raíz. Si bien la terminología aquí utilizada es específica de Unix, existen procesos análogos en otros sistemas operativos.

Exploración por firmas – Estrictamente, significa la búsqueda de la presencia de virus verificando una secuencia de bytes más o menos estática. De hecho, hasta los antivirus más básicos utilizan técnicas más complejas y eficientes actualmente. El término firmas es a menudo deplorado en la investigación antivirus a causa de su ambigüedad, a pesar de que probablemente sea demasiado tarde para erradicarlo del uso popular y en los medios. Sin embargo, todavía es utilizado por rutina en la detección de intrusos.

Stealth – Adjetivo: usualmente utilizado en seguridad como una alternativa de “stealthy” (sigiloso), por analogía a “stealthy aircraft” (nave aérea sigilosa) y otro tipo de terminología militar relacionada con las estrategias de ocultamiento.

Stealthware – Software (generalmente malware) que utiliza técnicas stealth para ocultarse a si mismo.

Trackware – Aplicación que registra información del uso del sistema. A veces se utiliza para distinguir los programas que llevan registro con el consentimiento del usuario.

WeaponX – Rootkit basado en Kernel para OS X.

Fuente: Vsantivirus

Rkhunter

Rkhunter (Rootkit Hunter) es una herramienta basada en Unix que busca rootkits, puertas traseras y las posibles vulnerabilidades locales. Lo hace mediante la comparación de hash SHA-1 de los archivos importantes, con buenos conocidos en bases de datos en línea, búsqueda de directorios por defecto (de rootkits), permisos erroneos, archivos ocultos cadenas sospechosas en los módulos del núcleo, y pruebas especiale gracias a loss para Linux y FreeBSD.

Características de Rkhunter:

* Comprueba los MD5 para saber si hay cualquier cambio en el sistema.

* Comprueba los binarios y herramientas del sistema para detectar cualquier rootkits conocido, o muestre características de troyano,..

* Comprueba cualquier característica de archivo sospechosa de la mayoría de los programas que se usan

* Realiza un par de las pruebas dependientes del Sistema operativo usado.

* Explora para cualquier interfaz promiscuo y comprueba puertos backdoor con frecuencia usados.

* Comprueba archivos de configuración (/etc/rc.d, sshd_config), archivos ocultos, sospechoso,..

* Hace una exploración de los servicios que escuchan en cualquier puerto, como apache, procmail, etc..

* Muestra si cierto programa es vulnerable (GPG, sendmail,…).

* Comprueba cadenas sospechosas en los módulos del kernel.

Instalar rkhunter:

#apt-get install rkhunter

Opciones de Rkhunter:

–checkall (-c) : Chequea todo.

–createlogfile [file]* : Crea un log (/var/log/rkhunter.log). (Siempre después de –checkall ó –cronjob).

–cronjob : No interactivo , no espera a que pulses enter (No tiene colores).

–display-logfile : Cuando termina el escaneo te sale el log.

–help (-h) : Muestra la ayuda.

–nocolors* : No muestra los colores.

–report-mode* : No muestra información considerada irrelevante (Poco recomendable).

–report-warnings-only* : Muestra los warnings (lesser output than –report-mode,: more than –quiet).

–skip-application-check* : No chequea la versión de las aplicaciones.

–skip-keypress (-sk)* : No interactivo, no espera que se pulse enter para seguir testando.

–quick* : Realiza un escaneo rápido.

–quiet* : Solo muestra warnings.

–update : Actualiza la base de datos y el programa si fuera necesario.

–version : Muestra la versión.

–versioncheck : Mira que versión es la ultima y la que tenemos instalada.

–bindir [bindir]* : Usa para indicar el directorio de los binarios (Si no usamos la de por defecto).

–configfile [file]* : Usar distinto archivo de configuración.

–dbdir [dir]* : Usa como directorio de la base de datos (Por defecto “/usr/rkhunter/lib/rkhunter/db” ).

–rootdir [rootdir]* : Usar en vez de /

–tmpdir [tempdir]* : Usar como directorio temporal.

Explicit scan options:

–allow-ssh-root-user* : Permite logueo de root mediante ssh.

–disable-md5-check* : Desactivar el chequeo con MD5.

–disable-passwd-check* : Desactivar el chequeo de passwd/group.

–scan-knownbad-files* : Detecta solo los rootkits “malos conocidos”.

–check-deleted : Realizar chequeo de archivos borrados.

–check-listen : Realizar el chequeo de ‘listening applications’.

Programas que escanea en busca de vulnerabilidades (programs_bad / programs_good):

httpd
sshd
exim
php
clamd
gpg
named
mc
procmail
proftpd
openssl

Ejemplos de salidas por pantalla de rkhunter:

* Application version scan
- GnuPG 1.2.7 [ Vulnerable ]
- Apache 1.3.33 [ Vulnerable ]
- Bind DNS 9.3.1 [ OK ]
- OpenSSL 0.9.7g [ Vulnerable ]

* Check: SSH
Searching for sshd_config…
Found /etc/ssh/sshd_config
Checking for allowed root login… [ OK (Remote root login disabled) ]
Checking for allowed protocols… [ Warning (SSH v1 allowed) ]

* Interfaces
Scanning for promiscuous interfaces… [ Warning! ]
Warning! Found promiscuous interface. Please use option ‘–createlogfile’ and check the logfile.

Ejemplo de lo mostrado al terminar el escaneo:

---------------------------- Scan results ----------------------------

MD5 scan
Scanned files: 0
Incorrect MD5 checksums: 0

File scan
Scanned files: 342
Possible infected files: 0

Application scan
Vulnerable applications: 3

scanning took 351 seconds

NOTA: Otras herramientas para completar lo que hacen los Rootkit Detectors de las importantes son: Sysinternals (Pack de varias herramientas, pero comprada por Microsoft,..) y Tripwire (Monitorea la consistencia de archivos y directorios de sistema críticos identificando todos los cambios hechos a ellos).

Estos dos detectores comentados en el articulo, como todos los demás, deben de saberse interpretar ya que muchas veces dan falsos positivos (Por haber añadido / actualizado algún programa). Es recomendable el uso de varios programas (Actualizados, logicamente) a la hora de escanear máquinas. Muchos rootkits cuando empiezan escaneos con estas herramientas se ocultan apagándose momentáneamente o incluso usan técnicas para confundir a estos Rootkit Detectors, la batalla es eterna.

Fuente: Busindre

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: