Perspectivas en competiciones CTF. Capítulo II

Esta entrada corre a cargo de @tunelko, analista de seguridad miembro de @DefConUA y apasionado jugador de competiciones CTF.

En el anterior artículo de esta serie empezamos a hablar sobre algunas diferencias y enfoques existentes en las competiciones de seguridad.

Se me olvidó comentar que hay dos tipos de plataformas donde podréis jugar. Las que te cobran por participar (huid!) y las que son organizadas de forma altruista por personas que invierten su tiempo a cambio únicamente de la satisfacción de que otros puedan aprender. No voy a ser yo quien diga a nadie cómo tienen que ganarse la vida los demás pero sí me gustaría advertir que existen competiciones de pago que, al menos para mí, me parecen engañosas. ¿Una plataforma de retos tan atractiva que hay que pagar? ¿Qué diferencias existen con las demás? Otra cosa bien distinta es que, con algún tipo de certificación o curso te den acceso a laboratorios o competiciones para poder poner en práctica los conocimientos. ¡Sí!, eso sí me gusta :).

En este capítulo quisiera hablar del aspecto estratégico a la hora de participar en competiciones por equipos. Todo ello dirigido a optimizar al máximo el tiempo de resolución de las pruebas.

La comunicación

Cuando juegas en equipo es vital contar con una herramienta de comunicación adecuada para intercambiar información entre los miembros. Desgraciadamente el IRC o la mensajería no constituyen el canal óptimo. Necesitamos compartir piezas de código, “exploits”, subir ficheros o mostrar cómo resolver un reto para que los compañeros vean y aporten posibles comentarios y mejoras. La rapidez con la que resolváis pruebas, en algunos casos, puede suponer el límite entre el primero y el segundo. Pensar en cómo resolver la prueba y usar técnicas adecuadas es una cosa y resolverla en el mínimo tiempo posible, otra bien distinta.

Afortunadamente existen en Internet herramientas colaborativas con planes gratuitos con las que podremos empezar a explorar las opciones que ofrecen para ver si se adecúan a nuestras necesidades. Algunas de ellas están en Github y son software libre, si contáis con recursos para su instalación y configuración, tendréis total libertad para adaptarlas y personalizarlas y no dependeremos de terceros de cara a proteger la privacidad de nuestro equipo.

El tiempo

La duración media de un CTF suele ser de 24 o 48 horas y se realiza durante el fin de semana. Competir lleva tiempo y consume mucha energía. Normalmente un equipo debe establecer unos criterios para descansar y gestionar los descansos. Sí, ya sé que puede parecer descabellado, pero dormir es importante ;)

“Team leader”

Un equipo debe contar siempre con un capitán. La elección de la persona debería surgir de forma natural. Alguien que sea capaz de ganarse el respeto en el grupo resolviendo pruebas o conflictos internos. Dentro de sus tareas y responsabilidades está la comunicación, durante y posterior, con los organizadores de los distintos CTF en los que participemos. Ha de seleccionar a los miembros del equipo que irán a las competiciones, determinar cierto equilibrio en la participación de las pruebas y seguir la evolución que tiene el equipo en la clasificación general. Supongo en este punto alguien puede pensar que “todos son parte del equipo y todos pueden hacer de capitán”. Esto, bajo mi punto de vista, es un error. Debemos repartir y asignar tareas y tener cierta coordinación.

Expansión, crecimiento y cantera

La capacidad de crecimiento de un equipo en competiciones CTF siempre viene dada por la experiencia de sus miembros en competiciones. Podemos tener un crecimiento vertical, incorporando a “fichajes” muy buenos o hacerlo “en la base horizontal” con un equilibrio entre la calidad y la constancia en los integrantes. Personalmente prefiero la segunda opción ya que si no un equipo no es constante, los puntos que ganen serán fugaces.

Para lograr cierta longevidad, los equipos suelen tener una cantera de miembros que, si bien no participan en las grandes competiciones, están ahí aprendiendo en otros eventos para en un futuro tomar el relevo. Suelen ser jóvenes, en sus primeros años de carrera y con mucho interés en la seguridad informática. Estos miembros entrenan en sitios que permanecen abiertos todo el año y juegan en las competiciones secundarias hasta que estén preparados para resolver pruebas más complejas. Son fundamentales para el equipo porque aportan ideas frescas y puntos de vista que algunos veteranos dan por sabidos.

Todos estos aspectos son importantes si queremos hacernos con un hueco en el top de ctftime.org. Ahora bien, más importante que todo esto es pasárnoslo bien, aprender y disfrutar sin agobios.

¿Y la estrategia?

Ah, ¿que pensabas que iba a hablar de la estrategia? No haría honor al código del guerrero de CTFs: no reveles tu estrategia. Bromas aparte, hemos hablado al principio de la comunicación. Para mi es el pilar fundamental a la hora de competir. Es la base. Tener rapidez implica tener una buena comunicación y esto es tener fluidez con herramientas que lo permitan, entre otras cosas. Yo empezaría por ahí.

A los que todavía jugáis en solitario os recomiendo juntaros. Como todo en esta vida lo que se hace compartido es más emocionante y productivo. Me despido ya, os dejo la solución al anterior reto y os agradezco vuestra paciencia. Ah! y si pasáis estos días por Euskadi os recomiendo el primer congreso de seguridad informática, concretamente en Donosti, que han montado las personas de la “Asociación Euskal Hack”.

Gracias a todo el equipo de @SecurityArtWork, por dejarme escribir en tiempo y forma, son geniales.

Solución al reto “Access denied”

El reto pedía usuario y contraseña para entrar a una zona restringida y tenía un “checkbox” para recordar nuestra decisión. Nos daban un usuario demo para probar el acceso. Con todos estos ingredientes, lo que debíamos hacer era entrar con ese usuario “demo” activando el “remember”. Al hacerlo se grababa una cookie con la siguiente información serializada:

a:2:{s:5:"login";s:4:"user";s:8:"password";s:64:
"d74ff0ee8da3b9806b18c877dbf29bbde50b5bd8e4dad7a3a725000feb82e8f1";}

Sabemos de algunas vulnerabilidades en los serializados y podemos obtener información en este documento de Stefan Esser sobre algunas de ellas.

Si analizamos el código que nos muestra el reto, hay una línea que no hace un uso correcto del comparador en la comprobación del password. Emplea ‘==’ en vez de ‘===’ que es el que se considera seguro.