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 1. Presentación del Proyecto 2 1.1 Titulo 2 1.2 Objetivos 2 1.2.1 Objetivo General 2 1.2.2 Objetivos Específicos 3 1.3 Justificación 3 2. Marco de Referencia 4 2.1 Marco Teórico 4 2.2 Marco Conceptual 5 2.3 Administración y control de la Investigación 8 2.3.1 Descripción del plan de actividades 8 2.3.2 Cronograma de actividades (Anexo 1) 8 2.4 Aspectos Financieros del Proyecto 8 2.1.4 Costo total estimado 8 3. Resultados 10 3.1 Análisis de requerimientos 10 3.1.1 Investigación preliminar 10 3.1.2 Análisis del sistema actual 10 3.1.3 Selección de las herramientas a utilizar 11 3.1.4 Selección de los sistemas operativos 11 3.1.5 Selección de las herramientas complementarias 12 3.1.6 Selección del hardware 12 4. Presentación de resultados 13 4.1.1 Los motivos de los atacantes 13 4.1.2 La parte Invisible “Stealth”. 13 4.1.3 ¿Cuando no importa ser invisible? 14 4.1.4 ¿Que es un Exploit y porque son un problema? 14 4.2.1 ¿Qué es un Rootkit? 15 4.2.2 Que no es un Rootkit 16 4.2.2.1 Un Rootkit no es Exploit.. 16 4.2.2.2 Un Rootkit no es un virus 16 4.2.3 Objetivos de un Rootkit 17 4.2.4 ¿Por qué existen los Rootkits? 17 4.2.4.1 Comando y control remoto 18 4.2.4.2 Escucha oculta de software (Sniffer) 18 4.2.5 Usos legítimos de Rootkits 18 4.2.6 ¿Cómo trabajan los Rootkits? 19 4.2.6.1 Patching 19 4.2.6.2 Huevos de Pascua 20 4.2.6.3 Modificaciones de Spyware 20 4.2.6.4 Modificación del Código Fuente 20 ROOTKITS MODO USUARIO Unix -Windows 21 4.3 Rootkits Modo-Usuario 22 4.3.1 Rootkits modo-usuario en Unix 24 4.3.1.1 Reemplazos en los binarios que proporcionan acceso a una puerta trasera 24 4.3.1.2 Reemplazos binarios para ocultar el atacante 25 4.3.1.3 Otras herramientas para ocultar que no substituyen programas binarios 25 4.3.1.4 Scripts de instalación 25 4.3.1.5 La familia LRK (The Linux Rootkit) 26 4.3.1.6 Crear procesos en ejecución 27 4.3.1.7 Utilizar la red 27 4.3.1.8 Crear directorios y archivos 27 4.3.1.9 Generar Logs 27 4.3.2 Herramientas del LRK 28 4.3.2.1 Otras herramientas de LRK 29 4.3.3 Defensa para los Rootkits modo-usuario en Unix 30 4.3.3.1 Prevención 30 4.3.3.2 Detección 31 4.3.3.3 Respuesta 34 4.4 Rootkits Modo-Usuario en Windows 36 4.4.1 Diferentes Técnicas para implementar un rootkit modo-usuario en Windows. 38 4.4.1.1 Técnica 1: Manipulación del Logon de Windows con FakeGINA 39 4.4.1.2 Técnica 2: WFP “Protección de Archivos de Windows” Cómo trabaja y los ataques contra él 44 4.4.1.2.1 Atacando al WFP 45 4.4.1.2.2 Herramienta para atacar al WFP: Code Red II 47 4.4.1.3 Técnica 3: Inyección del DLL, Enganchando a las API, y el AFX Windows Rootkit.. 49 4.4.1.3.1 Código de Windows: “EXE vs DLL” 49 4.4.1.3.2 Inyección del DLL y enganchando (Hooking) las API 50 4.4.1.3.3 AFX Windows Rootkit: Usando la inyección del DLL y enganchando a la API 54 4.4.2 Defensas ante un Rootkit Modo-Usuario en Windows 56 4.4.2.1 Prevención 56 4.4.2.2 Detección 58 4.4.2.3 Respuesta 60 4.4.3 Conclusión 60 ROOTKITS DEL NUCLEO UNIX -Windows 62 4.5 Rootkits del núcleo 63 4.5.1 Destruir el núcleo 63 4.5.1.1 Componentes importantes del núcleo 64 4.5.1.2 ¿Cual es el papel del núcleo en el sistema operativo?. 65 4.5.1.3 Impacto de Manipulación del Núcleo 66 4.5.2 Rootkits del Núcleo en Unix 70 Métodos para manipular el núcleo de Unix. 70 4.5.2.1 Método 1: Módulos malignos cargables al núcleo. 70 4.5.2.1.1 Ejemplo de Módulos malignos cargables al núcleo: Adore 72 4.5.2.2 Método 2: Atacando el “/dev/kmem”. 75 4.5.2.3 Método 3: Parcheando la imagen del Núcleo en el Disco Duro 77 4.5.3 Defendiendo el núcleo de Unix 79 4.5.3.1 Prevención de Rootkits del núcleo en Unix 79 4.5.3.2 Detección de Rootkit del núcleo en Unix 81 4.5.3.3 Respuesta ante un Rootkit del núcleo en Unix 84 4.5.4 El núcleo de Windows 85 4.5.4.1 Aventuras en el núcleo de Windows 85 4.5.4.2 Métodos para manipular el núcleo de Windows 90 4.5.4.3 Drivers Malignos de dispositivos 91 4.5.4.3.1 Ejemplo de un Rootkit del Núcleo para Windows Slanret/Krei 94 4.5.4.4 Alteración de un núcleo en ejecución en memoria 94 4.5.4.5 Parcheando el núcleo en el Disco Duro 96 4.5.4.6 Crear un sistema falso usando una máquina virtual 97 4.5.4.7 Defendiendo el núcleo de Windows 99 4.5.4.7.1 Prevención 99 4.5.4.7.2 Detección 101 4.5.4.7.3 Respuesta 102 4.6 Detección de los Rootkits 104 4.6.1 Detectar la presencia 105 4.6.1.1 Proteger las puertas 105 4.6.1.2 Escanear “los Cuartos” 106 4.6.1.3 Buscar ganchos “Hooks” 106 4.6.2 Detectar el comportamiento 107 4.6.2.1 Detectar archivos ocultos y llaves de Registro.. 107 4.6.2.2 Detectar procesos escondidos 108 4.7 Tecnologías ofensivas para los Rootkit 109 4.7.1 NIDS 110 4.7.2 Como los rootkits Evitan las identificaciones de los IDS /IPS 110 4.7.3 Evitar herramientas forenses 111 4.8 Diseño de un Rootkit. 114 4.8.1 Manipulación de hardware 114 4.8.2 Modificando el Firmware 114 4.8.3 Acceder al Hardware 115 4.8.4 Direcciones de hardware 115 4.8.5 ¿Qué tan lejos se puede ir? Actualización del microcódigo 116 4.9 Perspectivas del Proyecto 118 4.9.1 Perspectivas para la empresa 118 4.9.2 Perspectivas para la Universidad 118 4.9.3 Perspectivas para el Investigador 119 4.9.4 Conclusión 120 Bibliografía 122 Anexos 123 Lista de Tablas. Tabla 1. Plan de actividades 8 Tabla 2. Relación de costos 9 Tabla 3. Varias Herramientas de Inyección de DLL y enchanche a las API´s. 53 Tabla 4. Componentes funcionales del núcleo 64 Tabla 5. Herramientas de Maquinas Virtuales que podrían ser usadas para engañar a los usuarios. 98 Lista de Figuras. Figura A. Diferencias entre un Caballo de Troya y un Rootkit modo Usuario. 23 Figura 1. Usando la herramienta que comprueba la integridad de archivos antes y después de la instalación de parches. 32 Figura 2. El Proceso de autenticación de Windows 40 Figura 3. FakeGINA recolecta secretamente todas las identificaciones del usuario y passwords insertándose entre el winlogon.exe y msgina.dll. 42 Figura 4. Los Atacantes usan la Inyección de DLL para enganchar a las API´s en un proceso atacado. 52 Figura 5. La interacción entre iexplore.exe, iexplore.dll, explorer.exe, y explorer.dll cuando AFX Rootkit para Windows se ejecuta. 55 Figura 6. Manipulación del núcleo para ocultar procesos. 67 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. 71 Figura 8. Ava, La interfaz de usuario de Adore. 74 Figura 9. Alterando un núcleo en ejecución leyendo y escribiendo en /dev/kmem. 76 Figura 10. Reemplazando la imagen del núcleo en el disco duro. 77 Figura 11. Aplicando parches directamente en la imagen del núcleo del disco duro. 78 Figura 12. Una descripción del núcleo de Windows y su relación con los componentes vitales modo-usuario 86 Figura 13. Tres maneras que las DLLs hacen peticiones a los procesos modo-usuario. 88 Figura 14. Usar un driver de dispositivo para manipular el núcleo de Windows. 92 Figura 15. Modificando el NTLDR para omitir la comprobación de integridad de Ntoskrnl.exe, y entonces modificar el Ntoskrnl.exe. 97 Figura 16. Un rootkit debe añadir las nuevas características al código existente del firmware. 115 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. 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. 3 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. 4 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”). 5 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. 6 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. 7 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. 8 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 Fecha de Inicio Duración Investigación preliminar Mayo 20 del 2007 10 Días Recopilación de información Mayo 31 del 2007 15 Días Procesamiento de la información Junio 15 de 2007 30 Días Documentación Julio 18 de 2007 7 Días Entrega Julio 27 del 2007 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) 9 Tabla 2. Relación de costos Detalle Presupuesto Papelería y suministros $ 80.000 Costo del recurso Humano $ 2.000.000 Costo del hardware y software $ 2.300.000 Sub. Total $ 4.380.000 Imprevistos 10% $ 438.000 Total $ 4.818.000 10 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. 11 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 12 -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 13 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. 14 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 15 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. 16 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. 17 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. 18 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. 19 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 20 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. 21 ROOTKITS MODO USUARIO Unix -Windows 22 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. 23 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. 24 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. 25 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 atacante modificar logs del sistema. 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. 26 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: 27 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. 28 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”. 29 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. 30 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. 31 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 32 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. 33 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: 34 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. 35 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. 36 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 modousuuari 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 37 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 38 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”. 39 • 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 40 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 41 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. 42 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 43 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 passwordcracckin 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. 44 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. 45 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 46 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 47 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”. 48 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. 49 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 50 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. 51 -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?. Aquí es donde el concepto de enganche (Hooking) a las API entra en el juego, permitiendo que el atacante emplee técnicas de Rootkit modo-usuario. 52 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 53 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 Dirección MadCodeHook Extremadamente bien documentada, completamente equipada en inyección del DLL y enganche a las API. www.madshi.net/olddlp6.htm APIHijack Biblioteca para simplificar el enganche a la API. www.codeproject.com/dll/apihijack.a sp EliRT API que ejecuta VirtualAllocEx, CreateRemoteThread, y otras funciones, funciona en Windows (Win95/98/Me,NT/2000/XP/2003) www.anticracking.sk/EliCZ/export/Eli RT.zip Inject.exe Ejecutable en líneas de comandos, basado en EliRT. www.megasecurity.org/Programmin g/StealthDLLInjection.html 54 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 modousuuari 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”. 55 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. 56 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. 57 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”. Esta plantilla proporciona configuraciones razonables de seguridad para las estaciones de trabajo usadas en la mayoría de las organizaciones. 58 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. 59 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. 60 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. 61 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. 62 Rootkits del Núcleo Unix -Windows 63 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 64 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 Dirección de proceso Los procesos necesitan tiempo de CPU. El núcleo contiene código para asignar este tiempo de CPU. Si el OS soporta 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. Acceso de archivo El sistema de archivos es una de las características más importantes que un OS provee. Las unidades de dispositivo 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 65 puede esconder archivos y directorios. Seguridad 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 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. Gestión de la memoria 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 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. 66 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 caracterí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. 67 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. 68 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. 69 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. 70 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. 71 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. 72 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 73 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. 74 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. 75 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. 76 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. 77 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. 78 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. 79 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. 80 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. 81 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