Conferencias FIST – Madrid Febrero 2009
Para aquellos de vosotros que no lo conozcáis, deciros que las conferencias FIST (First Improvised Security Testing) se vienen celebrando desde hace ya prácticamente 5 años. Estas conferencias están totalmente abiertas a la participación de cualquier persona interesada en la seguridad informática y el pentesting, tanto a la hora de asistir, como a la hora de participar como ponente. Si estás interesado en asistir a la próxima edición de las conferencias FIST de Madrid o Barcelona, lo mejor es que visites la web, te suscribas a la lista, y estés atento a la próxima convocatoria.
Una vez realizada esta pequeña introducción, para poneros en antecedentes, me gustaría comentaros mis impresiones respecto a la última edición celebrada en Madrid, el pasado jueves día 19 de febrero.
Las conferencias fueron brevemente presentadas por Gonzálo Alvarez Marañón, quién dió paso inmediatamente a Vicente Aceituno, quien en calidad de actual presidente de ISSA España, nos hizo una introducción a la asociación, sus objetivos, como entrar a formar parte de ella, etc.
La primera conferencia técnica llegó de la mano de Alejandro Martín, de Informática64, quien con su presentación titulada “La jungla de las redes Wi-Fi” realizó un repaso a las diferentes técnicas de segurización de redes inalámbricas (WEP, WPA, WPA2, filtrados MAC, autenticación 802.1x, etc.) y presentó una herramienta que han estado desarrollando, orientada al usuario final, para evaluar el nivel de seguridad de la red inalámbrica a la que el usuario está conectado. Me pareció una idea interesante, han desarrollado una métrica para cuantificar cómo de segura es uan red inalámbrica, en base al tipo de cifrado usado, lo robusta que es la clave de cifrado, el tipo de autenticación, si se realiza algún tipo de filtrado, etc. De esta forma, el usuario final, a la hora de conectarse a través de una red inalámbrica ajena, como por ejemplo desde un aeropuerto, un hotel o un hotspot público, sabrá qué grado de confianza debe tener en la red, y qué mecanismos adicionales de seguridad debe usar para acceder de forma segura a los recursos remotos. La herramienta se llama Mummy, aún no la han liberado y le falta por pulir algunos detalles. Espero que liberen el código y abran el desarrollo a la comunidad, de esta forma seguro que se convierte en una herramienta muy útil incluso para unos primeros pasos de una auditoría. La pena es que parece que está desarrollada únicamente para Windows. Si la liberan como código abierto quizás sería buena idea trasladar la idea a otros entornos, como Unix y OSX.
La segunda charla, que en mi opinión fue magnífica, corrió a cargo de Alberto Moreno. En su presentación Alberto se centró en la seguridad de Bluetooth, demostrando en la práctica como con software y hardware al alcance de cualquiera se puede capturar tráfico bluetooth, romper la clave de asociación de dos dispositivos, hacer un spoofing de uno de ellos y acceder a información sensible (agenda de contactos, calendario, fotos, aplicaciones, etc.) en el dispositivo remoto. La parte de sniffing me resultó especialmente interesante, ya que el dispositivo usado por Alberto no fue un USRP con GNU Radio, sino un adaptador Bluetooth USB Zaapa totalmente normal, de los que podemos encontrar en cualquier tienda, que ha sido reflasheado con el firmware de un sniffer Bluetooth comercial. La particularidad de este adaptador, y otros que hay en el mercado, es que hace uso de un chipset concreto, el BlueCore de Cambridge Silicon Radio, con una memoria flash externa que puede ser reescrita con el firmware del sniffer. Si das con uno de estos adaptadores, puedes hacerte tu propio sniffer Bluetooth por 20 euros. Si estáis interesados en este tema, no dejéis de visitar su blog, es una verdadera enciclopedia sobre seguridad Bluetooth.
Y para terminar la tarde, una presentación realmente amena (a pesar de lo duro de la temática) por parte de David Carrasco. La presentación de David era sobre Microsoft NAP (Network Access Protection), es decir, los mecanismos disponibles en una red Windows para autenticar y autorizar a un cliente de la red, y tomar medidas de aislamiento en caso de que no cumpla con las políticas impuestas por el administrador. Una charla muy interesante, tanto por el tema tratado como por la forma de tratarlo, ya que David nos fué guiando a lo largo de varias películas por todos conocidas para ir explicando los conceptos de NAP y cómo se implementan en una red Microsoft. Por cierto, buenísimos los 3 trailers con los que explicó los diferentes tipos de usuario en una red ;)
Cuando el video de la charla esté en youtube os recomiendo que lo veáis, al igual por supuesto que el resto de las charlas. Por el momento podéis disfrutar de las transparencias de las ediciones anteriores.
En conclusión, una magnífica tarde disfrutando de unas magníficas charlas dadas por unos ponentes de primera. Es de agradecer el esfuerzo e interés que los organizadores de FIST ponen en cada una de las convocatorias. Muchas gracias desde aquí por ello.
Soluciones Geek Puzzle II: reto 0×07
Llegamos con este a lo que será el último post por mi parte explicando cómo solucionar los retos de Geek Puzzle II, ya que el resto de retos que no comento pertenecen a alguno de mis otros compañeros del Geek Puzzle Team. Falta por comentar el cómo solucionar el primer reto de Geek Puzzle II, que fue diseñado por Víctor Arambulo, nuestro ganador de la anterior edición del concurso.
Y sin más historias, pasamos a ver en qué consistía este último reto de la 2ª edición, al que bauticé con el título de “Barcode Privacy“.
En el enunciado del reto se referencia a una imagen JPEG. El nombre del fichero (128B.jpg) tiene su importancia, ya que cuando visualizamos la imagen vemos que es un código de barras, y que precisamente 128B es uno de los muchos tipos de códigos de barras que existen, así que mediante esta pista se nos está indicando qué tipo de código de barras es, de tal forma que el siguiente paso lógico es decodificar el código de barras para ver qué información podemos obtener de aquí.
La decodificación del código de barras puede llevarse a cabo de muchas formas. Podemos decodificarlo a mano, lo cual no es nada dificil dada la sencillez del código, podemos usar algún software en nuestra PDA con cámara para directamente decodificarlo desde la pantalla, podemos utilizar algún software de decodificación de códigos como zebra - no confundir con este otro zebra ;) – o incluso podemos decodificarlo online.
De una forma u otra, al final se obtendrá la cadena de texto que está codificada en el código de barras. Esta cadena de texto es: 0af28acb958b5eed09d6376c3bfbe3
Con este dato, a priori, parece que no avanzamos en exceso. Quizás sea buena idea seguir analizando la imagen por si hay algo más de información escondida, no únicamente el código de barras que se ve a simple vista.
Efectivamente, si se analizan los metadatos de la cabecera de la imagen, nos encontramos con una cabecera EXIF que nos proporciona un par de datos interesantes:
- Hay un campo de comentario o descripción que contiene la siguiente frase: Usa el valor correcto de “Fi” y podrás desvelar la información oculta
- Hay etiquetas de geolocalización GPS, con las coordenadas 64 2 2.69 para la latitud y 12 28 27.06 para la longitud. Se puede utilizar cualquier herramienta de conversión, para pasar de grados/minutos/segundos a coordenadas decimales, de tal forma que se obtienen latitud 64.03408 y longitud 12.474183. Introducciendo estas coordenadas en Google Maps, nos posicionamos en un lago noruego, de nombre Fjellskjaekra. Interesante, nos quedaremos con este nombre para más adelante ;)
Además, el JPEG cuenta con un thumbnail que es diferente a la imagen mostrada, en concreto, al extrae el thumbnail vemos que la imagen contiene dos definiciones matemáticas:
- La definción de la sucesión de Fibonacci
- La defincion del número áureo Fi en relación con Fibonacci.
Interesante… hay que recordar que en el campo de comentario de la cabecera EXIF del JPEG había una frase a modo de pista que indicaba que el valor correcto de Fi desvelará la información oculta.
Siempre que tenemos una imagen y sospechamos que hay “información oculta” ;) hay que pensar en esteganografía. Tenemos varias piezas de información interesantes: una cadena de texto alfanumérica, el dato que nos indica que el valor correcto de Fi nos desvelará información oculta, las coordenadas que nos posicionan en un lago noruego de nombre bastante exótico… ahora bien, todo esto parece que no nos conduce a nada.
Quizás sea interesante ver si hay algo más de información en la imagen… pensemos en esteganografia… probemos con algún programa como stegdetect o steghide… ¡Bingo! el steghide parece que quiere extraer algo de la imagen, aunque solicita un password. Quizás haya que proporcionar “el valor correcto de Fi” y así poder desvelar la información oculta en la imagen ;) tiene sentido… ahora bien, ¿cuál es el valor correcto de Fi? El número áureo, Fi, tiene un valor de 1.6180339887… probando digito a digito, es decir, 1.6, 1.61, 1.618, 1.6180, 1.61803 llegamos a poder extraer la información. Obteniendo un fichero ZIP.
Al intentar descomprimir el ZIP, de nuevo nos encontramos con que está protegido por password… rebuscando en nuestro “inventario” ;) nos encontramos con ese nombre tan curioso de lago noruego… y efectivametne es el password para descomprimir el ZIP.
La descompresión del ZIP nos proporciona un shell script.
##!/bin/bash
URL="http://www.techclot.es/geekpuzzle/geekpuzzle0205-barcode_privacy/"
if [ -z "$1" -o `echo -e "$1\c" | wc -c` -ne 30 ]; then
echo "Si no me das el parametro correcto no hacemos nada... :("
exit 1
fi
/usr/bin/wget -q ${URL}${1}.asc
PASS=`echo -e "$UID\c" | /usr/bin/md5sum | awk '{print $1}'`
/usr/bin/openssl rsautl -decrypt -inkey ${1}.asc -in leeme.enc -passin pass:$PASS
Este script hace lo siguiente:
- Se descarga un fichero, tomando como nombre el fichero el parámetro que indiquemos.
- Obtiene el hash MD5 del UID del usuario, y eso lo usará posteriormente como password.
- Intenta descifrar el contenido de un fichero leeme.enc, que aparentemente está cifrado con RSA, usando el fichero descargado como clave privada, la cual también se encuentra cifrada con DES, y el password para descifrar la clave privada y asi poder descifrar el mensaje es el password generado previamente con el hash MD5 del UID.
Pasando como parámetro al script la cadena alfanumérica que obtuvimos al princpio del reto, al decodificar el código de barras, obtenemos el fichero de la clave privada.
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-CBC,0B23E941CCC7D128
jy9H1GjHBOy6G32oAi0lGg4eGfR7Suwp0g+BuBXVicflI4PYfmlBExwQjLPno0kb
YyOdBadRPvrXn9iUhScEILZVLuYRUPLwFQSgAgsJQGbh1X1pIpyeisLwv0hRUxyr
RxGs3Lh+bHBb51EHTSDoNx6re8w7WfPgyfjroIkiF8bt/TFy5c/XPI0RD/LqVFzQ
1QKQAyqxSqxObLtcUJ09H0I6VZqM5DFgGAaCzsHgLckNBXA7IbpIIbogF+4VeECF
qhRL+0vRPWAkpZazMrCpdumUUp0KeNByF8AAqROKCRFMQoHqFhFDoOJELw/kgtjI
9bfoMZJHf4CZ9R4g3gzXpd0/WY/MHygi9ncgWJD/vnCNAM8eE/AD+JAfvu3xS3+P
RvrCy8ZeTbIhcHMu6roDlsyxTnvBqOBTn3T51HIEr+g=
—–END RSA PRIVATE KEY—–
El descifrado del fichero leeme.enc fallará, ya que o somos muy afortunados, o la clave generada a partir del MD5 de nuestro UID no coincidirá con la clave verdadera… la forma más directa será ir probando UID por UID, desde 0 hasta el máximo UID, que la verdad puede llegar a ser bastante ya que estamos hablando de 2^32 o incluso 2^64 posibilidades, pero en la práctica el máximo UID se queda restringido a 32767 o 65535 posibilidades.
Haciendo un bucle de 0 a 65535 y probando uno por uno, conseguimos descifrar sin problemas el fichero usando la clave privada cuando se llega al UID 23942 lo cual genera la clave b44d430b7454e3e7eae0636defd68abb
El proceso de resolución del reto finaliza aquí, una vez hemos obtenido la clave: M4yTheF0rceBeW1thY0u
Soluciones Geek Puzzle II: Reto 0×04
Al siguiente reto que diseñé para Geek Puzzle II lo bauticé con el nombre de “Fast-Track” y quizás fue uno de los retos que más guerra dió a los jugadores ;)
En la descripción del reto únicamente aparecía lo siguiente: Verbindung hier dringend.
Así que el punto de partida es una frase en alemán, y un enlace a una IP al puerto 65000. Si se empieza por lo fácil y evidente, que es establecer una conexión TCP al puerto 65000 de esa IP, no pasa absolutamente nada… el tráfico es aparentemente rechazado o ignorado por el servidor.
La frase evidentemente debe significar algo, y el que esté en alemán debe tener algún significado… quizás no ahora mismo, pero habrá que tenerlo en cuenta para más adelante ;)
Como quizás nuestro alemán no sea tan fluido como nos gustaría, lo mejor es hacer uso de google para hacer una traducción rápida de la frase. En castellano tendríamos algo así como: Conexión de urgencia
Bien, repasemos que tenemos antes de continuar:
- Está claro que es necesario establecer una conexión TCP al puerto 65000 de la IP 209.20.80.165 para continuar.
- Un intento de conexión a dicha IP y puerto no nos devuelve nada, el tráfico está siendo bloqueado o ignorado.
- La frase en alemán, nos hace referencia a una conexión de urgencia, o urgente.
Interesante… para la siempre paranoica y ágil mente del hacker, hablar de TCP y de urgencia, solo puede significar una cosa… nuestros segmentos TCP están siendo descartados por el servidor porque no van marcados como urgentes, es decir, el flag URG no está activado ;)
Hay varias formas de realizar un telnet al servidor marcando todos nuestros segmentos TCP con el flag URG, el cómo hacerlo dependerá de cada uno, de las herramientas o lenguajes con los que uno trabaje habitualmente.
Como referencia os pongo una posible solución a este problema usando scapy:
#!/usr/bin/python
from scapy import *
conf.verb=0
ans,unans = sr(IP(dst="209.20.80.165")/TCP(sport=RandShort(),seq=RandInt(),dport=65000,flags="SU"))
for snd,rcv in ans:
ans,unans = sr(IP(dst="209.20.80.165")/TCP(sport=rcv.dport,dport=65000,flags="AU",seq=rcv.ack,ack=rcv.seq+1))
for snd,rcv in ans:
print rcv.load
send(IP(dst="209.20.80.165")/TCP(sport=rcv.dport,dport=65000,flags="RU",seq=rcv.ack,ack=rcv.seq+1))
Esta vez si se consigue establecer diálogo con el servidor que está escuchando en el puerto 65000, y por stdout obtenemos la siguiente salida:
Muy bien, parece que sabes como manipular el trafico de red para conseguir lo que quieres, aunque me temo que aun no hemos terminado con esta prueba. Bajate el siguiente fichero y continua con el reto: http://www.techclot.es/geekpuzzle/geekpuzzle0204-fasttrac/38db59eef1ddc2be36a5f803bfb1f177.cap
Muy bien, primer paso dado, aunque se está indicando un fichero que habrá que descargar para continuar. Una vez realizada la descarga del mismo, se ve que es un fichero de capturá de tráfico en formato pcap, como en otras ocasiones podemos abrirlo con wireshark para analizar el tráfico que contiene.
Uno se da cuenta rápidamente de que el tráfico del fichero de captura es unidireccional, es TCP al puerto destino 5851 y dirigido a la dirección IP 130.37.198.243
Una búsqueda en google revela que el puerto 5851 pertenece al servicio OpenDHT, una vez en la web de este servicio público de tablas de hash distribuidas, se puede comprobar que efectivamente la dirección IP 130.37.198.243 se corresponde con uno de los servidores activos que proporcionan este servicio.
Un servicio DHT (Distributed Hash Table) permite almacenar datos temporalmente. Estos datos están asociados a una clave, de tal forma que puedan recuperarse posteriormente referenciando esta clave. Un servicio DHT puede por tanto verse como una base de datos distribuida, formada por varios servidores (más de 200 en el caso de OpenDHT) que permite guardar y recuperar datos asociados a una clave.
Siguiendo el flujo a nivel de aplicación del tráfico de este webservice, se obtiene lo siguiente:
POST / HTTP/1.0
Host: planetlab1.cs.vu.nl:5851
User-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)
Content-Type: text/xml
Content-Length: 330
<?xml version='1.0'?>
<methodCall>
<methodName>get</methodName>
<params>
<param>
<value><base64>R8mLCacmpUWhk23XQlGSBnlLzKA=</base64></value>
</param>
<param>
<value><int>10</int></value>
</param>
<param>
<value><base64></base64></value>
</param>
<param>
<value><string>get.py</string></value>
</param>
</params>
</methodCall>
El tráfico capturado que se proporciona se corresponde con una petición, en donde la clave va codificada en BASE64 y se corresponde con la cadena R8mLCacmpUWhk23XQlGSBnlLzKA=
El fichero de captura únicamente tiene tráfico en el sentido cliente -> servidor, y una vez que hemos identificado el servicio OpenDHT y hemos visto una consulta de donde se puede extraer la clave, es lógico pensar que se debe reproducir esta misma consulta para poder obtener la respuesta con los datos asociados. Si uno se fija en la peticiçpn capturada, se referencia a lo que parece un script en Python, get.py, que es precisamente uno de los scripts de referencia que aparece en la web de OpenDHT.
Se puede coger este script y modificarlo para lanzar una consulta reutilizando el base64 del valor de la clave. Digo “reutilizar” y no “crackear”, porque si decodificamos el base64 se verá que el resultado no es el valor de la clave en texto claro, sino que es un SHA1. Romper el SHA1 por fuerza bruta es una tonteria pudiendo hacer un replay de la consulta, ya que lo que realmente nos interesa es obtener de la DHT los datos asociados a dicha clave, no la clave en si misma.
Una vez lanzada la consulta se obtiene el dato asociado, que es la siguiente cadena:
gp2:$apr1$Qp4bp…$FLFrrkIgMmQ3WSht698ln1
Bueno, hemos superado dos escalones, pero parece que se presenta un tercer escalón para superar este reto. Está claro que esto que se ha obtenido de la DHT no es la clave del nivel, sino que tiene toda la pinta de ser una entrada de un fichero de passwords, donde tenemos un username y un password separados por el caracter ‘:’. El username es “gp2” y el password es “$apr1$Qp4bp…$FLFrrkIgMmQ3WSht698ln1“.
El formato del password está identificado por el prefijo “apr1“. No se trata de un password crypt, ni md5, ni sha1… una búsqueda rápida de nuevo en nuestro gran amigo google proporciona la pista para atacar correctamente esta clave. El prefijo “apr1” es particular de Apache y se trata de un algoritmo que hace uso de varias iteraciones de md5 junto con el password y un salt aleatorio.
¿Cómo crackear este formato?… una opción es, teniendo la implementación del algoritmo, hacerse la búsqueda por fuerza bruta de las passwords en base a diccionario o combinaciones. Esto mismo es lo que hace John The Ripper si lo compilamos tras aplicarle el jumbo patch necesario para que reconozca las passwords de tipo apr1.
Si se ejecuta el JTR y la táctica elegida es la fuerza bruta en base a combinaciones y permitaciones de cacracteres alfanuméricos… tardaremos mucho en encontrar el password, seguramente se pasará la semana que se proporciona para resolver el reto y el password aún no habrá sido encontrado (eso depende de la potencia de la que dispongamos).
En cualquier caso hay una pista de la que aún no se ha hecho uso… hasta ahora. ¿Recordáis que la primera frase estaba en alemán?… ¿y por qué en alemán?… esto debe significar algo… si en vez de usar fuerza bruta, hacemos un ataque al password por diccionario… ¿por qué no empezar por un diccionario alemán? ;)
¡Bingo! Usando un diccionario de palabras alemanas, el password es crackeado en unos pocos segundos, revelando la tan ansiada clave de este reto: gespenstisch
Tal y como muchos de vosotros habéis indicado, este es uno de los retos que os han tenido más entretenidos durante la semana de publicación ;) Includo alguno de vosotros os habéis hecho una idea mia de sádico-maniaco ;) pero vamos, no os lo tengo en cuenta que sé que os gusta ;)
Por otro lado, una de los problemas típicos que algunos os habéis encontrado y que nos hacíais llegar por mail durante la semana de publicación era que no podíais establecer la conexión con el servidor aún habiendo descubierto que teníais que enviar los paquetes TCP con el flag URG activado.
El problema es que si se genera tráfico a nivel de aplicación a bajo nivel, generando los segmentos TCP al margen de la pila TCP/IP del SO, cuando el tráfico TCP de respuesta llegue a vuestro sistema, será tráfico totalmente desconocido desde el punto de vista de la pila TCP/IP de vuestro SO, y será rechazado. Para evitar que vuestro sistema envíe un RST al sistema remoto cuando se reciban los segmentos TCP de respuesta se deben filtrar a nivel de firewall en vuestro propio sistema.
Como ya sabéis cualquier comentario es bien recibido, y tenéis este blog a vuestra completa disposición para preguntar cualquier cosa o si queréis que profundicemos más en cualquier aspecto de este reto o de las técnicas de resolución que se han propuesto.
Happy Hacking! ;)
Mayumana Momentum
This evening we’ve been to the Nuevo Apolo theatre in Madrid, seeing Momentum, the latest Mayumana’s show. I just have to say one word to summarize my feelings about this show: A W E S O M E
If you have the chance to see them in this show, don’t hesitate to go, you won’t be dissapointed.
Soluciones Geek Puzzle II: Reto 0×02
Hay un refrán que dice que “más vale tarde que nunca“, aunque esto no es en absoluto escusa para el retraso en la publicación de las soluciones de Geek Puzzle II, nunca está de más pediros disculpas a todos los que os quedásteis atascados en algún reto y estábais pendientes de la publicación de las soluciones por nuestra parte… una vez más, perdonad el retraso, aquí lo tenéis por fín :)
Como ya comentamos al principio del concurso, las soluciones que os proponemos no son más que una de las muchas formas de resolver los retos. Muchos de vosotros, sobre todos aquellos que habéis completado todos los retos o la mayoría de ellos, los habéis enfocado de forma diferente a cómo nosotros los diseñamos inicialmente cuando pensamos en ellos… así que si encuentras formas alternativas, e incluso mejores… no dudes en participar en los comentarios ya sea aquí o en el blog del concurso, la idea es aprender unos de otros.
Aquí, en mi blog, publicaré las soluciones a los retos que diseñé para Geek Puzzle II. También los tendréis dispònibles en el blog del concurso, junto con las demás soluciones al resto de los retos que diseñaron los otros miembros del Geek Puzzle Team.
Empecemos en orden cronológico por el reto 0×02 al que bauticé como “Virtual Crackable Network“.
En este reto, se os proporcionaba un fichero, y se os solicitaba lo siguiente base64(”usuario:password”).
Una vez descargado el fichero, el propio nombre reto02.cap.bz2 ya indica que puede tratarse de una captura de tráfico en formato pcap. Efectivamente, una vez se descomprime, se comprueba que es una captura de tráfico que puede visualizarse sin problemas con wireshark. Analizando con algo de detenemiento el tráfico que se proporciona en al captura, se ve sin problemas que se trata del establecimiento de una sesión PPTP.
Para superar el nivel se nos pide la codificación bse64 de la cadena de texto “usuario:password”, por lo que resulta evidente que lo que habrá que hacer es crackear este establecimiento de sesión PPTP para obtener el usuario y el password que están siendo usados.
La autenticación usada por PPTP es MSCHAPv2, un mecanismo de autenticación que puede ser atacado mediante un procedimiento de fuerza bruta basado en diccionario. Una posibilidad para llevar a cabo el ataque es usar la herramienta asleap, y precisamente será la que usaré para nuestra solución propuesta.
Conociendo un poco como funciona MSCHAPv2, nos daremos cuenta que para usar asleap con el fin de romper la autenticación, se debe obtener el challenge del cliente, el challenge del servidor y el nombre del usuario que se está autenticando, que en este caso es el usuario “remote“. Se cogen estos tres datos, se genera el SHA1, y se cogen los ocho primeros bytes, que es el challenge que habrá que darle al asleap junto con los 24 bytes de respuesta del servidor. Todo esto se puede ver muy facilmente en wireshark si filtramos el tráfico PPTP y nos quedamos únicamente con los paquetes que intercambian el cliente y el servidor en el establecimiento de la VPN.
El asleap necesita por otro lado, como se ha indicado antes, la lista de palabras para generar el ataque de diccionario. Se puede empezar por lo evidente, que es usar un diccionario de palabras en castellano. Si estamos en un sistema Linux, lo más cómodo es instalar el paquete wspanish. A partir de la lista de palabras, se generan los hash de las mismas con el comando genkeys que viene con el asleap y se guarda la lista de hash en un fichero.
Ya solo resta lanzar el asleap y esperar a que haga match alguna de las palabras… en este caso, a los pocos segundos/minutos obtendremos la tan ansiada password en nuestro terminal ;)
asleap -C 40:2f:60:d2:a9:34:99:c6 -R f1:68:d0:4a:c7:f6:3d:08:f9:c4:fb:6a:5d:34:2c:60:ae:a5:32:c0:a7:0a:c8:5f -f spanish.dat -n spanish.idx asleap 2.1 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com> hash bytes: 3a81 NT hash: 651b9a1752ecd5b80d84d02ecb023a81 password: paranoia
Como veis, se lanza asleap indicando los 8 primeros bytes del hash SHA1 de la concatenacion de datos previamente dicha. La respuesta recibida del servidor. El fichero con los hash de las palabras y el fichero con las palabras en texto claro.
¡Bingo! El password es “paranoia”. Por lo que obtener la clave del nivel ya es trivial, generar el base64 de la cadena “remoto:paranoia“.
De las respuestas recibidas encontramos algunas alternativas interesantes, con herramientas que requieren menos “procedimiento artesanal” y lo hacen de forma mucho más directa. Algunas propuestas:
- Daniel Kachakil. Hizo un replay del tráfico, lo capturón con Cain y lo crackeo desde la propia herramienta.
- Amin Taouirsa. Nos comentó que descartó asleap en favor de anger, un sniffer de PPTP que captura el establecimiento de sesión y hace que el crackeo sea un juego de niños.
- Unai Avila y Juanan Pereira siguen el mismo método, resolviéndolo utilizando la guia y herramientas disponibles aqui.
Al parecer, por los comentarios que recibimos de vosotros, esta prueba os gustó bastante, y muchos encontrásteis documentación y herramientas interesantes durante el proceso de resolución. A muchos os dio algún que otro quebradero de cabeza el extraer los challenge del fichero de captura o el pasar de un formato a otro para usar la herramienta de crackeo, pero en general la sacastéis bastante rápido ;)
Tenéis los comentarios a vuestra disposición para seguir profundizando en el tema si os apetece. El siguiente reto que comentaré será el 0×04… que parece ser que fue uno de los que más os hizo sufrir ;)