Saltando de VLAN mediante DTP

VLAN es el acrónimo de “Virtual Local Area Network” o red LAN virtual, se utilizan para segmentar una red LAN en varias subredes a nivel lógico con independencia del nivel físico. Con esto se permite conseguir aislar el tráfico de red agrupando distintos grupos de host, por ejemplo, una VLAN por departamento.

Las ventajas que se consiguen con el uso de VLAN son varias, por un lado, se consigue limitar el tráfico de broadcast ya que se utilizan múltiples subredes distintas, por otro, se consigue aumentar en cierta medida la seguridad al segmentar lógicamente unos dispositivos de otros ya que, aunque las VLAN funcionan a nivel dos en la capa OSI, requieren de un dispositivo de nivel tres para poder enrutar entre VLANS puesto que, por norma general, cada VLAN está asociada a una subred distinta.

Para realizar la distinción entre una VLAN y otra, se utiliza, por norma general, el protocolo 802.1Q de etiquetado con la finalidad de indicar que es una trama etiquetada y la VLAN a la que pertenece.

Formato trama 802.1Q

Ahora bien, los switches se han de configurar para indicarle el/las VLAN que se permiten en un puerto físico del mismo, así como ciertas características con respecto a si a dicho puerto físico del switch se conectará un dispositivo final, otro switch por el que fluirán múltiples VLAN, lo que se denomina como un puerto “trunk”, etc.

Los switches de Cisco incorporan un protocolo propietario denominado DTP (Dynamic Trunking Protocol) que se encarga de detectar otro switch Cisco interconectado para establecer automáticamente los puertos de tipo “trunk”.

Esto que puede parecer una gran comodidad puede ser un arma de doble filo ya que, por defecto, los puertos del switch tienen DTP activado en modo “auto”, lo que quiere decir que, si el otro extremo de la conexión lo solicita, se negociará un puerto de tipo “trunk”.

Para que un atacante pueda saltar de VLAN en un escenario así no tiene más que solicitar negociar el enlace “trunk” para poder comunicarse con cualquier otra VLAN, para ello existen diversas maneras, quizá la más sencilla sea usar Yersinia. Aquí un apunte, los que uséis Debian o distros que recurran a sus repositorios comentar que la versión disponible de Yersinia no funciona bien en modo interfaz interactiva (tipo ncurses) por lo que, o compilamos desde fuentes, o utilizamos alguno de los otros métodos de uso de Yersinia.

En este caso, muestro cómo hacer el ataque de negociación de DTP trunk de manera directa:

 

Yersinia negociando un puerto trunk

Si capturamos el tráfico con Wireshark y esperamos a que se negocie el puerto, veremos lo siguiente:

Puerto trunk negociado y primer tráfico broadcast

Como podemos observar, una vez que se ha negociado el puerto trunk, recibimos tráfico ARP de la subred 10.10.10.1 perteneciente a la VLAN 123:

 

802.1Q VLAN Tag

Ahora sólo tenemos que configurar una subinterfaz en la máquina atacante para indicarle que pertenece a una VLAN y los datos de la misma:

Configuración VLAN mediante vconfig

Ya podemos acceder a dicha VLAN, para probarlo, basta con un simple ping:

Salto de VLAN realizado

Con esto ya habríamos conseguido saltar de VLAN y podríamos intentar seguir comprometiendo la red en la que nos encontremos haciendo el pentest.

Existen varias defensas frente a este ataque, la primera de ellas es desactivar DTP, tal y como nos cuenta Jeremy Stretch en su fabuloso blog, la segunda, y si estamos utilizando el protocolo VTP (Virtual Trunking Protocol), es utilizar la característica de “vtp pruning” para evitar que se envíe tráfico de broadcast a switches que no tengan puertos registrados en la VLAN a la que corresponde dicho tráfico de broadcast. La opción más correcta es la primera, puesto que es la única que realmente desactiva la posibilidad de negociar un puerto trunk.

Hasta la próxima!

 

topsearches-hijacker o “inyectando XSS como búsqueda más común”

A la hora de realizar una auditoría web siempre tenemos que andar buscando si cada parámetro que podemos modificar en las peticiones provoca cualquier cambio en el resultado devuelto por el servidor, por poco perceptible que sea.

Es muy común que las páginas web hoy día muestren las búsquedas más realizadas por sus usuarios con la finalidad de proporcionar información que, estadísticamente, será de utilidad para gran parte de los visitantes. Lo que conviene tener en cuenta es que, si nosotros conseguimos alterar las búsquedas más realizadas para incluir la nuestra propia, podremos hacer que se muestre el texto que nosotros queramos en la página principal (siempre teniendo en cuenta posibles filtrados que realicen a los parámetros recibidos).

Para ello, la forma más sencilla de llevarlo a cabo es realizar búsquedas con la inyección XSS que queramos para que se realicen por parte de la aplicación web los correspondientes INSERT en la base de datos para guardar registro de todas las búsquedas realizadas hasta que detectemos que ya aparece nuestro XSS en la página principal.

He realizado un pequeño script en python que realiza justo lo comentado, le indicamos la url que muestra las búsquedas mas realizadas y la expresión regular para parsearlas, le indicamos la url utilizada para realizar las búsquedas “legítimas” y le decimos el “tag” que queremos inyectar.

Por ejemplo:

• URL del buscador: http://localhost/search.php?q=BÚSQUEDA
• URL que muestra las búsquedas más repetidas: http://localhost/show_searches.php
• Expresión regular para detectar dichas búsquedas más repetidas: tags = re.findall("<div class=\"mostsearched\"> (.+) <\/div>", html_response)

Para probarlo he “programado” dos sencillos php, por un lado el php que muestra los resultados más comunes:

Script en php que muestra las búsquedas más típicas

Lo sé, no tengo desperdicio como diseñador web... :p

Por otro lado, está el php que se encarga de guardar la “búsqueda” realizada (no muestra ningún resultado, sólo hace el correspondiente INSERT en la base de datos y lo muestra por pantalla).

Script en php para "buscar" y guardar registro de las búsquedas

Eso sería la parte que correspondería a la página web, algo austera pero funcional ;) .

Ahora bien, para inyectar búsquedas con nuestro XSS he creado un script muy sencillo en python que se encarga de realizar “búsquedas” hasta que detecta que el XSS ha sido inyectado correctamente (por supuesto, hay que recordar que si realizan algún tipo de filtrado el resultado no será el esperado...).

topshearches-hijacker.py en acción

En este caso vemos cómo han sido necesarias 12 peticiones para colocar el tag con el XSS entre los resultados más buscados y que, por tanto, sea mostrado en la principal, logrando un XSS almacenado que podría afectar a un gran número de visitantes.

Para todos aquellos que os apetezca trastear con el script tenéis todo para descargar en https://sites.google.com/site/navegandoentrecolisiones/home/scripts-python.
El script no es nada del otro mundo y necesitará cambios para que funcione en otro entorno, pero lo dejo a modo de PoC y por si le puede servir a alguien...

Nos vemos!

 

Kippo – SSH Honeypot

Si nunca habéis oído el término “honeypot” deciros que es, como su nombre indica, un tarro de miel para un posible atacante. Existen varios tipos de honeypots según el nivel de interacción que brindan, su finalidad, el tipo de servicio/s que emulen, etc.

Básicamente, un honeypot suele ser un sistema que simula ser vulnerable a algun vulnerabilidad, ser un relay de correo abierto, un servidor SSH con credenciales fáciles de adivinar, etc.

En este caso, Kippo es un honeypot de interacción media (no es una consola obtenida por SSH con todas sus posibilidades, pero sí tiene implementados ciertos comandos) escrito en Python y cuya finalidad es guardar un registro de los intentos de acceso al servidor por fuerza bruta y, cuando un atacante se conecte y realice cualquier acción, guardar toda la sesión de comandos y cualquier posible fichero que el atacante descargue en el servidor.

Las ventajas de tener un honeypot, o varios, son diversas. Por un lado, tenemos la posibilidad de detectar que alguien está intentando atacar nuestra red por las alertas del honeypot, además de que se mantendrá “ocupado” al menos hasta que descubra que es un honeypot o cambie de objetivo. Por otro, podemos recopilar multitud de herramienta que los atacantes suben a los servidores SSH comprometidos, así como obtener ciertas estadísticas relativas a los ataques SSH que recibamos y la metodología seguida por los atacantes cuando consiguen un acceso SSH.

Explicado esto, pasemos a la instalación, en sistemas Debian bastará con hacer:

root@ph0b0s:~# apt-get install python-dev openssl python-openssl python-pyasn1 python-twisted , si tenéis otros sistemas, podéis pasaros por la entrada de instalación en la wiki oficial.

Adicionalmente, y como veremos más adelante, Kippo puede utilizar una base de datos MySQL para guardar la información del honeypot, para ello necesitaremos también el paquete “python-mysqldb”.

Antes de arrancar Kippo, es necesario comentar que, ejecutarlo como root, es una acción bastante peligrosa, puesto que si algún atacante lograse saltarse el honeypot de algún modo, o encontrar algún fallo en el mismo, los privilegios con los que contaría serían los de root, por lo que lo mejor es ejecutarlo con un usuario limitado. Más adelante veremos cómo hacer para que Kippo se encuentre tras el puerto 22 sin estarlo realmente.

Ahora, una vez hayamos descargado y descomprimido el fichero en el directorio que queramos, pasaremos a modificar el fichero kippo.cfg para establecer la configuración del honeypot.

Entre las distintas opciones que tenemos de configuración se encuentran las siguientes:

• ssh_port: Puerto en el que dejar a la escucha Kippo, como comentamos anteriormente, que sea un puerto no privilegiado para ejecutarlo con un usuario con privilegios limitados.
• hostname: El nombre de la máquina que será mostrado en el prompt de la consola cuando alguien se conecte al honeypot.
• log_path: Ruta donde se guardarán los ficheros de log de toda actividad del honeypot.
• download_path: Ruta donde se guardarán todos los ficheros que se descarguen mediante el “comando” wget, muy útil para descubrir nuevas herramientas y/o malware utilizadas por los atacantes.

Una vez realizados los cambios necesarios tenemos que arrancar Kippo, para ello contamos con varias opciones. La primera es ejecutar directamente el fichero “start.sh”, que no es más que “twistd -y kippo.tac -l log/kippo.log --pidfile kippo.pid ”, lo que arrancará Kippo en segundo plano. En caso de que queráis ejecutarlo en primer plano para poder ver toda la actividad en tiempo real, podéis hacerlo con el comando twistd -y kippo.tac -n.

Una vez ejecutado, se nos irá mostrando la información de toda actividad:

Visualización en tiempo real de las sesiones de Kippo

Por supuesto, el atacante tiene una pseudo shell bastante completa. A pesar de que Kippo emula distintos comandos, es muy fácil que un atacante que realiza el proceso de forma manual se de cuenta de que está en un honeypot sólo con probar algunos comandos básicos.

Por ejemplo, el comando “top” dice que no se encuentra:

webdev:~# top

bash: top: command not found

Al igual que disponemos de un “ls”, pero con cierto comportamiento extraño de sus modificadores:

Comportamiento del ls "simulado"

  

Como vemos, el “ls” funciona, si le decimos que haga un “ls” extendido también nos devuelve la salida, pero con la particularidad de que nos muestra los ficheros ocultos. Por último, si probamos a realizar un “ls” “recursivo” el argumento no es procesado.

En cualquier caso, un honeypot como este considero que es muy útil para detectar y estudiar ataques automatizados que realizan ataques de fuerza bruta de contraseñas para acceder a servidores y, posteriormente, descargar herramientas de ataque, por ejemplo:

Descarga con "wget" de una herramienta de ataque

En este caso simulamos un atacante que descarga un fichero en C de una herramienta que permite realizar ataques de SYN flood. Recordemos que todo fichero descargado se guarda en la carpeta “dl” (establecida en el fichero de configuración), por lo que, si el atacante descargase una herramienta privada, algún exploit, etc, podríamos obtener una copia para su posterior análisis.

Para reproducir los logs tenemos la herramienta “playlog.py” dentro de la carpeta “utils”, para reproducir un log podemos, por ejemplo, utilizar el comando z0mbiehunt3r@ph0b0s:~/kippo-0.5/utils$ ./playlog.py ../log/tty/20111001-181757-4654.log 0, lo que empezará a mostrar por pantalla toda la sesión.

Por supuesto, existen más herramientas en dicha carpeta, como “passdb.py” que permite añadir más passwords aceptados para la conexión SSH o “createfs.py” que permite recrear el sistema de ficheros de la máquina real para simular un entorno más realista.

También hay que tener en cuenta que, para recibir más ataques automatizados, lo mejor es que Kippo “escuche” en el puerto 22, tal y como se ha comentado varias veces en el post, para escuchar en dicho puerto se requieren privilegios de root, por lo que lo mejor es utilizar iptables para redirigir la petición, por ejemplo: iptables -t nat -A PREROUTING -i IN_IFACE -p tcp --dport 22 -j REDIRECT --to-port 2222, si queréis más información al respecto, o métodos alternativos, visitad la correspondiente entrada en la wiki.

Por último, vamos a ver las opciones de log mediante MySQL con las que cuenta Kippo.

Lo primero será conectarnos al servidor MySQL como root, o un usuario con suficientes privilegios, para autorizar al usuario que usará Kippo.

z0mbiehunt3r@ph0b0s:~$ mysql -u root -p

mysql> CREATE DATABASE kippo;

mysql> GRANT ALL ON kippo.* TO 'kippo'@'localhost' IDENTIFIED BY 'kippo'; (Utilizar un password mejor...)

Ahora, nos conectamos como el usuario kippo e importamos el fichero .sql con la estructura utilizada por Kippo.

z0mbiehunt3r@ph0b0s:~$ mysql -u kippo -p

mysql> USE kippo;

mysql> source kippo-0.5/doc/sql/mysql.sql;

Una vez que tengamos preparada la base de datos, sólo nos queda realizar los cambios de configuración, recordemos que es el fichero kippo.cfg. Las líneas correspondientes al log mediante MySQL se encuentran justo al final. Tendremos que dejar algo similar a lo siguiente:

[database_mysql]

host = localhost

database = kippo

username = kippo

password = kippo

Una vez volvamos a arrancar Kippo, podremos recurrir a la base de datos para obtener estadísticas, comprobar el uso del Honeypot, etc.

Si alguno de vosotros utiliza Kippo en un servidor real, seguro que se “asusta” de la cantidad de ataques diarios que se realizan de manera automatizada...

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!

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.

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.

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!

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:

• Sucuri - Fingerprinting web applications
• Web Application Finger Printer (herramienta)
• Web Application Finger Printing (paper)
• BlindElephant_WebApp_Fingerprinting-PAPER-v2.pdf
• WASC Fingerprinting

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

CMS Fingerprinting – II

En el anterior post vimos cómo tratar de identificar un portal web y su versión, principalmente mediante análisis de contenido dinámico como metatags y cookies. En esta ocasión vamos a ver cómo funciona el fingerprinting web basado en contenido estático.

El fingerprinting web de contenido estático se basa en los directorios y ficheros estáticos, como imágenes, txt, html, JavaScript, etc, así como en sus hashes. ¿Qué es un hash? Un hash no es más que el resultado de una serie de operaciones matemáticas cuya finalidad es identificar de forma casi unívoca a un único documento, texto, etc. Se basan en que, para una única salida, no deberían existir dos entradas distintas. Esto quiere decir que, un hash dado, identifica únicamente a un fichero concreto.

Para poder identificar las distintas versiones de un sistema CMS primero es necesario realizar diversas acciones:

• Descargar las versiones de las que se desea realizar la tabla de fingerprinting
• Calcular los hashes de los ficheros estáticos, preferiblemente de aquellos que aparezcan de forma más específica y, por tanto, más significativa según la versión
• Intentar limpiar recursos no accesibles normalmente, como aquellos correspondientes a zonas de administración

Una vez se haya realizado dicha acción se tendrá algo parecido a lo siguiente (la imagen es de Patrick Thomas, autor de BlindElephant):

Disponiendo ya de la tabla de directorios, recursos y sus respectivos hashes, sólo queda intentar obtener los ficheros que sean necesarios para identificar correctamente la versión, tal y como se ve en la siguiente imagen:

Como ejemplo, vamos a utilizar blind elephant para tratar de identificar la versión de Wordpress utilizada por un sitio aleatorio.

Lo primero que haremos será listar los CMS que BlindElephant es capaz de detectar, para ello podremos ejecutar z0mbiehunt3r@ph0b0s:~/pentesting/www/blindelephant/$ ./BlindElephant.py -l y veremos dicha lista. 

Para intentar detectar la versión de Wordpress utilizada de la forma más exacta posible ejecutamos BlindElephant con el comando z0mbiehunt3r@ph0b0s:~/pentesting/www/blindelephant$ ./BlindElephant.py http://tastykitchen.com/ wordpress

Después de obtener unos pocos ficheros, 15 por defecto, comportamiento que podemos cambiar mediante el argumento -n , se nos muestran los resultados obtenidos mediante análisis de ficheros estáticos, tal y como vemos a continuación:

Como hemos visto, BlindElephant es una buena opción a la hora de tratar de identificar la versión de algunos gestores de contenido. Espero que os sirva.

CMS Fingerprinting – I

Durante las auditorías web es común necesitar identificar las tecnologías utilizadas así como cualquier posible sistema web y sus versiones, como pueda ser un sistema de foro, un CMS de blog, etc.

Según la metodología utilizada para ello disponemos de diversas herramientas, en este primer post vamos a ver cómo realizar la identificación del CMS utilizado gracias a un análisis de contenido dinámico.

Para ello, vamos a utilizar el programa WhatWeb, de la empresa morningstar IT security. WhatWeb utiliza, por defecto, una única petición HTTP y analiza las cabeceras de las mismas para intentar obtener información acerca de la solución software utilizada y su posible versión, veamos un ejemplo:

Sin indicarle ninguna opción, WhatWeb ha realizado una petición a la dirección indicada y ha analizado diversa información como cabeceras, metatags, cookies, etc, detectando un sistema de foros PHPBB versión 3.

Además de realizar un análisis de contenido dinámico, WhatWeb tiene la posibilidad de aumentar el intento de pruebas para obtener mayor información de la versión utilizada.

Pongamos un ejemplo, estamos realizando una auditoría web y hemos obtenido que la página web en cuestión utiliza Joomla, pues bien, con WhatWeb podremos intentar obtener información acerca de la versión utilizada de la siguiente manera:

Como podemos ver, ha acotado bastante la versión de Joomla utilizada, sólo ha hecho falta indicarle el plugin a utilizar para las pruebas (actualmente WhatWeb cuenta con casi 900 plugins...) y decirle el nivel de agresividad que queríamos utilizar.

En siguientes entradas veremos otros métodos de fingerprinting de página web.

Análisis estático de código con RATS

Durante el proceso de desarrollo, o mantenimiento, de software es necesario prestar atención a todos los aspectos relacionados con la seguridad del mismo y no únicamente al aspecto y/o funcionalidades del mismo.

Entre las acciones que se han de llevar a cabo para vigilar el nivel de calidad en cuanto a términos de seguridad se refiere, nos encontramos con la auditoría de seguridad de caja blanca de todo el código fuente. A pesar de que dicho proceso pueda realizarse manualmente revisando miles y miles de líneas de código es una tarea repetitiva y tediosa que puede automatizarse en gran medida.

Existe gran diversidad de software destinado a ayudar a la auditoría de código (semi)automatizada y, dependiendo del lenguaje auditado, de las necesidades de creación automatizada de informes, etc, necesitaremos usar uno u otro.

En este caso vamos a utilizar RATS (Rough Auditing Tool for Security), de la empresa Fortify y disponible como herramienta Open Source, para analizar de forma estática un programa en C y buscar de forma fácil vulnerabilidades en el mismo.

Para ello, vamos a utilizar el siguiente código:

int main(int argc, char *argv[]){

char buffer[10];

strcpy(buffer, argv[1]);

}

Es un código muy simple que, lo único que hace, es copiar el primer parámetro que se le proporcione en el array de char llamado buffer, sin realizar ningún tipo de comprobación previa. Ello, dependiendo de dicho parámetro, puede conducir a un stack buffer overflow, lo que podría provocar la ejecución de código arbitrario mediante la explotación de dicha vulnerabilidad. Es un ejemplo simple, pero nos servirá para la prueba de RATS.

Primero será necesario instalar RATS, o bien con un conocido ./configure, make, make install o bien directamente del repositorio según la distribución.

La forma más sencilla de ejecución de RATS es indicando únicamente el fichero, o directorio, que contiene el código fuente a auditar.

Como podemos ver en la imagen, RATS ha encontrado que se utiliza un buffer de tamaño fijo, así como la función strcpy, y nos avisa de que ambas acciones son peligrosas y pueden conllevar un desbordamiento de memoria.

Entre las distintas opciones disponibles, existe una que considero que puede resultar de gran utilidad, la opción --xml. Con ella, la salida de RATS se nos mostrará formateada en XML, por lo que podremos volcarlo a un fichero para su posterior tratamiento.

Un ejemplo de dicho tratamiento podría ser un script de entrada en un repositorio SVN para comprobar el número y gravedad de vulnerabilidades y, según los resultados, permitir o no hacer el commit (gracias Leo por la idea).

Esto es sólo un ejemplo muy sencillo pero que vale para demostrar la utilidad de herramientas como RATS que pueden ayudar en gran medida en los tediosos procesos de revisión de código, siempre sin olvidar que se realiza un contenido estático basado en las funciones utilizadas (en RATS dichas funciones peligrosas se declaran en ficheros XML, lo que permite una rápida modificación o expansión de las mismas) y que siempre será necesaria la revisión manual debido a posibles falsos positivos y/o falsos negativos.

Espero que a alguno de vosotros os sea de utilidad en algún momento, saludos.