Rootkits Unix Windows

Funcionamiento y Detección de los Rootkits Modo Usuario y del Núcleo en Windows y Unix. Rosmira Ospino Avila Orlando Leal Ahumada Facultad de Ingeniería Programa de Ingeniería de Sistemas Fundación Universitaria San Martin 2007 Funcionamiento y Detección de los Rootkits Modo Usuario y del Núcleo en Windows y Unix. Investigación para optar al título de Ingeniero de Sistemas Minor Seguridad Informática e Informática Forense Rosmira Ospino Avila Orlando Leal Ahumada Facultad de Ingeniería Programa de Ingeniería de Sistemas Fundación Universitaria San Martin 2007 DEDICATORIA Dedico esta investigación a mi familia, que siempre me ha apoyado en todos los momentos difíciles de mi vida y he salido adelante gracias a ellos. Orlando Leal Ahumada Dedico esta investigación a mis padres que hicieron todo lo posible por cumplir mis sueños personales. Rosmira Ospino Avila AGRADECIMIENTOS A todos las personas que me encontré en el camino y confiaron en mis capacidades y a los profesores por compartir su sabiduría conmigo. Orlando Leal Ahumada A mi familia que me apoyo y a todos los compañeros que siempre estuvieron conmigo y me dieron su ayuda cuando lo necesité. Rosmira Ospino Avila CONTENIDO Introducción 1. Presentación del Proyecto 1.1 Titulo 1.2 Objetivos 1.2.1 Objetivo General 1.2.2 Objetivos Específicos 1.3 Justificación 1 2 2 2 2 3 3 2. Marco de Referencia 2.1 Marco Teórico 2.2 Marco Conceptual 2.3 Administración y control de la Investigación 2.3.1 Descripción del plan de actividades 2.3.2 Cronograma de actividades (Anexo 1) 2.4 Aspectos Financieros del Proyecto 2.1.4 Costo total estimado 3. Resultados 3.1 Análisis de requerimientos 3.1.1 Investigación preliminar 3.1.2 Análisis del sistema actual 3.1.3 Selección de las herramientas a utilizar 3.1.4 Selección de los sistemas operativos 3.1.5 Selección de las herramientas complementarias 3.1.6 Selección del hardware 4 4 5 8 8 8 8 8 10 10 10 10 11 11 12 12 4. Presentación de resultados 4.1.1 Los motivos de los atacantes 4.1.2 La parte Invisible “Stealth”. 4.1.3 ¿Cuando no importa ser invisible? 4.1.4 ¿Que es un Exploit y porque son un problema? 4.2.1 ¿Qué es un Rootkit? 4.2.2 Que no es un Rootkit 13 13 13 14 14 15 16 4.2.2.1 Un Rootkit no es Exploit.. 4.2.2.2 Un Rootkit no es un virus 4.2.3 Objetivos de un Rootkit 4.2.4 ¿Por qué existen los Rootkits? 4.2.4.1 Comando y control remoto 4.2.4.2 Escucha oculta de software (Sniffer) 4.2.5 Usos legítimos de Rootkits 4.2.6 ¿Cómo trabajan los Rootkits? 4.2.6.1 Patching 4.2.6.2 Huevos de Pascua 4.2.6.3 Modificaciones de Spyware 4.2.6.4 Modificación del Código Fuente 16 16 17 17 18 18 18 19 19 20 20 20 ROOTKITS MODO USUARIO Unix - Windows 21 4.3 Rootkits Modo-Usuario 4.3.1 Rootkits modo-usuario en Unix 4.3.1.1 Reemplazos en los binarios que proporcionan acceso a una puerta trasera 4.3.1.2 Reemplazos binarios para ocultar el atacante 4.3.1.3 Otras herramientas para ocultar que no substituyen programas binarios 4.3.1.4 Scripts de instalación 4.3.1.5 La familia LRK (The Linux Rootkit) 4.3.1.6 Crear procesos en ejecución 4.3.1.7 Utilizar la red 4.3.1.8 Crear directorios y archivos 4.3.1.9 Generar Logs 4.3.2 Herramientas del LRK 4.3.2.1 Otras herramientas de LRK 4.3.3 Defensa para los Rootkits modo-usuario en Unix 4.3.3.1 Prevención 4.3.3.2 Detección 4.3.3.3 Respuesta 22 24 24 25 25 25 26 27 27 27 27 28 29 30 30 31 34 4.4 Rootkits Modo-Usuario en Windows 36 4.4.1 Diferentes Técnicas para implementar un rootkit modo-usuario en Windows. 4.4.1.1 Técnica 1: Manipulación del Logon de Windows con FakeGINA 4.4.1.2 Técnica 2: WFP “Protección de Archivos de Windows” Cómo trabaja y los ataques contra él 4.4.1.2.1 Atacando al WFP 4.4.1.2.2 Herramienta para atacar al WFP: Code Red II 4.4.1.3 Técnica 3: Inyección del DLL, Enganchando a las API, y el AFX Windows Rootkit.. 4.4.1.3.1 Código de Windows: “EXE vs DLL” 4.4.1.3.2 Inyección del DLL y enganchando (Hooking) las API 4.4.1.3.3 AFX Windows Rootkit: Usando la inyección del DLL y enganchando a la API 4.4.2 Defensas ante un Rootkit Modo-Usuario en Windows 4.4.2.1 Prevención 4.4.2.2 Detección 4.4.2.3 Respuesta 4.4.3 Conclusión 38 39 44 45 47 49 49 50 54 56 56 58 60 60 ROOTKITS DEL NUCLEO UNIX - Windows 4.5 Rootkits del núcleo 4.5.1 Destruir el núcleo 4.5.1.1 Componentes importantes del núcleo 4.5.1.2 ¿Cual es el papel del núcleo en el sistema operativo?. 4.5.1.3 Impacto de Manipulación del Núcleo 62 63 63 64 65 66 4.5.2 Rootkits del Núcleo en Unix Métodos para manipular el núcleo de Unix. 4.5.2.1 Método 1: Módulos malignos cargables al núcleo. 4.5.2.1.1 Ejemplo de Módulos malignos cargables al núcleo: Adore 4.5.2.2 Método 2: Atacando el “/dev/kmem”. 4.5.2.3 Método 3: Parcheando la imagen del Núcleo en el Disco Duro 4.5.3 Defendiendo el núcleo de Unix 4.5.3.1 Prevención de Rootkits del núcleo en Unix 70 70 70 72 75 77 79 79 4.5.3.2 Detección de Rootkit del núcleo en Unix 4.5.3.3 Respuesta ante un Rootkit del núcleo en Unix 81 84 4.5.4 El núcleo de Windows 4.5.4.1 Aventuras en el núcleo de Windows 4.5.4.2 Métodos para manipular el núcleo de Windows 4.5.4.3 Drivers Malignos de dispositivos 4.5.4.3.1 Ejemplo de un Rootkit del Núcleo para Windows Slanret/Krei 4.5.4.4 Alteración de un núcleo en ejecución en memoria 4.5.4.5 Parcheando el núcleo en el Disco Duro 4.5.4.6 Crear un sistema falso usando una máquina virtual 4.5.4.7 Defendiendo el núcleo de Windows 4.5.4.7.1 Prevención 4.5.4.7.2 Detección 4.5.4.7.3 Respuesta 85 85 90 91 94 94 96 97 99 99 101 102 4.6 Detección de los Rootkits 4.6.1 Detectar la presencia 4.6.1.1 Proteger las puertas 4.6.1.2 Escanear “los Cuartos” 4.6.1.3 Buscar ganchos “Hooks” 4.6.2 Detectar el comportamiento 4.6.2.1 Detectar archivos ocultos y llaves de Registro.. 4.6.2.2 Detectar procesos escondidos 104 105 105 106 106 107 107 108 4.7 Tecnologías ofensivas para los Rootkit 4.7.1 NIDS 4.7.2 Como los rootkits Evitan las identificaciones de los IDS / IPS 4.7.3 Evitar herramientas forenses 109 110 110 111 4.8 Diseño de un Rootkit. 4.8.1 Manipulación de hardware 4.8.2 Modificando el Firmware 4.8.3 Acceder al Hardware 4.8.4 Direcciones de hardware 114 114 114 115 115 4.8.5 ¿Qué tan lejos se puede ir? Actualización del microcódigo 116 4.9 Perspectivas del Proyecto 4.9.1 Perspectivas para la empresa 4.9.2 Perspectivas para la Universidad 4.9.3 Perspectivas para el Investigador 4.9.4 Conclusión Bibliografía Anexos 118 118 118 119 120 122 123 Lista de Tablas. Tabla 1. Plan de actividades Tabla 2. Relación de costos Tabla 3. Varias Herramientas de Inyección de DLL y enchanche a las API´s. Tabla 4. Componentes funcionales del núcleo Tabla 5. Herramientas de Maquinas Virtuales que podrían ser usadas para engañar a los usuarios. 8 9 53 64 98 Lista de Figuras. Figura A. Diferencias entre un Caballo de Troya y un Rootkit modo Usuario. Figura 1. Usando la herramienta que comprueba la integridad de archivos antes y después de la instalación de parches. Figura 2. El Proceso de autenticación de Windows Figura 3. FakeGINA recolecta secretamente todas las identificaciones del usuario y passwords insertándose entre el winlogon.exe y msgina.dll. Figura 4. Los Atacantes usan la Inyección de DLL para enganchar a las API´s en un proceso atacado. Figura 5. La interacción entre iexplore.exe, iexplore.dll, explorer.exe, y explorer.dll cuando AFX Rootkit para Windows se ejecuta. Figura 6. Manipulación del núcleo para ocultar procesos. Figura 7. Los Rootkits de módulos cargables al núcleo alteran las llamadas a la tablas del sistema, para ejecutar el modulo con el código maligno del atacante, en vez de la llamada legítima del sistema. Figura 8. Ava, La interfaz de usuario de Adore. Figura 9. Alterando un núcleo en ejecución leyendo y escribiendo en /dev/kmem. 74 76 71 67 55 52 42 23 32 40 Figura 10. Reemplazando la imagen del núcleo en el disco duro. Figura 11. Aplicando parches directamente en la imagen del núcleo del disco duro. Figura 12. Una descripción del núcleo de Windows y su relación con los componentes vitales modo-usuario Figura 13. Tres maneras que las DLLs hacen peticiones a los procesos modo-usuario. Figura 14. Usar un driver de dispositivo para manipular el núcleo de Windows. Figura 15. Modificando el NTLDR para omitir la comprobación de integridad de Ntoskrnl.exe, y entonces modificar el Ntoskrnl.exe. Figura 16. Un rootkit debe añadir las nuevas características al código existente del firmware. Figura 17. Cómo es escogido por el bus de dirección un microchip, y entonces los datos son leído del bus de datos. 77 78 86 88 92 97 115 116 Introducción. La amenaza de los rootkits, ha estado presente desde hace un cierto tiempo, pero se está usando con más frecuencia en la actualidad y una vez que el rootkit obtiene acceso al ordenador, es muy difícil rastrearlo y eliminarlo. Los rootkits son una forma particularmente peligrosa de código malicioso, con la cual es posible esconderse en el sistema operativo de la victima, y por medio de tecnologías de ocultación, permite que los programas espías y otras formas de código realicen alguna actividad dañina, al mismo tiempo que permanece indetectable. Debemos tener presente que esta forma de ataque, usando herramientas rootkits es muy peligrosa y es indispensable mejorar las técnicas de prevención, detección, y control de estos ataques. 1. PRESENTACIÓN DEL PROYECTO 1.1 Titulo. Funcionamiento y Detección de los Rootkits Modo Usuario y del Núcleo en Windows y Unix Área Temática: Seguridad Informática (Computación forense, Auditoria informática) 1.2 Objetivos. 1.2.1 Objetivo General. En este proyecto a veces tomaremos un enfoque ofensivo. Después de todo, para una penetración exitosa el fin es no ser detectado. Introduciremos la tecnología de rootkit y los términos generales de cómo trabaja. Los Rootkits son solamente una parte de la seguridad del computador, pero son críticos para que muchos ataques puedan ser exitosos. Los rootkits suponen una amenaza invasiva y evasiva 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 proyecto definiremos estrategias para encontrar la solución a los ataques realizados utilizando herramientas rootkits. 1.2.2 Objetivos Específicos.  Haremos un recorrido por las tecnologías de ocultación para comprender mejor estas amenazas.   Prevención, Detección y Respuesta ante un ataque de Rootkit. Analizaremos las motivaciones y tecnologías subyacentes que han propiciado el uso creciente de rootkits, examinaremos las tendencias recientes y ofreceremos una perspectiva sobre el futuro de esta relativamente nueva forma de malware. 1.3 Justificación. Este trabajo esta dirigido a aquellos que están interesados en la seguridad y quieren una perspectiva más real al tratar las amenazas de seguridad. Mucho se ha escrito sobre cómo adquieren el acceso a los sistemas los intrusos, pero poco ha sido dicho respecto a qué puede ocurrir en cuanto un intruso adquiere ese acceso inicial. Creemos que la mayoría de los distribuidores de software, incluyendo Microsoft, no toman a los rootkits seriamente. Probaremos que su escáner de virus o cortafuegos de escritorio no son suficientes. Probaremos que un rootkit puede entrar en su computadora y quedar allí por años sin que usted lo sepa. Cuando empecemos a aprender los objetivos y las técnicas de los atacantes, empezaremos a comprender los defectos de los sistemas y cómo mitigarlos. Este trabajo nos ayudará a mejorar la seguridad del sistema y nos ayudara a tomar buenas decisiones al comprar software de seguridad. 3 2. Marco de Referencia 2.1 Marco Teórico. El término rootkit se originó en el mundo de Unix, donde el acceso al sistema raíz implicaba el mayor nivel disponible de privilegios de control sobre el sistema, que se otorgaba únicamente a administradores. Los rootkits de Unix permitieron a los piratas escalar el nivel de acceso hasta la cuenta raíz, y prácticamente, realizar cualquier tipo de acción en el sistema, controlando ese equipo y amenazando otros sistemas que podrían estar conectados. Recientemente, los rootkits han invadido el mundo de Windows, donde se los reconoce por su capacidad para ocultar al sistema operativo, partes del sistema de archivos, entradas de registro y otros objetos internos. Al trabajar en segundo plano, los rootkits pueden continuar actuando con impunidad hasta que el sistema se formatea por completo o se utiliza tecnología igual de astuta para repeler su ataque. Kit, la segunda parte de la palabra, implica que existen conjuntos de herramientas que cualquier persona puede obtener gratuitamente o por una cuota y posteriormente adaptarlos, para ser utilizados junto con su propio código malicioso y encubrir las actividades de este mismo programa. Actualmente, el término no está restringido a los sistemas operativos basados en Unix, ya que existen herramientas similares para otros sistemas como Windows (incluso para los sistemas operativos que no utilizan cuentas de “root”). 4 2.2 Marco Conceptual Seguridad informática La seguridad informática generalmente consiste en asegurar que los recursos del sistema de información (material informático o programas) de una organización sean utilizados de la manera que se decidió, y que la información que se considera importante no sea fácil de acceder por cualquier persona que no se encuentre acreditada. Vulnerabilidad Un error de software, es el resultado de un fallo durante el proceso de creación de programas de ordenador o computadora (software). Dicho fallo puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Las Vulnerabilidades más comunes son: - División por cero. Ciclo infinito. Problemas aritméticos desbordamiento (overflow) o subdesbordamiento (underflow). Exceder el tamaño del array. Utilizar una variable no inicializada. Acceder a memoria no permitida (access violation). Pérdida de memoria (memory leak). Desbordamiento o subdesbordamiento de la pila (estructura de datos). Buffer overflow. Deadlock. Indizado inadecuado de tablas en bases de datos. 5 Buffer Overflow: En seguridad informática, un desbordamiento de buffer es un error de software que se produce cuando se copia una cantidad de datos sobre un área que no es lo suficientemente grande para contenerlos, sobrescribiendo de esta manera otras zonas de memoria. Como consecuencia, se producirá una excepción del acceso a memoria seguido de la terminación del programa o, si se trata de un usuario obrando con malas intenciones, la vulnerabilidad de la seguridad. Exploit: Exploit (del inglés to exploit, explotar, aprovechar) es el nombre con el que se identifica un programa informático malicioso, que trata de forzar alguna deficiencia o vulnerabilidad de otro programa (llamadas bugs). El fin puede ser la destrucción o inhabilitación del sistema atacado, aunque normalmente se trata de violar las medidas de seguridad para poder acceder al mismo de forma no autorizada y emplearlo en beneficio propio o como origen de otros ataques a terceros. Un "exploit" es usado normalmente para explotar una vulnerabilidad en un sistema y acceder a él, lo que es llamado como "rootear". Virus: Un virus informático es un programa que se copia automáticamente y que tiene por objeto alterar el normal funcionamiento de la computadora, sin el permiso o el conocimiento del usuario. Los virus, habitualmente, reemplazan archivos ejecutables por otros infectados con el código de este. Los virus pueden destruir, de manera intencionada, los datos almacenados en un ordenador, aunque también existen otros más benignos, que solo se caracterizan por ser molestos. Los virus informáticos tienen, básicamente, la función de propagarse, replicándose, pero algunos contienen además una carga dañina (payload) con distintos objetivos, desde una simple broma hasta realizar daños importantes en los sistemas, o bloquear las redes informáticas generando tráfico inútil. 6 El funcionamiento de un virus informático es conceptualmente simple. Se ejecuta un programa que está infectado, en la mayoría de las ocasiones, por desconocimiento del usuario. El código del virus queda residente (alojado) en la memoria RAM de la computadora, aun cuando el programa que lo contenía haya terminado de ejecutarse. El virus toma entonces el control de los servicios básicos del sistema operativo, infectando, de manera posterior, archivos ejecutables que sean llamados para su ejecución. Finalmente se añade el código del virus al del programa infectado y se graba en disco, con lo cual el proceso de replicado se completa. Malware: Malware (del inglés malicious software, también llamado malware o software malicioso) es un software que tiene como objetivo infiltrarse en o dañar un ordenador sin el conocimiento de su dueño. Backdoor: Una puerta trasera (Backdoor) es un software que permite el acceso al sistema de la computadora ignorando los procedimientos normales de autenticación o facilita la entrada a la información de un usuario sin su permiso o conocimiento. De acuerdo en como trabajan e infectan a otros equipos, existen dos tipos de puertas traseras. El primer grupo se asemeja a los caballos de Troya, es decir, son manualmente insertados dentro de algún otro software, ejecutados por el software contaminado e infecta al sistema para poder ser instalado permanentemente. El segundo grupo funciona de manera parecida a un gusano informático, el cuál es ejecutado como un procedimiento de inicialización del sistema y normalmente infecta por medio de gusanos que lo llevan como carga. 7 2.3 Administración y control de la Investigación. 2.3.1 Descripción del plan de actividades Tabla 2. Plan de actividades Etapa Investigación preliminar Recopilación información Procesamiento información Documentación Entrega de la de Fecha de Inicio Mayo 20 del 2007 Mayo 31 del 2007 Duración 10 Días 15 Días Junio 15 de 2007 Julio 18 de 2007 Julio 27 del 2007 30 Días 7 Días 1 Día 2.3.2 Cronograma de actividades (Anexo 1) 2.4 Aspectos Financieros del Proyecto. 2.1.4 Costo total estimado El costo estimado del proyecto con relación a las semanas de trabajo es de cuatro millones ochocientos dieciocho mil pesos ($ 4.818.000) 8 Tabla 2. Relación de costos Detalle Papelería y suministros Costo del recurso Humano Costo del hardware y software Sub. Total Imprevistos 10% Total Presupuesto $ 80.000 $ 2.000.000 $ 2.300.000 $ 4.380.000 $ 438.000 $ 4.818.000 9 3. Resultados 3.1 Análisis de requerimientos 3.1.1 Investigación preliminar La creación y venta de rootkits se ha convertido en un auténtico modelo de negocio. Debido a su capacidad para evitar las soluciones de seguridad tradicionales, así como a su gran versatilidad para ocultar la realización de todo tipo de acciones maliciosas, se han convertido en una excelente herramienta para los cibercriminales, que pueden obtener con ellos suculentos beneficios económicos. Los rootkits causan serios daños al sistema y, si se les deja tomar el control, pueden obligar al usuario a formatear por completo su ordenador. Sin embargo, si se toman precauciones razonables de seguridad y se cuenta con sistemas operativos y aplicaciones con sus correspondientes parches y un programa de seguridad actualizado, se hará mucho para evitar que los rootkits obtengan acceso al sistema. 3.1.2 Análisis del sistema actual. El mundo ha visto lo que los virus pueden hacer. Algunos programas de virus se han extendido a través de millones de computadoras en solamente en unas horas. El sistema operativo más común, Microsoft Windows, ha tenido defectos que ha permitido que los virus infecten computadoras en Internet. La mayoría de los piratas informáticos no revelarán defectos de software al distribuidor. En otras palabras, si un pirata informático encontrara un defecto en Microsoft Windows, no lo revelaría a Microsoft. 10 Comprender la tecnología de los rootkit es muy importante para defenderse contra los virus. Los programadores de virus han estado usando tecnología de rootkit para muchos años para potenciar sus virus. Ésta es una tendencia peligrosa, puede traspasar cientos de miles de máquinas en una hora. Las técnicas que existen pueden destruir sistemas de computadoras y equipo físico. 3.1.3 Selección de las herramientas a utilizar. Suite Ofimática: Suite Ofimática OpenOffice reconocida por ser gratuita, tener compatibilidad con los sistemas operativos usados, estabilidad y fácil uso. Anti-spyware Spy Sweeper, uno de los mejores Anti-Spyware. Antivirus Kaspersky Antivirus, considerado como el mejor antivirus del mercado. Navegador Web Mozilla Firefox 2.0.0.5 por su seguridad y amplios plugins existentes e Internet Explorer 7, por la compatibilidad con la mayoría de las páginas visitadas. 3.1.4 Selección de los sistemas operativos para el desarrollo del proyecto. En el proyecto utilizaremos 2 Sistemas Operativos, uno de ellos es Microsoft Windows XP Service Pack 2 por las siguientes razones: - Fácil de instalar Fácil Uso 11 - Amplia Compatibilidad de hardware y software. Soporte y opciones de actualización. En la otra mitad del proyecto se utilizara FreeBSD reconocida versión Libre del Sistema Operativo UNIX, que nos brindara la estabilidad necesaria para realizar todas las pruebas requeridas para la investigación. 3.1.5 Selección de las herramientas complementarias. Complementariamente se han de utilizar las siguientes herramientas: Necesitaremos para este proyecto una conexión a Internet rápida y que sea estable, por tal razón utilizaremos una Conexión de 512 kbps. Microsoft Windows Messenger 8.1, necesario para las conferencias del grupo. 3.1.6 Selección del hardware     PC Clon con procesador Pentium Core 2 Duo. 1 GB Memoria Ram. 120 GB Disco Duro. Impresora Samsung ML-1430 12 4. Presentación de resultados 4.1.1 Los motivos de los atacantes. Una puerta trasera en una computadora es una manera confidencial de conseguir acceso. Las puertas traseras han sido popularizadas como una contraseña confidencial o método para conseguir acceso a un sistema muy seguro. Las puertas traseras pueden ser usadas para robar los datos, monitorear usuarios, e iniciar los ataques profundos en las redes de computadoras. Un atacante podría dejar una puerta trasera en una computadora por muchas razones. Irrumpir en un sistema es un trabajo duro así que en cuanto un atacante tiene éxito, querrá guardar el terreno que ha logrado. También podría hacer que la computadora comprometida inicie ataques más profundos en la red. Los atacantes también traspasan computadoras para destruirlas y en tal caso el atacante podría dejar una bomba lógica en la computadora, que ha puesto para destruir la computadora a una vez que el lo establezca. 4.1.2 La parte Invisible “Stealth”. Para pasar inadvertido, una puerta trasera debe estar invisible. Si un administrador de sistemas sospecha que su computadora o red han sido violadas, debe llevar a cabo el descubrimiento forense, buscando actividad anormal o puertas traseras. 13 La mejor manera contrarrestar las pruebas forenses es que el programa sea invisible: si ningún ataque es sospechoso, entonces ningún procedimiento forense será aplicado al sistema. Los atacantes pueden usar los programas invisibles de maneras diferentes. Algunos sólo pueden usar el tráfico de la red a un mínimo y evitar almacenar archivos en un disco duro. Los otros pueden guardar archivos pero pueden emplear técnicas antiforenses que hacen las pruebas forenses más difíciles. Si un programa invisible es usado apropiadamente, las pruebas forenses nunca serán aplicadas a un sistema comprometido, porque la intrusión no habrá sido detectada. Incluso si un ataque es sospechoso y las pruebas forenses son usadas un buen atacante almacenará los datos y perpetrara una confusión para librarse de la detección. 4.1.3 ¿Cuando no importa ser invisible? A veces un atacante no necesita ser invisible. Por ejemplo, si el atacante quiere traspasar una computadora el tiempo suficiente para robar algo, como una cuenta de correo, quizás no importa si el ataque es detectado al final. Otro caso cuando estar invisible no importa, es cuando el atacante sólo quiere dañar la computadora objetivo. Por ejemplo, quizás la computadora objetivo está controlando un sistema de ataque antiaéreo. En este caso, estar invisible no es un objetivo, sólo dañar el sistema es suficiente. En muchos casos, un el daño a la computadora será obvia (y preocupante) a la víctima. 4.1.4 ¿Que es un Exploit y porque son un problema? La necesidad para tener seguridad en el software ha sido requerida hace mucho tiempo, pero los exploits continúan siendo un problema. La raíz del problema está dentro del software mismo. La mayoría del software no es seguro. Compañías como 14 Microsoft están haciendo progresos en diseñar mejor seguridad de cara al futuro, pero el sistema operativo esta escrito su mayoría en C o C++, estos lenguajes de programación presentan agujeros de seguridad graves. Tienen un problema conocido como el buffer overflow. El buffer overflow es la debilidad más grande que presenta el software hoy en día. Esta debilidad ha sido la puerta para diseñar miles de exploits. La Adopción de lenguajes de programación mas seguros como C# o Java, podría eliminar el riesgo del Buffer overflow, aunque esto no es garantía de seguridad total, desafortunadamente estos lenguajes no son mas rápidos que C o C++ y las ultimas versiones de Microsoft Windows siguen desarrolladas bajo estos lenguajes. 4.2.1 ¿Qué es un Rootkit? Los rootkits han estado presentes durante más de 10 años. Un rootkit es una "Caja de Herramientas" que consta de programas pequeños y útiles que permiten que un atacante mantenga el acceso ROOT o administrador, que es el usuario más importante sobre una computadora. En otras palabras, un rootkit es un juego de programas y clave que admite una presencia permanente o consistente y no detectable sobre una computadora. En nuestra definición de "Rootkit", la palabra clave es "No detectable." La mayor parte de la tecnología y los trucos empleados por un rootkit son diseñados para esconder la clave y los datos sobre un sistema. Por ejemplo, muchos rootkits pueden esconder archivos y directorios. Otras características de un rootkit son generalmente para el acceso remoto y espionaje, por ejemplo, para olfatear paquetes de la red. Cuando se combinan, estas características se abren brechas inmensas en la seguridad. 15 Pero los Rootkits no son intrínsecamente malos. Es importante tener en cuenta que un rootkit es sólo una tecnología. Hay muchos programas comerciales legítimos que proveen administración remota y sniffer. Algunos de estos programas pueden ser usados en modo Invisible. En muchos sentidos, estos programas podrían ser llamados rootkits. 4.2.2 Que no es un Rootkit. 4.2.2.1 Un Rootkit no es Exploit Los Rootkits pueden ser usados en conjunto con un exploit, pero el rootkit en si mismo es un juego de utilerías de programas. Un rootkit será usado después que un ataque de exploit es exitoso. Aunque un rootkit no es un exploit, el puede incluir un exploit. Un rootkit generalmente requiere el acceso para el núcleo y contiene uno o más programas que se ejecutan cuando el sistema es iniciado. 4.2.2.2 Un Rootkit no es un virus Un virus es un programa que se auto propaga. Por contraste, un rootkit no hace copias de sí mismo. Un rootkit está bajo el control absoluto de un atacante humano, mientras que un virus no. En la mayoría de los casos, podría ser peligroso que un atacante use un virus cuando requiere ser invisible y cauteloso. La mayoría de los virus son ruidosos y fuera de control. Un rootkit permite que a un atacante se quede con el control completo. 16 4.2.3 Objetivos de un Rootkit 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. Los objetivos secundarios de un rootkit pueden ser: - Ocultar los rastros de la entrada de una persona intrusa en ordenador. 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 exploits, backdoors. Recolectar información a la que la persona intrusa no podría tener acceso o acceso total de otra manera. - Utilizar al sistema comprometido como intermediario para llevar a cabo otras intrusiones y/o ataques maliciosos. 4.2.4 ¿Por qué existen los Rootkits? Los Rootkits son una invención relativamente reciente. Las personas quieren ver o controlar lo que las otras personas están haciendo. Con la dependencia inmensa en los sistemas y el inmenso procesamiento de datos que se hace a diario, las computadoras son los nuevos objetivos. 17 Los Rootkits son útiles sólo si queremos mantener el acceso para un sistema. Si todo lo que necesitamos hacer es robar algo y partir, no hay razón de dejar un rootkit, dejar un rootkit abre al riesgo para la detección. Si usted roba algo y limpia el sistema, usted no puede dejar rastro de su operación. Los Rootkits proveen dos funciones principales: comando y control remoto, y escucha oculta de software (Sniffer). 4.2.4.1 Comando y control remoto. El Comando y control remoto puede incluir el control sobre archivos, causando los reinicios o las "Pantallas azules de la muerte", y accediendo al shell de comandos (es decir cmd.exe o /bin/sh). 4.2.4.2 Escucha oculta de software (Sniffer) Un software Sniffer escucha en la red. Esto implica olfatear paquetes, interceptar las pulsaciones de teclado, y leer el correo electrónico. Un atacante puede usar estas técnicas para capturar contraseñas y descifrar archivos, o incluso claves criptográficas. 4.2.5 Usos legítimos de Rootkits Como ya mencionamos, Los rootkits pueden ser usados para propósitos legítimos. Por ejemplo, pueden ser usados por los organismos de la ley para recolectar pruebas. Esto es aplicable a cualquier crimen en el que una computadora es usada, como la intrusión de sistemas, crear o distribuir pornografía de menores, piratería de software o música. 18 Los Rootkits también pueden ser usados para librar guerras. Las naciones y sus ejércitos dependen de los sistemas de computación en exceso. Si estas computadoras fallan, el ciclo de decisión y las operaciones del enemigo pueden ser afectados. Los beneficios de usar una computadora en ves de un ataque convencional incluyen: Cuesta menos dinero, guarda a los soldados del peligro, causa poco daño colateral a la población civil, y en muchos casos no causa daño permanente. Por ejemplo, si una nación bombardea todas las centrales hidroeléctricas en un país, entonces esas centrales hidroeléctricas necesitarán ser reconstruidas bajo un gran costo. Pero si un virus contagia la red de control y la desactiva, el país pierde el uso del producto de las centrales hidroeléctricas, pero el daño no es permanente, tan costoso y es perfectamente reversible. 4.2.6 ¿Cómo trabajan los Rootkits? Los Rootkits trabajan usando un concepto simple llamado modificación. En general, el software es diseñado hacer decisiones específicas basadas en datos muy específicos. Un rootkit ubica y modifica el software para que tome decisiones incorrectas. 4.2.6.1 Patching El Código ejecutable consta de una serie de sentencias codificadas como bytes de datos. Estos bytes vienen en un orden muy específico, y cada uno representa algo en la computadora. La lógica del software puede ser modificada si estos bytes son modificados. Esta técnica es llamada Patching. El software no es inteligente; él simplemente hace lo que 19 le programamos que haga y nada más. Es por esto qué la modificación trabaja tan bien. 4.2.6.2 Huevos de Pascua Las modificaciones de la lógica del software pueden ser "Incorporadas." Un programador puede poner una puerta trasera en un programa que el escribió. Esta puerta trasera no está documentada en el diseño, así que el software tiene una característica escondida. Esto es llamado un huevo de Pascua, y puede ser usado de la misma manera que una firma: el programador deja algo escondido para mostrar que él escribió el programa. 4.2.6.3 Modificaciones de Spyware A veces un programa puede modificar otro programa para contagiarlo con "Spyware." Algunas clases de spyware informan qué sitios Web fueron visitados por los usuarios de la computadora infectada. De la misma manera que los rootkits, el spyware puede ser difícil de detectar. 4.2.6.4 Modificación del Código Fuente A veces el software es modificado en el código desde el principio. Un programador puede insertar líneas de código maliciosas en un programa que el escriba. Esta amenaza ha causado que algunas aplicaciones militares eviten software de código abierto como Linux. 20 ROOTKITS MODO USUARIO Unix - Windows 21 4.3 Rootkits Modo-Usuario Los Rootkits puede funcionar en dos niveles diferentes, dependiendo que de software substituyen o como alteran el sistema atacado. Podrían alterar ejecutables binarios o bibliotecas existentes en el sistema. Es decir un Rootkit podría alterar muchos programas que los usuarios y los administradores ejecutan. Llamaremos a tal Rootkits: Rootkits modo-usuario porque manipulan los elementos a nivel de usuario en el sistema operativo. Alternativamente, un Rootkit podría entrar en la pieza central del sistema operativo, el núcleo. Llamaremos ese tipo de Rootkit, un Rootkit de modo-núcleo. Aunque los dos niveles de Rootkits son de hecho primos, sus características los diferencian. Para ver cómo los Rootkits modo-usuario se diferencian de los Backdoors y de los caballos de Troya, comprobaremos la figura A. Como podemos ver, estas herramientas agregan un programa maligno al sistema, conocido como malware a nivel de aplicación. Con estas herramientas, la aplicación maligna permite el acceso, pero el sistema operativo sigue intacto, incluyendo varios programas, bibliotecas y el núcleo. Con los Rootkits modo-usuario, el atacante entra más profundo en el sistema, substituyendo ejecutables y librerías compartidas en el código del sistema atacado. Estos programas infectados aparentar estar intactos, pero realmente disfrazan la presencia del atacante en el sistema. El atacante no cambia todo, apenas los componentes que necesita del sistema operativo para alcanzar sus metas. 22 Figura A. Diferencias entre un Caballo de Troya y un Rootkit modo Usuario. Los Rootkits modo-usuario están disponibles para una variedad de tipos de sistemas operativos. 23 4.3.1 Rootkits modo-usuario en Unix: Los Rootkits fueron creados originalmente para los sistemas UNIX. Los ambientes de UNIX están muy bien adaptados a los ataques de rootkit, dada su confianza hacia la cuenta root. Con una cuenta tipo root, un atacante puede configurar de nuevo el S.O, sobreescribir archivos, cambiar logs. Además, los administradores de UNIX confían bastante en los programas de línea de comando para determinar el estado de sus sistemas. Con el acceso root, un atacante tiene todos los permisos requeridos para substituir estos programas de línea de comando, alterando el sistema para satisfacer sus necesidades. Dado el poder de la cuenta root y la confianza de los administradores en herramientas de línea de comando, UNIX es tierra muy fértil para los Rootkits. Las herramientas Rootkits modo-usuario en Unix se pueden usar en cinco diversas áreas: 4.3.1.1 Reemplazos en los binarios que proporcionan acceso a una puerta trasera. Estas herramientas son el corazón del Rootkits modo-usuario en Unix. Sobrescribiendo varios programas y los servicios usados para tener acceso a la máquina, un atacante utiliza estos reemplazos para abrirse una sesión al sistema con varios backdoors. Cuando se utilizan los backdoors, el atacante se concede inmediatamente privilegios root en el sistema atacado. 24 4.3.1.2 Reemplazos binarios para ocultar el atacante. Estas herramientas sobrescriben binarios existentes en el sistema, substituyéndolos por versiones de Caballo de Troya que dejan al atacante oculto. Estos nuevos binarios mienten a los usuarios y a los administradores sobre los archivos del atacante, los procesos, y el uso de la red en la máquina de la víctima. 4.3.1.3 Otras herramientas para ocultar que no substituyen programas binarios. Estos programas dejan al atacante alterar el sistema para ocultar sus actividades, aunque no substituyen comandos. En su lugar, apoyan al rootkit incluyendo características como alterar la fecha de modificación de un programa y disfrazar las alteraciones causadas por el rootkit. Otros dejan al sistema. atacante modificar logs del 4.3.1.4 Scripts de instalación. Este programa abre las otras herramientas del rootkit, las compila en caso de necesidad, y las mueve a la localización apropiada. Después que los programas de reemplazo se carguen en los lugares apropiados, les modifica la fecha de modificación incluso pueden comprimir o rellenar las porciones de código de modo que sean todos de la misma longitud que los programas originales. El underground ha creado una variedad enorme de tipos de Rootkits para todos los sabores de sistemas de UNIX, incluyendo Linux, BSD, Solaris, HP-UX, AIX, y otros, tales como LRK, URK, T0rnkit, Illogic, SK, ZK y Aquatica. Aunque cada Rootkit varía en los detalles de que substituye y cómo se configura, todo los Rootkits modo-usuario en UNIX siguen las mismas metodologías generales. 25 Por lo tanto, aprenderemos mucho sobre cómo defender contra tales ataques estudiando un puñado de los Rootkits mas extensamente usados, miremos algunos rootkits más detalladamente, como la familia de “Linux Rootkit (LRK)”. 4.3.1.5 La familia LRK (The Linux Rootkit) Uno de los Rootkits más extensamente empleados, es la familia de herramientas de Linux Rootkit. LRK substituye varios programas que los administradores de sistema utilizan típicamente para determinar el estado de sus sistemas, incluyendo herramientas para administrar programas en ejecución, ajustes de la red, el sistema de archivos, y registros del sistema. Esencialmente, el atacante altera cada una de estas herramientas de modo que mientan al administrador de sistema. Estos comandos actúan como los ojos y los oídos del administrador de sistema. Con los ojos y los oídos alterados, el administrador no puede determinar el estado verdadero del sistema. Después de asumir el control un sistema e instalar un Rootkit, el atacante probablemente ejecutara algunos programas. Estos programas podrían ser backdoors, otras herramientas de ataque para explorar sistemas más vulnerables, o exploits individuales utilizados para asumir el control de más blancos. Más allá del Rootkit en sí mismo, estos programas adicionales requerirán que el atacante haga las siguientes cosas: 26 4.3.1.6 Crear procesos en ejecución. Las herramientas del atacante crearán procesos en el sistema, que se podría detectar o aún matar por un administrador de sistema. 4.3.1.7 Utilizar la red. El atacante pudo funcionar un sniffer para capturar las identificaciones de usuario y contraseñas, así como un escuchador de puertos backdoor para proporcionar acceso remoto al Shell. A menos que se oculte el sniffer, los administradores podrían descubrir que el interfaz de red está en modo promiscuo, indicando que un sniffer está en uso. 4.3.1.8 Crear directorios y archivos. Los atacantes generalmente escriben varios programas y archivos de configuración en la maquina víctima. También, los atacantes almacenan a menudo la información robada, tal como archivos de contraseña, software pirateado, documentos confidenciales, y pornografía en la máquina víctima. Si los no ocultan, estos archivos podrían revelar la presencia del atacante. 4.3.1.9 Generar Logs. Como el atacante manipula el sistema, el visor de logs mostrará varias acciones incriminantes. Para seguir siendo cauteloso, el atacante necesita hacer que estas acciones nunca sean mostradas en los registros de sistema. 27 4.3.2 Herramientas del LRK Sin la intervención del atacante, un administrador de sistemas puede notar cada una de estas actividades. Para tratar esta situación, LRK viene al rescate del atacante, incluyendo reemplazos para las herramientas usadas por los administradores de sistema para encontrar estas anomalías. Primero, LRK incluye varios reemplazos que ocultan procesos en ejecución en la máquina. Para utilizar esta capacidad, el atacante debe incluir el nombre del proceso que desea ocultar en el archivo /dev/ptyp. Dependiendo de la configuración de este Rootkit, varios comandos en el sistema pueden ocultar los procesos basados en su nombre completo y el número de proceso. Entonces, LRK substituye “ps”, “top”, y “pidof”, que se utilizan para determinar qué procesos están funcionando activamente en un sistema. Además, LRK sobreescribe el comando “killall”, por si el administrador descubre un proceso, no pueda matar el proceso del atacante. Es importante observar, que aunque los procesos del atacante estén ocultos de los comandos, estos todavía serán visibles en el directorio “/proc”, el cual es un componente del sistema de archivos, creado por el núcleo para mostrar el estado de todos los procesos y el núcleo en funcionamiento. Más allá de ocultar procesos, LRK también soporta ocultación del uso de la red, el comando de “ifconfig” muestra si la interfaz de red está en modo promiscuo. LRK substituye el ifconfig de modo que nunca muestre el modo promiscuo, y así ocultar los sniffers. Además, los administradores utilizan con frecuencia el comando “netstat” qué muestra que puertos TCP y UDP están escuchando tráfico. La versión de LRK del netstat muestra todo el uso de puertos, excepto los puertos configurados por el atacante en el archivo “/dev/ptyq”. 28 LRK realmente brilla en su capacidad de ocultar archivos en el sistema de archivos. El atacante crea el archivo “/dev/ptyr”, que contiene una lista de los archivos que se ocultarán. El comando “ls”, usado normalmente para mostrar el listado de un directorio, omitirá de su salida cualquier archivo que se oculte. Finalmente, el comando “find”, usado para buscar archivos, no podrá encontrar cualquiera de las entradas ocultadas. Finalmente, el comando “du”, que muestra el uso del disco, omitirá el espacio tomado por los archivos ocultados por el atacante. Con cada uno de estos reemplazos, encontrar las herramientas del atacante en el sistema podría ser absolutamente difícil para un administrador de sistema. Finalmente, LRK substituye al demonio syslog “syslogd”, que es el programa que se utiliza para grabar todos los logs en el sistema. La versión de LRK del syslogd no grabara ninguna entrada del registro que contenga las configuraciones de archivo del atacante el “/dev/ptys”. Los atacantes pueden incorporar su propia IP en ese archivo, de modo que todos eventos del log relacionados con su IP serán omitidos del archivo. 4.3.2.1 Otras herramientas de LRK Aunque el foco principal de LRK está en substituir varios programas construidos en el sistema, el LRK también incluye varios programas no incluidos originalmente en el sistema operativo. Estas herramientas le dan al atacante el acceso e información adicionales sobre el sistema. Uno de estos programas es el “bindshell”, el cual crea un listener backdoor en un puerto TCP especificado por el atacante. Con esta herramienta un atacante activa el programa LRK bindshell, el cual solo puede escuchar en puertos TCP. Entonces, a través de la red, el atacante utiliza Netcat para conectarse con el puerto apropiado donde el bindshell espera silenciosamente. 29 LRK también incluye un sniffer, así el atacante puede recopilar información sensible transmitida en texto a través de la red local. La herramienta llamada “linsniffer” intercepta automáticamente las identificaciones de usuario y las contraseñas para las conexiones ftp y telnet y las guarda en un archivo. 4.3.3 Defensa para los Rootkits modo-usuario en Unix 4.3.3.1 Prevención Para evitar que los atacantes instalen un Rootkit modo-usuario en su sistema, debemos tratar cuidadosamente el sistema y aplicar los parches respectivos. Recordemos, para instalar un rootkit, primero el atacante deberá lograr permisos de nivel root, vía robar contraseñas, aplicando un exploit para aprovechar una vulnerabilidad en un sistema débil, o encontrar una máquina sin las actualizaciones al día en seguridad. Si el atacante no puede ingresar en el sistema con permisos root, no podrá utilizar un rootkit en la máquina. Para blindar un sistema, debe quitar servicios y funcionalidades innecesarias en la máquina. Mire todos los servicios de red disponibles. ¿Cuál necesita usted realmente? Después de cerrar todos los servicios de red innecesarios, mire los paquetes instalados en la máquina. ¿Se requirieren todos? Cualquier programa local con un defecto de seguridad podría ofrecer a un usuario maligno la capacidad de escalar privilegios hasta llegar a nivel del root. Para las distribuciones de Linux, HP-UX, y OS X de Macintosh todos derivados UNIX, debemos considerar “Bastille” disponible en www.bastille-linux.org. Esta herramienta libre, es un script automatizado encaminado a blindar el sistema. La meta fundamental del Bastille es proporcionar el sistema posible más seguro, pero usable. 30 4.3.3.2 Detección. Aunque la prevención es un camino difícil, debemos reducir al mínimo la ocasión en que una víctima que cae a estas herramientas. Si un atacante instala un Rootkit modo-usuario en su sistema, debemos detectar rápidamente el ataque. Hay dos tipos de herramientas que puedan detectar el Rootkit modo-usuario: Inspectores de la integridad de archivo y herramientas específicas de identificación. Cuando están instaladas, las herramientas que comprueban la integridad de archivos, crean una base de datos de hashes cifrados de los archivos críticos del sistema, incluyendo archivos de configuración y binarios sensibles. Estos hashes actúan como huellas digitales de los buenos archivos conocidos en la máquina, y se almacenan generalmente en un medio protegido de escritura como un CD-ROM o un diskette protegido. Estas herramientas usan cifrado hashing fuerte unidireccional o algoritmos de firma digital, tales como MD5 o SHA-1. Los criptógrafos diseñaron estos algoritmos de modo que un atacante no pueda determinar si una falsificación tiene el mismo hash resultante que un programa legítimo. Por lo tanto, aunque los Rootkits pueden rellenar el programa modificado para emparejar la suma de comprobación SIN CIFRAR, el rootkit simplemente no puede hacer coincidir el Hash CIFRADO del programa original. Después de crear una base de datos inicial de hashes de los archivos críticos del sistema, El administrador de sistemas debe ejecutar la herramienta que comprueba la integridad del archivo periódicamente, tal como una vez por día o una vez cada hora en sistemas especialmente sensibles. Cada vez que la herramienta que comprueba la integridad del archivo esta funcionando, recalcula el hash de cada archivo crítico y lo compara con el hash que esta en la base de datos. Si hay una discrepancia entre hashes, alguien alteró el archivo. El administrador del sistema debe determinar si el archivo fue alterado por 31 tareas rutinarias de administrador del sistema o por un atacante maligno que ha comprometido el sistema. Figura 1. Usando la herramienta que comprueba la integridad de archivos antes y después de la instalación de parches. Las herramientas que comprueban la integridad de archivos vienen con una lista de archivos críticos que son a menudo modificados por los atacantes. Estas listas varían levemente, pero todas incluyen un estándar de programas que son atacados frecuentemente, incluyendo sshd, login, netstat, ps, ls. Las herramientas que comprueban la integridad de archivos han estado disponibles durante muchos años. “Tripwire”, fue la primera herramienta en esta categoría. Y sigue siendo una de las soluciones más fuertes y utilizadas. Está disponible en versión Free en www.tripwire.org, o sobre una base comercial en www.tripwire.com. Tripwire tiene un amplio soporte de plataformas, funcionando en la gran mayoría de sabores del sistema operativo de UNIX (Incluyendo Linux, Solaris, HP-UX, IRIX, AIX, y Tru64) y también para Windows. 32 Tripwire no es la única herramienta en este campo. The Advanced Intrusion Detection Engine (AIDE) es una alternativa Free, Disponible en www.cs.tut.fi/~rammer/aide.html, Soporta Linux, Solaris, varias Versiones de BSD, Unixware, el AIX, y Tru64. Aunque de cierta forma las herramientas que comprueban la integridad de archivos son una necesidad para cualquier administrador de seguridad en un sistema, otras herramientas complementan las capacidades para identificar los rootkits. El chkrootkit es una de las herramientas más populares de esta categoría, disponible en www.chkrootkit.org. El chkrootkit está bien entrenado en detectar los cambios específicos que varios Rootkits populares hacen a un sistema atacado. El Chkrootkit funciona en Linux, Solaris, FreeBSD, OpenBSD, NetBSD, HP-UX, y Tru64 y hace preguntas al software en un intento por determinar si un rootkit está instalado. ¿Qué pregunta el chkrootkit? Hace muchas preguntas basadas en los Rootkits más utilizados hoy en día. Cada pregunta hecha al sistema operativo está bajo el test científico de chkrootkit. Por ejemplo, el chkrootkit busca los nombres de varios archivos de configuración usados por muchos Rootkits, tal como /dev/ptyp. Además, el chkrootkit controla si hay signos de entradas suprimidas en los archivos log, una indicación que pudo haber sido utilizado un rootkit. También vigila si la interfaz de red está en modo promiscuo, lo cual es una muestra probable de un Sniffer. Para detectar Backdoors asociados a varios Rootkits, el chkrootkit vigila los puertos TCP y UDP funcionando en la máquina para mirar si coinciden con los puertos que usan los Rootkits más populares. Aunque todas esas pruebas individuales son absolutamente útiles, la mejor característica del chkrootkit es probablemente su capacidad de analizar un selecto conjunto de programas binarios para determinar si se han modificado. La herramienta busca anomalías en los siguientes comandos: 33 Amd basename biff chfn chsh cron date du dirname echo egrep env find fingerd gpm grep hdparm su ifconfig inetd inetdconf init identd killall ldsopreload login ls lsof mail mingetty netstat named passwd pidof pop2 pop3 ps pstree rpcinfo rlogind rshd slogin sendmail sshd syslogd tar tcpd tcpdump top telnetd timed traceroute w write Cuando la herramienta está funcionando conduce todas estas complejas pruebas y arroja una sola respuesta: INFECTADO o NO INFECTADO, el chkrootkit también especificará qué prueba detectó la anomalía, así que podremos determinar qué binario fue substituido. Un aspecto del chkrootkit es que sus pruebas de anomalías no requieren el establecimiento de una base de datos con Hashes. Sus pruebas no se basan en comparar hashes; todas sus pruebas se ejecutan con la lógica de la herramienta en sí misma. Por lo tanto es un complemento perfecto paras las herramientas que comprueban la integridad de archivos. Usando ambos tipos de herramientas para la detección de rootkit, tendremos mayores oportunidades para descubrir un atacante. 4.3.3.3 Respuesta. Supongamos que descubrimos que un atacante ha instalado un rootkit Modo-Usuario en el sistema. Al Investigar un sistema que tenga potencialmente un rootkit instalado, no podemos confiar realmente en el software del sistema. No se debería abrir una sesión en la máquina y comenzar a ejecutar los programas existentes. Una solución es tener los archivos críticos originales y los programas necesarios para analizar el sistema grabados en un CD-ROM, tales como ls, lsof, ps, du, y netstat. Al investigar un potencial incidente de rootkit, podremos ejecutar estas herramientas desde el CD-ROM. Pero primero hay que cerciorarse que estos programas sobre el CD-ROM estén Linkeados estáticamente. Es decir, compilarlos (o descargar las versiones precompiladas) de modo que no necesiten de ninguna biblioteca o archivo en el sistema presuntamente infectado. 34 Los ejecutables Linkeados estáticamente son programas binarios autónomos que no necesitan ninguna biblioteca para ejecutarse. El ejecutable binario hace llamadas en el núcleo del sistema operativo para investigar qué está ocurriendo. Los resultados serán más dignos de confianza que los resultados con programas cargados en la máquina. Hay varias imágenes libres en CD-ROM con colecciones de programas binarios, estáticamente linkeados disponibles en Internet. Tenemos a Knoppix, disponible en www.knoppix.org. Knoppix esta llena con conjuntos de herramientas útiles para la investigación forense. Después de terminar la investigación con Knoppix del sistema infectado con un Rootkit, se necesita reconstruir su sistema. Lo mejor que se puede hacer es reinstalar el sistema operativo, reinstalar todas las aplicaciones críticas, y aplicar todos los parches apropiados. No es recomendable sustituir el programa maligno detectado por el inspector de integridad de sistema de archivos o el chkrootkit. Si los atacantes modificaron una sola pieza del sistema operativo, probablemente también modificaron muchos otros componentes, incluyendo las aplicaciones instaladas en la máquina. Se recomienda reinstalar el sistema operativo con el CD o DVD original, o utilizar una copia de seguridad de confianza. Sin embargo, tendremos que cerciorarnos que las copias de seguridad sean realmente dignas de confianza. La reconstrucción de un sistema con una copia de seguridad que incluya un rootkit no nos llevara a ningún lado, excepto a tener el sistema infectado de nuevo. Una vez que se restablece el sistema, tenemos que vigilarlo cuidadosamente con herramientas de detección de intrusos basados en host y en red. Un atacante vuelve con frecuencia a la escena del crimen e intentara abrir una sesión en el sistema otra vez. Si vigilamos el sistema esperando que el atacante vuelva a atacar, será mucho más probable capturarlo. Finalmente para crear una copia de seguridad para el análisis forense, cerciorarse de conseguir una copia bit a bit del sistema de archivos. 35 4.4 Rootkits Modo-Usuario en Windows. Por muchos años, los Rootkits modo-usuario fueron centrados sobre todo en los sistemas UNIX. Pero las técnicas de Rootkits modo-usuario se han adaptado también a otras plataformas, especialmente durante los últimos años. Particularmente, hay un puñado interesante de Rootkits modo-usuario para Windows. Como sus contrapartes de UNIX, los rootkits modo-usuario en Windows modifican el software crítico del sistema operativo para permitir que un atacante acceda y se oculte en la máquina. Las técnicas de rootkits modo-usuario se utilizan en algunas herramientas sobre Windows, pero debemos recalcar que no hay muchos rootkits modo-usuario tan sofisticados y populares en Windows como en UNIX. Hemos observado esto en los casos de ataque a los sistemas. En UNIX, los ataques rootkits modo-usuario se emplean con mucha frecuencia. Para Windows, por otra parte, los rootkits modousuario se utilizan mucho menos. Hay varias razones de este fenómeno, incluyendo éstas: - A principios, los backdoors a nivel de aplicación proliferaron en los sistemas Windows. A mediados de los años 90, mucho del trabajo en crear las herramientas backdoor para Windows se centró en crear backdoors a nivel de aplicación, tales como los port listeners y herramientas de control remoto GUI. La mayoría de los atacantes estuvieron perfectamente satisfechos con las características de las herramientas de control remoto GUI tales como VNC, Back orifice, y SubSeven. No necesitaron modificar componentes del sistema operativo porque todas las características ofrecidas por estas herramientas a nivel de aplicación eran suficientes. - Más adelante, muchos Rootkits en Windows se centraron en la manipulación del núcleo y no de los binarios generales del sistema. Los Rootkits en Windows saltaron al nivel del núcleo en los últimos años 90. Así que muchos desarrolladores de backdoor en Windows pasaron de centrarse 36 en el nivel de aplicación, y pusieron su objetivo en el núcleo, dejando un poco de lado a los rootkits modo-usuario. - La protección de archivos de Windows (WFP) obstaculiza el reemplazo de ejecutables. Con el lanzamiento del Windows 2000, Microsoft implemento la funcionalidad en el sistema operativo que explora automáticamente la máquina buscando cambios inesperados a los ejecutables críticos y las bibliotecas. Si el WFP encuentra un cambio a un archivo crítico del sistema, restaura automáticamente el archivo original: El WFP no elimina la posibilidad de un Rootkit modo-usuario en Windows. Si desean poner un Rootkit en ejecución que substituya archivos ejecutables o las bibliotecas, los atacantes tienen que trabajar más duro para derrotar el WFP. - Windows es un sistema operativo cerrado, así que crear un Rootkit modo-usuario en Windows requiere más trabajo. El código fuente para varias versiones de UNIX está disponible extensamente, permitiendo que los atacantes agreguen fácilmente puertas traseras a los programas existentes. Mucho del trabajo es hecho por los programadores del sistema operativo al crear los programas reales. El atacante simplemente tiene que agregar características malignas al código fuente existente, creando así las falsificaciones incluidas en los Rootkits modo-usuario para UNIX. Por otra parte, con Windows, Microsoft mantiene un control más fuerte (pero no perfecto) sobre el código fuente. Un atacante que intenta crear reemplazos para los binarios y ejecutables de Windows tiene que hacer ingeniería inversa a las funcionalidades de Windows. - Windows no esta tan bien documentado como UNIX. UNIX ha estado disponible por un tiempo más largo, y el código fuente es mucho mas extensamente conocido, los buenos individuos y los malos individuos entienden sus características con lujo de detalle. Al intentar determinar cómo trabajan los ejecutables y binarios de UNIX, el atacante simplemente hace una pregunta en un foro público, o utiliza un motor de búsqueda en Internet 37 para encontrar la respuesta. En cambio, en el sistema operativo Windows, mucho de la funcionalidad no se documenta. Los atacantes tienen que calcular por fuera cómo trabaja Windows, por medio de ensayo y error. Ahora que hemos analizado algunos de los desafíos a los que se enfrentan los desarrolladores de Rootkits modo-usuario para Windows, comenzaremos a analizar cómo ellos superan estos desafíos. Cubriremos tres métodos diversos para ingresar los Rootkits modo-usuario en Windows, y miraremos como ejemplo las herramientas usan cada técnica. 4.4.1 Diferentes Técnicas para implementar un rootkit modo-usuario en Windows.  Un rootkit modo-usuario en Windows podría interconectarse con los componentes existentes del sistema operativo de Microsoft para minar su seguridad. Microsoft ha ideado varias interfaces en Windows para ampliar su funcionalidad incorporada a través de herramientas de terceros fabricantes. Un Rootkit modo-usuario podía explotar estas interfaces insertándose en ellas, en vez de sobreescribir el código de Windows. Más adelante, discutiremos una herramienta llamada FakeGINA que utiliza esta técnica.  Un rootkit modo-usuario en Windows apenas puede sobreescribir archivos ejecutables y bibliotecas existentes en una máquina Windows, mucho menos que los Rootkits modo-usuario en UNIX. Para lograr esta tarea, un atacante debe primero inhabilitar el WFP (Windows File Protection) que previene cambios a archivos críticos del sistema operativo Windows. Analizaremos cómo desactivan el WFP así que pueden sobreescribir estos archivos, después miraremos un ejemplo particular del malware que conduce tal ataque: el gusano “The Code Red II”. 38  Finalmente, un atacante podría poner un Rootkit en ejecución utilizando un sistema de técnicas muy populares para inyectar código en procesos en ejecución y sobreescribir su funcionalidad. En vez de manipular los archivos en el disco duro, estos Rootkits de modo usuario ingresan el código en la memoria de los procesos en ejecución, usando las técnicas llamadas inyección del DLL y enganchar a las API (hooking). exploraremos esta técnica, y una herramienta basada en ella, llamado el “AFX Windows Rootkit”. 4.4.1.1 Técnica 1: Manipulación del Logon de Windows con FakeGINA. En un esfuerzo por ser flexible, Microsoft ha diseñado algunos componentes de Windows para que puedan ser modificados fácilmente, así las herramientas de terceras personas pueden agregar funcionalidades al sistema operativo. Algunas partes de Windows son altamente modulares, permitiendo que un administrador (o el atacante) agregue componentes al sistema usando interfaces creadas por Microsoft. Particularmente, el proceso de autenticación de usuarios es una de las partes más importantes desde la perspectiva de seguridad, pudiéndose ampliar y darle más funciones solo agregando bibliotecas al sistema con herramientas de terceras personas. El poder modificar este proceso de autenticación de usuarios, hace que sea posible desarrollar fácilmente nuevos mecanismos de autenticación, tal como la biométrica, infraestructuras de llaves públicas, y otras herramientas. Desafortunadamente, esta flexibilidad ofrece un apoyo para los atacantes. Un atacante podría derribar este proceso usando rootkits modo-usuario tan solo agregando código maligno al proceso de autenticación de usuarios. Para entender como esto es posible, necesitamos discutir el proceso de apertura de sesión en un sistema Windows. Cuando se intenta abrir una sesión Windows, el 39 sistema operativo invoca el proceso Winlogon. Este proceso recoge sus credenciales de autentificación (Ej, Un ID y un password) y las verifica si coinciden entonces se da acceso al sistema. Este proceso se ilustra en la figura 2 Figura 2. El Proceso de autenticación de Windows El usuario inicia el proceso de autenticación conducido por lo que Microsoft llama “Secuencia de acción segura”, mostrado en el paso número 1 de la Figura 2. La Secuencia de acción segura más común es presionar al mismo tiempo la combinación de teclas Ctrl+Alt+Supr. En el paso número 2, el proceso Winlogon invoca a “GINA”, que es una biblioteca especial diseñada para la autentificación. GINA es una abreviatura en ingles para “Graphical Identification aNd Authentication”. En el paso número 3, GINA le pide al usuario las credenciales de autentificación, tales como una identificación de usuario y una palabra clave. GINA entonces empaqueta estas credenciales para el mecanismo de autentificación apropiado (Ej, The Local 40 Security Authority), y si las credenciales son auténticas, entonces lanza el ambiente de usuario, lo cual se muestra en los pasos números 4 y 5. Por defecto, los sistemas Windows se ejecutan con un GINA proporcionado por Microsoft llamado “Msgina.dll”. Ahora, para dar soporte a varios mecanismos de autentificación, Windows permite que los administradores de sistema instalen GINAs de terceras personas. De hecho, en vez de escribir totalmente un GINA desde cero, un desarrollador podría poner un pedazo de código entre el proceso de Winlogon y el Msgina.dll existente, De tal manera, las funciones de autenticación existentes están preservadas, y las nuevas capacidades puede ser agregadas fácilmente. Al ser esto posible, los desarrolladores inescrupulosos modifican un GINA agregándole código maligno empleando las técnicas de rootkit modo-usuario en Windows. Una de las herramientas más populares de ataque a un GINA es “FakeGINA”, está disponible en http://ntsecurity.nu/toolbox/fakegina, FakeGINA no es por sí mismo un rootkit modo-usuario completo. Sin embargo, utiliza técnicas rootkit para minar el proceso de autentificación, y podría ser incluido como herramienta en un conjunto de Rootkits. Según lo ilustrado en la figura 3, FakeGINA se ubica entre el proceso de autenticación y el Msgina.dll existente. El propósito de FakeGINA no es dar acceso trasero. En su lugar, graba los passwords digitados por todos los usuarios del sistema, guardándolos en un archivo para el atacante. 41 Figura 3. FakeGINA recolecta secretamente todas las identificaciones del usuario y passwords insertándose entre el winlogon.exe y msgina.dll. El paso número 1 funciona igual que siempre; el proceso Winlogon es activado por un usuario, Sin embargo, en el paso número 2 el proceso Winlogon llama a la herramienta FakeGINA en vez de la GINA verdadera. Cuando el usuario digita su identificación y password, la herramienta FakeGINA las escribe secretamente al archivo del atacante, en los pasos números 3 y 4, después de la escritura al archivo, FakeGINA pasa las credenciales de autentificación a la GINA verdadera en el sistema, Msgina.dll. En los pasos números 6 y 7, la GINA verdadera termina el proceso de autentificación. Para instalar FakeGINA, el atacante debe modificar una llave en el registro indicando qué GINA debe utilizar el sistema. Esta llave, situada en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Wi nlogon, se nombra GinaDLL. Si esta llave del registro no se modifica, el Msgina.dll 42 original es utilizado por el sistema. Para instalar FakeGINA, el atacante debe cambiar esta llave del registro, de modo que contenga el nombre del archivo FakeGINA.dll, el cual debe ser guardado en el directorio System32. Luego de esto cuando se reinicie el sistema, FakeGINA comenzará a interceptar todos los Nombres de Usuarios y sus passwords, que se escriban y guardara todo esto a un archivo nombrado “passlist.txt” en el directorio System32. Para instalar FakeGINA, el atacante necesita privilegios de administrador para poder alterar el registro y para guardar la GINA maligna en el directorio System32. Sabiendo esto nos preguntamos ¿Porqué un atacante que tiene permisos de administrador en un sistema, querría conseguir una lista de passwords de la maquina? Realmente, estos passwords podrían tener mucho valor por varias razones. Primero, el atacante pudo haber explotado un cierto proceso en la máquina que se ejecutaba con privilegios de sistema o de administrador vía un buffer overflow. El atacante puede ejecutar comandos con estos privilegios y de tal modo instalar FakeGINA, sin saber el password de administrador. Después de instalar FakeGINA el atacante puede esperar a que el verdadero administrador se autentique para abrir una sesión. En este punto, el atacante sabrá el password del administrador. Otra razón por la cual FakeGINA es tan valioso para los atacantes que tienen ya privilegios de administrador, implica en la práctica común de los usuarios de usar los mismos passwords en varios Computadores. Teniendo en su poder los passwords, el atacante puede intentar ingresar a otros sistemas y con suerte se podrá autenticar. Finalmente, se podría pensar que es mejor el uso de una herramienta de passwordcracking en vez de FakeGINA. Después de todo, si un atacante tiene permisos de administrador, fácilmente podría grabar el archivo cifrado que almacena los passwords, y ejecutarle una herramienta de password-cracking. Dependiendo de cuán difícil sea descifrar el archivo de passwords, esto podría tomar entre segundos y años. 43 Con FakeGINA, por otro lado, los passwords se materializan inmediatamente en el archivo del atacante cada vez que un usuario abre una sesión. 4.4.1.2 Técnica 2: WFP “Protección de Archivos de Windows” Cómo trabaja y los ataques contra él. Aunque FakeGINA pueda ser peligroso, solamente altera las funciones de Windows que Microsoft diseñó específicamente para ser cambiadas a través de interfaces especiales. Suponiendo que un atacante quiere alterar otros ejecutables o bibliotecas con un ataque rootkit modo-usuario. El atacante tendrá que enfrentarse con el WFP, que es una característica incorporada a Windows 2000, XP, y 2003. Cuando un directorio que contiene los archivos críticos de Windows (Ej. El directorio System32) se cambia, el sistema invoca al WFP para revisar la firma digital del archivo cambiado. El WFP vigila programas sensibles, bibliotecas, y archivos de configuración para buscar cambios. Si detecta un cambio en estos archivos, el WFP compara la firma digital del archivo cambiado con la del archivo original. Si la firma no corresponde con un valor guardado en el registro aprobado por Microsoft, el WFP substituye el archivo por la versión original. Esta característica podría afectar seriamente el Rootkit modo-usuario de un atacante, desinstalando automáticamente la herramienta antes de que el atacante tenga ocasión de utilizarla. Pero en contraparte el WFP se centra en controlar si hay cambios a los archivos existentes; si un nuevo archivo se agrega a un directorio sensible, el WFP ni previene ni registra el hecho. Su único foco está en la detención de cambios a los archivos existentes que Microsoft considera sensibles. Microsoft creó el WFP para responder a las necesidades de estabilidad y seguridad. Podremos cambiar o suprimir un archivo protegido con WFP y treinta segundos después, aparecerá la misma vieja versión otra vez sin intervención del usuario. 44 Cuando detecta un cambio en un archivo critico, el WFP mira en las siguientes localizaciones, en este orden, para localizar una buena versión del archivo alterado: 1- El directorio “Dllcache”, que está por defecto en el directorio “System32”. Windows Xp: Se encuentra en C:\WINDOWS\system32\dllcache. Windows 2000: Se encuentra en C:\Winnt\system32\dllcache. 2- El archivo “Driver.cab”, que se almacena en el directorio “Driver Cache”. Windows Xp: Se encuentra en C:\WINDOWS\Driver Cache\i386\driver.cab. Windows 2000: Se encuentra en C:\WINNT\Driver Cache\i386\driver.cab. 3- En la ubicación de la instalación original del Windows, que puede ser el disco duro o en un directorio de red accesible si el sistema operativo fue originalmente instalado vía red. 4- Un CD-Rom o DVD insertado, con los archivos de instalación de Windows. 4.4.1.2.1 Atacando al WFP ¿Cómo puede un atacante manipular el WFP para reemplazar los programas originales de Windows? El atacante tiene por lo menos cuatro opciones. Primera Opción: El atacante podría simplemente borrar la versión de reserva que se encuentra en el Dllcache C:\WINDOWS\system32\dllcache y enseguida borrando el archivo real. Aunque esto funciona, tiene un inconveniente para el atacante: El usuario verá un mensaje de alerta en la pantalla. Segunda Opción: Alterar la localización del Dllcache modificando la llave del registro SFCDllCacheDir. Un atacante podría simplemente crear una nueva carpeta de Dllcache y configurar el sistema para utilizarla. El WFP entonces no estaría 45 comparando los archivos que contienen el rootkit con los archivos originales de Microsoft. Sin embargo esta técnica no trabaja tan bien, pues el WFP controla las firmas digitales de todos los archivos protegidos. Sin las firmas digitales correctas de los programas, el WFP no podrá asegurar la autenticidad de los programas del atacante. Por lo tanto, esta opción generaría muchos mensajes de error en el log, porque constantemente el WFP estaría preguntándose por qué ningunas de las firmas de archivos en la nueva carpeta de Dllcache están correctas. Tercera Opción: Fijar la llave del registro “SFCDisable” al valor recomendado por Microsoft para apagar el WFP. Fijando este valor del registro a 1, el atacante puede invalidar el WFP la próxima vez que el sistema reinicie. Sin embargo el cambio no es inmediato, hasta que el sistema reinicie el WFP seguirá activo. Por lo tanto, un atacante tendría que cambiar la llave del registro, instalar un depurador del núcleo, forzar el sistema para reiniciar, y después instalar un rootkit modo-usuario. Para complicar las cosas al atacante, al haber cambiado el valor de configuración del registro de SFCDisable a 1, el sistema operativo al reiniciar mostrara un cuadro de diálogo con este texto: “¡Alerta! La protección de archivos de Windows no está activa en este sistema. ¿Le gustaría activar la protección de archivos de Windows ahora? Esto permitirá la protección de archivos de Windows hasta el próximo reinicio del sistema. .” Al ver este mensaje, un administrador de sistemas diligente enseguida empezaría una investigación en el sistema. Cuarta Opción: El atacante podría fijar la llave del registro SFCDisable a un valor diverso indocumentado por Microsoft, Se determino que fijar el valor de SFCDisable a 46 0xFFFFFF9D invalidaría totalmente el WFP. En el próximo reinicio del sistema, el WFP no se activara. También, al usar esta configuración, el sistema no imprimirá ningún cuadro de diálogo indicando que el WFP se ha apagado, aunque en el registro del sistema quedara el siguiente mensaje: “La protección de archivos de Windows no está activa en este sistema.” Esta cuarta opción es un poco más complicada en Windows 2000 Service Pack 2, Windows Xp, y Windows 2003. En estos tipos de sistemas, además de cambiar el valor del registro de SFCDisable, el atacante debe alterar una biblioteca específica en el sistema, llamada Sfc.dll. Usando un editor hexadecimal, el atacante tiene que cambiar cuatro dígitos hex en esta biblioteca para activar el clave de SFCDisable. (Los cuatro dígitos varían según el sistema operativo). Después de ejecutar cualquiera de estos cambios, el atacante puede modificar cualquier archivo en el sistema. El WFP desactivado no interferirá con las acciones del atacante, quedando el sistema listo para implantar un Rootkit modo-usuario. 4.4.1.2.2 Herramienta para atacar al WFP: Code Red II. Una herramienta que ataca al WFP, es el gusano “Code Red II”, que utiliza técnicas de gusano y de rootkit para atacar los sistemas Windows que ejecutan el servidor Web Internet Information Server (IIS). El gusano Code Red II explora y penetra los servidores IIS de la víctima, explotando una vulnerabilidad buffer overflow. Una vez ejecutándose en la máquina de la víctima, el gusano Code Red II hace copias del shell de comando cmd.exe en varias localizaciones, incluyendo C:\Inetpub\Scripts\Root.exe. Este directorio es donde el servidor IIS guarda todos los scripts Accesibles vía Web. El Code Red II copia el Cmd.exe allí, renombrándolo como “Root.exe”. 47 Con una copia del ejecutable del shell de comando situado en este directorio del IIS, el atacante puede enviar remotamente comandos a este shell vía IIS. Con este backdoor listo, el gusano tiene que encubrir este backdoor ocultando el archivo Root.exe. Para lograr esto, el Code Red II inserta un caballo de Troya llamado “explorer.exe” en los directorios de C:\ y de D:\. El Windows Explorer normal ejecuta el GUI estándar de Windows. Desafortunadamente, debido a un fallo en maquinas Windows sin parchear, llamada “Relative Path Vulnerability”, un archivo nombrado explorer.exe en la raíz de las estructuras de directorios (C:\ o D:\) será ejecutado por defecto siempre que un usuario inicie su sesión. Así pues, cuando un usuario abre su sesión, automáticamente se ejecuta el gusano cuando se inicia la GUI. La versión del gusano de explorer.exe era simplemente una envoltura para filtrarse cuando se ejecuta el verdadero “explorer.exe”. El filtro incorporado a la herramienta, sin embargo, enmascara todas las referencias a los ficheros de Root.exe y explorer.exe creados por el gusano. Así es cómo el explorer.exe falso y el backdoor del shell de comando se ocultan. La versión maligna del explorer.exe también tiene otra característica. Altera el valor de la llave del registro “SFCDisable”, cambiándola a 0xFFFFFF9D de modo que el WFP sea desactivado. De tal manera, un atacante puede tener acceso al sistema y realizar cambios a los archivos sin tener que preocuparse del WFP. Una manera de protegerse de este ataque es tener al día todas las actualizaciones y parches oficiales de Microsoft. 48 4.4.1.3 Técnica 3: Inyección del DLL, Enganchando a las API, y el AFX Windows Rootkit Hemos visto cómo un atacante pone código como “FakeGINA” entre los componentes medios de Windows y sobreescribe archivos del sistema invalidando el WFP. Ahora, hablaremos de otra técnica de Rootkit modo-usuario en Windows que es perniciosa y popular. En vez de desactivar características de Windows o engañar al sistema operativo, los atacantes están cada vez más inyectando código maligno en el espacio de memoria de procesos corriendo en una máquina. En una máquina ejecutando Windows, varia docena se están ejecutando en un momento dado, cada uno con su propio espacio de memoria. Algunos procesos son aplicaciones del usuario, tales como Word o un reproductor de música. Otros se asocian al sistema operativo, tal como el proceso de Winlogon usado para la autenticación de usuarios. Con los privilegios apropiados en la máquina, un atacante puede inyectar código maligno en cualquier proceso que se ejecuta, sobreescribir funciones existentes en ese proceso, y activar el código maligno para ejecutarse adentro de otro proceso. Con esta forma de Rootkit modo-usuario en Windows, en vez de substituir archivos en el disco duro, los atacantes inyectan código maligno en los procesos en ejecución. 4.4.1.3.1 Código de Windows: “EXE vs DLL” Para entender cómo esta técnica de inyección del código trabaja, necesitamos discutir dos de las formas más comunes de código en las máquinas Windows: programas ejecutables (EXE) y bibliotecas de conexión dinámica “dynamic link libraries” (DLLs). Los archivos .EXE son simplemente programas que pueden ejecutarse en la máquina. Cuando un EXE comienza a ejecutarse, crea un proceso corriendo en el sistema. Los 49 archivos .DLL, por otra parte, no se ejecutan directamente. En su lugar, proporcionan funciones a un proceso .EXE de modo que pueda realizar ciertas cosas. Los archivos .DLL son pequeños paquetes de código, repartidos en diversas funciones. Todas las funciones relacionadas ofrecidas por una o más archivos .DLL se llaman “application programming interface” (API). Cada función individual en un DLL realiza una cierta acción en el sistema. Los procesos .EXE funcionando en el sistema cargan archivos .DLL en su memoria y los comparten con otros procesos .EXE. Por ejemplo, un solo .DLL que muestra información en la pantalla, se puede utilizar por cientos de archivos .EXE, todos para beneficiarse de las mismas funciones de la .DLL. 4.4.1.3.2 Inyección del DLL y enganchando (Hooking) las API. Así pues, un programa .EXE carga varias .DLL que el requiere para realizar acciones en el sistema. Los atacantes utilizan una técnica llamada inyección del DLL, para forzar a un proceso .EXE validar un .DLL que él nunca pidió. El atacante inyecta código bajo la forma .DLL directamente en el espacio de memoria del .EXE. La inyección del DLL requiere varios pasos del atacante los cuales son: - Afectar un espacio en el proceso .EXE para que el código .DLL se inyecte. Microsoft ha incluido una función incorporada en la API de Windows para lograr esta tarea, llamada “VirtualAllocEx. - Escribir el nombre y el código DLL en la memoria del proceso víctima. Windows incluye una API con una función para hacer esto, llamada “WriteProcessMemory” que se puede utilizar para escribir datos arbitrarios en la memoria de un proceso ejecutándose. 50 - Crear un hilo en el proceso víctima para ejecutar el DLL inyectado. La API “CreateRemoteThread” empieza un hilo de ejecución en el proceso para poder inyectar la DLL. El atacante ejecuta una herramienta de inyección del DLL que crea un proceso atacante para utilizar estas llamadas de función de Windows, el proceso de inyección del DLL del atacante, inserta funciones en cualquier otro proceso que se ejecuta. Por ejemplo se podría usar esta técnica, para inyectar código para implementar un backdoor funcionando tras el proceso “Notepad.exe”. Para realizar cada uno de estos pasos vistos de inyección del DLL, el atacante debe tener los programas correctos de depuración en el sistema. Estas Herramientas se utilizan normalmente cuando un administrador de sistema debe localizar detenidamente fallas en un programa. Para realizar su trabajo, un depurador requiere el acceso detallado a las estructuras de memoria de un programa funcionando, incluyendo todos los datos así como el código. Con este gran nivel de acceso y control, los programas de depuración se guardan muy cuidadosamente en el sistema, dado solamente a los administradores, sin embargo, asumiendo el control de una máquina, los atacantes pueden explotar esta capacidad. Al tener acceso a estos programas de depuración, el atacante los utiliza para realizar la inyección del DLL. Con las herramientas que proporciona Microsoft, cualquier tipo de código se puede inyectar en cualquier proceso en ejecución. Empleando esta técnica, el atacante puede inyectar código en un proceso. ¿Pero qué tipo de código inyectará el atacante?. Rootkit modo-usuario. Aquí es donde el concepto de enganche (Hooking) a las API entra en el juego, permitiendo que el atacante emplee técnicas de 51 El atacante sobreescribe código de .DLL existentes cargadas en el proceso en ejecución. El atacante engancha ciertas funciones en las API´s ofrecido por una DLL legítima hacia el código maligno proporcionado por el atacante, según lo ilustrado en la figura 4. Es decir, estas llamadas de función no activarán más el código legítimo en la DLL. En su lugar, cuando un proceso .EXE hace un llamada de función para realizar una acción, tal como visualizar información en una ventana en la pantalla, el DLL inyectado del atacante será ejecutado. El código del atacante decidirá si muestra correctamente la información en la pantalla, filtra la salida, o realiza otra actividad totalmente diferente. Figura 4. Los Atacantes usan la Inyección de DLL para enganchar a las API´s en un proceso atacado. Usando estas técnicas de enganchar a las API en coordinación con la inyección del DLL, un atacante puede substituir o envolver las funciones críticas del sistema, teniendo una puerta trasera y ocultándose en un sistema. Es decir usando estas técnicas, un atacante puede implementar un Rootkit modo-usuario en Windows. Este proceso de varias fases de inyectar DLL’s y de enganchar API’s suena bastante complejo, con muchos pasos para realizar. Sin embargo, los atacantes no usan estos 52 pasos a mano. En vez de eso, utilizan programas automatizados para conducir todo el proceso sin mucha intervención manual. De hecho, se han desarrollado herramientas de inyección del DLL y enganche de API, simplificando el proceso. La herramienta “MadCodeHook”, es una de estas herramientas API que incluye el código que puede inyectar DLL’s en una variedad de sistemas operativos de Windows, incluyendo Windows 95 /98/NT/2000/XP/2003. El MadCodeHook lo hace tan fácil como es posible, inyectando DLL’s en procesos ya en ejecución. El atacante apenas escribe un pequeño programa que llame al MadCodeHook, y la herramienta se encargara del resto. Una lista de varias herramientas de inyección del DLL y enganche de API, se incluye en la tabla 3. Tabla 3. Varias Herramientas de Inyección de DLL y enchanche a las API´s. Nombre Características Extremadamente bien completamente Dirección MadCodeHook documentada, equipada en inyección del DLL y enganche a las API. www.madshi.net/olddlp6.htm APIHijack Biblioteca para simplificar el www.codeproject.com/dll/apihijack.a sp enganche a la API. API que ejecuta VirtualAllocEx, EliRT CreateRemoteThread, y otras www.anticracking.sk/EliCZ/export/Eli funciones, funciona en Windows RT.zip (Win95/98/Me,NT/2000/XP/2003) Inject.exe Ejecutable en líneas de www.megasecurity.org/Programmin g/StealthDLLInjection.html comandos, basado en EliRT. 53 4.4.1.3.3 AFX Windows Rootkit: Usando la inyección del DLL y enganchando a la API. “AFX Windows Rootkit” distribuido en www.iamaphex.cjb.net, este Rootkit modousuario se centra en ocultar cosas en todas las versiones Windows, incluyendo Win95/98/Me/NT/2000/XP/2003. Este Rootkit no incluye ninguna función para ejecutar un backdoor. AFX se centra solamente en ocultar cosas. El atacante tiene que usar una herramienta backdoor aparte, tal como “Netcat listener”, “VNC”, o cualquier otra herramienta que deje un backdoor remoto. Una vez que el backdoor esté instalado, el AFX Windows Rootkit oculta el backdoor utilizando la inyección del DLL y enganche a la API. El AFX Windows Rootkit es capaz de enmascarar cuatro aspectos diversos de los backdoors: procesos en ejecución, archivos en el disco duro, llaves del registro, y los puertos del TCP o UDP. Un atacante primero asumiría el control del sistema e instalaría una herramienta backdoor, después instalaría y utilizaría el AFX Windows Rootkit para ocultar cualquier rastro del backdoor en el sistema, los administradores y los usuarios no podrán ver la evidencia de procesos del backdoor, archivos, las configuraciones del registro, o de las conexiones de red. La herramienta solamente consiste en un programa ejecutable, la consola de configuración de AFX Windows Rootkit, que se utiliza para configurar y para generar Rootkits personalizados basados en las necesidades del atacante. El atacante activa esta consola de configuración en su sistema local y configura el Rootkit, después genera un archivo ejecutable para ser ejecutarlo en la máquina de la víctima. El proceso usado por el ejecutable Rootkit para instalarse se muestra en el cuadro 7.21. Cuando se ejecuta en la máquina de la víctima, primer el ejecutable del Rootkit hace una copia de sí mismo en el directorio System32. Entonces, en los pasos 1 y 2 de la figura 5, crea otros dos archivos en el mismo directorio: “iexplore.dll y explorer.dll”. 54 Estos archivos a simple vista parecen ser los que se asocian al Internet Explorer (iexplore.exe) y al Windows Explorer (explorer.exe), pero prestando atención a los sufijos de los archivos nos damos cuenta que no lo son. Figura 5. La interacción entre iexplore.exe, iexplore.dll, explorer.exe, y explorer.dll cuando AFX Rootkit para Windows se ejecuta. Después de grabar éstas DLLs en el directorio System32, el ejecutable del Rootkit inyecta el explorer.dll al proceso explorer.exe, en el paso 3. El proceso explorer.exe es un programa legítimo que muestra la GUI de Windows al usuario. Una vez dentro del proceso explorer.exe legitimo, el explorer.dll maligno entonces engancha la API. En el paso 4, engancha el código dentro de iexplore.dll. Para acabar el proceso, en el paso 5, explorer.dll inyecta el iexplore.dll al proceso explorer.exe, sobreescribiendo las llamadas de función asociadas a visualizar procesos, archivos, llaves del registro, y las conexiones. 55 Cuando las herramientas de Windows se ejecutan, como el Administrador de tareas, el explorador del archivos, el editor de registro, o el comando netstat, el código maligno API inyectado en el Windows Explorer oculta la salida. De esta manera, los hechos del atacante se ocultan en la máquina. Desafortunadamente, si decidimos desinstalar del sistema el Rootkit, no basta con intentar borrar los archivos iexplore.dll y explorer.dll en el directorio System32. Si se intenta suprimir estas DLL’s, Windows mostrara una advertencia diciendo que estos archivos están funcionando y no pueden ser borrados. Mientras el sistema operativo se esté ejecutando, no permitirá que éstas DLL’s sean quitadas del sistema. 4.4.2 Defensas ante un Rootkit Modo-Usuario en Windows. ¿Cómo podremos defendernos de los ataques Rootkit del modo-usuario en Windows?. Las herramientas de defensa y las técnicas requeridas para estas herramientas están muy asociadas a las que discutimos en los sistemas UNIX. Como vimos en UNIX, las defensas de Rootkit modo-usuario se manejan en tres áreas: prevención, detección, y respuesta. Pasemos a cada una, citando las herramientas específicas que se pueden utilizar para proteger los sistemas Windows. 4.4.2.1 Prevención. Como en los Rootkits de UNIX, los atacantes requieren privilegios de superusuario para ejecutar cada una de las técnicas de Rootkit para Windows que hemos discutido. Por lo tanto, se necesita endurecer y parchear los sistemas cuidadosamente, para asegurarse de que un atacante no pueda conseguir privilegios de administrador o del sistema. 56 Para endurecer el sistema, hay una variedad de guías y programas disponibles. Sin embargo, uno de las mejores es el “Win2K Pro Gold Template” disponible en http://www.cisecurity.org. Windows 2000, XP, y 2003 utilizan el concepto de plantillas de seguridad, que es un archivo que contiene varias configuraciones de seguridad para el sistema. Las plantillas de seguridad se pueden utilizar para empaquetar en una misma plantilla todas las configuraciones para permisos de cuentas de usuarios, configuraciones del registro, controles de password, y autenticación, así como muchas otras opciones de configuración de seguridad en Windows. Aplicando la misma plantilla a muchos sistemas, podremos estar seguros que la seguridad a través de todo el ambiente manejado es estándar. Los administradores pueden aplicar estos archivos de plantilla de seguridad a los sistemas usando una variedad de mecanismos, incluyendo la herramienta de línea de comandos “Secedit.exe”, la “The Security Configuration and Analysis Tool GUI”, o, si se maneja el “Active Directory”, se configura un objeto en la política del grupo. Windows viene de fábrica con una variedad de archivos de plantillas de seguridad para las estaciones de trabajo, servidores, y controladores de dominio. Sin embargo, estos modelos incorporados tienden a ser demasiados débiles de modo que cualquier atacante puede pasar a través de ellos, o tan fuertes que hacen el sistema inutilizable en un ambiente del mundo real. El centro para la seguridad del Internet (CIS), la agencia de seguridad nacional, y el instituto SANS, junto con una variedad de organizaciones, emprendieron la tarea de crear una plantilla que fuera lo suficientemente segura pero usable a la vez. El resultado fue “Win2K Pro Gold Template”. mayoría de las organizaciones. Esta plantilla proporciona configuraciones razonables de seguridad para las estaciones de trabajo usadas en la 57 Sirve como un punto de partida y referencia excelente para la configuración de seguridad. Se puede configurar para hacerla más fuerte, o mas débil dependiendo del grado de seguridad que se quiera manejar. El CIS también lanzo una herramienta libre para comparar la configuración de seguridad de nuestro sistema contra un modelo dado, la herramienta funciona localmente, y compara el nivel de seguridad del sistema contra un modelo de la plantilla, dando resultados entre 0 y 10. A un resultado más alto, más cerca se encuentra el sistema a la plantilla de seguridad usada para la comparación. Para generar el resultado, la herramienta usa un elaborado algoritmo que analiza los Services Packs y Hotfixes, cuentas de usuarios, políticas de seguridad, servicios disponibles y otras configuraciones de seguridad. “The CIS scoring tool” esta disponible sin cargo alguno en: http://www.cisecurity.org/tools2/windows/ng_scoring_tool-gui-1.0-win32.exe. 4.4.2.2 Detección La prevención es buena, pero no hay defensa totalmente impermeable. Por lo tanto, se necesitan sólidas capacidades de detección para los Rootkits modo-usuario en Windows. Como en UNIX, las herramientas que controlan la integridad de archivos, son uno de los mejores métodos para buscar los cambios maliciosos introducidos por los Rootkits modo-usuario en Windows. El WFP proporciona una seguridad mediana, y se debe estar alerta a cualquier cuadro de diálogo o a los logs de registro del WFP, que dirán si se ha alterado un archivo crítico del sistema. 58 Aunque el WFP proporciona cierta protección contra cambios en archivos críticos, se necesita ir más lejos, empleando herramientas de integridad de archivos para sus sistemas críticos. Estas herramientas exploran el sistema y buscar cambios en los archivos críticos del sistema, basados en hashes cifrados de los archivos legítimos y sus configuraciones. “Fcheck” es una herramienta gratuita que realiza tales funciones en Windows, disponible en www.geocities.com/fcheck2000/fcheck.html. Adicionalmente, la versión comercial de “Tripwire” también se ejecuta en Windows, disponible en www.tripwire.com. Tripwire busca alteraciones a las configuraciones críticas del registro, tales como la llave “SFCDisable” que controla el WFP. Los programas antivirus, pueden detectar muchos Rootkits modo-usuario cuando se cargan en el sistema, antes de que sean instalados. La mayoría de las soluciones de antivirus tienen firmas para diversos Rootkits modo-usuario en Windows. Así pues, usando un antivirus, será mas difícil para el Atacante Ocasional intentar infectar un sistema con un Rootkit modo-usuario. Desafortunadamente solo desactivando el antivirus, el sistema quedara comprometido a una infección de un rootkit modo-usuario. El atacante tendrá que ser bastante listo para desactivar el antivirus primero, o modificar su base de firmas, antes de instalar el Rootkit. Además, usted se debe tener un CD-ROM o DVD con las herramientas de terceras personas que se puedan utilizar para analizar el sistema. Incluyendo los programas que buscan el uso extraño de puertos, tal como las herramientas de “Sport” disponible en: http://www.foundstone.com/us/resources/proddesc/fport.htm y “TCPView” disponible en: http://download.sysinternals.com/Files/TcpView.zip. 59 El AFX Windows Rootkit es poderoso, pero solamente oculta la información de los componentes de Windows que el conoce. Si se ejecuta una herramienta separada en CD-ROM, será más probable saber que esta sucediendo en el sistema. El CD-ROM bootable basado en Linux “FIRE”, incluye algunas herramientas de Windows. Aunque el CD básicamente sea centrado en Linux, este puñado de herramientas para Windows se pueden utilizar para apoyar el sistema y para conducir un análisis forense en una partición NTFS. 4.4.2.3 Respuesta Después de que se haya desinfectado el sistema, se necesita reinstalar el Sistema operativo desde cero, usar el CD o DVD del sistema operativo original, instalar todos los parches y actualizaciones. Recordemos que no se debe reinstalar el sistema sin parchearlo. Si no se hace, el atacante atacara de nuevo usando la misma vulnerabilidad que uso antes. Después que el sistema entre en producción, se necesita vigilarlo cuidadosamente, usar un sistema IDS basado en red y en host. También, vigilar los logs del sistema muy de cerca, para poder detectar rápidamente si el atacante vuelve. 4.4.3 Conclusión Con las tácticas de Rootkit modo-usuario, los atacantes van más allá de los simples backdoors. Con un Rootkit modo-usuario en su máquina, el sistema operativo estará mas bajo su control. En su lugar, el sistema operativo se convierte en un agente dual, prestándole el servicio al usuario, pero realmente mantiene lealtad al atacante. El atacante requiere un sistema operativo que oculte archivos, procesos en ejecución, y uso de la red. El Rootkit modo-usuario le entrega todo esto a atacante. 60 Sin embargo, esta transformación del sistema operativo por un Rootkit modo-usuario no es completa. Seguro, el atacante puede tener acceso a la máquina y ocultarse en ella usando estas herramientas. Pero, si el administrador de sistema inicia el sistema con un CD-ROM que incluya versiones estáticamente linkeadas de varios comandos y herramientas, el rootkit del atacante será revelado. FIRE y Knoppix son excelentes herramientas que el administrador tendrá que usar en caso de un ataque, estas herramientas detectarán la presencia en el sistema. Esta debilidad del Rootkit modo-usuario limita ciertamente su eficacia. Desafortunadamente, este no es el final de la historia para los Rootkits. Algunos Rootkits van más allá de infectar los archivos, bibliotecas, y procesos en funcionamiento. Estos rootkits fijan su puntería en el funcionamiento más profundo del sistema: en el núcleo en sí mismo. 61 Rootkits del Núcleo Unix - Windows 62 4.5 Rootkits del núcleo En los Rootkits del Núcleo las metas siguen siendo iguales, pero los medios son mucho más sofisticados. Porque apuntan al núcleo, el Rootkit del núcleo mina la máquina de la víctima mas adentro y eficientemente que el Rootkit modo-usuario. 4.5.1 Destruir el núcleo Las computadoras de todas formas y tamaños tienen software instalado en ellos, y la mayoría de las computadoras tienen un sistema operativo. El sistema operativo es un núcleo de software que provee servicios a otros programas en la computadora. Muchos sistemas operativos procesan tareas múltiples, permitiendo que programas múltiples sean operados simultáneamente. Los dispositivos de computación pueden contener sistemas operativos diferentes. Por ejemplo, el sistema operativo más ampliamente usado sobre PCs es el Windows de Microsoft. Un gran número de servidores en Internet operan Linux. Los dispositivos embebidos operan el sistema operativo de VXWorks, y muchos teléfonos celulares usan Symbian. Sin considerar los dispositivos sobre los que es instalado, cada sistema operativo tiene un propósito común: proveer una interfaz sola y consistente que el software de aplicación pueda usar para acceder al dispositivo. Estos servicios de núcleo controlan el acceso para el sistema de archivos del dispositivo, la interfaz de la red, teclado, el ratón, y la visualización de video. Una función secundaria del OS es suministrar la depuración e información de diagnóstico sobre el sistema. Por ejemplo, la mayoría de los sistemas operativos pueden listar las aplicaciones instaladas y cuales se están ejecutando. La mayoría 63 tiene mecanismos de logs para que las aplicaciones puedan informar cuándo han fallado, etc. Aunque es posible escribir aplicaciones que evitan el OS, la mayoría de los desarrolladores no hacen eso. El OS suministra el mecanismo "Oficial" para el acceso, y es mucho más fácil sólo usar el OS. Esto es por qué casi todas aplicaciones usan el OS para estos servicios y es por qué un rootkit que cambia el OS afectará casi todo software. 4.5.1.1 Componentes importantes del núcleo Para comprender cómo los rootkits pueden ser usados para dañar el núcleo del OS, debemos saber qué funciones maneja el núcleo. La tabla 4 describe cada componente funcional del núcleo. Tabla 4. Componentes funcionales del núcleo Los procesos necesitan tiempo de CPU. El núcleo contiene código para asignar este tiempo de CPU. Si el OS soporta Dirección de proceso hilos, el núcleo programará el tiempo a cada hilo. Las estructuras de datos en la memoria guardan el rastro de todos los hilos y procesos. Modificando estas estructuras de datos, un atacante puede esconder un proceso. El sistema de archivos es una de las características más importantes que un OS provee. Las unidades de dispositivo Acceso de archivo pueden ser cargadas para manejar los sistemas de ficheros subyacentes diferentes (como el NTFS). El núcleo provee una interfaz consecuente para estos sistemas de archivos. Modificando la clave en esta parte del núcleo, un atacante 64 puede esconder archivos y directorios. El núcleo es en última instancia responsable de imponer las restricciones entre procesos. Los sistemas simples no pueden imponer seguridad en absoluto. Por ejemplo, muchos dispositivos arraigados permiten que cualquier Seguridad proceso acceda a la extensión llena de la memoria. Sobre UNIX y Sistemas Windows, el núcleo impone los permisos y las extensiones de memoria distintas para cada proceso. Con tan sólo algunos cambios en el código en esta parte del núcleo se pueden quitar todos los mecanismos de seguridad. Algunas plataformas, como la familia de Pentium de Intel, tienen complicados esquemas de dirección de memoria. Una dirección de memoria puede ser mapeado a múltiples locaciones físicas. Por ejemplo, un proceso puede leer la memoria en 0x00401111 de dirección y conseguir el valor el "HELLO" mientras que otro proceso puede leer esa Gestión de la memoria misma memoria en 0x00401111 de dirección pero conseguir el valor "GO AWAY" La misma dirección señala a dos ubicaciones de memoria físicas totalmente diferentes, conteniendo datos diferentes cada una. Esto es posible porque los dos procesos son correlacionados de manera diferente. Explotar la manera en que esto trabaja en el núcleo puede ser muy útil para esconder los datos de depuradores o software forense. 4.5.1.2 ¿Cual es el papel del núcleo en el sistema operativo?. En la mayoría de los sistemas operativos, incluyendo UNIX y Windows, el núcleo es software especial que controla varios elementos extremadamente importantes en el sistema. 65 El núcleo se ubica entre los programas en ejecución y el hardware, por lo tanto el núcleo tiene un papel crítico. Muchos núcleos, incluyendo los encontrados en los sistemas UNIX y Windows, incluyen las siguientes características: Proceso y Control de los hilos: El núcleo dicta qué programas funcionan y cuando funcionan, creando varios procesos y los hilos dentro de esos procesos. Un proceso no es nada más que una memoria asignada a un programa en ejecución, y los hilos son las ejecuciones individuales de un proceso. El núcleo orquestra varios procesos y sus hilos de modo que múltiples programas puedan funcionar simultáneamente y transparentemente en la misma máquina. Control de comunicación entre procesos: Cuando un proceso necesita enviar datos a otro proceso o al núcleo mismo, puede utilizar varias c aracterísticas de comunicación entre procesos del núcleo para enviar señales y datos. Control de la memoria: El núcleo asigna memoria a los programas en ejecución, y libera esa memoria cuando no es requerida. Este control de la memoria es implementada en la administración de la memoria virtual del núcleo. Control de Hardware Variado: El núcleo controla la interface entre varios elementos de hardware, como el teclado, Mouse, audio y sonido. 4.5.1.3 Impacto de Manipulación del Núcleo ¿Qué sucede si un atacante comienza a manipular el núcleo en sí mismo? Porque en el núcleo está el control, modificando el núcleo, el atacante puede cambiar el sistema de una manera fundamental. Para aplicar cambios al núcleo, el atacante requiere privilegios de root en UNIX y acceso como administrador o del sistema en Windows. 66 Una vez que esté instalado, un Rootkit del núcleo substituye o modifica los componentes del núcleo. Estas alteraciones pueden hacer que todo el sistema aparentemente funcione bien, pero el sistema operativo esta realmente afectado desde lo mas profundo. El atacante puede cambiar el núcleo de modo que este mienta sobre el estado de la máquina. Por ejemplo, el administrador puede ejecutar un comando que mira si algunos procesos backdoor están funcionando. Este comando llama el núcleo para conseguir una lista de procesos en ejecución. Sin embargo, como el atacante cambió el núcleo de modo que este mienta, el comando no mostrara el proceso backdoor del atacante, según lo ilustrado en la figura 6. Alternativamente, un administrador puede ejecutar una herramienta de comprobación de integridad de archivos, para ver si algunos archivos críticos en la máquina se han cambiado. El núcleo miente y le dice a administrador que no se han alterado ningún archivo; Figura 6. Manipulación del núcleo para ocultar procesos. 67 Usando la manipulación del núcleo, los atacantes pueden alterar el núcleo, de modo que oculte a fondo las actividades del atacante. La mayoría de Rootkits del núcleo incluyen las siguientes características: Ocultación de archivos y directorios. Ocultan la mayoría de los archivos y directorios de los usuarios y administradores de sistema. Cuando se oculta un archivo, el núcleo mentirá a cualquier programa que venga buscando el archivo. Ocultación de procesos. Ocultando un proceso, el atacante puede crear un backdoor invisible que no se pueda descubrir usando las herramientas de análisis de procesos. Ocultación de puertos en la red. Escondiendo los puertos TCP y UDP que se encuentran escuchando, los programas locales no pueden notarlos, así el backdoor es incluso más invisible. Ocultación del modo promiscuo. El atacante no quiere que un administrador detecte un sniffer funcionando en el sistema, así que el núcleo miente sobre el estado promiscuo de la interfaz de red. Redirección en la ejecución. Con esta característica, cuando un usuario o un administrador ejecutan un programa, el núcleo finge hacer funcionar el programa solicitado. Sin embargo, el núcleo realmente lo substituye por un programa diferente. Los usuarios y el administrador del sistema piensan que está funcionando un programa legitimo, pero están ejecutando otro programa elegido por el atacante. 68 Por ejemplo, en vez de confiar en las técnicas de Rootkit modo-usuario para substituir el programa “sshd”, se utiliza un Rootkit del núcleo para redirigir la ejecución del sshd a otra versión con un backdoor. El administrador puede comprobar la integridad del archivo sshd y el archivo parecerá totalmente intacto, porque realmente esta intacto. Cuando un usuario o un administrador intentan ejecutar el comando sshd para acceder remotamente, la versión backdoor será ejecutada, dando al atacante el acceso remoto a la máquina víctima. Interceptación de dispositivos y control. Con un Rootkit del núcleo, un atacante puede interceptar o manipular los datos enviados a o desde cualquier dispositivo de hardware en la máquina. Por ejemplo, un atacante podría modificar el núcleo para registrar en un archivo local cualquier golpe de teclado en el sistema, Otro ejemplo el atacante puede alterar el núcleo para que el núcleo le deje espiar las sesiones de terminal de los usuarios (TTY). Con un Rootkit del núcleo, las modificaciones del atacante convierten el sistema de tal modo que los administradores y los usuarios estén en una prisión. 69 4.5.2 Rootkits del Núcleo en Unix Analizaremos cómo los atacantes manipulan el núcleo para alcanzar sus metas. Tengamos presente que la meta de cada una de las técnicas de manipulación del núcleo, es el mismo objetivo de todo Rootkit: proporcionar el acceso backdoor, mientras oculta la presencia del atacante en el sistema. Con esa meta en mente, hay por lo menos hoy en día tres métodos diversos para poner un Rootkit del núcleo en Unix. Analicemos cada método detalladamente: Métodos para manipular el núcleo de Unix. 4.5.2.1 Método 1: Módulos malignos cargables al núcleo. Un método primario para invadir el núcleo de Unix es crear un módulo maligno cargable al núcleo para manipular el núcleo existente. Recordemos que los módulos cargables al núcleo son una característica legítima del núcleo de Unix, usada a veces para agregar soporte a nuevo hardware o insertar código en el núcleo para dar soporte a nuevas características. Los módulos cargables al núcleo pueden aumentar o aún substituir las características existentes del núcleo, todas sin un reinicio del sistema. Debido a la conveniencia de esta característica para inyectar código nuevo en el núcleo, es uno de los métodos más fáciles para poner el Rootkit en ejecución en Unix y sus derivados. 70 Para lanzar esta clase de ataque, el atacante utiliza un módulo cargable del núcleo que incluye dos componentes, identificados como A y B en la figura 7. El atacante inserta este módulo en el núcleo, usando el comando “insmod”. Figura 7. Los Rootkits de módulos cargables al núcleo alteran las llamadas a la tablas del sistema, para ejecutar el modulo con el código maligno del atacante, en vez de la llamada legítima del sistema. Una vez que esté insertado el módulo maligno, mostrado como el elemento A en la figura 7, incluye el código que funciona casi igual al código original de la llamada al sistema dentro del núcleo. 71 En nuestro ejemplo, el atacante ha creado un módulo cargable del núcleo que implementa la llamada del sistema “SYS_execve” usada para ejecutar programas, este modulo tiene un pequeño truco. Cuando se invoca a la nueva y maligna llamada del sistema de SYS_execve, esta comprobará qué programa ha pedido ejecutarse. Si la petición de ejecución es para un programa que el atacante configuró redireccionar, el módulo maligno del núcleo ejecutará un programa diferente en lugar del legítimo. Si la petición de ejecución es para un programa que el atacante no este interesado en redireccionar, el programa legítimo será ejecutado. La nueva llamada del sistema SYS_execve incluye inteligencia para decidir qué programa se ejecuta legítimamente y cual redireccionar. Ese es el truco. Todo esto parece fácil, pero en primer lugar ¿cómo el SYS_execve maligno consigue ejecutarse? Aquí es adonde el elemento B de la figura 7 entra en el juego. El módulo maligno cargable del núcleo alterará la tabla de llamada del sistema, de modo que en ninguno de sus puntos el SYS_execve normal llama al núcleo. En vez de eso, la entrada en la tabla de llamada del sistema asociada a SYS_execve señalará al código del atacante. La llamada legítima del sistema de SYS_execve seguirá inutilizada en el sistema. Con este método, el atacante está jugando con un especie de interruptor del sistema, redirigiendo la ejecución de programas o ejecutando los legítimos. 4.5.2.1.1 Ejemplo de Módulos malignos cargables al núcleo: Adore “Adore” es el Rootkit del núcleo para Unix más popular y de uso mas extenso hoy en día. Permite que el atacante se oculte en el sistema, remapeando y envolviendo 72 varias llamadas del sistema con un solo módulo cargable del núcleo. Una vez Instalado en una víctima, adore deja al atacante hacer el siguiente: - Esconder o mostrar archivos. Hacer un proceso visible o invisible. Hacer la identificación de un proceso invisible permanentemente, de modo que incluso adore no pueda hacerla visible otra vez. Ejecutar cualquier programa como root, sin importar los permisos reales del usuario que invoca el programa. Ocultar el modo promiscuo de la interfaz de usuario para disfrazar un sniffer. Ocultar el módulo cargable de si mismo “adore”. Para lograr estas tareas, adore consiste en dos componentes: un módulo cargable del núcleo (llamado adore) y un programa (llamado “Ava”). que el atacante utiliza para interactuar con el módulo del núcleo. Ava es la interfaz de usuario para adore. Después de instalar el módulo de adore usando el comando “insmod”, el atacante debe configurarlo ejecutando Ava en el mismo sistema donde el módulo reside. Ava no trabaja a través de una red; debe ser utilizado para configurar adore en un sistema local. Ava presenta una interfaz simple, mostrada en la figura 8. 73 Figura 8. Ava, La interfaz de usuario de Adore. Para el acceso remoto a la máquina víctima, adore también incluye un backdoor configurable en un puerto por el atacante. El atacante puede utilizar Netcat en modo cliente para conectarse con el backdoor que esta escuchando a través de la red y conseguir el acceso directo al shell de comando de la máquina. El proceso del shell de comando, por supuesto, también es ocultado por el módulo del núcleo. Adore también oculta los puertos TCP y UDP configurados por el atacante. De tal manera, los procesos de red creados por el atacante que están escuchando serán disfrazados. Aunque adore tiene muchas características, tiene un defecto significativo. La herramienta no incluye capacidades de redirección en la ejecución de procesos; su foco está solamente en ocultar archivos, procesos, los puertos TCP y UDP, y modo promiscuo. 74 4.5.2.2 Método 2: Atacando el “/dev/kmem”. Supongamos que la máquina objetivo fue construida sin soporte de módulos del núcleo. Al compilar un núcleo personalizado para una máquina Unix, un administrador puede elegir si agregar el soporte a módulos cargables del núcleo o los omite del núcleo resultante. Sin este soporte, este núcleo no se puede infectar con los módulos malignos cargables del núcleo. ¿Si se construye un núcleo que carezca de soporte del módulo, estemos seguros de los Rootkits del núcleo? La respuesta es No. Los varios desarrolladores de Rootkits del núcleo han encontrado la manera de infectar la maquina sin usar ningún módulo cargable del núcleo. Para lograr esto, utilizan el archivo “/dev/kmem”, este archivo tiene una imagen del espacio de la memoria que maneja el núcleo, allí es donde el código del núcleo se encuentra. Parcheando cuidadosamente el núcleo en memoria a través de /dev/kmem, un atacante puede poner en ejecución el ataque, pero sin usar ningún módulo. Los desarrolladores de esta técnica lanzaron un código que a través de /dev/kmem, busca la tabla de llamada del sistema. Cuando encuentra la tabla de llamada del sistema, el software busca en la tabla varias entradas de llamadas del sistema, asociadas a “SYS_open”, “SYS_read”, y “SYS_execve”. El código incluye una variedad de funciones, pero las de mayor interés son “rkm” (abreviatura en ingles de “Memoria leída del núcleo”) y la “wkm” (abreviatura en ingles “Memoria escrita del núcleo”). Usando rkm, el atacante puede leer varios ítems útiles dentro del espacio de memoria del núcleo. Con el wkm, el atacante puede insertar código directamente en el espacio de memoria del núcleo. 75 Además, el atacante puede modificar o aún substituir la tabla de llamadas del sistema dentro del núcleo, de modo que señale al código del atacante y no al código legítimo del núcleo. Con estas capacidades, mostradas en la figura 9, el atacante tiene control completo sobre el sistema y puede implementar o esconder archivos, procesos, puertos en la red, y modo promiscuo. Y al final también el atacante puede modificar el núcleo de modo que realice la redirección de procesos en ejecución. Figura 9. Alterando un núcleo en ejecución leyendo y escribiendo en /dev/kmem. Estos cambios a un núcleo en ejecución con /dev/kmem no sobreviven a través de un reinicio del sistema. Por lo tanto, los atacantes modifican el “init” u otro programa para modificar el inicio, al hacer esto la alteración del /dev/kmem es aplicada al núcleo mientras el sistema está iniciando. 76 4.5.2.3 Método 3: Parcheando la imagen del Núcleo en el Disco Duro. Con permisos de root en el sistema, el atacante podría substituir o parchear el archivo de una imagen del núcleo en el disco duro. De esta manera, en el siguiente reinicio del sistema, el núcleo maligno será cargado en el sistema en vez del núcleo legítimo, según lo ilustrado en la figura 10. Figura 10. Reemplazando la imagen del núcleo en el disco duro. En el sistema de archivos de Linux, la imagen del núcleo se almacena en un archivo llamado “vmlinuz”, establecido típicamente en el directorio /boot. Durante el inicio del sistema, la primera porción de vmlinuz se carga en la memoria y es ejecutada. Esta primera porción de vmlinuz después descomprime el resto del archivo vmlinuz y carga la imagen entera del núcleo en la memoria. Para substituir un núcleo original por una versión maligna, el atacante debe crear la imagen maligna del núcleo, comprimirla, y sobrescribir el archivo existente /boot /vmlinuz. Modificando el código de fuente del núcleo para crear un núcleo maligno, el atacante puede ocultar archivos con ciertos nombres, enmascarar puertos específicos de TCP y UDP, redirigir procesos. 77 El atacante podría incluso programar el nuevo núcleo maligno de modo que parezca el núcleo original. Por ejemplo, el núcleo maligno se puede configurar de modo que si cualquier persona abre el archivo alterado /boot/vmlinuz, el núcleo vuelve al archivo original, sin modificar de la imagen del núcleo. De esta manera, el atacante puede evadir cualquier herramienta de comprobación de integridad de archivos. Hay algunos problemas para al atacante que utiliza el reemplazo del núcleo, Por ejemplo si la máquina de la víctima tiene opciones muy específicas del núcleo, como compilación especial para hardware que el atacante no conoce. Si el atacante crea un núcleo maligno y lo intercambia en lugar del núcleo legitimo, el administrador puede notar rápidamente el ataque porque quizás el hardware deje de funcionar adecuadamente. Para evitar esta situación, el atacante puede modificar el archivo existente del vmlinuz en vez de substituirlo. Aplicando parches al archivo de la imagen del núcleo en el disco duro en vez de substituirla enteramente, la mayoría de la funcionalidad existente del núcleo será preservada., según lo representado en la figura 11. Figura 11. Aplicando parches directamente en la imagen del núcleo del disco duro. 78 4.5.3 Defendiendo el núcleo de Unix Como hemos visto, hay una variedad de posibilidades de atacar el núcleo de Unix, ¿Cómo podemos defendernos contra tales ataques? , las defensas se dividen en tres diversas categorías: Prevención, detección, y respuesta. 4.5.3.1 Prevención de Rootkits del núcleo en Unix Justo como los Rootkits modo-usuario que discutimos anteriormente, todos los ataques de manipulación al núcleo requieren antes de instalar cualquier código, que el atacante tenga permisos de root en la máquina víctima. Por lo tanto, debemos parar a los atacantes del núcleo evitando que consigan privilegios de root en sus máquinas. Inhabilitar los servicios innecesarios y cerciorarse de aplicar los parches y actualizaciones al sistema. Las versiones mas antiguas de Unix son particularmente susceptibles a los ataques del núcleo, y tienen vulnerabilidades que un atacante podría explotar. Además, tenemos que educar a los usuarios sobre la necesidad de asegurar sus sistemas y no ejecutar código o archivos que no sean de confianza. Con los Rootkits en el ambiente, es más importante ahora que nunca endurecer la seguridad al configurar y usar los sistemas. Además de configurar el sistema con seguridad y parchearlos, consideraremos la posibilidad de configurar el núcleo de Unix para que no soporte módulos cargables del núcleo en sus sistemas más críticos, tales como: Sistemas públicos accesibles vía Web, E-mail, DNS, y Firewall. Probablemente no se necesite soporte de módulo del núcleo en tales máquinas. 79 Podremos usar el script constructor de núcleo de Bill Stearns, con esta herramienta se puede crear fácilmente un núcleo de Unix que tenga toda la funcionalidad, sin los módulos de soporte del núcleo. Por supuesto, como vimos anteriormente, los atacantes podrían ir al /dev/kmem y envenenar el núcleo incluso si el soporte del módulo no está disponible. No obstante, apenas consiguiendo quitar los módulos cargables del núcleo, se levanta la barrera contra los atacantes. Después de endurecer la máquina y quitar el soporte de módulo del núcleo, podemos utilizar herramientas para limitar el acceso de los atacantes al sistema. Una herramienta excelente es “Systrace”, disponible en www.citi.umich.edu/u/provos/systrace/, esta herramienta controla las llamadas del sistema y las monitoriza. Por ejemplo, podemos poner en funcionamiento un servidor Web en una máquina de pruebas y registrar toda su actividad de llamadas del sistema. Con esto tendremos un paquete conocido de llamadas del sistema requeridas por el servidor Web. Conociendo esto, podemos utilizar “Systrace” para limitar a la maquina para que no pueda hacer ningún otro llamado del sistema que no este registrado. Si Systrace observa un intento de hacer funcionar otras llamadas del sistema, mostrara una alerta y detendrá la llamada. Además de Systrace, también podríamos utilizar otra herramienta llamada LSM, descrita detalladamente en http://lsm.immunix.org. Es importante observar que LSM no detiene los módulos malignos del núcleo directamente. En su lugar, la tecnología de LSM hace el sistema mas seguro, cerrando varios caminos generalmente usados por los atacantes. Negándoles el acceso del root, LSM mejora la seguridad de modo que los atacantes no puedan modificar el núcleo o comprometer de otra manera la máquina. 80 4.5.3.2 Detección de Rootkit del núcleo en Unix. Incluso con las mejores defensas, un atacante todavía puede encontrar un agujero en la armadura del sistema e instalar un Rootkit del núcleo. Una vez que un Rootkit del núcleo esté instalado, no podremos confiar en ningún resultado de nuestro sistema. Aunque la detección puede ser un desafío importante, tenemos numerosos mecanismos a nuestra disposición para descubrir rastros del Rootkits del núcleo en el sistema. Primero, tenemos que buscar actividad sospechosa en la red de la maquina. Aunque la actividad local se oculta del administrador del sistema, un IDS basado en red, puede observar paquetes malignos viniendo de una máquina infectada con un Rootkit del núcleo mientras el atacante intenta asumir el control de otras maquinas a través de la red. Además, si el atacante inserta un backdoor escuchando en un puerto TCP o UDP, un explorador de puertos tal como Nmap, (disponible en www.insecure.org) puede detectar remotamente los puertos que están escuchando. También, prestar atención a los reinicios inesperados del sistema. Aunque el módulo cargable del núcleo y las alteraciones a /dev/kmem no requieran un reinicio, el método de Parchear la imagen del Núcleo en el Disco Duro si requiere reanudar el sistema. Aunque un reinicio inesperado NO es garantía que un atacante ha asumido el control de la maquina, es una indicación que algo pudo ser estar fuera de lo normal. Entonces debemos hacer una mirada más profunda, y usar las herramientas de respuesta que discutiremos en esta sección. Por ultimo, también debemos utilizar las herramientas que controlan la integridad de archivos, tales como “Tripwire”, y “AIDE”. Aunque, un buen atacante configurará el núcleo maligno con redirección de ejecución, y otras alteraciones que mienten al comprobador de la integridad de archivos sobre todos los archivos cambiados en el sistema. 81 Si el atacante cubre muy bien todas sus huellas, el puede engañar a una Herramienta de comprobación de integridad de archivos. Sin embargo, un atacante menos cuidadoso pudo olvidar configurar el Rootkit del núcleo para ocultar alteraciones a uno o dos archivos críticos del sistema. Incluso un solo error en la configuración de ocultación de un Rootkit del núcleo podría exponer a la detección por parte de una Herramienta de comprobación de integridad de archivos. Por lo tanto, la Herramienta de comprobación de integridad de archivos sigue siendo muy valiosa. Otra herramienta que discutimos anteriormente y puede ser útil en la detección de estos ataques del núcleo, es “chkrootkit”. Chkrootkit Busca las anomalías del sistema introducidas por el Rootkit y es capaz de detectar varios Rootkits del núcleo, entre ellos el famoso “Adore” que ya comentamos anteriormente, Para tener una idea de cómo trabaja, el chkrootkit busca inconsistencias en la maquina, lo que puede ser una indicación que algo malo está pasando. Los scripts incluidos en el chkrootkit realizan las pruebas que se pueden utilizar para capturar al núcleo mintiendo sobre la existencia de ciertos archivos, directorios y el modo promiscuo de la interfaz de red. Una de las maneras en el que chkrootkit encuentra Rootkits, es buscando inconsistencias en la estructura de archivos cuando se oculta un fichero o un directorio. Cada directorio en el sistema de archivos tiene un “Contador de Links”, que indica el número de directorios y ficheros que están conectados con la estructura del sistema de archivos. Para cada directorio, este Contador de Links debe ser dos más que el número de archivos en el directorio. De esta manera, el directorio tendría una conexión para cada archivo, más uno para el directorio padre (..) y uno para sí mismo (.) Muchos Rootkits del núcleo, por ejemplo “Adore”, esconden archivos y directorios sin manipular el Contador de Links del directorio padre. Chkrootkit se pasea a 82 través de la estructura de directorios entera, contando el número de archivos y directorios que puede ver dentro de cada directorio y compararlo con el contador de links. Si encuentra alguna discrepancia, el chkrootkit imprime un mensaje indicando que puede haber directorios que son ocultados por un Rootkit del núcleo. Más allá de las herramientas comprobadoras de integridad de archivos y el chkrootkit, también se encuentran herramientas que se especializan en la detección de comportamiento más a menudo asociado con Rootkits de núcleo, tales como los que alteran la tabla de llamadas del sistema o los módulos cargables. Particularmente, una herramienta llamada “KSTAT” disponible en www.s0ftpj.org/en/tools.html. Esta herramienta encuentra y desinstala Rootkits del núcleo. Para la detección, KSTAT busca cambios a la tabla de llamadas del sistema. Incluso explorará el /dev/kmem para buscar las posiciones de memoria asociadas a todas las llamadas del sistema, y compara estos resultados con la información en el fichero de System.map. Si encuentra una discrepancia, KSTAT advierte al administrador de sistema que alguien ha alterado la tabla de llamadas del sistema. Mientras que los atacantes miran el /dev/kmem para romper nuestros sistemas, nosotros podemos utilizar KSTAT para mirar el /dev/kmem y encontrar sus ataques. KSTAT también crea una lista de huellas digitales para las llamadas del sistema usadas por varios programas críticos, tales como un servicio Web o el servidor de correo. Eventualmente si estas llamadas del sistema se alteran, o llamadas del sistema adicionales son invocadas por estos programas, KSTAT puede advertir al administrador que esta ocurriendo algo fuera de lo común. Otra herramienta se llama “Syscall Sentry”, la cual es un módulo cargable del núcleo que se inserta durante el inicio del sistema. Si un atacante inserta un 83 módulo que altere la tabla de llamada del sistema, el módulo “Syscall Sentry” detecta la alteración, registra el acontecimiento, y alerta al administrador de sistema sobre esta actividad anómala. 4.5.3.3 Respuesta ante un Rootkit del núcleo en Unix Ahora, suponiendo que con estos mecanismos de detección muestren que un atacante ha instalado un Rootkit del núcleo en la máquina. Para investigar y determinar qué está sucediendo realmente en el sistema, no se puede confiar en cualquier cosa que sale del núcleo. Cualquier herramienta de análisis que se ejecute en el sistema puede ser engañada por el núcleo maligno, y por lo tanto este análisis no puede ser confiable. Recordemos que se debe utilizar un CD-ROM bootable que incluya un sistema operativo Linux, recomendamos las distribuciones “Knoppix” y “FIRE”, las cuales incluyen configuraciones y herramientas para usos específicos de las investigaciones forenses. Un investigador puede insertar FIRE o Knoppix en una máquina potencialmente comprometida, e iniciar el sistema operativo LIVE CD. Cuando el sistema se apaga, el núcleo maligno también se detendrá. Cuando el sistema reinicie, el núcleo de FIRE o Knoppix será cargado en la memoria. Como este núcleo esta en el CD-ROM, el investigador puede utilizarlo para leer el sistema de archivos de la máquina víctima, con resultados más dignos de confianza. Por lo tanto cuando el sistema operativo que se encuentra en el CDROM inicia, el investigador debe ejecutar una Herramienta de comprobación de integridad de archivos (incorporada en el CD-ROM, por supuesto) para buscar cambios a los archivos críticos en el disco duro. 84 4.5.4 El núcleo de Windows Dado su extensa popularidad en el escritorio y los servidores, el sistema operativo Windows y su núcleo subyacente son un blanco perfecto para todos los atacantes del mundo. En esta sección, comenzaremos discutiendo cuál es el núcleo de Windows y como funciona. Después de eso, veremos cómo los atacantes pueden invadir y manipular el núcleo de Windows. Para esta discusión, nos centraremos en el núcleo de Windows NT,2000,XP y 2003, ya que son núcleos absolutamente similares, incluyendo diferencias de menor importancia debido a la evolución del núcleo en un cierto plazo. Los núcleos de Win9x se diferencian radicalmente, y no serán nuestro objeto de estudio. 4.5.4.1 Aventuras en el núcleo de Windows El núcleo de Windows incluye numerosos componentes para interactuar con los procesos de modo-usuario. La configuración total del núcleo de Windows se muestra en la figura 12. 85 Figura 12. Una descripción del núcleo de Windows y su relación con los componentes vitales modo-usuario. Para tener una idea de cómo todas estas capas funcionan, comencemos por arriba: procesos de modo-usuario, los programas que funcionan sobre una base cotidiana, tal como el procesador de textos, un juego, o aún un servidor de correo. Para obrar recíprocamente con el sistema operativo, un proceso modo-usuario hace llamadas de función a varias DLLs. Cuando los desarrolladores crean programas para ejecutarse en Windows, estas llamadas de función son el interfaz crucial en Windows en sí mismo, implementando el API dentro del sistema operativo Windows. Estas DLLs incluyen todo tipos de capacidades, tales como visualizar la información sobre la pantalla, abrir archivos, o funcionar con otros programas. Para animar el desarrollo de las aplicaciones para Windows, Microsoft ha proporcionado mucha documentación sobre las llamadas de función disponibles en el subsistema de las DLLs. Los Win32 DLLs se agrupan en varios diversos archivos, cada uno con su propio código para lograr ciertas tareas, incluyendo User32.dll, Gdi32.dll, Advapi32.dll, y Kernel32.dll. 86 Para aclarar, el archivo nombrado Kernel32.dll no es el núcleo. En su lugar, junto con User32.dll, Gdi32.dll, y Advapi32.dll, se ejecuta en modo-usuario y proporciona a una API varias aplicaciones de modo-usuario para los archivos la lectura, los archivos de escritura, y realizar otras acciones. Se llama Kernel32.dll porque proporciona una API para que los programas modo-usuario envíen peticiones al núcleo, pero estas peticiones no van directo al núcleo. En su lugar, deben pasar con Ntdll.dll primero. Así, la mayoría de los procesos modo-usuario hacen llamadas de función directamente a las DLLs. Cada llamada de función dentro de Win32 puede, alternadamente, hacer una de tres cosas. Primero, como mostramos en el elemento A de la figura 13, para las peticiones relativamente simples que no requieren la interacción del a nivel del núcleo con el hardware u otros procesos, la función Win32 podría apenas manejar la petición y enviar una respuesta. Una función de ejemplo de este tipo es la función de “GetCurrentProcessId”, que deja a un proceso conseguir su propio número de identificador de proceso. No se requiere ninguna llamada más profunda. 87 Figura 13. Tres maneras que las DLLs hacen peticiones a los procesos modo-usuario. La segunda posibilidad de manejar una llamada de función de una aplicación modo-usuario, implica que el DLL necesita la información de un proceso modousuario muy especial que sea responsable de guardar el funcionamiento del subsistema Win32. Este tipo de interacción se ilustra como elemento B la figura 13. El proceso de Csrss.exe, que es una abreviatura en ingles para “Client/Server Run-Time Subsystem”, mantiene el subsistema Win32 en funcionamiento invocando procesos del usuario y manteniendo el estado asociado a cada proceso. Un proceso modo-usuario puede pedir a Csrss.exe la información acerca de sí mismo u otros procesos sin llamar al núcleo. La tercera posibilidad de una llamada de función Win32 es la más interesante para nuestros propósitos, y se muestra como elemento C en la figura 13. La aplicación modo-usuario podría pedirle a un DLL Win32 que tome ciertas medidas que requieren la invocación de una función del núcleo. Por ejemplo, el proceso modo- 88 usuario podría llamar las llamadas de función “ReadFile” o “WriteFile” en un DLL Win32. El DLL bien documentado que los desarrolladores utilizan asociará las llamadas de la función de ReadFile y de WriteFile en otro código, llamado Ntdll.dll, que es un API interno y relativamente indocumentado. El propósito de Ntdll.dll es tomar las altamente documentadas llamadas de función de Win32 API (como ReadFile y WriteFile), y las convierte en las llamadas de función entendidas por el núcleo (llamadas NtReadFile y NtWriteFile, respectivamente). Una vez que el código Ntdll.dll asocia las llamadas de función, necesitamos hacer una transición de modo-usuario al modo del núcleo, Usando un mecanismo, el código Ntdll.dll invoca las funciones de nivel del núcleo llamadas “The Executive”. “The Executive”, nombrado así por sus altas y poderosas capacidades, sirve para numerosos propósitos, incluyendo poner la llamadas de función del núcleo a disposición del modo-usuario. “The Executive” se ejecuta dentro de un archivo crítico llamado “Ntoskrnl.exe”. Cuando se invoca The Executive, determina qué pedazo de código subyacente del núcleo es necesario para manejar la petición, tal como lectura o escritura de un archivo. Después de determinar qué pedazo de código del núcleo se requiere para manejar la petición, The Executive ejecuta la transición a otro componente de Ntoskrnl.exe. Este pedazo inferior de Ntoskrnl.exe se llama el núcleo, aunque The Executive en sí mismo se ejecuta en modo del núcleo y el Ntoskrnl.exe también. El código en el núcleo ahora necesita interactuar con el hardware. En nuestro ejemplo de ReadFile y WriteFile, el núcleo necesita interactuar con el disco duro. Para lograr esta tarea, el núcleo confía en otro nivel de código, llamado “Capa de abstracción de hardware” (HAL). Ejecutado en un archivo llamado HAL.dll, el 89 propósito de este componente es hacer que los diversos productos de hardware de terceras personas sean consistentes para el núcleo. Enviando mensajes a HAL, el núcleo puede leer en o escribir al archivo. Así, hemos atravesado las capas del sistema operativo Windows: Primero: Un programa de usuario puede hacer llamadas de función a una DLL Win32, llamada Ntdll.dll, que invoca The Executive. Segundo: The Executive llama el núcleo, que pide a la HAL que haga algo, esta interactúa con el hardware. Hay un componente crucial en este proceso en el cual necesitamos enfocarnos: la transición de modo-usuario al modo del núcleo, ¿Cómo Ntdll.dll hace llamadas al núcleo, invocando The Executive? En cierto modo, estamos haciendo el equivalente de hacer una llamada del sistema en Unix. Sin embargo, la documentación de Windows se refiere a este concepto como “system service dispatching” (Envió de servicio del sistema). 4.5.4.2 Métodos para manipular el núcleo de Windows El núcleo de Windows y sus APIs asociadas componen un sistema complejo, pero funcionan apropiadamente para millones de usuarios alrededor del mundo. Como nos imaginaremos los atacantes ven a Windows como el objetivo principal para sus ataques. Varios proyectos de Rootkit del núcleo están en servicio en Internet, pero el sitio más rico en información y más prolífico dedicado a Rootkits de Windows es el Website de www.rootkit.com, el cual es el sitio para los desarrolladores de Rootkits de Windows para compartir código e ideas para mejorar sus creaciones. 90 Los tres diversos métodos de manipulación del núcleo del Unix que discutimos anteriormente, tienen analogías directas en el mundo del núcleo de Windows. Los atacantes podrían emplear drivers malignos de dispositivos, alterar un núcleo en ejecución en memoria, sobreescribir la imagen del núcleo en el disco duro, desplegar un núcleo en un sistema virtual para engañar a los usuarios, e intentar hacer funcionar código modo-usuario en el nivel del núcleo. Ahora, cada uno de estos cinco elementos en las máquinas Windows es una posible avenida para el ataque, pero los primeros dos (empleando los drivers malignos de dispositivos y alterando un núcleo en ejecución en memoria) son en gran medida los más utilizados. Las otras opciones son los vectores posibles de ataque, que podrían llegar a ser más populares en el futuro. Miremos cada uno de estos tipos de ataque más detalladamente. 4.5.4.3 Drivers Malignos de dispositivos La primera y más popular técnica para manipular el núcleo de Windows es insertar un driver maligno de dispositivo en el sistema, el cual parchea el núcleo para alterar el manejo de llamada de servicio del sistema. Como los atacantes que explotan los módulos del núcleo de UNIX, para cargar el malware dentro del núcleo de UNIX, utilizan trucos muy similares en Windows. Cargando un driver de dispositivo especializado, este altera las llamadas de servicio específicas de sistema asociadas a procesos en ejecución, mostrando archivos, directorios e identificando el uso de puertos TCP y UDP, un atacante puede alterar con eficacia el núcleo para ocultar un backdoor en la máquina, según lo ilustrado en la figura 14. 91 Figura 14. Usar un driver de dispositivo para manipular el núcleo de Windows. Así, un atacante puede inyectar un driver maligno de dispositivo en el núcleo para alterar funciones existentes y ocultar procesos backdoors. Windows utiliza firmas digitales en los drivers de dispositivo, de modo que un administrador pueda verificar la integridad de todos los drivers mientras están instalándose en la máquina. Sin embargo, con privilegios del administrador en la máquina receptora, un atacante puede instalar fácilmente un driver de dispositivo incluso sin una firma apropiada. El sistema advertirá al atacante que el driver de dispositivo no esta firmado por una fuente de confianza, pero el atacante puede aceptar fácilmente la alerta y aplicar el driver maligno al sistema. 92 Sin embargo, una vez que el driver maligno de dispositivo se inserta en el núcleo, cómo el atacante engaña al núcleo para que este haga funcionar el código del atacante, en vez del código legitimo del núcleo de Windows para las llamadas de servicio del sistema?. Dada la complejidad del núcleo de Windows, una variedad enorme de opciones está disponible, de las cuales tres se ilustran como elementos A, B, y C del cuadro 8.34. Cada uno de estos elementos es realmente una forma de enganchar a la API, pero esta vez dentro del núcleo de Windows en sí mismo. En el elemento A, el atacante utiliza un driver maligno de dispositivo para sobreescribir simplemente funcionalidad existente del núcleo, substituyendo el código dentro del núcleo por el nuevo código, que ocultará las acciones del atacante cambiando la funcionalidad del servicio que maneja el sistema. En el elemento B, el atacante utiliza un driver de dispositivo que implementa varias funciones de núcleo, entonces altera la tabla del “system service dispatcher” (envío de servicio del sistema) de modo que señale al código del atacante en vez de las funciones existentes del núcleo. Finalmente en el elemento C, un atacante podría emplear una técnica llamada “interrupt hooking” (enganche de interrupción) para modificar como el núcleo maneja las interrupciones de la CPU. Cambiando la tabla asociada con el manejo de la interrupción en el núcleo, el atacante podría redireccionar las llamadas al “system service dispatcher” (envío de servicio del sistema) al propio código del atacante, en vez de las funciones incorporadas del núcleo. Usando la “interrupt hooking” (enganche de interrupción), el atacante podría interceptar todas las llamadas al “system service dispatcher” (envío de servicio del sistema), y escoger que funciones dirigir al núcleo normal, y cuales dirigir al código maligno del atacante. 93 4.5.4.3.1 Ejemplo de un Rootkit del Núcleo para Windows Slanret/Krei. Un ejemplo de un popular Rootkit del núcleo para Windows es “Slanret/Krei” el cual mezcla los elementos A y B del cuadro 8.34, Slanret/Krei consiste realmente en dos pedazos: el driver de dispositivo de “Slanret” y una herramienta backdoor de acceso remoto llamada “Krei”. Con privilegios de administrador, un atacante primero carga el driver de dispositivo de Slanret en la máquina víctima. Slanret modifica el núcleo, de modo que este miente sobre los procesos ocultos del atacante, los archivos, las llaves del registro, y los puertos TCP y UDP para cualquier aplicación modo-usuario que pregunte acerca de ellos. Ahora ¿Qué oculta Slanret particularmente? Oculta Krei, por supuesto. Después de instalar el driver de dispositivo, el atacante carga el backdoor de Krei, una aplicación modo-usuario de 27 kilobytes que escucha en el puerto 449 del TCP y concede al atacante el backdoor remoto a máquina víctima. Por supuesto, Slanret y Krei trabajan mano a mano, Slanret esconde todas las acciones de Krei. 4.5.4.4 Alteración de un núcleo en ejecución en memoria. En vez de usar un driver de dispositivo, un atacante podría parchear directamente el núcleo en la memoria de la máquina víctima, Para entender esta técnica, necesitamos mirar cómo la memoria se maneja en Windows, específicamente con respecto a la CPU. En una de Windows, el “Global Descriptor Table” (GDT) contiene la información sobre cómo la memoria es dividida en varios segmentos, dividida en los programas de usuario y al núcleo. Todas las posiciones de memoria entre 94 0x80000000 y 0xC0000000 son reservadas para uso del núcleo, y bajo condiciones normales, no pueden ser tocadas por procesos de usuario. El GDT almacena los datos sobre cómo se dividen los varios segmentos de memoria, y el tiempo de CPU que se requiere para que un programa toque cada parte de la memoria. Los segmentos definidos por el GDT pueden solaparse uno con otro. Es decir, el mismo rango de direccionamiento de memoria puede simultáneamente estar en segmentos múltiples en el GDT. El valor por defecto del GDT dice que las posiciones de acceso a la memoria entre 0x80000000 y 0xC0000000, necesitan ejecutarse en el anillo 0 del CPU. Ése es territorio del núcleo. Aquí está el detalle. Usando varios trucos para alterar la memoria, un atacante puede agregar una nueva entrada al GDT, de tal modo escribiendo un nuevo segmento definido por el atacante que direcciona a un rango de memoria. Esta nueva entrada no sobreescribirá entradas del GDT ya existentes, pero agregará otra entrada que se refiera al mismo rango de memoria incluida en otras líneas del GDT. Pero que dice la nueva entrada?, la nueva entrada del GDT podría direccionar un espacio de memoria que comienza en 0x00000000 y termina en 0xFFFFFFFF. En una arquitectura de 32 bits, ese es el espacio de la memoria entera. Por supuesto, la nueva entrada del GDT permite a alguien leer y escribir en este nuevo segmento solapado. Escribiendo un cierto código en lenguaje de máquina que agregue una entrada al GDT, el atacante puede leer y escribir directamente en el espacio de memoria del núcleo. Luego se explota esta técnica parcheando el núcleo en ejecución de modo que deshabilite todas las características que controlan la seguridad de la máquina. Cuando cualquier usuario intenta tener acceso a un objeto, tal como una llave del 95 registro o archivo, la función “SeAccessCheck” del núcleo verifica que el usuario tiene los derechos de manipular el objeto. Sobreescribiendo 4 Bytes del núcleo de Windows en memoria, se desvían todos los controles de seguridad asociados a acceso de objetos en la máquina, cambiando la llamada de función interna del núcleo SeAccessCheck. Repentinamente, aplicando esta corrección, un atacante puede tener acceso a cualquier archivo, cuenta de usuario, configuración del registro, o todo lo demás en la máquina de la víctima, sin ninguna interferencia del núcleo y de sus controles de seguridad. 4.5.4.5 Parcheando el núcleo en el Disco Duro. En vez de parchear el núcleo de Windows en memoria, un atacante también podría alterar el archivo de la imagen del núcleo en el disco duro, reemplazando funcionalidad dentro de “Ntoskrnl.exe” por software modificado que proporciona un backdoor y oculta la presencia del atacante en la máquina. Ahora, un atacante no puede alterar el archivo Ntoskrnl.exe por sí mismo, porque la integridad de este archivo se comprueba cada vez que el sistema inicia. Durante el proceso inicio, un programa llamado “NTLDR” verifica la integridad de Ntoskrnl.exe antes que el núcleo se cargue en memoria. Si se ha alterado el archivo Ntoskrnl.exe, el programa NTLDR muestra el famoso mensaje de “La pantalla azul de la muerte”, indicando que el núcleo esta corrupto. Para superar esta dificultad, los atacantes manipulan los archivos NTLDR y Ntoskrnl.exe. Usando un pequeño parche para sobreescribir algunas instrucciones en código maquina, el NTLDR omitirá la comprobación de la integridad del archivo Ntoskrnl.exe. Los atacantes entonces pueden alterar libremente el Ntoskrnl.exe a su voluntad, según lo ilustrado en la figura 15. 96 En el paso 1, el archivo modificado NTLDR se copia a la memoria en el comienzo del inicio del sistema. El programa NTLDR ha sido alterado para omitir la comprobación de integridad de Ntoskrnl.exe. Por lo tanto, en el paso 2, el archivo maligno Ntoskrnl.exe se carga en la memoria. Figura 15. Modificando el NTLDR para omitir la comprobación de integridad de Ntoskrnl.exe, y entonces modificar el Ntoskrnl.exe . Aunque esta técnica todavía no se ha utilizado extensamente para poner acceso backdoor y Rootkits en ejecución, varios virus han utilizado la técnica durante los últimos años. 4.5.4.6 Crear un sistema falso usando una máquina virtual. Un atacante podría crear una máquina virtual que funciona encima de un sistema comprometido. Los administradores y los usuarios pensarían que iniciando su 97 sesión en la máquina verdadera, pero en realidad están registrándose en un sistema operativo huésped, construido encima del sistema verdadero poseído por el atacante. Para hacer funcionar una máquina virtual en Windows, un atacante podría instalar varios ambientes de máquinas virtuales, enumerados en la tabla 5. Tabla 5. Herramientas de Maquinas Virtuales que podrían ser usadas para engañar a los usuarios. Herramienta VMWare VirtualPC Plex86 Bochs Tipo Licencia Comercial Comercial Free Free S.O Soportado Linux y Windows Windows, MacOS,y OS/2 Linux Linux, Windows, y MacOS X Dirección Web www.vmware.com www.connectix.com http://plex86.sourceforge.net http://bochs.sourceforge.net Una desventaja significativa para el atacante que usa cualquiera de las herramientas enumeradas en la tabla 5, implica la complejidad y falta de transparencia en el proceso de inicio de la máquina virtual en Windows. El atacante podría entrar en una máquina Windows, instalar una herramienta de máquina virtual, construir un sistema virtual que imite la máquina original, y después configurar la maquina virtual para que inicie apenas el sistema operativo inicie, utilizando scripts en el inicio del sistema. Sin embargo, la activación de la herramienta de máquina virtual y el proceso de inicio del sistema operativo huésped, probablemente serían notados por un administrador de sistema. 98 Una técnica similar es posible en UNIX. Sin embargo en Unix, los scripts de lanzamiento de la maquina virtual pueden ser disfrazados, de modo que realmente no muestre ninguna actividad a un usuario que mira el proceso de inicio del sistema. En Windows engañar a un administrador o a un usuario que se sienta al frente de la interfaz grafica y no sospeche cuando repentinamente se ejecute el VMWare, VirtualPC, Plex86, o Bochs es una tarea mucho más complicada para el atacante. Cada una de las herramientas de máquina virtuales enumeradas en la tabla 8.4 muestra algún tipo de información en la pantalla cuando se activa. Por lo tanto, aunque es una posibilidad, este aproximamiento a Herramientas de máquina virtual es menos probable de ser utilizada en Windows que en Unix. 4.5.4.7 Defendiendo el núcleo de Windows. Con los núcleos Windows expuestos a tipos similares de ataques como en el núcleo de Unix, también debemos endurecer la seguridad de nuestras máquinas Windows. Analicemos las defensas contra la manipulación del núcleo de Windows en las mismas tres categorías que discutimos para los ataques del modo del núcleo de Unix: prevención, detección, y respuesta. 4.5.4.7.1 Prevención Como con la mayoría del malware que hemos cubierto en este proyecto, un elemento crucial del plan defensivo es mantener a los atacantes en la raya endureciendo la configuración y aplicando los parches de una manera oportuna. 99 Tales defensas son tan importantes en Windows como en los sistemas UNIX. Además de estas importantes recomendaciones, podemos considerar otra clase de las herramientas que pueden ayudar a prevenir la instalación de Rootkits del núcleo: Sistemas de prevención de intrusión (IPSs). Las soluciones IPS limitan la exposición del sistema bloqueando funcionalidades, usadas a menudo por los atacantes para obtener privilegios de superusuario en un sistema, mirando y parando la actividad sospechosa asociada a comprometer la maquina. Estas actividades incluyen algunos ataques de buffer overflow, y llamadas sospechosas de llamadas del sistema. “Cisco's Security Agent”, “Network Associates Entercept”,y “Watchguard's ServerLock products” son todos ejemplos de las herramientas comerciales IPS que funcionan en Windows. Ofrecen una variedad de estrategias de protección, pero una de las capacidades mas interesantes de estas herramientas implica el limitar las llamadas de servicio del sistema que varias aplicaciones pueden hacer en la máquina. Configurando el IPS para limitar qué llamadas del sistema que utiliza un programa dado pueden hacer (Ej, Un servidor Web, un servidor de correo, o un servidor DNS), los atacantes tendrán mas dificultad conseguir privilegios de administrador e instalar Rootkits. Algunas herramientas comerciales IPS apoyan varios sistemas operativos. “The Cisco Security Agent” funciona en Windows y Solaris. Entercept está disponible para Windows, Solaris, y HP-UX, Watchguard se centra en Windows y Solaris. Debemos observar que la configuración y mantenimiento de estas herramientas IPS no es ninguna tarea pequeña en un ambiente de producción. Necesitamos instalar la herramienta y configurarla cuidadosamente de modo que opere apropiadamente con las aplicaciones de producción, dando la funcionalidad de 100 uso que necesite para funcionar, mientras que se bloqueen las funciones que no se requieran. En este sentido, la herramienta tiene que ser entrenada con respecto a la actividad normal de la máquina, de modo que pueda detectar y bloquear el comportamiento anormal. Sin embargo, después de configurar la herramienta IPS, habremos agregado una gran medida de seguridad al sistema. 4.5.4.7.2 Detección Para detectar un Rootkit del núcleo en Windows, muchos antivirus incluyen firmas para docenas de herramientas de manipulación del núcleo. Cuando un antivirus marca en el disco duro un Rootkit del núcleo, comparando el contenido del archivo con sus firmas, el antivirus pone en cuarentena el archivo para no poder ser ejecutado e instalado. Por lo tanto, una buena infraestructura actualizada de antivirus, apoya la prevención y detección de Rootkits del núcleo en Windows. Estas firmas del antivirus trabajan lo mejor posible antes de que la herramienta de modificación del núcleo esté instalada, así que el despliegue proactivo de las herramientas antivirus es más importante ahora que nunca. Después que el Rootkit del núcleo esté instalado, el antivirus tiene menos oportunidad de detectarlo, porque las técnicas que ocultan al Rootkit, podrían ayudar a enmascararlo del antivirus. Sin embargo, algunos Rootkits en Windows pueden ser marcados por el antivirus incluso después que el Rootkit esté instalado, debido a fallas en las técnicas que ocultan el Rootkit. 101 Aunque las soluciones antivirus ofrecen un nivel significativo de protección contra estas formas de malware, debemos también considerar una herramienta de comprobación de integridad de archivos, tal como “Tripwire”, “GFI LANguard System Integrity Monitor” y “Ionx Data Sentinel tools”, cada una de estas herramientas puede detectar los cambios en archivos realizados por un Rootkit del núcleo. Es común que los atacantes no puedan ocultar todos los cambios de archivos con un Rootkit del núcleo. Por lo tanto, buscar estos cambios con una herramienta de comprobación de integridad de archivos es una estrategia sana. 4.5.4.7.3 Respuesta Cuando nos enfrentemos a un ataque que emplee un Rootkit del núcleo en una maquina Windows, debemos tener un CD-ROM con una copia de instalación del antivirus y las firmas actualizadas. Muchos antivirus de Windows pueden detectar y desinstalar varios Rootkits del núcleo, tener esta capacidad de respuesta en el campo de batalla es inestimable. Apenas instalemos el antivirus en la máquina víctima, tendremos suerte si tenemos la firma de virus que detecte el Rootkit ya instalado y eliminarlo. Si el antivirus no puede encontrar o quitar el malware, necesitaremos realizar un análisis más detallado del sistema sin confiar en el núcleo de Windows. Una vez más los CD´s de “FIRE” y “Knoppix” entran en juego. Nos preguntamos ¿cómo podemos utilizar un CD-ROM de Linux para analizar un sistema Windows?, aunque FIRE y Knoppix son imágenes de Linux, incluyen una variedad de herramientas para analizar particiones de disco en Windows. 102 Para analizar el sistema más detalladamente, debemos configurar el sistema para iniciar desde el CD-ROM de FIRE o Knoppix, así empezaremos en un ambiente de Linux. Entonces, funcionaran varias herramientas de Linux para analizar la partición de Windows de la máquina. En el caso de FIRE, incluye una variedad de programas para analizar un disco duro con Windows, mostrados en la tabla 6. Tabla 6 Herramienta Descripción Una versión libre de F-prot. Esta versión puede buscar F-prot malware de Windows y Linux, incluyendo una variedad de Rootkits del núcleo. Una herramienta de línea de comando de Linux para Editreg buscar y alterar el registro en una partición de Windows. Una herramienta de Linux para el análisis forense del The Sleuth Kit disco duro, incluyendo varios formatos de UNIX, y particiones de Windows como FAT y NTFS. Actualmente, un CD-ROM de Linux es la mejor opción, pues no hay ninguna imagen de Windows en CD-ROM que contenga herramientas forenses. El Licenciamiento de Microsoft prohíbe a la gente crear una distribución de Windows, y hacerla disponible para la descarga en el Internet. Armado con estas herramientas del CD-ROM de FIRE, podremos realizar búsquedas sólidas en el registro y el sistema de archivos. 103 4.6 Detección de los Rootkits. Como hemos mostrado, los rootkits puede ser difíciles de detectar, especialmente cuando operan en el núcleo. Esto es porque un rootkit del núcleo puede modificar las funciones usadas por todo software, incluyendo las que usan el software de seguridad. Las mismas herramientas disponibles para el software de prevención están también disponibles para un rootkit. Así que las vías que se bloqueen para prevenir la intrusión del rootkit simplemente pueden ser desbloqueadas. Un rootkit puede impedir que el software de detección o prevención pueda ejecutarse o trabajar apropiadamente. Al final, se reduce a una carrera entre el atacante y el defensor, con una ventaja grande para el que se cargue primero en el núcleo y se ejecute. Eso no quiere decir que todo esta perdido para el defensor, pero se debe ser cuidadoso, lo que hoy trabaja perfectamente detectando rootkits, podría no detectar el rootkit de mañana. Cuando los desarrolladores de rootkit aprenden qué está haciendo el software de detección, mejores rootkits desarrollaran. detección constantemente cuando las nuevas técnicas de rootkit aparezcan. Lo contrario también es verdadero: los defensores actualizarán el software de Miraremos los dos enfoques básicos para la detección de rootkit: detectar el rootkit mismo, y detectar el comportamiento de un rootkit. En cuanto estemos más familiarizados con estos enfoques, estaremos en un mejor puesto para defendernos de esta amenaza. 104 4.6.1 Detectar la presencia Muchas técnicas pueden ser usadas para detectar la presencia de un rootkit. En el pasado, el software tipo Tripwire buscaba una imagen en el sistema de archivos. Este enfoque todavía es usado por algunos distribuidores de antivirus, y puede ser aplicado a la detección de rootkit. La suposición detrás de tal enfoque es que un rootkit usará el sistema de archivos. Obviamente, esto no trabajará si el rootkit se ejecuta solamente en la memoria o está ubicado en una pieza de hardware. Además, el programa de anti-rootkit no será efectivo, si es ejecutado sobre un sistema que esta ejecutándose y ya esta infectado. Un rootkit que este escondiendo sus archivos enganchando las llamadas del sistema no será detectado. Porque el software como Tripwire tiene estas limitaciones, otros métodos de detectar la presencia de rootkit se han desarrollado. 4.6.1.1 Proteger las puertas Todo software debe "Vivir" en la memoria en algún lugar. Por lo tanto, para descubrir un rootkit, miraremos en la memoria. Esta técnica toma dos formas. La primera trata de detectar el rootkit cuando se carga en la memoria. Esto es un enfoque de “Proteger las puertas", detectando lo que entra en la computadora (procesos, unidades de dispositivo, etcétera). Un rootkit puede usar muchas funciones de sistemas operativos diferentes para cargarse el mismo en la memoria. Mirando estos puntos de ingreso, el software de detección puede a veces descubrir el rootkit. Sin embargo, hay muchos otros puntos para mirar; si el software de detección no vigila cualquier otro método de carga, el rootkit no será detectado. 105 4.6.1.2 Escanear “los Cuartos” La exploración es la segunda técnica para detectar rootkits en la memoria. Para evitar la labor tediosa de proteger todos los puntos de entrada en el núcleo o en el espacio de direccionamiento de un proceso, se puede explorar la memoria periódicamente, buscando conocidos módulos o firmas de módulos que corresponden a rootkits. Esta técnica puede encontrar a solamente atacantes conocidos. La ventaja de este método de detección es la sencillez. 4.6.1.3 Buscar ganchos “Hooks” Otro método de basado en detección de memoria en es buscar Hooks dentro del sistema operativo y dentro de procesos, hay muchos lugares donde un hook puede esconderse. Buscar hooks, tiene un gran defecto: El rootkit ya ha sido cargado en la memoria y se esta ejecutando; puede entrometerse en sus métodos de detección. Pero una ventaja para buscar hooks es que es un enfoque genérico. Buscando hooks, usted no tiene el problema de buscar conocidas firmas o patrones. 106 4.6.2 Detectar el comportamiento Detectar el comportamiento es una nueva área prometedora en la detección de los rootkits. Es quizás la más fuerte. El objetivo de esta técnica es captar el sistema operativo cuando "Esta Mintiendo." Si descubre que una API devuelve valores que sabe son falsos, no sólo usted ha identificado la presencia de un rootkit, también ha identificado lo que el rootkit está tratando de esconder. El comportamiento que se busca es la mentira. 4.6.2.1 Detectar archivos ocultos y llaves de Registro “RootkitRevealer” Existe una herramienta llamada disponible en www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml, con la que se puede detectar las anotaciones de registro escondidas y archivos ocultos. Para determinar que es "Verdad", RootkitRevealer descompone gramaticalmente los archivos que corresponden a las diferentes entradas de registro. También descompone gramaticalmente el sistema de ficheros en un nivel muy bajo, evitando las típicas llamadas de API. RootkitRevealer llama a las API de mas alto nivel para comparar el resultado con el lo que es conocido que es verdadero. Si se encuentra una discrepancia, el comportamiento del rootkit (y, por lo tanto, lo que está escondiendo) es identificado. Esta técnica es bastante sencilla, aunque muy fuerte. 107 4.6.2.2 Detectar procesos escondidos Los procesos escondidos y archivos son algunas de las amenazas más comunes. Un proceso escondido es particularmente amenazador porque representa código corriendo en un sistema del cual el administrador es totalmente inconsciente. 108 4.7 Tecnologías ofensivas para los Rootkit Un buen rootkit debe poder evitar cualquier medida de seguridad, como un cortafuegos o un sistema de detección de intrusos (IDS). Hay dos tipos principales de IDS: Basados en la red (NIDS) y basados en Host (HIDS). A veces los HIDS son diseñados para tratar de parar los ataques antes de que estos tengan éxito. Esta "Defensa activa" a veces es referida como Sistema de prevención de intrusión basado en Host (HIPS). HIPS Recomendados. • Blink, www.eEye.com) • Integrity Protection Driver, www.pedestal.com) • Entercept (www.networkassociates.com) • Cisco Security Agent , www.cisco.com) • LIDS, www.lids.org) • WatchGuard ServerLock (www.watchguard.com) Para el rootkit, la amenaza más grande es la tecnología HIPS. Un HIPS puede detectar un rootkit a veces cuando se instala, y también puede interceptar un rootkit cuando se comunica con la red. Muchos HIPS utilizan la tecnología de núcleo y pueden monitorear los sistemas operativos. Un HIPS es un Anti- rootkit. Cuando un rootkit entra a un sistema lo más probable es que será detectado y neutralizado. Cuando un atacante quiera usar un rootkit contra un sistema protegido por HIPS, tiene dos elecciones: evitar los HIPS, o escoger otro objetivo más fácil. 109 4.7.1 NIDS Los IDS Basado en Red (NIDS) también preocupan a los desarrolladores de rootkits, pero un rootkit bien diseñado puede eludir un NIDS. Aunque, en teoría, el análisis estadístico puede notar canales de comunicación encubiertos, esto es hecho raramente. Las conexiones en la red para un rootkit usarán un canal encubierto escondido y aparentando llevar paquetes inocentes. Cualquier transferencia de datos importante será cifrada. La mayoría de los NIDS tratan con flujos de datos grandes (Mas de 300 mb/segundo), y el pequeño canal de datos en el que irá un rootkit pasará inadvertido. El NIDS posee una sensibilidad de detección más grande cuando un exploit conocido públicamente es usado en conjunción con un rootkit. 4.7.2 Como los rootkits Evitan las identificaciones de los IDS / IPS. Los rootkits más avanzados pueden evitar firewalls y software de IDS / IPS, hay dos enfoques: activo y pasivo. Ambos enfoques deben ser mezclados para que un rootkit no sea detectado. Las ofensivas activas operan en tiempo de ejecución y son diseñadas para prevenir la detección. Solo en el caso que el software se protección ponga su atención en el rootkit, La Ofensiva Pasiva es aplicada para hacer el análisis forense tan difícil como sea posible. Las ofensivas activas son modificaciones en el sistema y el núcleo diseñadas para confundir y enredar al software de detección. Las medidas activas son requeridas 110 generalmente para desactivar el software de HIPS. En general la ofensiva activa es usada contra el software que se ejecuta en memoria e intenta detectar rootkits y dejarlo inútil. Por ejemplo, una ofensiva activa podría localizar un escáner de virus y desactivarlo. La Ofensiva pasiva es manipular el almacenamiento de datos y su transferencia. Por ejemplo, cifrar los datos antes de guardarlo en el sistema de ficheros es una ofensiva pasiva. Una ofensiva más avanzada sería guardar la llave para descifrar en memoria no volátil (Como una memoria Flash) en lugar del sistema de ficheros. Otra forma de ofensiva pasiva es el uso de canales encubiertos para filtración de datos afuera de la red. Definitivamente, un rootkit no debe ser notado por un escáner de virus. Los Escáneres de virus no sólo funcionan en tiempo de ejecución, también pueden ser usados para escanear el sistema de archivos en modo "Offline." Por ejemplo, una unidad de disco duro en un laboratorio de pruebas puede ser analizada para virus. Para evitar la detección en tal caso, un rootkit debe esconderse en el sistema de ficheros con el propósito de que no puede ser detectado por el escáner. 4.7.3 Evitar herramientas forenses. Un rootkit nunca debería ser notado por el análisis forense. Existen fuertes herramientas para escanear unidades de discos duros. Algunas herramientas como Encase, pueden ser usadas cuando un sistema es sospechoso de estar comprometido. Un profesional usando una herramienta como Encase analizara en la unidad de disco sus estructuras de bytes. Esta herramienta puede mirar la unidad de disco 111 completamente, no solo los archivos regulares. El espacio desperdiciado y los archivos eliminados serán escaneados. Para evitar la detección en este caso, el rootkit no debe tener estructuras fácilmente identificables. El uso de esteganografia puede ser de mucha ayuda en esta área. También puede ser usado el cifrado de datos, pero las herramientas para medir la aleatoriedad de los datos pueden ubicar bloques cifrados de los datos. Si el cifrado es usado, la parte del rootkit responsable del descifrado necesitaría quedarse sin cifrar. Las herramientas que llevan a cabo hashing de cifrado en el sistema de ficheros, como Tripwire, requieren que una base de datos de hashes sea hecho en un sistema limpio. En teoría, si la copia de un sistema limpio es hecha antes de que la infección de rootkit tenga lugar, un análisis offline podría ser llevado a cabo para comparar la nueva imagen de unidad de disco con el viejo. Cualquier diferencia entre las unidades de disco serán inmediatamente detectadas y el rootkit será una detectado indudablemente, pero otros archivos también serán identificados porque fueron modificados. Esto se explica porque en cualquier sistema que a estado activo hay archivos que cambian con el tiempo. Para evitar la detección, un rootkit puede esconderse en el ruido regular del sistema de ficheros. Adicionalmente, estas herramientas solamente miran archivos considerados importantes y, no miran algunos archivos por ejemplo no analizan los datos guardados de maneras no convencionales (por ejemplo, en sectores defectuosos sobre una unidad de disco). Además los archivos de datos temporales son propensos a ser ignorados. Esto deja muchos lugares potenciales para esconderse y no ser verificados. Si un atacante esta muy preocupado porque que el administrador del sistema tiene todas sus cosas hashed y el rootkit será notado, podría entonces evitar el 112 sistema de archivos totalmente, quizás instalando un rootkit en la memoria y no usar nunca la unidad de disco. Una desventaja, por supuesto, es que un rootkit guardado en la memoria desaparecerá si el sistema es reiniciado. Para llevar cosas a un extremo, quizás un rootkit puede instalarse en el microprograma presente en el BIOS o un chip de RAM en algún lugar. 113 4.8 Diseño de un Rootkit. Un atacante diseña un rootkit para que afecte a un OS y software en especial. Si el rootkit es diseñado con acceso directo a hardware, entonces estará limitado a ese hardware específico. Los Rootkits pueden ser genéricos para las diferentes versiones de un OS, pero todavía estarán limitados a una familia de OS en particular. Por ejemplo, algunos rootkits de dominio público afectan toda la familia del Windows NT, 2000, y XP. Esto es solamente posible cuando toda la familia del OS tiene estructuras de datos similares. Por ejemplo, es menos viable crear un rootkit genérico que infecte tanto el Windows como el Solaris,. 4.8.1 Manipulación de hardware. La manipulación de hardware es una espada de doble filo. Por una parte, pone al rootkit en una capa debajo de todas las cosas. Esto quiere decir que el rootkit tiene más control y es más invisible. Sus opciones incluyen el acceso directo a periféricos de hardware, controladores de disco, procesadores, y el firmware. Por otro lado, el hardware es más difícil de hacer funcionar, y es intrínseco de una plataforma específica. El rootkit debe estar diseñado para un hardware en particular. En otras palabras, el rootkit no será muy portátil. 4.8.2 Modificando el Firmware. Por diseño, un procesador empezará a funcionar ejecutando un programa guardado en chips de memoria. Por ejemplo, un PC ejecuta la BIOS cuando carga. Los sistemas de hardware varían extensamente, pero todos comparten un hecho en común: en algún lugar, de algún modo, el Firmware debe ser activado. 114 Teniendo en cuenta que el firmware es muy importante para la operación de sistema, un rootkit no debe quitar las características existentes del firmware. En vez de eso, un rootkit debe añadir las nuevas características al código existente (Mirar Figura 16). El tamaño de la memoria del firmware generalmente es restringido así que un rootkit no debe ser tan grande. Figura 16 4.8.3 Acceder al Hardware. La mayor parte del hardware sobre la computadora puede ser controlado con software vía instrucciones hacia y desde un microchip. La mayoría de dispositivos de hardware tienen un microchip que puede ser direccionado en algún lugar. 4.8.4 Direcciones de hardware. Cambiar de lugar los datos hacia y desde un microchip requiere una dirección. El bus de dirección consta de muchos cables pequeños, algunos de los cuales están conectados a la instalación eléctrica de cada microchip. Así que, especificando una dirección en la memoria a la que escribir, estaremos realmente seleccionando un microchip. 115 Una vez seleccionado, el microchip lee los datos del bus de datos. Este microchip controla el hardware en cuestión. la Figura 17, ilustra cómo es escogido por el bus de dirección un microchip, y entonces los datos son leído del bus de datos. Figura 17 4.8.5 ¿Qué tan lejos se puede ir? Actualización del microcódigo. Los procesadores modernos de Intel y AMD incluyen una característica conocida como la actualización del microcódigo. Esto Permite que un código especial sea actualizado al procesador para que pueda cambiar la manera en que el hardware trabaja. Es decir el chip del procesador puede ser modificado interiormente. La actualización de microcódigo no fue diseñada para permitir piratearse; fue creado para permitir que las correcciones de errores puede arreglarlo. sean aplicadas al procesador. Si algo está mal en el procesador, una actualización de microcódigo 116 En teoría, si un pirata informático pudiera proporcionar o reemplazar el microcódigo en el procesador, podría añadir instrucciones malignas. Sin embargo el obstáculo más grande está comprender el mecanismo de actualización del microcódigo. Si este es comprendido, podría ser posible hacer códigos de puertas traseras. La actualización de microcódigo es almacenada como un bloque de datos y debe ser cargado al procesador cada vez que este es iniciado. La actualización tiene lugar usando registros de control especiales sobre el chip. Típicamente, el bloque de la actualización de microcódigo será guardado en la BIOS de sistema y aplicado por el BIOS al sistema en el inicio. Ningún reinicio es requerido, el nuevo microcódigo es utilizado inmediatamente el sistema inicie. Intel en sus procesadores protegen la actualización de microcódigo con un fuerte cifrado. Para modificar la actualización correctamente el cifrado debe ser roto. Los procesadores de AMD no usan cifrado, así que en teoría son más fáciles de actualizar. 117 4.9 Perspectivas del Proyecto 4.9.1 Perspectivas para la empresa Corto Plazo Mediano Plazo Mostrar el peligro real de los rootkits hoy en día. Concientizar a los administradores de sistemas sobre los peligros latentes de los rootkits, para que implementen medidas de prevención y control. Largo Plazo Mantener las medidas de seguridad en la empresa para evitar los ataques, mejorando constantemente los controles y actualizando los sistemas de prevención. 4.9.2 Perspectivas para la Universidad Corto Plazo Mediano Plazo Empezar un ciclo de investigación científica. Brindarles a los estudiantes herramientas de calidad para sus consultas y servir de pilar para que estos continúen los proyectos iniciados. Largo Plazo Seguir con la realización de este tipo de investigaciones para darle mas renombre a la institución a nivel nacional e internacional. 118 4.9.3 Perspectivas para el Investigador Corto Plazo Enfrentar y conocer la realidad en el campo de la seguridad hoy en día. Mediano Plazo Investigar más a fondo sobre todo el mundo de la seguridad informática, y compartir todos nuestros conocimientos con otros administradores de sistemas, y a su vez enseñar a los usuarios a adquirir una cultura de seguridad. Largo Plazo Conociendo la responsabilidad que manejaremos en el futuro, aplicaremos todos los conocimientos adquiridos en el área de la seguridad informática en los sistemas que administremos. 119 4.9.4 Conclusión La primera generación de rootkits eran sólo programas normales. Hoy, los rootkits son empacados como drivers de dispositivos. Durante los siguientes años los rootkits avanzados podrían modificar o instalarse en el microcódigo de un procesador, o existir principalmente en los microchips de una computadora. Mientras los exploits existan, los rootkits se aprovecharan de estos exploits. Los dos trabajan en conjunto. Sin embargo, incluso si los exploits no sean posibles, los rootkits todavía existirían. En las siguientes décadas, el buffer overflow, actualmente llamado el "Rey de todos los exploits", estará muerto y enterrado. Los avances en lenguajes de programación seguros, y compiladores harán el buffer overflow inútil, dando un golpe inmenso contra los que usan los exploits. Esto no quiere decir que los exploits se irán. El nuevo mundo del exploit estará basado en los errores de la lógica de los programas más que en el defecto de la arquitectura o el buffer overflow. Con o sin los exploits, los rootkits persistirán. Los Rootkits pueden ser puestos en sistemas de muchas maneras, Mientras haya personas, las personas querrán espiar a las otras personas. Esto quiere decir que rootkits tendrá un lugar en nuestra tecnología por mucho tiempo. La mayoría de los métodos de detección consisten en detectar hooks y procesos escondidos. Ningún algoritmo de detección es completo o infalible. Cuando el atacante avanza, los métodos de detección se desarrollarán. Una desventaja de publicar demasiado sobre los rootkits y las metodologías de detección es que esto favorece al atacante. Cuando los métodos de detección son explicados a un atacante, el atacante modificará su metodología. Sin embargo, el simple hecho de que una técnica de manipulación especial no haya sido escrita en 120 un libro o sea presentada en una conferencia no hace a nadie más seguro. Actualmente, somos conscientes de algunos esfuerzos de envolver rootkits en la memoria con el propósito de que incluso el escaneo de memoria sea corrupto. Los otros grupos se están trasladando al hardware, con procesadores embebidos para explorar la memoria del núcleo sin depender del sistema operativo. Debido a que ninguna puesta en práctica estará disponible para el escrutinio público, es difícil decir cuál tendrá la ventaja. Estamos seguros que cada uno tendrá sus propias limitaciones y defectos. Recientemente hemos visto compañías mostrar sus primeras señales de interés en la detección de rootkit. Esperamos que esta tendencia continúe. Tener la mayor cantidad de usuarios bien informados causará que el software de protección avance aunque lo mismo se puede decir al contrario: tendremos mayor cantidad de atacantes bien informados. Los atacantes tienen una variedad de opciones para manipular el núcleo, enganchando las llamadas a la API del núcleo para reemplazar el núcleo en sí mismo. Usando estas técnicas de gran alcance, los atacantes pueden poner Rootkits en ejecución extremadamente invisibles, haciéndolos muy difícil de detectar y eliminar, una vez tengan acceso en una máquina. Hemos visto la progresión gradual de los ataques del malware desde los Rootkits modo-usuario, hasta los Rootkits del núcleo. ¿Pero es el núcleo la posibilidad más profunda que hacemos frente al luchar el malware? Realmente NO, este es solo el principio, en un futuro muy cercano los atacantes podrán ir más profundo. En nuestro medio, las corporaciones y empresas no están motivadas para protegerse contra un ataque potencial hasta que hay un ataque. Ayudemos a cambiar las cosas! 121 Bibliografía  Malware - Fighting Malicious Code. Ed Skoudis, Lenny Zeltser Editorial Prentice Hall PTR  Rootkits - Subverting the Windows Kernel. Greg Hoglund, James Butler Editorial Addison Wesley Professional  http://www.rootkit.com/  http://www.wikipedia.com 122 Anexos. Anexo 1. Cronograma de actividades: Actividad Investigación preliminar Recopilación de información Procesamiento de la información Documentación Entrega Fin de la etapa = X Mayo X X X X X Junio Julio 123