DockerMaze challenge write-up
UPDATE 23/11/2015: new info thanks to @nibble_ds, one of the challenge authors, inline the post 🙂
Last November 16-17th the Dockercon eu 2015 was held in Barcelona, and the Schibsted team published the DockerMaze challenge, a labyrinth escape game like those we used to play in the 90s. In the game you wake up alone in the middle of a labyrinth and you have to escape from it, and through a console you can use commands to interact with the environment.
In this post I will show how I had fun solving the challenge! 😀
The «help» command uncovers a set of commands that includes «look», «interact» and «escape». If you do «look front» the game says that there are some signs on the wall, and after executing «inspect wall» some clues are revealed:
Found rooms:- schibstedchallenge/dockermaze-weisse:latest- schibstedchallenge/dockermaze-stout:latest- schibstedchallenge/dockermaze-porter:latest- schibstedchallenge/dockermaze-ipa:latestFound Keys:- FollowTheWhiteRabbitFollowed path:- Input: https://challenge.schibsted.com/assets/data/ct1.bin- Output: ?More than a year and I'm still here. I'm loosing all hope. Maybe there is another key?
A quick inspection of the binary file doesn’t give much information.
Next step was to download the docker images and to inspect them:
docker pull schibstedchallenge/dockermaze-weisse:latestdocker pull schibstedchallenge/dockermaze-stout:latestdocker pull schibstedchallenge/dockermaze-porter:latestdocker pull schibstedchallenge/dockermaze-ipa:latest
Let’s play with those docker images then 🙂
WEISSE
docker inspect schibstedchallenge/dockermaze-weisse:latest
Relevant info:
"Entrypoint": [ "/usr/local/bin/start.bash" ]
"ExposedPorts": { "1954/tcp": {} }
Seems that there’s a ruby application («weisse.rb») listening at the port 1954/tcp, that is executed by the bash script «start.bash». Inside that script additional information is given:
# We use eureka + prana for service discovery.
This clue will be useful later 🙂
Looking at the «weisse.rb» file I saw that the application exposes a REST endpoint («/turing») that runs the received data in an Enigma machine. Furthermore, to set up the enigma machine it tries to get some information making DNS requests to a host with name «porter».
Here are some snippets of it 🙂
...SNIP...BFBASE = 'aaa'set :bind, '0.0.0.0' set :port, 1954
post '/turing' do data = request.body.read rotors = get_rotors('porter')plugboard = Hash[*PLUGBOARD.pack('H*').split('')] plugboard.merge!(plugboard.invert) rotors.map! do |r| Hash[[r].pack('H*').split('').zip((0...256).map{|i| i.chr})] end reflector = Hash[*REFLECTOR.pack('H*').split('')] reflector.merge!(reflector.invert) enigma(data, plugboard, rotors, reflector) end
...SNIP...def get_rotors(nameserver) rotors = []Resolv::DNS.open({:nameserver=>[nameserver]}) do |r| ctr = 0loop do begin n = r.getresource("walzen-#{ctr}.dockermaze", Resolv::DNS::Resource::IN::TXT).data.to_i rescue Resolv::ResolvError break end
bf = BFBASE.dup found_chunks = 0 rotors[ctr] = ''while found_chunks < n begin ck = r.getresource("walzen-#{ctr}-#{bf}.dockermaze", Resolv::DNS::Resource::IN::TXT).data.delete('"') rotors[ctr] << ck found_chunks += 1 rescue Resolv::ResolvError next ensure bf.next! end end
ctr += 1 end endrotors end...SNIP...
STOUT
docker inspect schibstedchallenge/dockermaze-stout
Relevant info:
"Entrypoint": [ "/usr/local/bin/stout.py" ]
"ExposedPorts": { "31337/tcp": {} }
But an error is raised when trying to run the docker image:
As the container didn’t start due to the error, I changed the entry point of the container to be able to snoop the «stout.py».
docker run -ti --entrypoint /bin/bash --name stout schibstedchallenge/dockermaze-stoutdocker cp stout:/usr/local/bin/stout.py .
#!/usr/bin/env pythonimport os import sys import socket import base64 from datetime import datetime from dns import resolver from flask import Flask, request, make_responseapp = Flask('stout')PORTER_HOST = os.getenv('PORTER_PORT_53_TCP_ADDR')
def xor(data, key): return "".join(map(lambda i: chr(ord(data[i]) ^ ord(key[i%len(key)])), xrange(len(data))))def transform(data): s = socket.socket() s.connect(('ipa', 6060)) s.sendall(base64.b64encode(data) + "\n") ret = s.makefile().readline().decode('base64') s.close() return ret@app.route("/gate", methods=['POST']) def gate(): t1 = datetime.now()
data = request.stream.read()
dns_resolver = resolver.Resolver() dns_resolver.nameservers = [PORTER_HOST] dns_answer = dns_resolver.query('bitwise.dockermaze', 'TXT') secret = dns_answer[0].to_text().strip('"')ret = transform(xor(data, secret))
t2 = datetime.now()resp = make_response(ret, 200) resp.headers.extend({'X-Dockermaze-Time': t2-t1})return respif __name__ == '__main__': if not PORTER_HOST: sys.exit('error: cannot get key') app.run(host='0.0.0.0', port=31337)
What can be seen is that the script is publishing a REST endpoint that XORes the received data with a secret, obtained through a DNS request to the «porter» host (you have to provide its IP by an envvar), and sends the result to the «ipa» host.
PORTER
docker inspect schibstedchallenge/dockermaze-porter
Relevant info:
"Entrypoint": [ "/usr/sbin/named" ]
"ExposedPorts": { "53/tcp": {} }
As suspected providing the info obtained from the «stout» and «weisse» containers, the porter looks like a DNS server.
Bingo! one of the entries present in the «db.dockermaze» dns zone configuration for bind contains the secret key needed by «stout.py» to work (between other relevant entries we’ll see below).
IPA
docker inspect schibstedchallenge/dockermaze-ipa
Relevant info:
"Entrypoint": [ "/usr/local/bin/start.bash" ]
"ExposedPorts": { "6060/tcp": {} }
"Env": [ "PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "GOLANG_VERSION=1.5.1", "GOLANG_DOWNLOAD_URL=https://golang.org/dl/go1.5.1.linux-amd64.tar.gz", "GOLANG_DOWNLOAD_SHA1=46eecd290d8803887dec718c691cc243f2175fe0", "GOPATH=/go" ]
The golang traces clearly point to @nibble_ds as one of the crime authors 😉
When trying to run the «ipa» image, an error is raised:
2015/11/22 12:20:20 error: envvar AES_KEY not defined
Let’s try to get more info of it:
As can be seen the container also makes use of Prana and Eureka (parts of the Netflix stack), and runs a «ipa» golang binary. In this case, the challenge authors made our life easier giving us the source code too ;). In any case, the bin was not stripped.
$ file ipa ipa: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
Snooping the source code of the «ipa» application («ipa.go»), we can see that it listens to the port 6060/tcp, and decodes (base64) and decrypts the received data, using AES-256 CTR mode using a key provided by the environment variable «AES_KEY». The result is sent to the «weisse» REST endpoint and the returned data is base64 encoded and sent back to the caller.
Snippets FTW!
...SNIP...var AesKey = os.Getenv("AES_KEY")
func main() {...SNIP...ln, err := net.Listen("tcp", ":6060")
...SNIP...func handleConnection(conn net.Conn) { defer conn.Close()br := bufio.NewReader(conn) line, err := br.ReadString('\n')...SNIP...data, err := base64.StdEncoding.DecodeString(line)
...SNIP... decdata, err := decrypt(data, []byte(AesKey))
...SNIP...transdata, err := transform(decdata)
...SNIP...ret := base64.StdEncoding.EncodeToString([]byte(transdata))
fmt.Fprintln(conn, ret) }...SNIP...func transform(data []byte) (transdata []byte, err error) { c := goprana.NewClient(goprana.DefaultPort) resp, err := c.Post("weisse", "/turing", "application/octet-stream", bytes.NewReader(data)) if err != nil { return nil, err } defer resp.Body.Close()return ioutil.ReadAll(resp.Body) }
OK so, let’s put all the pieces together:
- The «stout» machine expects some data to be received by a POST HTTP method to its REST endpoint, listening at the 31337/tcp port. He gets a secret key from the «porter» machine (via DNS request) and after applying a transform to the received data, sends it base64 encoded to the «ipa» host.
- The «ipa» host receives the data sent by «stout», decodes it (base64) and decrypts it using the provided AES_KEY via envvar. Then sends the decrypted data to the «weisse» endpoint.
- The «weisse» endpoint applies an enigma decryption to the received data, getting information about the rotors through DNS requests to the «porter» DNS server, and returns the decrypted data to the «ipa».
- The «ipa» base64-encodes the response and returns it to «stout».
- The «stout» machine decodes the bas64 response and delivers it to the caller.
On the other hand we had the «ct1.bin» file and the «FollowTheRabbit» key, so we can make the below assumptions:
- The AES_KEY is «FollowTheRabbit».
- The «ct1.bin» is the encrypted data we want to decrypt using the container chain.
So we need to link the containers in order to let them talk to each others, taking into account that «weisse» and «ipa» use Prana & Eureka to communicate.
Note of the author: Juan told me that would be great to put a diagram in this place to improve the explanation, but… I’ll do it only for a beer. If you want a diagram just make me happy and bring me one! ;-P
UPDATE 23/11/2015: nibble provided this awesome diagram 🙂
This is what I did:
docker pull netflixoss/eureka:1.1.147 docker run -d --name eureka netflixoss/eureka:1.1.147 docker run -d -P --name porter schibstedchallenge/dockermaze-porter docker run -d -P --name weisse --link porter:porter --link eureka:eureka schibstedchallenge/dockermaze-weisse docker run -d -P -e "AES_KEY=FollowTheWhiteRabbit" --name ipa --link weisse:weisse --link eureka:eureka schibstedchallenge/dockermaze-ipa docker run -d -p 31337:31337 --name stout --link ipa:ipa --link porter:porter schibstedchallenge/dockermaze-stout
And then I waited some minutes before sending the requests to the «stout» endpoint (due to the advice found in the «start.bash» file):
curl -v -X POST --data-binary @ct1.bin http://localhost:31337/gate --header "Content-Type:application/octet-stream"
OK, I was on the right path but unfortunately I was not attending the Dockercon :(. Fortunately after the con @nibble_ds sent me the key they were giving in the Schibsted booth (thanks sir!).
When scanned the QR code a snippet of ruby code appeared:
puts 'z4LufsdfTf{bNsfldpE'.bytes.map { |ch| (ch.ord - 1).chr }.reverse.join
After executing it you get the new key! («DockerMazeSecretK3y»).
We should be close, but when I tried again the same «curl» command but modifying the AES_KEY, the «ct1.bin» didn’t work as the encrypted message. Where could we get a new message?
I remembered the DockerMaze «escape» command that receives a parameter «ip». So I did a DNAT from my public IP to the 31337/tcp port of the «stout» (PublicIP:31337 -> PrivateIP:31337), and executed:
escape x.x.x.x
Where «x.x.x.x» was my public IP, and I got:
Trying to escape... Wait... Hummm… Everything seems to be okay but you must be faster… 20.040787 seconds is too much
So we need to make something to be faster. After inspecting what part of the chain triggered more, the «weisse» component stood up as highly inefficient. The problem was in this loop when getting the rotors:
...SNIP... BFBASE = 'aaa' ...SNIP... def get_rotors(nameserver) rotors = []
Resolv::DNS.open({:nameserver=>[nameserver]}) do |r| ctr = 0loop do begin n = r.getresource("walzen-#{ctr}.dockermaze", Resolv::DNS::Resource::IN::TXT).data.to_i rescue Resolv::ResolvError break endbf = BFBASE.dup found_chunks = 0 rotors[ctr] = ''
while found_chunks < n begin ck = r.getresource("walzen-#{ctr}-#{bf}.dockermaze", Resolv::DNS::Resource::IN::TXT).data.delete('"') rotors[ctr] << ck found_chunks += 1 rescue Resolv::ResolvError next ensure bf.next! end endctr += 1 end endrotors end
Most of the requested DNS entries were like these:
walzen-0 IN TXT "4" walzen-0-aaa IN TXT "7b57e0a216b65a40534e4c8bcc787a8e5b3722657dcfb0d199950688ef0c718cbf1094bd0ff7d687c69cfba09d42caaa13d4cdb24f8f892877b4a91f596b2615" walzen-0-aab IN TXT "6f48936c561d66625e31702143c2978ddaf19f60dcfd340e3b3c2b725404a820613ad369ae0a30a5b76de14d08d041337c02ceacbed5e7c3deee67ad7f63f529" walzen-0-aac IN TXT "f3523e2746b1e524a48451ff1e5c92f6d796b9b89036c43d8ae8f486c7c1bc2ea601499e6eab81e383c0392c2d0514f0e9324af985507efa116a743523cb00fe" walzen-0-aad IN TXT "1a68df6455c8ec914476fcc5808279f298ed3f5dbba7a3b54b250309d92f17a112b307db75eb1c2af8dd38e473d819afd2e2ea1be6c90b589aba5f470d18459b" walzen-1 IN TXT "4" walzen-1-aaa IN TXT "0ec8580062742e72c3d96fc76d4f21bacdf03887256bb7c9d42a27c5cb43e216405163e7a3427a071033ea3944899f88d63f83e41d91ad1a19b39c455c041294" walzen-1-aab IN TXT "ac8ccfafe184de033afdf13ddcdfd27b8b86989e82d1ffbca99290fbc4a115c2eba05323be80060a30eeaed3689385148aa56e37a6bb4a1bef0db5bd34dbf846" walzen-1-aac IN TXT "eddd05480c7df9c6d0b69b591eb48f7f20175022f4577170ab7ea78e77b04c5d4e029dbf47fa3e8d49e3d83b4b816999ecb178f561081c292f2b6097544136f7" walzen-1-aad IN TXT "18a46635e9b9f6d756753cf35f65e0aac1266c7c5ba25231e5e60bce0f2cb82432da675a09132d5e9acafc76a8110155b2c04d1ff2d5fe73cce8966a79286495"
But some of them were not consecutive, leading to a lot of unnecessary failed DNS requests. For example:
walzen-9 IN TXT "4" walzen-9-aaa IN TXT "3a8a13373496029d73b8d44e23147e947f45d5fd8640073f2ff7953858bb5ce076cfbef68860d8986a7a8fc8ad26d9d3f8fc9fee0e56ed65b14cb0fe84acc724" walzen-9-aab IN TXT "299cda0f3001505a3caf0b99e2c380f3b532161aa861b2f00675dfa4d08da0ea550dcc53f581692a5bd6d119744272fac0b7db8c6210ffbc8bc9a166bacd9305" walzen-9-aac IN TXT "a76f638943aae11d925d680948e4672dd252ab54495fc2caf27cf45133b65e7d6ba6820a1225398e214b274dbd00596efbefe6229e18473b20c56de3c135153d" walzen-9-rzd IN TXT "644fe5f18583ebf9c62e1e1f7bc4ecdd44b4ce70a5086c4ad7579a17a9413e3171bfde11790c877704a2a3e8b32891369bb946e9ae2b2c1bcbe797781c90dc03"
So what I did is to edit the «db.dockermaze» configuration file to make them all consecutive and updated the docker image.
docker cp ./modified-db.dockermaze porter:/etc/bind/db.dockermaze docker commit porter redsadic/dockermaze-porter:v2 docker run -d -P --name porter redsadic/dockermaze-porter:v2
And when I ran the «escape x.x.x.x» command again… Voilà!
Trying to escape... Wait... You put the key in the lock and... the door opens! Congratulations! You are out of the labyrinth! Send an email with the following info to big.ideas+DockerMaze@schibsted.com: - IP used to escape - The token 'XXXXXXXXXXXXXXXXXX' - Short explanation about how you escaped
Wohoooo! challenge solved! 😀
I would want to thank the Schibsted team because I really had a lot of fun with the challenge! Thank you guys! 😀
And that’s all folks!
UPDATE 23/11/2015: some easter eggs from the challenge authors :
- The hostnames are different kind of beers
- The STOUT endpoint is /gate because it implements a XOR (a logic gate)
- The IPA exposed port is :6060 or GOGO 😀
- The WEISSE (enigma) endpoint port is 1954, the year Alan Turing died
- Also the endpoint /turing is in honor of him, due to his contribution breaking enigma
- The DNS records where the rotors are stored are called «walzen-x-yyy». Walzen means rotor in german
- And…
- STOUT is the kind of beer that nibble likes less, this is why he did it in python (as a good python hater he is)
- IPA is one of his favorites beers, and he did it in go 😉
- WEISSE is other kind of beer he loves, for this reason it is ruby!
PD: looks like the https://challenge.schibsted.com site is down now. Too late if you want to play the challenge now ;(
UPDATE 23/11/2015:
PD: the challenge is now available at http://challenge.schibsted.com. If you wanna play, go for it!!!
Write Up 5h311 – Final CTF NCN 2014
Buenas,
Para continuar con la saga de write-up’s iniciada en el anterior post con @julianvilas, hoy os pondremos la solución a otro de los retos que tuvimos el placer de testear.
Se trata de un fichero llamado “5h311”, que al ejecutarlo se abre un servicio en local en el Puerto 6969, que la conectarnos muestra lo siguiente:
Parece ser un acceso por consola que permite una serie de comandos, concretamente “cat”, “echo”, “env”, “exit”, “help”, “ls”, “set” y “unset”.
Si hacemos ls encontramos que el flag se encuentra en el mismo directorio del binario, pero al hacer un “cat flag.txt” podemos observar que no disponemos de privilegios para accede .
Bueno pues nos ponemos manos a la obra y abrimos el programa con IDA para ver que es lo que nos esconde.
Buscamos en IDA las ocurrencias del comando “cat” con la búsqueda de Strings (ALT+T), con la finalidad de identificar la sección de código donde se están gestionando los comandos:
Como resultado, en la sección .rodata podemos observar el vector que incluye los comandos que son printados por pantalla.
Pero observando unas direcciones de memoria más abajo, se pueden observar de nuevo los comandos asignados a unos offsets, pero con la peculiaridad que aparece un nuevo comando que no nos ha listado el comando HELP, el comando “Puts”.
Miramos las Xrefs del offset correspondiente a “aPuts” (x Key):
Miramos de analizar la primera ocurrencia, que parece ser que se está empleando dentro de una función.
Antes de nada un apunte, observando el programa desde la View Graph, ya se observa algo raro, como si se hubiera ofuscado con algún tipo de programa, debido a que todos los paths van a parar a un mismo punto como se observa en la siguiente imagen:
Procedemos a analizar el bloque de código que emplea el offset de «puts», y observamos que se realizan una serie de comparaciones:
Concretamente hace una comparación de dos offsets con una llamada a strcmp y verifica mediante el siguiente cmp si son iguales, en ese caso activa el ZF.
Antes de continuar refrequemos que hace el opcode “setz”:
- The setz sets the byte in the destination operand to 1 if the Zero Flag (ZF) is set, otherwise sets the operand to 0.
Después mediante la instrucción “setz”, se setea el valor de “bl” a 1 si ZF vale 1, es decir bl valdrá 1 si el resultado del strcmp es que son iguales.
Posteriormente mediante la instrucción “test”, se modifica otra vez el ZF en función del resultado del registro bl. (Empezamos a observar algo de redundancia aquí, por lo que la hipótesis de que se ha empleado algún tipo de programa para ofuscar el código es cada vez más firme :P)
Finalmente se mueven de nuevo los dos valores comparados en el strcmp, y se ejecuta la instrucción cmovz (al parecer sin valor alguno debido a que solo se ejecuta si ZF=1, es decir, si ecx y eax ya son iguales).
Como podéis ver, una locura para al final solo acabar realizando una comparación xD Por lo que antes de ingresar en un psiquiárico, procederemos a realizar un análisis dinámico partiendo del bloque de código identificado.
Cuando el proceso recibe una conexión al puerto 6969, éste crea un nuevo proceso hijo mediante la syscall ‘clone’ y le pasa el control al mismo para que continúe su ejecución. Para poder debugear el proceso hijo sin que el padre nos moleste (al cabo de un tiempo envia un SIGALARM y nos mata el proceso), empleamos la instrucción “catch” de GDB para que, una vez cree el proceso hijo, podamos pausar su ejecución, y de esta forma poder debugear el proceso hijo con calma.
Añadimos un breakpoint a la dirección del bloque de código donde hemos observado el offset del ‘puts’, y ejecutamos la instrucción para ver que ocurre. Observamos que no se observa ningún cambio, por lo que el flujo de ejecución no pasa por ahí. (ouch!) Continuemos con el análisis pues.
Observando más detenidamente el código y continuando con la búsqueda de cadenas de texto interesantes como los comandos encontramos una zona de memoria donde se definen los offsets de las funciones asociadas a cada comando de la shell analizada:
En la imagen se muestran los offsets de las funciones ya renombrados.
Usando la funcionalidad de cross-reference vemos que el primero de estos offsets es llamado desde otro punto del código:
En ese punto se aprecia el acceso a este offset con un desplazamiento dinàmico con el valor almacenado en [eax*8]. Esto permite con el valor de eax recorrer la zona de memoria que contiene los punteros a las funciones de cada comando. Más tarde este offset guardado en el registro eax será llamado con call eax.
Tirando del hilo veremos que el valor de eax viene condicionado supuestamente por el valor del comando introducido por el usuario, mediante el offset «off_804E848».
Vemos que este valor parece venir de la función _fgets. Aunque de momento, debido a que el flujo del código esta ofuscado con la implementación de una máquina de estados, no podemos estar seguros de todas estas conjeturas. Deberemos por lo tanto ejecutar el análisis de forma dinámica para estar seguros.
Para analizar todos los valores comentados anteriormente de forma dinámica, utilizaremos gdbserver para debuggar cómodamente de forma remota y poder indicar los breakpoints directamente desde IDA.
Luego en IDA seleccionamos el Debugger de tipo GDB server y configuramos la ip y el puerto:
Ya podemos a priori centrarnos en el comportamiento de los comandos que más nos interesen, en este caso ‘cat’, ‘set’, y el misterioso ‘puts’. Para ello prepararemos el entorno para debuggar y pondremos breakpoints en los puntos más interesantes.
Focalizando en las funciones cat, set, i puts vemos que todas están implementadas ofuscando el flujo del código con una máquina de estados. Por lo tanto buscaremos las llamadas mas interesantes para poner breakpoints. Para verificar que no se nos escapa nada y por donde podemos empezar a mirar, sacamos un grafo de llamadas desde cada función que nos interesa con Graphview.
Ponemos los breakpoints en las llamadas empleadas en cada una de las funciones anteriormente mostradas en los callgraphs (strcmp, fopen, fgets, strncpy), con la finalidad de identificar, por ejemplo, las comparaciones realizadas en cada una de las llamadas a “strcmp”, y empezamos a jugar.
En la función «cat» observamos se emplea una llamada a fopen para abrir el fichero a leer y que el valor de dicho fichero esta hardcodeado a “flag.txt”, por lo que solo se podrá abrir un fichero con dicho nombre.
En la función «set» observamos que las variables de entorno se guardan en memoria empezando en el offset dword_804e8a8 sumando un desplazamiento de 0x100 bytes (por lo que resulta en 804e9a8) y que el numero de variables de entorno se guarda en el offset dword_804e8a4.
Podemos ver como en las direcciones de memoria anteriormente comentadas se almacenan las variables de entorno seteadas con el comando «SET», (variable en 0x804e8a8 y valor en un offset de 0x100, concretamente en 0x804e9a8).
En la función “puts” observamos que recorre las variables definidas con set (incluso recorre las que se han “eliminado” con unset pero que aún siguen en la memoria pero sin la primera letra) y compara su valor con la cadena “puts”.
Si una de las variables se llama “puts” entonces compara su valor con “printf”.
Probamos el comportamiento creando una variable de entorno que se llame puts y que su valor sea printf y luego invocamos a puts. Como podemos ver, parece que se hemos conseguido una escalada de privilegios o algo parecido.
Probando ahora el comando cat con un fichero cualquiera del directorio desde donde ejecutamos la shell vemos que nos devuelve “error: permission denied”
Pero si recordamos que el valor de «flag.txt» está hardcodeado en el binario, miremos de probar pues de modificar el fichero de nuestro entorno local a dicho nombre. Volvemos a provar y ya podemos mostrar el contenido de flag.txt!
En este caso esta prueba no logramos resolverla dentro del tiempo del CTF. Pudimos resolverlo con calma luego desde casa 😛
Solo queda dar gracias al staff de las NCN por la originalidad de los juegos!
Post escrito con la colaboración de «Pau Rodriguez», miembro activo de 0xb33r$ 🙂
Solución HIDDENtation – Final CTF NCN 2014
Buenas,
hoy hemos tenido el placer de participar en la final del CTF de las No cON Name por segundo año consecutivo y, antes de explicaros nuestra solución a uno de los retos (que no conseguimos terminar a tiempo ;( ), nos gustaría dar las gracias a la organización; ya que se han currado un montón las pruebas (tanto las de la final como las de las quals) con el único objetivo de hacernos pasar un buen rato. Gracias de verdad, porque ha sido muy divertido! 🙂
El reto que vamos a explicaros se llama HIDDENtation, y el texto que describía el reto decía tal que así: «Dig deep into the file and find the flag.». Este texto venía acompañado por un archivo, que es en el que se centra el juego.
En un primer vistazo al archivo vemos algo tal que así:
Por lo que parece que se trate de una imagen de un volumen cifrado con LUKS (estándar de cifrado de discos duros en Linux). El tema es que el comando «file» no ha identificado el fichero como tal, así que procedemos a analizar si la estructura del archivo es correcta. Para ello utilizamos una plantilla para el «010 Editor» para analizar el format de volúmenes LUKS.
Al ejecutar la plantilla vemos que nos da un error que dice que el archivo no es LUKS, ya que no se corresponde su firma. Así que pasamos a mirarnos el estándar de LUKS para ver cual es su firma, donde nos dice que la cabecera de la partición empieza con el siguiente magic: «{’L’,’U’,’K’,’S’,0xBA,0xBE}», y en nuestro caso en vez de una ‘S’ había una ‘s’ minúscula. Una vez modificada esa letra, volvemos a aplicar el template y vemos como ahora sí lo reconoce:
curioseando un poco el fichero vemos que en la sección de padding de caracteres aparece el siguiente texto: «Try … most common passwd in …», donde los «…» son dos números hexadecimales: 0x19 (25) y 0x07dd (2013). Así que nos vamos a preguntarle a Google y encontramos esto.
Utilizando el siguiente comando
cryptsetup luksOpen hiddentation volume1
intentamos descifrar el volumen con los 25 passwords sin éxito :(. Así que parece que tocaba trabajar más en los headers.
Después de pelearnos con el estándar vemos que nos faltaría arreglar las secciones de los key-slots en el header.
En este caso vemos :
- que los ocho que hay están desactivados («00 00 DE AD»), cuando tendría que haber al menos uno activo (en el que supone que está la clave con la que se cifran los datos protegida con la passphrase correspondiente a uno de los 25 passwords más comunes en 2013),
- que los campos donde se indican los offset de los KeyMaterials no parecen estar correctamente calculados. Para estar bien calculados deberían cumplir la fórmula round_up(key_length * stripes / sector_size); en este caso: (32*4000) /512 = 250, por lo que tomamos 256 (0x100).
Así que ya que parece que el key-slot8 es «el bueno», pues marcamos este slot como ENABLED (0x00AC71F3) y retocamos los 8 offsets, quedando algo tal que así:
Ahora nos disponemos a probar otra vez los 25 passwords y tenemos éxito con el número 18: «shadow».
Así que ahora vemos qué pinta tiene el disco:
Y vemos que la tabla de particiones es GPT, y que fdisk no soporta GPT. Procedemos a utilizar parted:
Y aparecen tres particiones, una XFS, una EXT2 y una FAT32. Haciendo uso de los dispositivos de loop las vamos montando una a una. Por ejemplo:
losetup -o 44040192 /dev/loop2 /dev/mapper/volume1
donde indicamos el offset de la partición, el dispositivo de loop a utilizar y el volumen de disco. Este caso concreto es el de la tercera partición (tras buscar en la primera y la segunda no encontramos el flag).
Y al montar la tercera nos aparece un fichero que se llama «flag.txt». Quedaba un minuto para que se acabase el CTF y con toda el ansia procedemos a abrir el fichero para encontrarnos un «It’s inside this partition, but hidden ;)». Agggggggghhhh xD
Bien, después de analizar la partición con el autopsy, no vimos nada relevante en cuanto a ficheros borrados. Utilizando el comando testdisk vemos que en el mismo volumen hay una partición NTFS borrada previamente.
La extraemos del siguiente modo:
dd if=/dev/loop2 of=ntfs2 skip=69632 count=34816
la montamos y vemos que hay un «readme.txt». Abrimos y…. «You are very near, but it’s even more hidden!». Mekagüen!! esta gente está loca! ;***, jajaja
De nuevo autopsy, esta vez sobre la partición NTFS y encontramos esto:
Un fichero flag.txt borrado (que no contiene el flag) pero con un Alternate Data Stream que contiene esa secuencia codificada en ROT13. La decodificamos y voilà, ahora sí tenemos flag «NCNd986942b809daa32a6987a7422771a53f59e5a1f02ed700cce43c5196aba749e» (pero el CTF ya ha acabado xD).
Pues parece que si que había que «Dig deeper» para encontrar la bandera ;).
Genial la prueba, muy muy currada. Gracias de nuevo staff de las NcN!! 🙂
Solución reto China – Final CTF NcN 2013
Hace unos días tuvimos la suerte de poder participar en la final del CTF de las No cON Name 2013, organizado por el Security Staff de Facebook.
La verdad, estuvo genial organizado y realmente nos divertimos mucho. ¡Felicidades Facebook & NcN staff! Enhorabuena también a los otros participantes, y en especial a los ganadores 🙂
En el concurso se publicaron un conjunto de servidores, cada uno de ellos correspondiente con un país.
Cada servidor/país podía ser una base o un flag:
- Las bases contenían retos que podían ser resueltos una vez por cada equipo.
- Los flags contenían algún tipo de vulnerabilidad que permitía a los equipos capturarlo (el flag). Los puntos se otorgaban por el tiempo que el equipo tuviese en su poder el flag. Básicamente los flags consistían en escribir en el fichero «/tmp/SCORE_POINTS» del servidor en cuestión, el nombre del equipo.
En este post os vamos a explicar como pudimos capturar el flag de China! 🙂
Al realizar un escaneo de puertos contra el servidor, éste presentaba abiertos los puertos 80 y 12345. El segundo era el utilizado por la organización para monitorizar los flags, así que procedimos a acceder al puerto 80.
Y esto era lo que nos encontramos. Lo primero que hicimos, tirar de google translate para traducir el texto en chino. Básicamente era un formulario de login. Al probar a autenticarse, daba un error en el usuario/contraseña, y las pruebas de inyección realizadas no dieron resultado.
Por lo que procedimos a examinar con más detalle las peticiones y respuestas intercambiadas. Para ir al grano, el punto interesante era el proceso de autenticación:
Y ¿qué era lo interesante de este caso?
- Un token AntiCSRF en el formulario de autenticación nos pareció un poco raro. Este tipo de tokens se utiliza en formularios que permiten hacer algún tipo de modificación
- El token AntiCSRF, tiene pinta de algo codificado (desde luego no de un hash)
Procedimos a su decodificación:
Lo que nos indicaba que era un archivo binario, nos revelaba un path con un archivo .py, nos mostraba un hash y la palabra secret. Volcamos el contenido en un fichero y ejecutamos el comando file:
python 2.7 byte-compiled
Por lo que procedimos a decompilarlo:
Básicamente lo que contenía era una asignación de una variable, siendo el path un metadato del fichero. Por lo que construimos nuestro propio python:
Generamos un fichero byte-compiled (.pyc):
Lo codificamos en base64:
Y finalmente hacemos tampering de la petición cambiando el token AntiCSRF por el que hemos generado nosotros, y voilà! habíamos capturado la bandera de China 🙂
Esperamos poder subir en los próximos días alguna solución más 🙂
Un saludo!