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!

 

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.

Armitage - juguete para Metasploit

Buenas a todos, os dejo rápidamente una breve entrada respecto a una herramienta que he probado hace poco.

Recientemente la gente de Offensive Security han añadido la herramienta Armitage al repositorio de Backtrack.

¿Qué es Armitage? Pues "simplemente" una interfaz para Metasploit realizada en Java. A priori puede parecer simple en el aspecto (mucho mejor, como se ve en cuanto se empieza a usar), pero permite sacarle prácticamente todo el potencial a Metasploit.
Permite realizar todo tipo de ataques, escaneos de red para detectar host y puertos abiertos, importar resultados de Nessus, Nmap, Nexpose..., realizar explotaciones remotas, generación de payload y mucho más.

Pero, donde realmente empieza la diversión, es cuando ya tenemos una shell y empezamos la post explotación. Armitage nos ayuda en multitud de tareas para la postexplotación, como ataques pass-the-hash, pivotar a través de los host ya comprometidos, montar un servidor proxy para utilizar otras herramientas mediante los host con los que vamos a pivotar (ojito la cantidad de posibilidades que nos abre esto), etc, etc.

Todo ello de forma gráfica, estilo "click & exploit". Puede ayudarnos enormemente a la hora de realizar algunos ataques y tenerlo todo más controlado de forma gráfica y menos enrevesada.

Por último, os dejo el enlace a la web oficial desde donde podréis descargarlo y ver un par de vídeos con la herramienta en acción:

http://www.fastandeasyhacking.com/

Saludos a todos!

Detectando balanceadores de carga

A la hora de realizar un pentest o auditoría, y antes siquiera de escanear equipos, debemos intentar detectar e identificar posibles balanceadores de carga. Esto tiene una explicación muy sencilla y es la siguiente: podemos realizar un escaneo de puertos y darse la situación de que, por ejemplo, unas peticiones han sido asignadas a un servidor concreto y otras peticiones a otras, por lo que se obtendrán resultados incosistentes.
Lo mismo pasará a la hora de realizar un escaneo de vulnerabilidades, podemos encontrar un servidor vulnerable, lanzarle un exploit y que el exploit se dirija a un host no vulnerable. Por el contrario, puede darse el caso de no encontrar una vulnerabilidad por haber auditado sólo un host.

Antes de pasar a ver los principales métodos de detección de balanceadores vamos a ver las principales técnicas usadas para balancear:

• Basado en DNS: basado en algoritmo round robin, cada petición es respondida con una IP distinta. Ello no quiere decir ni que sea el servidor con menos carga ni que dicho servidor esté accesible.
• Least connections: Se redirigen las peticiones al servidor con menos conexiones.
• Dicho balanceo se puede configurar para dar "pesos" a cada servidor según sus capacidades.
• Persistencia por cookie: En casos como una tienda online o un portal que se requiera un constante chequeo de credenciales se puede marcar mediante cookie una conexión "persistente" para que, una vez autenticado, tus peticiones vayan al mismo servidor y así no tener problemas con las sesiones.
• Los sistemas anteriores pueden complementarse con mecanismos como la latencia de un ping para intentar entregar el recurso solicitado desde el servidor más cercano geográficamente para intentar conseguir un mejor rendimiento.

Dicho esto vamos a ver un par de formas para detectar balanceadores de carga:

Mediante consulta DNS

Para ello bastará con realizar una consulta de tipo A y ver si se nos devuelven múltiples entradas.

z0mbiehunt3r@d3im0s:~$ dig www.tuenti.com A

;; ANSWER SECTION:

www.tuenti.com. 860 IN A 95.131.168.193

www.tuenti.com. 860 IN A 95.131.168.194

www.tuenti.com. 860 IN A 95.131.168.195

www.tuenti.com. 860 IN A 95.131.168.196

Como vemos se nos devuelven dos entradas de tipo A que corresponden a dos host de la red Akamai.

hping3

Con la herramienta hping3 podemos crear paquetes "al gusto", para realizar esta comprobación vamos a crear paquetes con la flag SYN establecida y el puerto de destino 80, para intentar abrir una conexión con el/los host remotos.

root@d3im0s:~# hping3 -S -p 80 www.f5.com

HPING www.f5.com (eth1 65.61.115.222): S set, 40 headers + 0 data bytes

len=46 ip=65.61.115.222 ttl=239 DF id=30681 sport=80 flags=SA seq=0 win=1608 rtt=221.1 ms

len=46 ip=65.61.115.222 ttl=239 DF id=34470 sport=80 flags=SA seq=1 win=1608 rtt=222.5 ms

len=46 ip=65.61.115.222 ttl=238 DF id=35460 sport=80 flags=SA seq=2 win=1608 rtt=229.4 ms

len=46 ip=65.61.115.222 ttl=239 DF id=36912 sport=80 flags=SA seq=3 win=1608 rtt=218.5 ms

len=46 ip=65.61.115.222 ttl=239 DF id=37908 sport=80 flags=SA seq=4 win=1608 rtt=223.8 ms

len=46 ip=65.61.115.222 ttl=240 DF id=38775 sport=80 flags=SA seq=5 win=1608 rtt=219.7 ms

len=46 ip=65.61.115.222 ttl=238 DF id=40694 sport=80 flags=SA seq=6 win=1608 rtt=219.9 ms

len=46 ip=65.61.115.222 ttl=239 DF id=43097 sport=80 flags=SA seq=7 win=1608 rtt=226.0 ms

Podemos observar que el IP ID devuelto no es sólo incremental o establecido a 0 siempre, sino que tenemos varios que son menores que el IP ID anterior, cosa imposible salvo que sean servidores distintos.

Load Balancing Detector

root@bt:/pentest/enumeration/lbd# ./lbd.sh www.microsoft.com

lbd - load balancing detector 0.1 - Checks if a given domain uses load-balancing.

                                    Written by Stefan Behte (http://ge.mine.nu)

                                    Proof-of-concept! Might give false positives.

Checking for DNS-Loadbalancing: FOUND

lb1.www.ms.akadns.net has address 207.46.170.10

lb1.www.ms.akadns.net has address 207.46.170.123

Checking for HTTP-Loadbalancing [Server]: 

 Microsoft-IIS/7.5

 FOUND

Checking for HTTP-Loadbalancing [Date]: 21:23:54, 21:23:55, 21:23:55, 21:23:56, 21:23:56, 21:23:56, 21:23:57, 21:23:58, 21:23:58, 21:23:59, 21:23:59, 21:24:00, 21:24:00, 21:24:01, 21:24:01, 21:24:01, 21:24:03, 21:24:03, 21:24:04, 21:24:04, 21:24:05, 21:24:05, 21:24:05, 21:24:06, 21:24:06, 21:24:07, 21:24:07, 21:24:08, 21:24:08, 21:24:09, 21:24:09, 21:24:09, 21:24:11, 21:24:11, 21:24:12, 21:24:12, 21:24:13, 21:24:13, 21:24:14, 21:24:14, 21:24:14, 21:24:14, 21:24:16, 21:24:16, 21:24:16, 21:24:17, 21:24:17, 21:24:18, 21:24:18, 21:24:19, NOT FOUND

Checking for HTTP-Loadbalancing [Diff]: FOUND

< VTag: 279850942700000000

> VTag: 791860011400000000

www.microsoft.com does Load-balancing. Found via Methods: DNS HTTP[Server] HTTP[Diff]

En este caso se ha identificado balanceo de carga gracias a las diferencias introducidas en las cabeceras HTTP por cada servidor.

Cookie

z0mbiehunt3r@d3im0s:~# telnet communities.vmware.com 80

Trying 92.123.78.41...

Connected to a1005.g.akamai.net.

Escape character is '^]'.

HEAD / HTTP/1.1

HOST: communities.vmware.com

HTTP/1.1 500 Internal Server Error

Server: Apache-Coyote/1.1

Content-Type: text/html

Expires: Tue, 16 Nov 2010 22:02:49 GMT

Cache-Control: max-age=0, no-cache, no-store

Pragma: no-cache

Date: Tue, 16 Nov 2010 22:02:49 GMT

Connection: keep-alive

Set-Cookie: JSESSIONID=5CFA78E5C5959F0298E0AAFFEAF17589; Path=/

Set-Cookie: BIGipServercommunities-prod-pool=1396601098.36895.0000; expires=Tue, 16-Nov-2010 23:02:49 GMT; path=/

Connection closed by foreign host.

Como podemos observar en la imagen, a parte de usar la red Akamai, se utilizan appliances F5 BIG-IP. Existe un fallo de information disclosure que nos permite sacar las direcciones IP internas de los servidores a través de la cookie para comprobarlo usamos el plugin 20089 de Nessus.

Plugin Output

The first column is the original cookie, the second the IP address and

the third the TCP port:

  BIGipServercommunities-prod-pool=1396601098.36895.0000 10.113.62.83 8080

  BIGipServercommunities-prod-pool=1379823882.36895.0000 10.113.62.82 8080

  BIGipServercommunities-prod-pool=1363046666.36895.0000 10.113.62.81 8080

Bueno, y hasta aquí llegó la breve introducción a la detección de balanceadores de carga, espero que os haya gustado y os haya despertado el gusanillo de comprobar distintos sitios.

Saludos!

Montando un lab ( I ) - De-ICE

Hace ya un mes desde la última entrada... me temo que he estado más liado de lo que me hubiese gustado (bueno, y una escapadita a Asturias, pero eso no cuenta :P ) y no he podido escribir antes a pesar de que tengo bastantes cosas pendientes por publicar... vamos a ver si poco a poco se normaliza todo y puedo volver a publicar varias entradas a la semana.

En más de una ocasión he acabado hablando con compañeros o amigos acerca de cómo montar un "laboratorio de pentest" con el que poder practicar distintas técnicas, hacer perrerías de todo tipo y demás; la verdad que actualmente es bastante fácil montarse uno gracias a las máquinas virtuales, además de que ya hay disponibles varias máquinas virtuales ideadas para hacer prácticas de seguridad y aprender en el camino.

Las primeras que voy a comentar son las máquinas virtuales disponibles en http://www.de-ice.net/, varias creadas por Thomas Wilhelm y otra creada por un miembro del foro, bond00.

Entre las creadas por Thomas tenemos tres grupos por así decirlo, un primer nivel compuesto por dos máquinas virtuales, un segundo nivel compuesto por una única máquina virtual y otro correspondiente a unos artículos que Thomas está publicando en la revista hakin9 (si no la conocéis os la recomiendo encarecidamente, podéis suscribiros y recibirla gratuitamente en el correo desde hace unos meses).

De-Ice Level 1:

Bajo mi punto de vista no tienen mucho a nivel técnico puesto que casi todo se basa en técnicas de fuerza bruta (por supuesto es una opción más a tener en cuenta a la hora de realizar una prueba de pentest), básicamente realizar una enumeración de posibles usuarios con los datos de la web, comprobarlos con el correo y conseguir una credencial básica para poder realizar una escalada de privilegios posteriormente.

Aunque no me gusten tanto como otras opciones también conviene practicar dichas técnicas y llevará darle al coco un buen rato para resolver alguna que otra cosa.

De-Ice Level 2:

Aún no he podido jugar mucho con él, pero por lo que he podido ver (por Internet circulan distintos vídeos de cómo resolverlo) tiene mejor pinta que los anteriores (al menos bajo mi punto de vista, claro). Siento no poder decir mucho más, pero sin haberlo resuelto tampoco me voy a mojar demasiado, jeje.

VM Hakin9:

La verdad que hasta donde he podido ver con dichas máquinas virtuales me ha gustado mucho (en los números de hakin9 va publicando las "soluciones"). Entre las cosas que más me ha gustado es la implementación de una backdoor que abre una shell de root mediante una técnica simple de "port-knocking", realmente original el implementarlo y realmente fácil de encontrar en un servidor que ha sido comprometido.

También ha incluido la segunda máquina virtual para que se ataque desde la primera, aprovechándonos de lo que se conoce como "abuso de confianza", algo que es fácil que se nos pase por alto en un momento dado, pero conviene tener en cuenta que muchas máquinas tienen un firewall de host que permite ciertas conexiones sólo desde ciertas máquinas "seguras y administradas".
Realmente recomendables...

pwnOS:

Además del trabajo realizado por Thomas nos encontramos con una máquina virtual creada por bond00 llamada pwnOS.
Dicha máquina virtual está pensada para ser atacada con exploits encontrados en, la ya difunta, milw0rm; estuvo mucho tiempo en la brecha, aunque finalmente str0ke decidió no continuar el trabajo y tras un tiempo de incertidumbre de si alguien cogería el relevo decidió cerrar.
Los chicos de Offensive Security (la gente de Backtrack) crearon www.exploit-db.com e importaron todo el material ya existente en milw0rm, además de que diariamente se añaden cosas nuevas, también os recomiendo que os deis una vuelta por la web.

Pero bueno, que me voy por los cerros de Úbeda... volviendo al tema de la máquina virtual, podéis encontrar los exploit en exploit-db e incluso en Metasploit.

Lo que me gustó de dicha máquina es que tiene varias formas de resolverse, algunas más técnicas y otras menos. Por ejemplo, podemos aprovecharnos de la predictibilidad, digo aleatoriedad, de la que sufrió Debian para poder conectarnos por ssh y después escalar privilegios con exploit local...

Espero que os haya gustado la entrada y ya estéis descargando las máquinas para probarlas... (si tenéis cualquier duda pregutad).

En las próximas entradas mostraré otras máquinas pensadas también para ser atacadas y practicar cosillas de seguridad (además de explicar cómo montar un pequeño laboratorio de red para realizar ataques a protocolos de red)


Un saludo, gente

PD: Si véis que con este tipo de máquinas virtuales no sabéis por donde tirar probad a escanearlas con Nessus y OpenVAS ;)