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...