miércoles, 28 de septiembre de 2011

Módulo prefetchtool de Metasploit


Para aquellos que no lo sepáis, cada vez que se ejecuta un programa en Windows se guarda en un fichero .pf información relativa al mismo, uso de las aplicaciones, librerías y ficheros que utilizan, etc, toda esta información se guarda con la finalidad de optimizar los tiempos de carga al arrancar el Sistema Operativo.

Son archivos muy útiles a la hora de realizar un análisis forense en un equipo ya que permiten saber los últimos programas que se han ejecutado, así como trazar un “patrón de uso” realizando las mediciones de uso de cada programa.

Desde el punto de vista del atacante, nos puede ser muy útil a la hora de saber para qué se suele utilizar la máquina comprometida, basándonos claro está en la frecuencia de uso de los programas, así como la posibilidad de descargar los ficheros de prefetching (alojados en %%windir%%\Prefetch) y “parsearlos” en busca de cadenas de texto útiles (por ejemplo, con el binario “strings” de Linux) como puedan ser los últimos ficheros abiertos por el Word o el Excel, etc, etc.

Para obtener información de un rápido vistazo a partir de la carpeta de prefetching, Metasploit cuenta con un módulo de meterpreter para ello.

Ayuda del módulo prefetchtool

Tal y como vemos en la ayuda, disponemos distintas opciones:
  • Parsear todos los ficheros de prefetching buscando en Internet el nombre del software (-i) – Para ello utiliza http://www.liutilities.com/products/wintaskspro/processlibrary/ y http://www.processlibrary.com/
  • Descargar un log del análisis de la carpeta de prefetching (-l)
  • Listar los programas instalados (-p) – Si vemos el código veremos que lo obtiene de la entrada del registro “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall”
  • Listar los X programas más utilizados (-x)
 
Lo primero que hará el módulo será descargar la última versión de la herramienta para Windows “prefetch-tool”, aunque aquí os dará un error debido a la forma en la que parsea el checksum de la web para comprobar si tenemos la última versión. El cambio que hay que hacer en el código es realmente simple y lo he enviado para que lo apliquen al SVN (al momento de acabar esta entrada ya ha sido aplicado :) ). Una vez realizado dicho cambio el módulo funcionará perfectamente.

Si nosotros ejecutamos el módulo sin ningún tipo de comando nos analizará la carpeta de prefetching entera:

Descarga de la herramienta desde Internet
 
Como vemos, primero descarga la última versión que exista de la herramienta y la sube al equipo comprometido, después muestra toda la información obtenida.

Análisis de la carpeta de prefetching

 
Por ejemplo, si le decimos que nos muestre el TOP 5 de programas más utilizados, obtendremos algo parecido a lo siguiente:

meterpreter > run prefetchtool -x 5

Top de programas utilizados

Una vez que hayamos visto la lista de software instalado, y las frecuencias de uso de cada programa, podremos hacernos una idea de la utilidad de la máquina, etc.
En este caso, los programas más utilizados son cmd.exe, minishare.exe, ipconfig.exe, python.exe y vulnserver.exe, se trata de una de las máquinas que utilizo para trastear temas de exploiting...

Por último, y antes de cerrar el post, comentar que existe una herramienta para Windows llamada WinPrefetchView que nos permite visualizar los ficheros de prefetching, por defecto utilizará la carpeta %%windir%%\Prefetch, pero le podemos indicar otra ruta (por ejemplo, en la que tengamos los ficheros de prefetching descargados ;) )

Vista de prefetching con WinPrefethView


Un saludo a todos y nos vemos en el siguiente post!





domingo, 25 de septiembre de 2011

FTP Bounce o ¿Por qué el servidor FTP está escaneando la red?


Buenas a todos, una vez más traigo una de esas entradas de las que me gustan a mí... de las que consisten en darle una vuelta de tuerca a algún asunto y darle un uso que no es para el que fue diseñado.
En este caso es una técnica algo antigua pero que, a veces, uno tiene la suerte de encontrarse un host que permita emplearla.

Antes de nada, voy a explicar en qué se basa; Dentro del protocolo FTP existen dos maneras de llevar a cabo la sesión, el modo activo y el modo pasivo.

En el modo activo, el cliente se conecta al servidor FTP en su puerto 21 (usado como canal de órdenes), deja un puerto a la escucha (normalmente N+1, siendo N el puerto de origen en la conexión hacia el puerto 21 del servidor) y le indica al servidor FTP el puerto al que ha de conectarse desde su puerto de transmisión de datos, el 20. Para indicar dicho puerto se utiliza el comando PORT, por ejemplo: PORT 192,168,1,1,12,234 , con esto, estamos indicándole al servidor que la transferencia de ficheros se va a recibir en la dirección IP 192.168.1.1 en el puerto 3306. Aquí aclarar una cosa respecto a la forma en la que se indica el puerto, si os fijáis son dos valores (12,234 en este caso), lo que hay que hacer es coger por separado cada número y pasarlo a hexadecimal:
12 = 0x0C
234 = 0xEA
Ahora los juntamos y obtenemos 0x0CEA, si dicho número lo pasamos a decimal obtendremos que el puerto de conexión destino es el 3306.
Comentar que existe una manera más fácil de calcular lo mismo, consiste en multiplicar el primer número por 256 y sumar el resultado al segundo número: (12*256) + 234 = 3306. Lo sé, podría haberlo explicado antes, pero nunca esta de más saber varias formas de hacer lo mismo :P.

Por otro lado, en el modo pasivo, el cliente inicia la conexión como siempre al puerto 20 del servidor FTP y, en lugar de utilizar el comando PORT, utiliza el comando PASV para indicarle al servidor FTP que se va a utilizar el modo pasivo y solicitar el puerto al que conectarse para establecer el canal de datos, en ese momento el servidor FTP dejará a la escucha un puerto alto (no privilegiado) aleatorio y responderá al cliente con una respuesta con el mismo formato que el comando PORT, finalmente, el cliente conectará al puerto indicado por el servidor y ya existirá el canal de datos y el canal de comandos.

Ya hemos visto cómo funcionan ambos modos de conexión, así que pasaremos a ver el mencionado ataque “FTP Bounce”. Como acabamos de ver, el cliente le indica al servidor el host y el puerto al que conectarse para establecer la comunicación, tal y como se establece en el RFC959 – File Transfer Protocol (FTP), se puede utilizar el comando PORT para conectar con un tercer host para que reciba los datos. Si le damos una vuelta a esto, veremos que podemos utilizarlo para escanear equipos, si no puede establecer el “canal de datos”, quiere decir que el puerto está cerrado, en caso contrario, el puerto estará abierto.

Para poder llevar a cabo este escaneo tenemos que encontrar un servidor FTP que permita el comando PORT y del que contemos con usuario y contraseña (o que permita conexiones anónimas).
Si queréis poner Nmap a buscar, podéis intentarlo con el siguiente comando:
root@ph0b0s:~/nmap-svn# ./nmap -sS -p 21 -Pn -n --min-hostgroup 500 -oA /tmp/ftpopen-bounce -v -iR 100000 --script ftp-bounce (el script ftp-bounce permite probar si un servidor FTP se puede utilizar par realizar un escaneo de tipo bounce)

Podéis ir monitorizando el fichero de salida con un tail -f y, en el momento que veáis el texto “ftp-bounce: bounce working!” sabréis que habéis encontrado un servidor FTP que podéis usar para realizar este tipo de escaneo.

A continuación, pongo una imagen del proceso de “escaneo” realizado de forma manual.

Comando PORT realizado de forma manual

El primer PORT es el correspondiente al puerto 3306 (recordemos, (12*256) + 234 = 3306) a una de las direcciones IP de google, como vemos, la respuesta al LIST indica que no se ha podido establecer la conexión de datos, por lo que el puerto está cerrado o filtrado.
El siguiente PORT es a la misma dirección IP pero al puerto 80, como podemos observar, al hacer el comando LIST no se nos devuelve el error, lo que indica que se ha podido establecer correctamente la conexión, sabiendo así que el puerto está abierto.

Hacer este proceso a mano es bastante tedioso, por lo que podríamos hacernos una herramienta para ello basada en sockets bastante sencillita de hacer (ya tenemos algo que hacer para cuando no sepamos con qué trastear :P) o utilizar para ello el propio Nmap.

Para ello, bastaría con utilizar el siguiente comando: root@ph0b0s:~/nmap-svn# ./nmap -b XXX.XXX.XXX.11 -Pn -n -p80,3306 www.google.es -v (importante recordar que con -Pn evitamos que se realice ningún tipo de ping anterior al escaneo y con -n indicamos que no se relice ningún tipo de resolución DNS, para no enviar tráfico relacionado con las máquinas que van a ser escaneadas).

Escaneo "FTP bounce" realizado con Nmap

Tal y como vemos en la imagen anterior los resultados son los mismos que obtuvimos de forma manual, el puerto 80 abierto y el 3306 filtrado.

En este caso hemos escaneado un host accesible desde Internet, pero si el servidor FTP tiene acceso a direccionamiento IP interno, podemos utilizarlo para realizar escaneos de red a rangos de red internos desde Internet, puesto que realmente es el propio servidor FTP el que se conecta a dichas direcciones IP internas y no nosotros.

Por último, seguro que os estáis preguntando si esto se sigue viendo.... la verdad es que yo en auditoría externa lo he visto sólo una vez, pero basta con realizar escaneos aleatorios para encontrarse con host que permiten este tipo de escaneo. Otra cosa es en auditorías internas, puesto que suele ser común encontrar servidores FTP que permiten el comando PORT implementados en impresoras, así que ya sabéis, si un día veis que la impresora está haciendo conexiones raras....

Espero que os haya resultado interesante, nos vemos en el siguiente post.



viernes, 23 de septiembre de 2011

Enumeración de direccionamiento IP mediante NTP


El protocolo NTP (Network Time Protocol) está diseñado para permitir sincronizar los relojes de los distintos dispositivos de red mediante su uso. Utiliza el protocolo de transporte UDP y el puerto 123.

Entre las distintas consultas que se pueden realizar a un servidor NTP tenemos la consulta monlist, pensada como herramienta de diagnóstico y que nos proporciona información de las últimas 600 direcciones IP que consultaron al servidor NTP.
Desde el punto de vista del atacante, o a la hora de hacer un pentest, podemos aprovecharnos de dicho comportamiento para realizar una enumeración de direcciones de red y obtener direcciones IP de los equipos de la empresa, internos o externos, que utilicen dicho servidor NTP.

Antes de empezar a realizar las pruebas conviene tener en mente que, en el caso por ejemplo de 0.europe.pool.ntp.org, detrás de dicho nombre de host existen varias direcciones IP y que, dependiendo de la que resuelva cuando uséis los programas, tendrán o no activada dicha consulta.

Entradas A para 0.europe.pool.ntp.org
Para realizar dicha enumeración disponemos de distintos métodos, el primero de ellos es utilizar el cliente ntp de linux “ntpdc”, tal y como vemos en la siguiente imagen (si da un error de timeout hay que repetir la petición).

Consulta monlist mediante ntpdc
También podemos utilizar el módulo de metasploit auxiliary/scanner/ntp/ntp_monlist para ello, aunque a mí me da algunos problemas y me muestra basura al final...

Nmap tiene también un script para realizar esto, ntp-monlist.nse , el cual presenta la ventaja de separarnos los clientes con direccionamiento público de aquellos que utilicen direccionamiento privado.

Script ntp-monlist de Nmap
La última herramienta que voy a comentar es de sensepost y se llama ntp_monlist.py que, además de realizar dicha consulta, nos genera también un fichero para maltego.
Para ejecutarlo basta con hacer lo siguiente: z0mbiehunt3r@ph0b0s:/$ ./ntp_monlist.py 0.europe.pool.ntp.org y luego comprobar el fichero NTP.txt.

Resultados obtenidos por ntp_monlist.py
Comentar también que HD Moore, quien hizo público este “uso alternativo” del comando monlist, comentó también la posibilidad de utilizar una lista de servidores que permitan realizar dicho comando para realizar un ataque de tipo DdoS ya que, con una única petición, obtenemos múltiples respuestas hasta completar el listado completo de los últimos 600 clientes. Esto, unido al uso de UDP como capa de transporte, hace trivial la falsificación de dirección IP de origen para hacer que un servidor objetivo reciba gran cantidad de respuestas NTP no solicitadas.

Por último, y para aquellos que queráis buscar servidores NTP con los que trastear, deciros que podéis hacerlo fácilmente con Nmap de la siguiente manera:

root@ph0b0s:~/nmap-svn# ./nmap -sU -pU:123 -Pn -n -iR 10000 --reason -v -oA /tmp/ntp-happyhunting –min-hostgroup=500

Con ello, estáis diciendo que escanee sólo el puerto UDP 123, que no realice ping primero ni resolución DNS (ahorramos bastante tiempo y ancho de banda), que genere 10000 direcciones IP aleatorias a escanear, que nos muestre el motivo por el cual Nmap establece el estado del puerto, que muestre más información del estado del escaneo, que nos guarde la salida en /tmp/ntp-happyhunting (en tres formatos distintos con sus correspondientes extensiones) y que realice el escaneo de forma paralela con grupos de 500 host.
Una vez acabado sólo tenéis que buscar en los ficheros de salida el texto udp-response que nos indica que ha habido respuesta, lo que significa que el puerto está abierto.
También podéis buscar en los listados de servidores NTP públicos pero, admitámoslo, no es tan divertido.... ;)

Espero que os haya resultado interesante y que os acordéis de ello si algún día estáis haciendo un pentest y os encontráis con un servidor NTP.

Saludos y hasta otra.




miércoles, 21 de septiembre de 2011

pyrasite - Inyectando código en procesos de python


Recientemente me he topado con el proyecto pyrasite el cual está pensado para poder inyectar nuestro propio código python en cualquier proceso en python que se esté corriendo en el sistema.
Obviamente, tal y como veremos un poco más adelante, esto tiene sus propias limitaciones.

Lo primero que haremos será realizar la instalación de todo lo necesario para ejecutar pyrasite y sus módulos

Instalamos pyrasite: root@ph0b0s:~# easy_install pyrasite
Instalamos meliae (para poder utilizar los módulos de dumpeo de procesos): root@ph0b0s:~# apt-get install python-meliae

Ahora necesitaremos un proceso en python para hacer de víctima, he estado probando distintos scripts que utilizo para diversas cosas y funciona bien, pero para no complicarlo, voy a utilizar ahora un ejemplo de código muy sencillo:.

#!/usr/bin/env python
import re
import time
import urllib2
import sys
if __name__ == '__main__':
while 1:
print "En nuestro bucle..."
time.sleep(10)

Ahora, dejamos corriendo el programa: z0mbiehunt3r@ph0b0s:~/workspace/pyrasite-test/src$ ./pyrasite-test.py
Proceso de prueba corriendo


Ahora, necesitamos saber el PID del proceso:

z0mbiehunt3r@ph0b0s:~/workspace/twitter-follow/src$ ps a | grep pyrasite-test
15447 pts/0 S+ 0:00 python ./pyrasite-test.py clear

Una vez que sabemos el PID del proceso podemos proceder a intentar inyectar código en el mismo (nótese que, para evitar problemas de rutas y hacerlo lo más fácil posible, he cambiado de path)


z0mbiehunt3r@ph0b0s:/usr/local/lib/python2.6/dist-packages/pyrasite-1.0-py2.6.egg$ pyrasite 15447 payloads/helloworld.py 

Si lo hacemos así, nos dará el siguiente error:

Error de ptrace


Si nos dirigimos a dicho fichero veremos lo siguiente: 
# A PTRACE scope of "0" is the more permissive mode.  A scope of "1" limits
# PTRACE only to direct child processes
kernel.yama.ptrace_scope = 1

Por lo que, para que pueda hacerse correctamente, tenemos dos opciones, cambiar dicha variable o utilizar el comando sudo para lanzar la inyección de código. En mi caso, voy a hacerlo de la última manera: z0mbiehunt3r@ph0b0s:/usr/local/lib/python2.6/dist-packages/pyrasite-1.0-py2.6.egg$ sudo pyrasite 15447 payloads/helloworld.py

Ahora, si nos vamos a la pantalla del script de prueba, veremos lo siguiente:
Código python inyectado en el proceso

Gracias a pyrasite, podemos inyectar el código que nosotros queramos. Con el propio proyecto se incluyen diversos payloads, para listar módulos, para dumpear la memoria del proceso (y buscar información útil), para forzar el recolector de basuras y, algo bastante graciosillo, para obtener una shell inversa, tal y como vemos en la siguiente imagen:
Shell inversa obtenida mediante inyección de código


Bueno, espero que os haya resultado interesante y que probéis cosillas que se os ocurran, estaré encantado de leerlo si alguien me deja algún comentario.

Un saludo y hasta la próxima!

viernes, 9 de septiembre de 2011

CMS Fingerprinting – III


Continuamos, y de momento acabamos, con el CMS fingerprinting mediante una breve entrada.
Hasta ahora, hemos visto fingerprinting pasivo mediante análisis de cabeceras, cookies, metatags, etc y fingerprinting activo mediante análisis de contenido estático.
En esta ocasión, vamos a ver fingerprinting web de forma totalmente pasiva, simplemente mientras navegamos por la página web.

Existen varias maneras de hacerlo, bajo mi punto de vista, la más efectiva es utilizar el plugin de Firefox / Chrome (en versión beta) WAPPALYZER. Dicho plugin identifica servidores web, frameworks JavaScript, CMS, etc, etc con tan sólo navegar por la página web, tal y como se ve en la siguiente imagen.


Si bien Wappalyzer no es capaz de detectar las versiones exactas, sí que identifica con gran precisión cientos de software y tecnologías distintas, lo que puede proporcionarnos una pista por el camino a seguir a la hora de auditar la página.

Para todos aquellos que estéis interesados en más información acerca del fingerprinting web os dejo algunos recursos:


Un saludo a todos, espero que os haya ayudado lo aquí expuesto (brevemente, eso sí, jeje). Nos vemos en la próxima!