Conferencia ISSA-Spain (Madrid)
El pasado jueves día 15 se celebró en Madrid la 2ª edición de las Conferencias ISSA de Seguridad. Heredando, en cierto modo, el espíritu de las Conferencias FIST, con mismo lugar de celebración y formato similar, se contó en esta ocasión con la presencia de Samuel Linares quien presentó una interesantísima charla sobre la seguridad lógica en entornos industriales e infraestructuras críticas, con Rob Kloots quién nos ilustró sobre métricas en proyectos de seguridad y por último, el que yo personalmente considero el plato fuerte de la jornada, la ponencia de Gonzalo Alvarez sobre computación cuántica y cómo puede afectar este nuevo paradigma a la criptografía simétrica y asimétrica tal y como la concebimos hoy día.
La charla sobre seguridad en entornos industriales e infraestructuras críticas me pareció realmente interesante. Sin entrar tampoco en gran detalle, supuso una buena toma de contacto con este asunto, y un repaso a la evolución que han sufrido los entornos industriales en los últimos 15 años, lo cual marca su estado actual de indefensión mezcla de su apertura a redes como Internet o a su integración con sistemas abiertos y redes IP. La historia es bien conocida, el choque de dos mundos completamente diferenciados, el de las IT y el del negocio al que lo único que le importa es que se siga produciendo y que ve las infraestructuras de IT como una herramienta más a la producción y que no hay que tocar si no da problemas. Esto nos lleva a sistemas con Windows 95 en pleno año 2010, o a sistemas que siempre han estado aislados en redes con protocolos propietarios, que se encuentran actualmente conectados a redes IP o incluso accesibles vía Internet.
Cuando estos sistemas son los que soportan la actividad básica de una sociedad “moderna” a efectos de suministro eléctrico, agua potable, control de presas, control de tráfico, etc. se los denomina “infraestructuras críticas” y su protección se convierte en asunto de seguridad nacional.
Personalmente creo que si bien este asunto siempre ha estado presente, ha sido desde hace un par de años, y especialmente en el último año, cuando más presente ha estado en conferencias y diferentes foros, especialmente con la “puesta de largo” del CNPIC español.
Por otro lado, para clausurar la jornada, la siempre interesante, amena y tremendamente ilustrativa charla de Gonzalo sobre computación cuántica. Como todos sabemos, la mayoría de actuales paradigmas de seguridad que se basan en criptografía confían en la seguridad de algoritmos de cifrado simétrico como AES y de algoritmos de cifrado asimétrico como RSA. En ambas familias de algoritmos, estamos hablando de diseños ampliamente conocidos y que han sido escrutados durante años por especialistas en criptografía, lo cual ofrece cierta confianza en su uso. En el caso del cifrado simétrico, su robustez está íntimamente ligada a la longitud de la clave que se use. En el caso del cifrado asimétrico, la seguridad computacional que ofrecen viene dada por la dificultad de factorizar dos números primos de longitud considerable.
Ahora bien, ¿qué pasaría si un nuevo paradigma como la computación cuántica echase por tierra la seguridad de los actuales estándares criptográficos? Esta es precisamente la idea que nos presentó Gonzalo en su interesante charla. Haciendo una introducción para “dummies” :) de qué es la computación cuántica, sus dos principales algoritmos de cálculo, y cómo esto afectaría en reducción de tiempos de proceso a la rotura de RSA, por ejemplo. Ahora bien… podemos estar tranquilos por el momento, las previsiones más optimistas apuntan a la aparición de un ordenador cuántico funcional en no menos de 30 años, lo cual no quita para que muchos expertos en criptiografía ya hayan entrado en la era post-cuántica, y estén estudiando algoritmos capaces de aguantar los envites de los futuros crackers cuánticos :)
Rooted CON
Me acaba de llegar ahora mismo un E-Mail confirmando mi inscripción a la Rooted CON en la cual me registré hace unos días. Este evento tendrá lugar en Madrid, del 18 al 20 de Marzo de 2010. Aún no hay publicada agenda (ni oficial ni oficiosa) ni se sabe aún qué propuestas de las recibidas en respuesta al CFP han sido aceptadas (el plazo finaliza en un par de días, el 20 de Diciembre). Lo que sí es seguro es que, en cualquier caso, será un evento interesante. Es la primera vez que se celebra una “con” de este tipo en Madrid, y quién sabe… con el tiempo, y si esta primera edición sale bien y establece un buen precedente, puede que dentro de unos años tengamos en Madrid una “con” de la envergadura del CCC de Berlin, o la Defcon/Blackhat de Las Vegas. En cualquier caso, ¿vas a ir?, ¿aún no te has registrado? ¡nos vemos en la Rooted en Marzo!
Reto Hack-It de la Euskal Encounter 17
Dice el refrán popular que “más vale tarde que nunca” y en este caso particular más vale publicar la solución de este reto cinco meses después de la Euskal, que no hacerlo nunca :)
Este año, al igual que hice el año pasado, he realizado mi modesta aportación al Hack-It de la Euskal Encounter con una prueba para gozo y disfrute del personal que tuvo a bien participar en lo que, en mi opinión personal, es una de las mejores actividades que se realizan durante este evento y al que llevo acudiendo ya la friolera de 13 años si mi memoria no me falla. Agradecer a hey_neken el haber incorporado mi reto al Hack-It de este año.
Bien, basta de rollos, ¡pasemos a la acción! :)
El sufrido participante del Hack-It, una vez llega a mi prueba, se encuentra con que lo único que se le proporciona es una dirección IP, correspondiente al servidor del Hack-It en la LAN de la party, y un puerto TCP. Lógicamente, el primer paso es hacer uso de lo que nos dicen y conectar mediante un telnet a ver qué pasa. La conexión se establece sin problemas, apareciendo lo siguiente en el terminal desde el que realizamos el telnet:
# telnet 1.2.3.4 9999
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
CONNECTED
Enter received access code:
Nos pide que introduzcamos un código, pero no sabemos la longitud del mismo o incluso el juego de caracteres válido. De igual forma, en unos pocos segundos la conexión se corta, por lo que parece que hay un timeout definido, durante el cual es necesario que introduzcamos el código que nos pide. Ahora bien, ni en la página del reto se nos da pista alguna sobre este código, ni parece que haya información oculta de ningún tipo. Debe ser que hay que extraer algo más de información de esta conexión que establecemos, que parece que es lo único que tenemos en este momento para seguir investigando.
En retos de este tipo, siempre es buena idea tener un ojo en la red, ver qué se mueve por el cable (o las radiofrecuencias) más allá de lo que vemos, así que es buena idea repetir la conexión telnet pero con un sniffer capturando todo el diálogo, no sea que haya cosas que no vemos pero que nos pueden aportar información útil. Para ello, podemos usat tcpdump, snoop, wireshark o cualquier aplicación de captura de tráfico. Repetimos el telnet y veamos que se mueve por la red…
18:01:46.461990 IP 5.6.7.8.45385 > 1.2.3.4.55555: S 2307708527:2307708527(0) win 5840 <mss 1460,sackOK,timestamp 3301879450 0,nop,wscale 5>
18:01:46.650067 IP 1.2.3.4.55555 > 5.6.7.8.45385: S 2158051019:2158051019(0) ack 2307708528 win 5792 <mss 1460,sackOK,timestamp 1964456258 3301879450,nop,wscale 3>
18:01:46.650092 IP 5.6.7.8.45385 > 1.2.3.4.55555: . ack 1 win 183 <nop,nop,timestamp 3301879497 1964456258>
18:01:48.109403 IP 1.2.3.4.31337 > 5.6.7.8.31337: UDP, length 90
18:01:48.113211 IP 1.2.3.4.55555 > 5.6.7.8.45385: P 1:11(10) ack 1 win 724 <nop,nop,timestamp 1964456624 3301879497>
18:01:48.113228 IP 5.6.7.8.45385 > 1.2.3.4.55555: . ack 11 win 183 <nop,nop,timestamp 3301879862 1964456624>
18:01:48.306398 IP 1.2.3.4.55555 > 5.6.7.8.45385: P 11:39(28) ack 1 win 724 <nop,nop,timestamp 1964456673 3301879862>
18:01:48.306415 IP 5.6.7.8.45385 > 1.2.3.4.55555: . ack 39 win 183 <nop,nop,timestamp 3301879911 1964456673>
18:02:03.120239 IP 1.2.3.4.55555 > 5.6.7.8.45385: P 39:40(1) ack 1 win 724 <nop,nop,timestamp 1964460376 3301879911>
18:02:03.120293 IP 5.6.7.8.45385 > 1.2.3.4.55555: . ack 40 win 183 <nop,nop,timestamp 3301883614 1964460376>
18:02:03.124090 IP 1.2.3.4.55555 > 5.6.7.8.45385: FP 40:67(27) ack 1 win 724 <nop,nop,timestamp 1964460376 3301879911>
18:02:03.124220 IP 5.6.7.8.45385 > 1.2.3.4.55555: F 1:1(0) ack 68 win 183 <nop,nop,timestamp 3301883615 1964460376>
18:02:03.308138 IP 1.2.3.4.55555 > 5.6.7.8.45385: . ack 2 win 724 <nop,nop,timestamp 1964460423 3301883615>
Analicemos la captura, paso por paso:
- Los tres primeros paquetes intercambiados es el establecimiento de conexión TCP.
- Nada más establecerse la conexión con el servidor, éste nos envía un paquete UDP.
- Hay un intercambio de segmentos TCP, ya que el servidor también nos envía los datos correspondientes a lo que nos aparece en el terminal, la petición del código.
- Tras 15 segundos, durante los cuales nosotros no hacemos nada, el servidor finaliza la conexión.
¡Bingo!. ¿Qué es ese paquete UDP que nos envía el servidor cada vez que conectamos?. Si se hace un dump del contenido del paquete y se realizan varias conexiones para comparar varios paquetes UDP se advierte que:
- El juego de caracteres es limitado, aparece el espacio y los caracteres _ – |
- Siempre se devuelven 90 caracteres.
- Cada conexión devuelve una secuencia de caracteres distinta.
Por tanto, viendo esto, ¿estará el código codificado con esos caracteres?. Eso parece improbable, al igual que pensar que es algún tipo de cifrado, ya que la cadena que se devuelve en el paquete UDP desde el servidor únicamente hace uso de estos 4 caracteres (los tres tipos de barras y el espacio). Ahora bien, y si estos caracteres son una representación “gráfica” de algún tipo (ASCII art) del código. Eso podría ser… ;)
Si os digo “display de 7 segmentos”… ¿a que a muchos se os acaba de encender un LED de alta luminosidad sobre la cabeza? ;)
Pues efectivamente… lo que nos está llegando en el paquete UDP es la representación “7 segmentos” del código. Si intentamos “dibujar” un digito (suponemos inicialmente que el juego de caracteres del código es exclusivamente numérico) como lo hacen los displays de 7 segmentos en ASCII nos damos cuenta de que necesitamos 9 caracteres para “dibujar” el dígito. Por tanto, podemos suponer que nos están enviando una secuencia de 10 digitos.
Hagamos una prueba. Vamos a hacer el telnet, y en otro terminal, con un nc vamos a visualizar la secuencia de caracteres que nos llegan en el paquete UDP:
# nc -l -u -p 31337 > /tmp/datos.txt
# cat /tmp/datos.txt
_ _ _ _ _ _ _ _ |_ |_||_||_| | ||_| _|| ||_ |_||_| | | | ||_||_ |_||_|
Vamos a validar la teoría, reformateamos esta secuencia, insertando un CR/LF cada 30 caracteres y… ¡et voilà!
# cut -b1-30 </tmp/datos.txt; cut -b31-60 </tmp/datos.txt; cut -b61-90 </tmp/datos.txt
_ _ _ _ _ _ _ _ |_ |_||_||_| | ||_| _|| ||_ |_||_| | | | ||_||_ |_||_|
Ante nuestros ojos (para esto mejor tener una fuente de espaciado fijo) aparece la secuencia numérica, en este caso, 6894178206. Ahora bien, únicamente nos queda resolver un pequeño “problema”. La recepción del paquete UDP, decodificación de la secuencia y envío de la contestación debe, de alguna forma, automatizarse para poder realizar toda esta secuencia de pasos dentro del timeout que cierra la conexión, o bien ser muy rápidos cambiando de un terminal a otro y tecleando el código :)
Por cierto, recordad que cada vez que nos conectamos la secuencia numérica cambia, por lo que no vale eso de conectarse, capturar y decodificar, volver a conectarse y dar como respuesta el código enviado en la conexión anterior… el malvado diseñador del reto nos obliga a programar para automatizar la decodificación, jeje ;)
Hacemos el programa, se conecta, decodifica la secuencia, la devuelve y… ¡mierda! esto aún no ha terminado, obtenemos nueva información en nuestro terminal ;)
Access Granted!
Your code is correct, use it to select the right characters and get the passphrase ;)
0 1 2 3 4 5 6 7 8 9 0 M V U S H c C s L D 1 L T J r U X d P o p 2 m Y O o q t A N j d 3 A x h W e q A s k N 4 A O j J q F g V X i 5 O N K f D F c F S N 6 S U M B r g r t H f 7 J c e s l W B V t Y 8 L M n S r r Z V x u 9 k T Q w W L L P H L
NO CARRIER
La conexión se corta tras presentar esta matriz de caracteres. De nuevo, con cada conexión tanto el código numérico como la matriz de caracteres que se obtiene al devolver el código correctamente cambia. la passphrase del nivel está oculta dentro de esa matriz de caracteres, así que parece que hay que seleccionar la secuencia de caracteres correcta para obtener la passphrase alfanumérica del nivel, y así continuar con el siguiente reto.
¿Qué coordenadas elegir?, ¿qué fila y columna seleccionar y en qué orden?… Parece lógico pensar que el código numérico y la matrix están relacionados, además ambos cambian con cada conexión. La matriz de caracteres además viene indexada del 0 al 9 tanto para filas como para columnas… ¿y si el código numérico nos indica la fila y la columna de cada caracter de la passphrase que buscamos?
Siguiendo con el razonamiento anterior, y tras algunas pruebas fallidas hasta que damos con la lógica del maquiavélico diseñador del reto ;) damos con la solución. Cada digito del código indica la columna que se debe seleccionar en cada una de las filas, y esto nos permite extraer los caracteres de la matriz. En este ejemplo concreto, los caracteres correctos son los correspondientes a las posiciones:
Caracter 0 = Fila 0, Columna 6 => C
Caracter 1 = Fila 1, Columna 8 => o
Caracter 2 = Fila 2, Columna 9 => d
Caracter 3 = Fila 3, Columna 4 => e
Caracter 4 = Fila 4, Columna 1 => O
Caracter 5 = Fila 5, Columna 7 => F
Caracter 6 = Fila 6, Columna 8 => H
Caracter 7 = Fila 7, Columna 2 => e
Caracter 8 = Fila 8, Columna 0 => L
Caracter 9 = Fila 9, Columna 6 => L
La passphrase buscada en este caso concreto es… CodeOFHeLL
Espero que os haya gustado, y a los que la pasastéis en el Hack-It de la Euskal, espero que os divirtiese romper este reto :)
Transmisión #42 de El Geek Errante
El Geek Errante ha vuelto :)
Tras más de un año y medio en “animación suspendida”, los integrantes de El Geek Errante volvemos a la carga, en lo que se podría denominar el comienzo de la “segunda temporada” :)
Los motivos por los cuales se ha producido este corte en nuestras transmisiones han sido tanto de caracter profesional, como de caracter personal, en todos y cada uno de los integrantes de la tripulación. Al final se nos hacía muy complicado el poder preparar y grabar el podcast semana tras semana, con los contenidos y nivel de calidad que le queríamos dar, así que hemos tenido que esperar todo este tiempo hasta que el ordenador central de la nave ha visto que disponiamos de ciclos de CPU suficientes como para poder abordar de nuevo esta tarea con garantías y nos ha sacado de nuestro estado de ibernación :)
En esta segunda temporada, el formato se mantendrá casi sin variación respecto a nuestras transmisiones previas y la periodicidad es la que pasará a ser mensual en vez de anual. Lógicamente las noticias que demos no serán tanto de actualidad, como antes, y pasaremos a tratar temas más “atemporales” en lo relativo a noticias, y por supuesto mantendremos nuestro formato de monográficos-tecnológicos de las cosas que nos gustan y que sabemos que a vosotros también os interesan ;)
Pues nada… que aquí estamos de nuevo. Agradecer a todos los que durante todo este tiempo habéis insistido en que grabásemos de nuevo, nos habéis preguntado, animado… ¡muchas gracias!
[ ADVERTISEMENT MODE: ON ]
Disponible la transmisión #42 de tu podcast favorito: El Geek Errante.
[ ADVERTISEMENT MODE: OFF ]
III Jornadas STIC CCN-CERT
Un año más tengo la suerte de poder acudir a las Jornadas del CCN-CERT, celebrándose en esta ocasión la tercera edición de las mismas. Estas jornadas se han ido celebrando anualmente desde el año 2.006, fecha en la que nació y comenzó su andadura el CERT y su portal web. El objetivo de esta reunión es doble, por un lado ponerse al día en el “estado del arte” de las amenazas y vulnerabilidades más relevantes presentes a lo largo del año en curso y, por otro lado, conocer de primera mano los proyectos más interesantes que en el ámbito de la seguridad que se están desarrollando en los diferentes organismos de la AAPP.
Paso a continuación a comentar brevemente cada una de las ponencias que tuvieron lugar.
- Actualización del CCN-CERT. Se comentaron las últimas novedades del portal web, resaltando los cursos de formación que en formato E-Learning pueden hacerse a través del portal, destacando el curso base que nace de la serie 400 de guías. Precisamente es en el portal donde se pueden encontrar las famosas guías STIC con recomendaciones de seguridad para casi todos los tipos de sistemas y tecnologías: Solaris, Linux, Windows, Apache, comunicaciones inalámbricas, sistemas SCADA, etc. Otro servicio interesante es el de AV On-Line y por supuesto los feed RSS para mantenerse al día en cuestión de vulnerabilidades o noticias. Destacar el magnífico servicio de correlación de eventos/logs que actualmente ofrece el CCN-CERT en lo relativo a los puntos de conexión a red SARA (Intranet Administrativa) que los diferentes organismos de las AAPP tienen, de tal forma que puedan tener una visión global de posibles ataques que se realicen desde un organismo a otro, o poder detectar con mayor eficacia patrones de propagación de gusanos. Esta misma idea anunciaron que quieren ofrecerla para los puntos de interconexión a Internet, con lo que se tendría este mismo servicio pero en lo relativo al análisis de los logs que los IDS perimetrales que dan la cara a Internet generan con los registros de ataques provenientes desde “La Red”.
- Esquema Nacional de Seguridad. Miguel A. Amutio expuso a modo de continuación a la ponencia que ya dió el año pasado en este mismo foro, los avances y novedades en lo relativo al desarrollo del Esquema Nacional de Seguridad. Resaltar que mediante este proyecto se intenta determinar la política de seguridad a aplicar a los medios electrónicos a través de los cuales los ciudadanos acceden a los Servicios Públicos ofrecidos por las AAPP, tal y como se refiere la Ley 11/2007. Como véis, muy interesante, si tenemos en cuenta que estos son los cimientos sobre los que se debe sustentar, a nivel de seguridad, la Administración Electrónica.
- Capacitación Técnica para Evaluación Hardware de Seguridad. Ponencia en la que se explicó qué se evalúa en un dispositivo que se quiere certificar y cómo se evalúa. Muy interesante su repaso a las técnicas usadas para intentar modificar un dispositivo o alterar su comportamiento, así como los procedimientos de ingenieria inversa aplicables tanto a dispositivos multi-chip como sería, por ejemplo, un router o a dispositivos inside-chip, como, por ejemplo, el DNI Electrónico.
- Seguridad Web: XSS. J.Miguel Holguín de TB-Security repasa un clásico de la seguridad web, los ataques XSS o de Cross-Site Scripting. Haciendo uso de BeEF como framework de ataque y de Damn Vulnerable Web App como plataforma atacada vulnerable a XSS, ilustró a la perfección el potencial peligro que supone una mala práctica a nivel de desarrollo web, y cómo un XSS puede derivar a algo hoy día omnipresente, como puede ser una botnet de zombies donde el vector de ataque ha sido un XSS en una página web.
- Análisis Dinámico de Riesgos. Si tuviese que describir esta ponencia con una palabra, esta sería dinámica, y no es porque el tema tratado sea el análisis dinámico de riesgos :) sino por la energía que el profesor Mañas (UPM) supo dar a su presentación sobre PILAR, la herramienta que va de la mano de la metodología MAGERIT, para la identificación de activos, evaluación de amenazas y cálculo de riesgos. Informativa y divertida, sin duda.
- Implantación de un SGSI basado en PILAR y OSS. Muy en relación con lo comentado anteriormente, Andrés Méndez de Ingenia nos presentó PULPO, una herramienta que ofrece un SGSI completo, integrando a su vez como módulos varias herramientas OSS (OCS-Inventory, Alfresco, JasperReports, Moodle) además de con PILAR.
- Panorama de las botnets actuales. Si hay una charla sobre botnets en algún congreso o foro de seguridad, es muy probable que corra a cargo de David Barroso, de S21Sec, y si así es os garantizo que no saldréis defraudados. He tenido la ocasión de ver a David hablar sobre Malware y Botnets en varias ocasiones, y es una verdadera fuente de conocimiento en lo referente a este tema. Son las típicas charlas, al menos si eres un techie como yo, que duren lo que duren siempre se hacen cortas, porque quieres más y más datos. En esta ocasión, David ha hecho un repaso a las botnets más recientes: Bobax, Warezov, Srizbi, Ozdok, Donbot, Butterfly… explicando motivaciones de cada una así como el diseño y las técnicas usadas. Creo que el fenómeno malware y por extensión el fenómeno botnet han ocupado, sin lugar a dudas, el número 1 en el ranking de amenazas en Internet desde hace 2 ó 3 años. Un fenomeno complejo, donde se mezclan techies con mafiosos, donde el dinero rápido es el principal motivador y que amenaza seriamente con envenenar la red hasta el punto de que no sea usable ni confiable por muchas contramedidas que los usuarios se preocupen en activar.
- Avances del Malware. Ero Carrera de HispaSec / VirusTotal continuó con su ponencia ahondando en el tema del Malware explicando las técnicas usadas por los troyanos más conocidos, que como comentaba antes, casi siempre van de la mano de las botnets más activas, ya que un troyano hoy día no trabaja aislado, sino que trabaja para integrar a la victima en una red de zombies dentro de la botnet, y de esa forma pasar a formar parque de la infraestructura de la botnet a efectos de implementar técnicas de protección como el fast-flux, o para envío masivo de spam, realización de ataques DDoS, etc. Ero comentó algunas técnicas frecuentemente usadas, tanto a nivel de networking (fast-flux, domain-flux) como de kernel (hooks en kernel, implementación de sus propias pilas TCP/IP, implementación de hipervisores, infección de firmwares en hardware, toma de control de los modos avanzados de gestión de las últimas familias de procesadores Intel). Todo realmente muy interesante.
- Seguridad en VoIP. Marcos Monge, de TB-Security hizo un repaso a los típicos vectores de ataque que pueden ser usados en redes que hayan desplegado VoIP hasta el puesto de usuario. No hay que olvidar que los protocolos de señalización, como por ejemplo SIP (u otros como H.323 o IAX2) no van normalmente cifrados, aunque exista la posibilidad de hacer uso de una capa SSL, y que las credenciales de autenticación van muchas veces en texto claro o como mucho como simples hash que pueden ser atacados por fuerza bruta mediante rainbow tables. Por otro lado, el tráfico RTP que es el que transporta la voz, tampoco va cifrado (aunque de nuevo se podría hacer uso de una capa SSL) y puede llegar a ser capturado y reproducido por una persona no autorizada, con herramientas como Wireshark o Cain, produciéndose el típico “pinchazo telefónico”. Las debilidades de los protocolos de señalización y de transporte de la voz, junto con los vectores de ataque típicos en una red Ethernet/IP, como por ejemplo un MiTM en base a un ARP Spoofing, pueden dar lugar a escenarios de captura de conversaciones, modificación de conversaciones, suplantación de CID, etc. Autenticaciones robustas (criptográficas), junto con el cifrado del tráfico (vía SSL), más un buen diseño de la red (segmentación en distintas VLAN, autenticación 802.1x, control de MAC/ARP spoofs…) podrían garantizar una buena implantación de VoIP en una organización… pero no siempre es así, ¿verdad? Sino no estariamos hablando de ello ;)
- Seguridad en Sistemas Wireless. Un clásico en cualquier foro de seguridad, las redes WiFi :) Sergio González, de PWC y miembro del grupo de desarrollo de WiFiSlax hizo un repaso a las vulnerabilidades de los mecanismos de autenticación y cifrado de las redes WiFi. Esto es, WEP, WPA, WPA2. Demostró cómo en la práctica, el nivel de seguridad máximo que se puede obtener sin desplegar un servidor RADIUS y autenticación mediante certificados, es decir, el nivel de seguridad que se obtiene mediante WPA2 con cifrado CCMP puede ser roto si se captura el proceso inicial de autenticación, pudiendo romper la clave mediante un proceso de fuerza bruta mediante diccionario y/o rainbow tables. Lógicamente la robustez, asumiendo que pueden capturar el inicio de una sesión, la dará únicamente la dificultad de la clave, por lo que siempre habrá que pensar en el peor escenario y hacer uso de claves que sepamos que son costosas de obtener mediante procedimientos de fuerza bruta. Con un poco más de tiempo Sergio podría haber realizado alguna prueba práctica más que tenía preparada, pero desgraciadamente los ponentes tenían unos escasos 40 minutos asignados para su exposición :(
- Seguridad en dispositivos móviles. Y para finalizar la tarde, Alberto Moreno habló de la seguridad en bluetooth, y de cómo un atacante usando un adaptador bluetooth usb al que se le ha modificado el firmware para actuar como sniffer, puede capturar el handshake inicial del proceso de peering entre dos dispositivos bluetooth, romper por fuerza bruta el PIN, y mediante un MAC spoofing hacerse pasar por cualquiera de ellos, pudiendo robar información del dispositivo aprovechando algún fallo, como el directory transversal del OBEX FTP en dispositivos HTC. La demo que hace Alberto es buenisima, además que se ve que lo tiene ya practicado y como hace un mago con los trucos de cartas y te pide que elijas una carta para a continuación adivinarla, Alberto pide a alguien que le diga un PIN para a continuación hacer la demostración de como capturar el handshake, romper el PIN y engancharse al dispositivo haciendose pasar por una de las víctimas en la cual la otra víctima ya confía. Pude asistir ya a esta misma charla de Alberto hace unos meses en el FIST de Madrid, y a raíz de aquello estuve varias semanas buscando un adaptador bluetooth con el maldito chipset CSR BC-4 (chipset de Cambridge Silicon Radio con memoria flash). Al final lo conseguí gracias a mi amiguete Iñaky (Linux Kernel Gurú) que tuvo el detalle de enviármelo desde Yankilandia y pude jugar con todo lo que comenta Alberto en sus charlas. Muy, muy, muy interesante.
Puedo afirmar que esta tercera edición ha mejorado las anteriores. Las ponencias han sido todas magnifícas, la logística inmejorable, y si hubiese que decir algo “negativo” quizás es que el tiempo dado a cada ponencia en muchos casos era insuficiente para poder abarcar el tema tratado con un mínimo de amplitud. Lógicamente el dar más tiempo implicaría que quizás el evento debería durar dos días en vez de un único día, si eso fuese posible, sería magnífico… yo creo que al final, las jornadas STIC CCN-CERT deberán pasar a un formato de varios días para poder satisfacer esta necesidad.
Reuniones SYNACK en Medialab-Prado
Durante el pasado mes de diciembre, en el Chaos Computer Congress de Berlin, estuve tanteando, entre los madrileños que por allí nos juntamos, qué les parecería la posibilidad de que nos viésemos una vez al mes y organizásemos una reunión periódica, de caracter totalmente abierto, para tener un punto de contacto en donde conocer gente con intereses comunes, intercambiar ideas y aprender unos de otros.
Yo personalmente echo en falta en Madrid movimientos de hackspace serios, en locales multipropósito que permitan dar charlas o talleres en condiciones (con sus sillas, sus mesas, su proyector, sistema de audio, una pizarra, etc.) donde poder tener quedar periódicamente a charlar, y donde podamos dar rienda suelta a nuestra curiosidad e imaginación en proyectos comunes.
Con esta idea en mente me pongo a maquinar, junto con mis cómplices Jose Angel y Mario, la idea de las reuniones… las bautizamos como SYNACK Meetings, acordamos que tendrán lugar el último domingo de cada mes, y pensamos que un buen sitio para celebrarlas es el Medialab-Prado de Madrid, que ya conocemos de algún otro evento al que hemos asistido.
El pasado viernes nos acercamos por allí los tres a hablar con Marcos y Laura, responsables de planificación y contenidos de actividades del Medialab, y a quienes ya les habíamos pasado por mail nuestra propuesta hace un par de semanas. La idea parece que ha cuajado y ya es oficial, las reuniones SYNACK tendrán lugar cada último domingo de mes, de 11:00 a 15:00 en el Medialab-Prado. La primera reunión tendrá lugar el último domingo de abril, el día 29 :)
Todas las reuniones comenzarán con una o dos charlas, de entre 45 minutos y una hora de duración cada una. Después de las charlas, podremos conocernos, charlar e intercambiar ideas entre nosotros en el espacio abierto que se abrirá a continuación.
El objetivo es tener una agenda de charlas definida para cada una de las reuniones, y que la gente se anime a participar, a dar sus charlas y a ofrecer su conocimiento a los demás.
Ilusión no falta… y lo fácil ya está hecho, ahora biene lo dificil, que la gente se anime a participar, ya sea asisitiendo ya sea colaborando activamente… ¡animáos!
En breve pondré más detalles sobre el wiki donde tendréis toda la información de las reuniones, fechas, agenda, material de las charlas, etc.
Por cierto, gracias desde aquí a Julio, complice mio también de Geek Puzzle, por el logo que ha hecho para las reuniones… ¡eres un figura! :)
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! ;)
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 ;)