La semana pasada asistí por primera vez a la ekoparty después de muchos años tratando de ir. Cerca de 2500 asistentes (más menos cinco veces la 8dot8 Chile), un programa de charlas técnicamente interesantes y un buen ambiente con un montón de desafíos por parte de compañías y organizaciones.
El que más me llamo la atención fue el CTF oficial de la conferencia organizado por Null-Life. Anteriormente no había tenido tiempo para participar en las versiones remotas así que me anime para la competencia local y logré el segundo lugar!
Fue una competencia dura ya que participé solo y la mayoría de los contrincantes eran teams de 3+ personas. Sumado a eso, no iba preparado: no tenía máquinas virtuales en mi laptop ni servidores con salida directa a Internet.
Sin embargo, logré resolver varias tareas:
Hay un claro déficit en el área de reversing y exploiting ya que no es mi fuerte. Conforme a eso, hay una serie de writeups ya en Internet así que me centraré en dos que me permitieron obtener el segundo lugar debido a su puntaje: LSSO (Misc 200) y The Fake Satoshi (Misc 300).
LSSO
All my passwords are safely stored, or not?
Junto a esto, venía el siguiente adjunto: misc200.zip. Lo primero que me llamó la atención fue que viniera un fichero comprimido .rar dentro del .zip, lo cual no era común en las otras tareas.
Dentro del .rar venían dos ficheros: cwallet.sso y ewallet.p12. Buscando en Google por el primer fichero veo que corresponde a una solución de Oracle para guardar información de autologin. También en los primeros resultados sale una referencia a ssoDecrypt, la cual es una herramienta para descifrar estos ficheros. Después de instalarla una primera corrida arrojó lo siguiente:
$ ./ssoDecrypt.sh ../cwallet.sso
PKCS12 key store mac invalid - wrong password or corrupted file.
PKCS12 key store mac invalid - wrong password, wrong LSSO secret (username + hostname) or corrupted file.
Leyendo más sobre la herramienta, al final de su README sale una referencia a Local SSO wallet, por lo que relacionando con el título LSSO, la respuesta debía ir por ese lado. ¿ Dónde encontrar el usuario y hostname? Los ficheros comprimidos soportan comentarios así que lo primero en revisar sería el famoso .rar.
$ unrar v ekochall.rar
UNRAR 5.30 beta 2 freeware Copyright (c) 1993-2015 Alexander Roshal
By Hugo@ekodesktop
[...]
Tenemos nuestro usuario y hostname, ahora a intentar obtener la respuesta.
$ ./ssoDecrypt.sh ../cwallet.sso Hugo ekodesktop
sso key: a252ece7d911fa0e
sso secret: 0e6b16ac78d6231bd237e71e0bb931c53765a6bf8f356acd
obfuscated password: 444a4f701601137b7447745039566b03
p12 password (hex): 2b416f615a571a645f442766103d2334
--------------------------------------------------------
----------------------------------------------
Credential #1: ekoparty/EKO{vPgsSHXO0LiHlZk667Xr}@ekoparty
La solución era EKO{vPgsSHXO0LiHlZk667Xr}.
The Fake Satoshi
Hello Mr. Giarc, upload again your false PGP key to pgp.mit.edu and send us any file you want with its signature to prove you are the fake Satoshi!
The key on the server should look like the following line (case sensitive):
Type bits/keyID Date User ID
pub 1024R/5EB7CB21 2008-10-30 Fake Satoshi EKOPARTY12 (csalazar) <satoshin@gmx.com>
Cuando leí este desafío, se me vino en mente un problema que hubo este año sobre las short-key ids en el desarrollo de un software open-source. Teniendo ya claro para donde iba el asunto, leí un completo post sobre la problemática escrito por Gunnar Wolf.
Este post menciona el proyecto scallion que sirve para generar llaves GPG con ciertas características. Para este caso, hay dos requerimientos:
- Los últimos 8 bytes del fingerprint (
short-key-id) debe ser5EB7CB21. - La fecha de generación de la llave debe ser
2008-10-30.
Afortunadamente scallion soporta expresiones regulares para definir los requerimientos de nuestra llave y el requerimiento de la fecha se puede solucionar fácilmente. Mi laptop no cuenta con una tarjeta GPU activa por lo que mi primo Francisco Chirino me ayudo en la generación de la llave apropiada:
scallion.exe --gpg 5EB7CB21$
El output de ese comando contiene una llave privada que tiene short-key-id=5EB7CB21. Teniendo ya la llave GPG privada en satoshi.key, la importé en el anillo GPG:
$ gpg --import --allow-non-selfsigned-uid satoshi.key
Lo último que quedaba por editar era el nombre que aparecía en la llave, lo cual se puede hacer con la opción --edit-key:
$ gpg --edit-key 5EB7CB21
Ahí es necesario eliminar el nombre inicial y agregar Fake Satoshi EKOPARTY12 (csalazar) con el correspondiente e-mail satoshin@gmx.com. Finalmente, subí la llave a pgp.mit.edu con la opción --send-keys:
$ gpg --send-keys --keyserver pgp.mit.edu 5EB7CB21
Luego, el reto consistía en firmar un fichero cualquiera (en este caso boom.txt) con la llave:
$ gpg -u 5EB7CB21 --sign boom.txt
Se debía subir el fichero y la firma. Tras eso, el servidor bajaba todas las firmas con short-key-id=5EB7CB21 para verificar si mi fichero fue firmado por una llave con ese short-key-id. Como lo anterior es verdadero, retornaba la solución en su output.