1. Identificando el tipo de tarjeta NFC
Lo primero es identificar el tipo de tarjeta. Lanzando comandos como “lf search” o “hf search” enseguida vemos que se trata de una tarjeta de alta frecuencia (hf – high frequency) de tipo Mifare Classic 1k.
Vemos que tiene el UID AB 1D A2 24. Aunque para la resolución del reto no es relevante. Todas las acreditaciones tienen los mismos datos y el mismo UID.
2. Lectura por defecto de los sectores
Ahora lanzaremos un comando para ver si podemos leer todos los sectores. “hf mf chk *1 ?”
Como podemos observar en la columna res, todo lo que está con el valor “1” es que se ha podido leer porque tenía una clave muy estándar como es el caso de la key ffffffffffff o aabbccddeeff y lo que está con “0” no se ha podido leer porque tiene una clave que no es estándar. Por lo que hemos podido leer todo a excepción de los sectores 002, 012 y 013 de la sección A de la tarjeta.
3. Lectura completa de la tarjeta
Para poder acceder a todos los datos debemos ser capaces de leer todos los sectores. Para ello, llegados a este punto hay diferentes técnicas. Está el ataque “hardnested” que puede ser llevado a cabo con la aplicación “mfoc” o con el software de la Proxmark3. En nuestro caso, no nos complicaremos tanto ya que como siempre en todo “crackeo” primero antes de meternos en ataques de fuerza bruta, se suele probar ataques por diccionario. En este caso bastará con utilizar cualquiera de los diccionarios estándar que vienen con el software de la Proxmark3. En la carpeta “client” tenemos el fichero “default_keys.dic” que hará las funciones perfectamente como diccionario y será capaz de crackear sin problemas los sectores que nos faltan por leer.
Lanzaremos el comando “hf mf chk *1 ? d client/default_keys.dic”.
Mostramos primero la parte de arriba (donde lanzamos el comando).
Pero la parte interesante es la parte de abajo donde vemos que ahora tenemos todas las columnas “res” con el valor “1” incluyendo los sectores 002, 012 y 013 que antes no podíamos leer. Tenían la clave 111111111111 que se encontraba incluida en el diccionario utilizado.
4. Creando un fichero dump
Ahora como podemos leer completamente la tarjeta, podemos hacer un “dump” completo de la misma. Utilizaremos el comando “hf mf dump 1”.
Mostramos la parte de arriba (donde lanzamos el comando).
Y ahora la parte final de la salida del comando.
Como podemos ver, lo ha guardado en un fichero llamado “dumpdata.bin”. A partir de ahora ya no necesitaremos más utilizar nuestro hardware NFC.
Trabajaremos con el fichero.5. Estudiando los datos existentes en los sectores
Abrimos el fichero en un editor hexadecimal. En este write-up se ha utilizado el software gratuito de Windows HxD. Rápidamente observamos varias cosas. A primera vista, además de un flag claramente troll, vemos un par de hints señalados en rojo en la imagen.
Parece que la cosa tiene que ver con algo de criptografía básica. Concretamente AES.
También se observan unos sectores con datos. El sector 001 por una parte y los sectores 011 y 012 por otra. Centrémonos en su contenido. El sector 001 contiene una cadena ASCII extraña que remarcamos en rojo en la siguiente imagen.
En los sectores 011 y 012 también hay datos, además de que el primero de ellos comienza con la cadena “Salted”, algo bastante característico de un cifrado AES.
Por si no ha quedado claro, ¿cómo identificar que filas son de cada sector? Lo podemos hacer o bien contando, o bien tomando como referencia las keys. Recordemos que en los sectores 012 y 013 la key utilizada fue la que salió tras efectuar el ataque de diccionario. Era la key 111111111111. Como podemos observar en las filas 00000330 y 00000370 las primeras columnas son esta key, por lo que podemos deducir que son los sectores 012 y 013, aunque los datos que nos interesan están en los sectores 011 y 012 ya que el 013 está vacío (todo a ceros).
6. Descifrando AES
Ahora que tenemos todos los elementos solo falta ponerlo todo junto. Copiaremos los datos (en hexadecimal) del sector 001:
Obtenemos esta cadena:
“652DE5BAA4FD0130503ED72FBDED1BBA61C1260A1A3E2160194F7AFFE79B632E082820DAD3C1D3B5532E7C05E3FE0800”
Hacemos lo mismo con los datos de los sectores 011 y 012 (solo la parte que tiene datos):
Por lo que obtenemos la cadena hexadecimal:
“53616C7465645F5FC7C935F41C52F032A139656448A1A19C271851889AC1C5B0D7444D0F01F72E68336A0C3E95A4470743D25186C6947A5B9D02F095CA3C8908”
Como esta última parte es la que contiene el comienzo de cadena “Salted”, sabemos que es lo que está cifrado con AES. Y la cadena que estaba en el sector 001 es otra cosa... muy probablemente la key utilizada para cifrar.
Ahora utilizamos mismamente la web online https://gchq.github.io/CyberChef/ para transformar esta última cadena hexadecimal (la de los sectores 011 y 012) a un fichero poniendo el filtro “from hex” como se ve en la imagen y descargamos el fichero. El resultado es el fichero AES que hay que descifrar. Llamaremos al fichero por ejemplo “cifrado”.
Ahora teniendo ya el fichero a descifrar y la supuesta key, recordemos el hint que decía “Recuerda que la key es b64” por lo que cogeremos la cadena hexadecimal (la del sector 001) y utilizando también la misma web Cyberchef la transformaremos con el filtro “from hex” y “to base64” como indica la imagen:
Obtenemos la cadena resultante
“ZS3luqT9ATBQPtcvve0bumHBJgoaPiFgGU96/+ebYy4IKCDa08HTtVMufAXj/ggA” y la guardaremos en un fichero llamado por ejemplo “key.b64”.
Ahora con ayuda de openssl desciframos el fichero con el siguiente comando:
“openssl enc -aes-256-cbc -d -pass file:key.b64 -in cifrado -out archivoclaro.txt”
A pesar de los warnings por utilizar una derivación del cifrado un tanto obsoleta, obtendremos el resultado en un fichero llamado “archivoclaro.txt” según hemos indicado en el comando.
Este fichero contiene la flag.
Writeup gracias a @oscarakaelvis
Agradecimientos: @oscarakaelvis, @gibdeon, @frankytech
Ganador/es: Alexis Fernandez +2
Comentarios
Publicar un comentario