Autor: jlrambla

Uno de los grandes cambios producidos en Windows Vista y que había sido demandado por los usuarios, consiste agregar mejoras para la presentación de información a través del visor de sucesos. Incorporando el nuevo sistema de gestión de eventos, Windows Eventing 6.0, Vista permite un mejor análisis de la información, permitiendo la exportación en XML de datos y el filtrado coherente de los mismos. A través de 5 post evaluaremos el nuevo sistema de gestión de eventos y las mejoras en administración que ofrece a los usuarios y operadores.

Fig. 1.- Nuevo visor de eventos.

 

El primer cambio significativo que encontramos, reside en el hecho de encontrarnos a través del visor de sucesos de una serie de nuevas carpetas de gestión de eventos. Como medida significativa el sistema cuenta con un generador de vistas personalizadas, donde alimentar de sucesos a la vista, con las opciones deseadas y así poder monitorizar de una forma controlada, la información proporcionada por el sistema.

La vista contará con el nivel de eventos recogidos, el tipo de registro u origen a recoger (se mencionarán los registros más importantes y la forma en la cual se generan internamente, en un post más avanzado) y en función del tipo de evento, categorías de filtrado por palabras, usuarios y equipos. La generación de una consulta puede ser visualizada y editada en su formato XML, lo que permite su posterior exportación a otros sistemas.

Fig. 2.- Evento en formato XPath

 

Otros de los avances del nuevo sistema de gestión de eventos lo constituyen los registros de aplicaciones y servicios que se unen a los existentes del Registro de Windows. A través de este sistema de registro se diferencian cada uno de los elementos y servicios que dan funcionalidad a Windows Vista, permitiendo un diagnóstico más sencillo de los componentes. Por ejemplo todos los eventos relativos a Gestión Parental, quedan registrados en su carpeta correspondiente.

Cada uno de los eventos recogidos permite habilitar el mecanismo de ayuda. Dicho mecanismo implica la conexión a través del centro de mensajes de eventos y errores. Aquí se realiza una descripción del evento, permitiendo incrementar la consulta con la Base de datos de conocimiento de Microsoft, consulta en Technet y en los blogs correspondientes.

Otro nuevo elemento lo constituye el uso de suscriptores. Esto permitirá la consolidación de eventos de diferentes Equipos en una máquina gestionada por operadores para tareas de mantenimiento. Para utilizar suscriptores, es necesario habilitar el servicio de Recopilación de Eventos de Windows. Los suscriptores permiten  recuperar registros de maquinas, indicando el filtro de eventos y las cuentas que serán utilizadas para la recuperación de la información.

El sistema de gestión de eventos cuenta con el antiguo sistema de registro de Windows, aunque significativa han cambiado la identificación y los tipos de eventos que se generan, separado los eventos relativos a instalación.

Uno de los problemas a los que se pueden enfrentar los usuarios a la hora de migrar su Windows XP a Windows Vista o bien instalar una versión completamente nueva sobre una máquina antigua,  es la problemática de la compatibilidad de sus aplicaciones, los requisitos para la correcta instalación y si el Hardware y Drivers que contiene la máquina será compatible con la versión de Windows Vista que queremos instalar.

 

Para ayudar con este problema, Microsoft proporciona una herramienta: Windows Vista Upgrade Advisor, desde la cual nos generará un informe de incidencias para la migración e instalación y nos permitirá ver cual de las versiones de Windows Vista existentes se adaptará mejor a nuestras necesidades y a nuestra máquina.

  Fig.- Asistente analizando el sistema. 

La herramienta una vez instalada realizará a través de un sencillo asistente unas comprobaciones del sistema, donde nos dirá los problemas que podemos encontrarnos en caso de querer realizar la migración. Diferencia entre los siguientes elementos:

–         Sistema.

–         Dispositivos.

–         Aplicaciones.

 

 

 Fig.- Necesidades de revisión del sistema

 

 

Dentro de las características importantes que nos reportará la herramienta, será la de compatibilidad de drivers o pérdida de funcionalidades con el existente, que pueden requerir una actualización de los mismos, aquellas aplicaciones que pueden perder funcionalidad o simplemente sean incompatibles. Esta visión nos permitirá decidir si nos conviene realizar la instalación o si existen versiones de esas aplicaciones que puedan ser compatibles con Windows Vista.

   

Para finalizar la aplicación nos mostrará una serie de tareas que deben llevarse, bien sobre la máquina o de preparación de Drivers y aplicaciones, antes de efectuar la migración o instalación del sistema.

 Fig.- Detalle de Listas de Tareas a efectuar previas a la instalación. 

Windows Vista Upgrade Advisor, también nos comentará las características de cada una de las funcionalidades que contienen las diferentes versiones del Sistema Operativo para que conozcamos cual pueden encajar mejor en nuestro perfil y uso que queramos dar a las diferentes herramientas.

 

Fig.- Detalle de versiones y características.

        Hace tiempo inicie una serie de post relativos a Bitlocker, donde se habla entre otras cosas de la importancia del cifrado de datos, la funcionalidad del algoritmo de cifrado de Bitlocker y las operativas y limitaciones que aportaban Bitlocker.

        Pues con la salida del Service Pack 1 de Windows Vista  aparecen funcionalidades adicionales con Bitlocker que supueran algunas de las limitaciones que inicialmente tenía restringido el uso de Bitlocker. Entre las nuevas características aportados por Windows Vista SP1 podemos destacar aquellas enfocadas a Bitlocker:

–          Implementación de cifrado para cualquier partición de la Máquina además de la partición de sistema, que era la única que originalmente podría cifrarse. Evidentemente esto planteaba un problema inicial de uso para bitlocker, puesto que muchas empresa generan dos particiones, siendo una para el sistema operativo y otra para datos y significativamente no podía establecerse cifrado de la partición de datos con el sistema operativo previo al SP1.

Como limitación nos encontramos que no podremos habilitar el cifrado de las unidades adicionales de sistema hasta que no hayamos cifrado esta.

 

Fig.- Selección de Unidades para cifrado. Se puede activar Bitlocker en la Partición F: cuando esté activado Biltlocker en la partición C:

 

–          Se han aumentado los factores de autentificación para Bitlocker, permitiendo el uso combinado del Chip TPM, con una clave almacenada en USB y un Pin de acceso. Esto genera la ventaja adicional de múltiples factores de autentificación que permiten la combinación de elementos, incluida la posibilidad de utilizar USB a la vez que un Pin de acceso. Poco a poco además se han incrementado el número de Placas Bases que cuentan con el Chip TPM, lo que facilita la implementación de Bitlocker, evitando la necesidad de depender de un dispositivo USB que pudiera fallar o estamos obligados, por motivos obvios de seguridad,  a llevarso físicamente separdo, del lugar donde tengamos o desplacemos el equipo sujeto al cifrado

        Para todos aquellos que hayan intentado la implantación de Service Pack 1 con Bitlocker implementado, se habrán podido encontrar con fallos en la instalación que sesolucionan mediante la implementación de una actualización del sistema. La información relativa a solucionar el problema lo podéis encontrar  a través del KB-935509

 

Continuamos con la serie de análisis del comportamiento de Windows Vista con diferentes tipos de Malware, y en esta circunstancia analizaremos las acciones con un troyano de tipo reverso. Este tipo de troyanos al contrario que los convencionales no abren un puerto en nuestros sistemas, sino que lo que intentan es establecer una conexión contra la máquina del atacante, manteniendo esta conexión, el atacante puede pasar las órdenes al proceso que estará en la máquina víctima. Este tipo de aplicaciones plantea muchas problemáticas para el afectado, puesto que el Router de tipo ADSL (o arquitectura similar), Proxy o Firewall de entrada no proporciona la capacidad por ellos mismos de constituir un tipo de barrera contra la acción perniciosa de este tipo de herramientas.

Para el análisis de este escenario contaremos con la ayuda de Turkojan Version 4 como troyano reverso y Windows Vista como víctima.

Fig.- Turkojan 4. 

El primer objetivo será evaluar el comportamiento que proporcionará la ejecución de la aplicación generada (cliente aunque lo definan servidor en todas las aplicaciones troyanos reversos), con el sistema de UAC activo. Ejecutamos la aplicación víctima y esta se ejecuta sin problemas, aunque notamos que no lanza el típico mensaje en pantalla indicando que la aplicación requiere la elevación de privilegios. Aún así comprobamos que la aplicación ha iniciado correctamente la conexión con el atacante, con lo cual ha realizado una de las características nativas de este tipo de Malware para la conexión reversa. Notamos además que el proceso encargado de iniciar la conexión con el atacante está iniciado con nuestra cuenta y a través del administrador de tareas nos muestra la ruta de ejecución del proceso.

 

Fig.- Proceso y aplicación víctima sin icono de UAC. 

 

Puesto que determinadas acciones requiere privilegios administrativos y supuestamente Windows Vista no ha solicitado la elevación de privilegios, es posible que muchas de las funciones del troyano reverso puedan no ser funcionales. La mayor parte de las funcionalidades requieren interaccionar con el sistema, modificar su comportamiento o acceder a determinados drivers para los cuales se requieren esos privilegios efectivos. Para ello vamos a probar alguna de las características fundamentales como la ejecución de la Shell Remota. Con la ejecución de la Shell, intentaremos la ejecución de alguna acción que requiere ser administrador para su ejecución, para ello intentaremos crer un usuario local que requiere obviamente unos privilegios administrativos, que en principio si tiene la cuenta pero que no debiera haber proporcionado el control del UAC.

Cuando intentamos ejecutar el comando advertimos que no tenemos el derecho necesario para la acción implementada.

 

Fig.- Shell Turkojan

Bueno pues parece que el UAC está haciendo su papel, bien advertirnos o no permitir la ejecución de cualquier aplicación con privilegios independientemente de las cuenta con la que estemos trabajando. Eso sí cuidado con utilizar la cuenta predeterminada del Administrador que por defecto no implementa UAC.

Para el siguiente post evaluaremos que hubiera pasado si hubiéramos forzado la ejecución de la aplicación con privilegios administrativos.

 

Dentro del análisis de Malware que estamos recorriendo y antes de meternos en el análisis de los nuevos elementos maliciosos que están surgiendo, vamos a evaluar el comportamiento de los Troyanos de toda la vida. Aunque evidentemente los podemos considerar como una tecnología en desuso con respecto a otros, no por ello han desaparecido totalmente y por lo tanto veremos la respuesta de nuestro Windows Vista y la forma de detección de los mismos.

 

Para la prueba utilizaremos como juguetito el “DuckToy”. Este elemento presenta el típico comportamiento de los Troyanos de toda la vida en el que el proceso de infección, pasa por copiarse a nuestro sistema, abrir un puerto de escucha para las peticiones del atacante y realizar cambios en el registro para que el proceso se active en la carga de la sesión del usuario. En esta circunstancia el proceso se cargará con el nombre “Explorer.exe”. Para este tipo de comportamiento tendremos en cuenta una serie de los elementos incorporados por Windows Vista: UAC, Firewall y Windows Defender.

 

La ejecución del Troyano requiere del uso del privilegio del Administrador, por lo que lo ejecutamos con elevación de Privilegios. El primer resultado visible nos lo alerta el Firewall, indicándonos que una aplicación Server está intentado abrir una nueva conexión en la máquina, cosa que aún así permitimos para evaluar la siguiente barrera de defensa: Windows Defender.

 

Fig. 1.- Detección amenaza

El sistema de Windows Defender aunque no constituye en sí misma una herramienta Antivirus en esencia si es capaz de detectar determinado software malicioso. En esta circunstancia detecta la firma del DuckToy como una aplicación de Acceso Remoto. El sistema detecta además un cambio en el comportamiento de ejecución de aplicaciones.

 

 

Fig. 2.- Análisis de la traza

 

El explorador de Software que incorpora Windows Vista nos ofrece la información necesaria para detectar la ruta de ejecución de la aplicación y la forma de arranque de la aplicación desde el registro del sistema.

 

Fig. 3.- Explorador de Software

Si analizamos el historial de Windows Defender encontraremos las trazas del elemento malicioso detectado, así como las medidas que hemos aplicado para cada circunstancia. Para un análisis de amenazas y comprobar si es detectado por las herramientas antimalware de Microsoft os recomiendo la página de Security Intelligent Report, donde nos detallan el tipo de amenaza al que nos enfrentamos y desde cuando se detecta esta amenaza, entre otras posibilidades.

Tal y como comenté en el anterior post de Malware y Windows Vista, hoy procederemos a realizar un análisis sobre un rootkit de Kernell más agresivo con las librerías, que el Hacker Defender y comprobar el comportamiento de Windows Vista con el mismo. En Windows XP modificaba el comportamiento de las librerías dependientes de Rundll32 y colgándose del QueryInformation del sistema, impidiendo incluso posteriormente el acceso al administrador de tareas.

 

A diferencia con el anterior, el AFX-Rootkit no presenta un dichero de configuración sino que mediante una herramienta para la construcción del malware ya implementaremos los objetivos iniciales del ataque. Por un lado presenta la ventaja de que solo genera un ejecutable y no el fichero ini de configuración, pero por otra parte lo hace menos flexible al no permitir una configuración posterior de las operaciones del mismo.

 

En una primera instancia procederemos a crear un Rootkit que tenga como objetivo ocultar todos aquellos ficheros y carpetas que contengan la palabra “oculto”. Posteriormente procederemos a intentar su instalación con un usuario con privilegios de administrador. Para este procedimiento dejaremos Windows Vista como viene de serie con la configuración del UAC activa y Windows Defender también activo.

  Fig. 1.- Creación del Rootkit 

 

Una vez generado lo copiamos a una carpeta llamada oculta generada en el escritorio que contiene un fichero llamado “fichero oculto.txt”

 

Procedemos inicialmente a ejecutarlo sin elevar nuestros privilegios, pero no se observa ningún cambio, modificación de dll o ejecución de servicios y procesos. Ante esta ejecución infructuosa procederemos a elevar los privilegios.

 

Puesto que no proviene de un editor de confianza el UAC nos advierte de cambios que pudieran perjudicar a la máquina. Aún así procedemos a permitir la ejecución del programa.

 

El primer hecho descriptivo consiste en la desestabilización del escritorio que debe volver a ejecutarse, y que en 30 segundo vuelve a reiniciarse sin un aparente cambio significativo evidente, aunque lo comprobaremos.

 

Fig. 2.- Ejecución del Rootkit en modo Administrador.  

La primera comprobación consiste en determinar si se ha producido la ocultación, cosa que no se ha realizado, con lo cual seguramente no ha podido modificar las librerías del Kernell. La siguiente evidencia es que no ha podido bloquear ni el administrador de tareas, ni ha podido ejecutar el servicio correspondiente.

 

¿A que se debe la ineficacia de este Rootkit frente a su ejecución en Windows XP? Pues la respuesta es bastante clara, la nueva estructuración de capas y servicios de Windows Vista, con respecto a las capas presentes en Windows XP.

 

Fig. 3.- Estructura de capas de Windows Vista

 

Para las siguientes pruebas pasaremos a evaluar el comportamiento de Troyanos y Troyanos reversos y las respuestas ofrecidas por Windows Vista.

Referencias Externas

—————————————————–

AFX Rootkit

Ejecución de Servicios en Windows Vista

 

 

  Para esta nueva campaña de Hand On Lab que comienza en Enero hemos incorporado una nueva serie de laboratorios y componentes que han sido demandados por los asistentes de anteriores ediciones. Uno de los temas que más ha preocupado en general, ha sido todo aquello lo tocante en aspectos legales que pudieran afectar a todo el entorno IT, y del que desgraciadamente se desconoce bastante pero que nos influye significativamente.

    Ya iniciamos una andadura en este campo, con los Hand On Lab basados en la LOPD, con una gran aceptación y que llevados tanto a sus aspectos legales como su posible aplicación técnica en entornos Windows, han conseguido llegar esta normativa a informáticos, estableciendo esa vinculación técnica-legal necesaria. Evidentemente y ante la acogida recibida entre el personal IT y la demanda para la ampliación de la misma a otras Leyes, Reglamentos e Instrucciones existentes, lanzamos un nuevo HOL con duración de 30 horas con el nombre de LEGALIZ@IT y que recoge estas demandas en un escenario nuevamente técnico-legal.

    En este nuevo laboratorio nos vamos a encontrar además de la LOPD visto desde nuevos escenarios y con la base de aplicación del nuevo Reglamente de Seguridad, que amplía y ofrece una nueva perspectiva a los HOL sobre LOPD impartidos anteriormente, normativas sobre el Código Penal referente a los delitos informáticos, Ley de Acceso electrónico, Ley de Propiedad, LSSI, los reglamentos correspondientes a estas leyes y otras normativas tales como la PCI-DSS y la ISO 27000. Además de los aspectos legales, se realizarán laboratorios con resolución de escenarios planteables para las normativas en vigor, basados en arquitecturas y productos de Microsoft.

La fecha de impartición del Hand On Lab LIT-01 Legaliz@IT será del 4 al 8 de Febrero en horario 8:30-14:30

Si quieres más información de la campaña puedes obtenerla a través de la web: http://www.microsoft.com/spain/seminarios/hol.mspx 

¿Qué tal? Antes de iniciar esta serie sobre
redes WiFi y Windows Vista es de recibo que sepamos de qué estamos hablando. En
un breve pero intenso articulo haremos un repaso a como ha ido evolucionando la
seguridad de las redes inalámbricas y como podemos protegerlas ante los ataques
externos.

Al principio el IEEE diseño un estándar para
comunicaciones WiFi al que nombro 802.11. Para hacerlo tan seguro «como una conexión por cable»
desarrollaron un protocolo de autentificación al que llamaron WEP (Wired Equivalent
Privacy) y que al principio pareció funcionar bien, pero claro, solo al
principio…

WEP usa un sistema de cifrado de tipo RC4,
con claves de 40 o 104 bits, que sumados a los 24 bits del vector de
inicialización (IV) dan unas longitudes de clave de 64 o 128 bits. Esto en los
años en los que se publico la especificación (1997) y con el hardware
disponible en aquella época, era considerado seguro, pero en la actualizad, y
usando técnicas para intensificar el envío de paquetes en la red, es posible
crackear una de estas claves en menos de 15 minutos, aunque con técnicas
recientes se ha conseguido reducir este tiempo a solamente 60 segundos. Es por
eso que no vamos a dedicarle mucho más tiempo al tema de la encriptación
mediante WEP, considerándola insegura, insuficiente y desfasada en comparación
con las actuales técnicas de encriptación como son WPA y WPA2.

Cuando la industria de fabricantes de
dispositivos WiFi se dio cuenta de los riesgos que presentaba para sus clientes
la debilidad de WEP se puso en marcha para desarrollar un sistema de
encriptación que permitiese asegurar las comunicaciones. Bajo el auspicio de la
Wi-Fi Alliance, que agrupa a empresas tan importantes como Cisco, AT&T o HP,
se desarrollo un nuevo sistema de seguridad al que llamaron WPA (Wi-Fi
Protected Access) que lanzaron en el 2003, adelantándose en un año al IEEE
802.11i (o WPA2).

¿Qué ventajas trae este nuevo protocolo de
encriptación frente a WEP? Pues para empezar nos proporciona dos maneras
distintas de autenticarnos, la primera como en WEP, con una clave compartida,
la segunda, contra un servidor de autentificación IEEE 802.1X, con encriptación
basada en EAP o, mediante un servidor RADIUS, con EAP-TLS.

En el caso de la autenticación por clave
compartida (o WPA-Personal), aunque siguen
haciendo uso del cifrado RC4 (con clave de 128 bits y IVs de 48 bits), se usa
un sistema de TKIP (Temporal Key Integrity Protocol) que nos permite asegurar
nuestra red de una forma mucho mas consistente, haciendo que cada paquete
enviado vaya encriptado de forma única. Por otro lado, la autenticación contra
el servidor de autenticación IEEE802.1X (WPA-Enterprise),
nos proporciona una clave única para cada usuario, haciendo más difícil si cabe
el crackeo de la red.

¿Y que diferencia hay con la WPA2? Pues
básicamente dos. La primera es que se modifica el sistema de protección de TKIP
por otro aun mas seguro, el CCMP, basado en el algoritmo de encriptación AES.
La segunda y no menos importante es que este ya si es un estándar de la IEEE y
que la Wi-Fi Alliance marca como requisito indispensable para los nuevos
dispositivos inalámbricos para lograr el reconocimiento de Wi-Fi Certified, con
lo que eso nos garantiza para una red de mediana o gran empresa.

Bueno, todo esto esta muy bien, pero ¿como
nos afecta esto a la red esa que queremos montar en nuestra empresa y por la
que van a viajar datos confidenciales de clientes? La respuesta es simple. Para
empezar hay que descartar de raíz la autentificación WEP, es insegura por
definición y no debe de ser usada en ningún tipo de entorno. Luego llegamos a
la disyuntiva entre WPA y WPA2. En este caso, aunque la diferencia no es tan
abismal como cuando hablamos de WEP, debemos decantarnos por WPA2 en la medida
de lo posible, pues la encriptación de los paquetes ofrece mayor seguridad.
Para terminar, la elección entre Personal o Enterprise va a venir definida por
el número de personas que se conectaran a nuestra red. En el caso de una red
domestica o una pequeña empresa, con una clave compartida no bastara, pero si
tenemos un gran grupo de usuarios con necesidad de conectarse a nuestra red lo
mejor será decantarse por un servidor RADIUS de autenticación y configurar los
ordenadores clientes para conectarse usando este.

Todas estas tecnologías vienen soportadas de base
por Windows Vista y en el próximo artículo veremos como configurar nuestro
ordenador para que se conecte a una red con autenticación WPA2-Enterprise.

¡Un saludo y hasta pronto!
 

Referencias Externas 

 —————————————————————-

 

Wifi

 

WPA Enterprise

 

Tras haber analizado el intento de ejecución del Rootkit Hacker Defender con un usuario administrador y el UAC habilitado y haber sido infructuoso, vamos a proceder a realizar el ataque haciendo uso de los privilegios de Administrador.

Para realizar un rastreo al comportamiento del Rootkit evaluaremos 5 componentes básicos de este tipo de malware:

                – Ocultación de ficheros y carpetas.

                – Ocultación de procesos y servicios.

                – Ocultación de Puertos.

                – Ocultación de aplicaciones.

                – Componente troyano con tecnología de redirector.

Partimos de la base de que tenemos tanto el fichero de ejecución del rootkit como su fichero de configuración se encuentran en el escritorio de usuario y lo ejecutamos con privilegios de administrador.

Imagen 1- Ejecutando HXDEF100 y comprobando puertos

Inicialmente no detectamos ningún comportamiento anómalo típico, como la desaparición automática de los ficheros hxdef100, ¿ha fallado o es un comportamiento anómalo? Pasamos a realizar las comprobaciones de rigor: no aparece el proceso, ni el servicio, los puertos no han desaparecido aunque desde el fichero de configuración se solicitaba la ocultación de los puertos TCP 135 y 445, el troyano con tecnología de redirector no es funcional, pero ¡curiosamente aunque nuestra aplicación de referencia: la calculadora, se ejecuta sin problema, el icono ha desaparecido!

Imagen 2 – Comprobando proceso ocultacion de aplicaciones.

Bueno estos último nos deja una única funcionalidad: el rootkit se ha ejecutado con eficacia, aunque sus comportamientos para enlazar mediante Hooks las aplicaciones y procesos a engañar no han sido fructuosas, el tratamiento del modelo de UIPI y MIC ha funcionado correctamente.

Aún así  como no me deja tranquilo las pruebas, vamos a poner a Windows Vista en más aprietos. Como uno de los comportamientos a esperar es la ocultación de las carpetas, vamos a crear una carpeta con el mismo nombre el ejecutable (hxdef100) y movemos los ficheros hxdef100.exe y hxdef100.ini a la carpeta. ¡Oh sorpresa! Los ficheros desaparecen, pero no la carpeta. Pues vamos a comprobar el proceso y este aparece en el administrador de proceso, aunque no queda oculto, tampoco cambia el comportamiento con respecto a los puertos ni a la calculadora.

¿Porque se ha producido este comportamiento? Se ha producido una posible manipulación en la devolución de datos en el proceso explorer.exe, que se está ejecutando en la capa del administrador, aunque no se ha podido incidir sobre otros procesos restringidos, ni en el Kernell del sistema. Tal y como esperaba, el hecho de reiniciar el Sistema, lleva consigo que el servicio que controla y ejecuta el proceso HXDEF100, no puede levantarse puesto que no encuentra el fichero para la ejecución del servicio.

 

El resultado final de las pruebas realizadas nos devuelven los siguientes resultados:

–          El comportamiento del Rootkit no ofrece la misma funcionalidad que en un Windows XP o en un Windows 2003.

–          Hemos tenido que forzar por predicción de comportamiento la ejecución y el proceso de acción del Rootkit.

–          Se revela bajo el procedimiento convencional que existe un proceso anómalo en ejecución.

–          Las funcionalidades para la ocultación de aplicaciones y puertos no ha resultado efectiva.

–          El comportamiento del troyano en tecnología de redirector ha fallado, no devolviendo ninguna Shell de ejecución.

Pues como este laboratorio no me ha dejado satisfecho, para el siguiente, un Rootkit un poco más puñetero. Seguiremos probando a Windows Vista…

Referencias Externas

 

 —————————————————————-

 

Rootkit 

 

UIPI y MIC

Comenzamos un nuevo ciclo de post
y para ello vamos a analizar el comportamiento de Windows Vista con diferentes
funciones de Malware, y para ello contaremos con la ayuda inestimable de un
Windows Vista Ultimate y unos amiguitos de lo ajeno, más o menos reciente que
nos permitirán estudiar el comportamiento del nuevo sistema operativo de
Microsoft, con antiguos y nuevos amigos.

Para el estudio contaremos con
todos los mecanismos de defensa con los que cuenta Windows Vista y que en
función de las características se irán activando o desactivando comprobando
todas las características y las circunstancias en cada uno de las pruebas que
se realicen.

Cada post será un laboratorio
donde se analizará algunos de estos elementos y se evaluarán las diferentes
opciones de seguridad que aporta Windows Vista al laboratorio. Estableceremos
el laboratorio desde la perspectiva de usuario avanzado y usuario básico,
teniendo en cuenta los esquemas básicos de seguridad como son el uso del UAC,
pero analizaremos también los comportamientos en caso de que estos hayan sido
deshabilitados.

Para los laboratorios contaremos
con la ayuda inestimable de Rootkits, troyanos, troyanos reversos, keyloggers,
virus, gusanos, etc.

Para el primer laboratorio
contaremos con un elemento Rootkits que conoceréis muchos de vosotros:
Hackerdefender. Este Rootkit de tipo Kernell empezó a hacer sus pinitos allá
por el 2004 y ha sido uno de los elementos más extendidos y del cual se han
hecho algunas modificaciones.

Básicamente el objetivo es
realizar la ocultación de ficheros y carpetas, elementos del registro y
procesos y servicios. Engañaba con el espacio de disco existente en el sistema
y oculta puertos localmente. Utiliza tecnología de redirector de puerto que
junto con la funcionalidad de troyano, nos devuelve una Shell por cualquiera de
los puertos que tengamos abiertos. En fin toda una pieza, compuesto por dos
ficheros: el ejecutable y el fichero de configuración en un fichero ini.

Partimos de la base que el
susodicho elemento necesita privilegios de administrador para poder ejecutarse,
con lo que a priori puede encontrar el primer hándicap cuando se ejecute con el
UAC activo y funcional.

Para la primera prueba vamos a
contar con un usuario perteneciente al grupo de administradores (no el
administrador) y que será el que lance el ejecutable. Por comparativa cuando se
ejecutaba en Windows XP con un usuario con privilegios el Rootkit iniciaba todo
el proceso malicioso para el que estaba configurado el fichero de
configuración. En el caso de Windows Vista, la ejecución del mismo no comporta
ninguna acción: el Rootkit no ha funcionado. ¡Vaya! la estructuración en capas
de Windows Vista ha hecho su función y ha impedido que este usuario pueda
llegar a ejecutar los drivers a nivel de Kernell, eso sí no ha intervenido el
UAC. En este caso concreto el sistema tiene habilitado la función de UAC para
que solicite credenciales y no se ha activado. En principio no hay ningún
resultado significativo que evidencie el intento de acción que se ha empleado.
El análisis a nivel de ficheros demuestra los intentos de acceso a las
librerías shell32 son infructuosos y no puede cargar el driver: hxdefdrv, a
nivel de sistema, lo que impide que su acción sea consecuente. La ejecución por
lo tanto en un contexto no privilegiado no es satisfactorio.

 

 

En el siguiente post analizaremos
el comportamiento de este mismo rootkit en un contexto privilegiado y en el
contexto del administrador.

 

 

Referencias Externas

 

 —————————————————————-

 

Rootkit 

 

Hacker Defender 

 

Filemon