#GeratuEtxean: HackIt! Level 3

Para terminar, un clásico.

Un ELF para arm64 con mensaje para w0pr / Ramandi incluido 🙂

Abrimos con Ghidra y vemos que hay una función encargada de pedirnos 16 caracteres y comprobar que forman una key correcta.

Toca generar el programa que revierta las comprobaciones… Pero antes habrá que arreglar ese monstruo de código del descompilador…

$ file cambridge_technology
cambridge_technology: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped

$ uname -a
Linux ip.ec2.internal 5.0.10-300.fc30.aarch64 #1 SMP Tue Apr 30 16:06:13 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

$ ./cambridge_technology
Password: 12312312313123131
FAIL!

w0pr (@abeaumont en concreto) fue el primer y único equipo que consiguió hacer ingeniería inversa de ese monstruo ¯\_(ツ)_/¯ Alfredo ha publicado el write-up, merece la pena leerlo (y replicarlo) con detalle.

#GeratuEtxean: HackIt! Level 2

Nuestros espias han localizado la flag de este nivel, pero… ¡Alguien ha destruido la caja de password! Afortunadamente, nos han proporcionado instrucciones para enviarla, pero no acabamos de entenderlas… ¿Nos ayudas?

— BEGIN TRANSMISSION —
PAYLOAD FOUND ON trololo@54.171.128.20:34342
ACCESS b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW QyNTUxOQAAACD48tA2UHkNwf1gjzFoefbSiiA3s0+FIYWYOlxHuwDAVAAAALhSf19rUn9f awAAAAtzc2gtZWQyNTUxOQAAACD48tA2UHkNwf1gjzFoefbSiiA3s0+FIYWYOlxHuwDAVA AAAECeukBbUT2Vlozfd98BRRvKGCFRc0mdvRhAItlDfp1U7vjy0DZQeQ3B/WCPMWh59tKK IDezT4UhhZg6XEe7AMBUAAAALnJvb3RAaXAtMTcyLTMxLTYtNjUuZXUtd2VzdC0xLmNvbX B1dGUuaW50ZXJuYWwBAgMEBQYH
IDENTIFY USING 20ce8a7cc776a39ad291d4648e3e39ae.hax
SEND FLAG AS TEXT
— END TRANSMISSION —

Si nos intentamos conectar por ssh trololo@54.171.128.20 -p 34342 vemos que el servidor responde, pidiendo clave pública. Descodificando el string de ACCESS de base64, vemos una referencia a una máquina remota (AWS) y esta keyword: openssh-key-v1nonenone3

Haciendo pruebas, detectamos que la clave sigue el algoritmo DSA (no RSA). La preparamos:

$ cat id_dsa
—–BEGIN OPENSSH PRIVATE KEY—–
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACD48tA2UHkNwf1gjzFoefbSiiA3s0+FIYWYOlxHuwDAVAAAALhSf19rUn9f
awAAAAtzc2gtZWQyNTUxOQAAACD48tA2UHkNwf1gjzFoefbSiiA3s0+FIYWYOlxHuwDAVA
AAAECeukBbUT2Vlozfd98BRRvKGCFRc0mdvRhAItlDfp1U7vjy0DZQeQ3B/WCPMWh59tKK
IDezT4UhhZg6XEe7AMBUAAAALnJvb3RAaXAtMTcyLTMxLTYtNjUuZXUtd2VzdC0xLmNvbX
B1dGUuaW50ZXJuYWwBAgMEBQYH
—–END OPENSSH PRIVATE KEY—–

Y conectamos:

$ ssh -i id_dsa -p 34342 trololo@54.171.128.20
Last login: Sat Mar 28 14:34:31 2020 from xxxxxxx
-sh-4.2$

Es una shell restringida (ni ls, ni gaitas). Además, si intentas borrar algo, te añade un espacio en blanco… En fin… El autocompletamiento con tabulador funciona. Vemos que existen algunos directorios, entre ellos /bin. Añadimos /bin al PATH y disponemos de cat, dig, ls y nsupdate.

El comando dig nos da una pista…. recordemos también que no hemos usado esta parte del enunciado:

IDENTIFY USING 20ce8a7cc776a39ad291d4648e3e39ae.hax

Investigando un poco vemos que existe un proyecto con TLD .hax para DNS dinámicos. La otra pista «SEND FLAG AS TEXT » nos parece indicar que necesitamos crear un registro TXT con la Flag. ¿Pero dónde está la flag? Bueno, no había muchos directorios en la máquina restringida donde nos encontramos, así que rastreando carpetas nos encontramos con /var/tmp/secret,

-sh-4.2$ cat /var/tmp/secret
Is0latI0nFl4w3dNetW0rkz!

Pedimos un dig del TLD hax:

dig -t txt 20ce8a7cc776a39ad291d4648e3e39ae.hax

y vemos que vamos bien:

-sh-4.2$ dig -t txt 20ce8a7cc776a39ad291d4648e3e39ae.hax

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> -t txt 20ce8a7cc776a39ad291d4648e3e39ae.hax
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12895
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;20ce8a7cc776a39ad291d4648e3e39ae.hax. IN TXT

;; AUTHORITY SECTION:
hax. 60 IN NS ns1.hax.

;; ADDITIONAL SECTION:
ns1.hax. 60 IN A 127.0.0.1

;; Query time: 0 msec
;; SERVER: 172.31.6.65#53(172.31.6.65)
;; WHEN: Sat Mar 28 16:41:53 UTC 2020
;; MSG SIZE rcvd: 136

Nos queda hacer el nsupdate … pero antes, veamos quién resuelve los DNS en esta máquina:

-sh-4.2$ cat /etc/resolv.conf
nameserver 172.31.6.65

$ nsupdate

server 172.31.6.65

update add 20ce8a7cc776a39ad291d4648e3e39ae.hax. 300 TXT «Is0latI0nFl4w3dNetW0rkz!»

send

Y listo! Pulsamos en el botón que nos ha preparado la ORG en ese level y pasamos de nivel

#GeratuEtxean: HackIt! Level 1

Esta edición de la GipuzkoaEncounter ha sido un tanto extraña. Confinados en casa, hemos intentado llevarlo lo mejor posible. Aunque no es para nada lo mismo y todos preferimos la presencial, esta edición online no ha estado nada mal. Y para no perder las buenas costumbres, vayamos con el write-up.

¡Ayuda! ¡Nos han hackeado la cuenta de Discord! Parece que han hecho cosas raras. Hemos conseguido un log de lo que han hecho…

Nos pasan un fichero .har (un dump de una conexión HTTP). Aunque internamente es simplemente un enorme fichero JSON, lo mejor para visualizarlo de forma rápida es abrirlo directamente con el editor de Chrome DevTools, pestaña Network. Importamos el fichero HAR para echarle un vistazo y vemos lo siguiente.

Podemos ver puntos verdes en la línea del timeline, donde van varios POST

Seleccionando uno de esos puntos:

Mensajes POST hacia el servidor de Discord. Se ve que el usuario está tecleando contenido («0ur53»)

El problema es que no vale con recorrer esos mensajes de tipo POST. Hay una complicación: el autor del reto ha editado algunos trozos (mensajes con método HTTP PATCH) e incluso borrado otros (mensajes DELETE).

Solucionamos con un pequeño script en nodejs

HackIt! 2019, Level 2

Este level parece que se le atragantó a muchos grupos. Aunque estuvimos unas cuantas horas dándole vueltas, una vez resuelto te das cuenta de que, lo que lo hacía complejo, realmente eran varios red-herring o falsas pistas. Si las seguías, estabas muerto. El level empieza con 3 ficheros: yellow, red, green. Aquí está el primer anzuelo: ¿para qué estos colores?… En fin, sacando strings, el que más llama la atención es red.

Juanan-2:2 juanan$ strings -n 12 red|more
Ktablered1000red1000^LCREATE TABLE red1000(redz blob)N
ytablered100red100
CREATE TABLE red100(reda varchar(10),redb varchar(10))H
utablered9red9
CREATE TABLE red9(reda varchar(10),redb varchar(10))H
utablered8red8
CREATE TABLE red8(reda varchar(10),redb varchar(10))H
utablered7red7
CREATE TABLE red7(reda varchar(10),redb varchar(10))H
utablered6red6
CREATE TABLE red6(reda varchar(10),redb varchar(10))H
utablered5red5
CREATE TABLE red5(reda varchar(10),redb varchar(10))H
utablered4red4
...
CREATE TABLE red1(reda varchar(10),redb varchar(10))
0000000 5473 6572 6d34 3352 000a

Vaya… una base de datos, probablemente SQLite. Y el campo redz de la tabla red1000 es de tipo blob. Estuvimos dándole vueltas y vueltas a esto. Conseguimos incluso importar la estructura de las tablas.

En la tabla red1, la columna reda tiene algo:

Pero eso ya salía en los strings, no hacía falta liarse la manta con SQLite… Mmmh, veamos qué significa:

misterio = [0x54,0x73,0x65,0x72,0x6d,0x34,0x33,0x52,0x00,0x0a]
import binascii
print("".join( chr(c) for c in misterio))
Tserm43R

¿Tserm43R? WTF? @ochoto comentó en el grupo que tal vez habría que darle la vuelta a cada par de valores (big endian?) porque los últimos bytes son un salto de línea + fin del string invertidos (0x00, 0x0a). Vamos allá (quitando el salto de línea):

misterio = [0x54,0x73,0x65,0x72,0x6d,0x34,0x33,0x52]
"".join([chr(a)+chr(b) for a,b in [i for i in zip(misterio[1::2], misterio[::2])]])

'sTre4mR3'

Tiene sentido, parece un trozo de string en h4x0r. Dejémoslo ahí y vayamos a por green. Este fue más fácil:

$ binwalk -e green

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
27337196      0x1A121EC       HPACK archive data
33554432      0x2000000       gzip compressed data, has original file name: "trololo", from Unix, last modified: 2019-07-15 23:29:50

$ ls -al _green.extracted/
total 8
drwxr-xr-x   3 juanan  wheel    96 Jul 25 21:28 .
drwxrwxrwt@ 70 root    wheel  2240 Jul 29 22:15 ..
-rw-r--r--   1 juanan  wheel     8 Jul 25 21:28 trololo

$ cat _green.extracted/trololo
ce1VEd!

Vaya, si concatenamos red con green (mismo orden que el enunciado), obtenemos ‘sTre4mR3ce1VEd!’. Tiene muy buena pinta. Sólo nos queda un fichero, yellow. Es un fichero binario, sin ningún magic number ni strings asociados. Tras muchas vueltas, se nos ocurrió algo evidente (a que sí, @navarparty? XDDD), abrirlo con Audacity:

Bingo, se oye a alguien deletreando, en inglés y a mucha velocidad, la parte que nos falta del password. Ajustando la velocidad y teniendo en cuenta que las zonas más oscuras de la señal reflejan mayúsculas, obtenemos R0tT3nB1t.

Así que… R0tT3nB1tsTre4mR3ce1VEd!

Nota: este post no refleja la dificultad de la prueba. No fue «tan fácil» como parece 🙂 Estuvimos muuuuuuuuuucho tiempo analizando los 3 binarios hasta encontrar la secuencia de pasos y herramientas adecuadas.