Un blog de Seguridad Informática, desde un punto de vista tecnológico

Más reciente

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:latest
Found Keys:
  - FollowTheWhiteRabbit
Followed 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.


Captura de pantalla 2015-11-21 a las 23.05.11

Next step was to download the docker images and to inspect them:

docker pull schibstedchallenge/dockermaze-weisse:latest
docker pull schibstedchallenge/dockermaze-stout:latest
docker pull schibstedchallenge/dockermaze-porter:latest
docker pull schibstedchallenge/dockermaze-ipa:latest

Let’s play with those docker images then 🙂


docker inspect schibstedchallenge/dockermaze-weisse:latest

Relevant info:

"Entrypoint": [
"ExposedPorts": {
 "1954/tcp": {}

Captura de pantalla 2015-11-21 a las 23.39.25

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 🙂

BFBASE = 'aaa'
set :bind, ''
set :port, 1954
post '/turing' do
 data = request.body.read
 rotors = get_rotors('porter')
plugboard = Hash[*PLUGBOARD.pack('H*').split('')]
 rotors.map! do |r|
 Hash[[r].pack('H*').split('').zip((0...256).map{|i| i.chr})]
 reflector = Hash[*REFLECTOR.pack('H*').split('')]
 enigma(data, plugboard, rotors, reflector)
def get_rotors(nameserver)
 rotors = []
Resolv::DNS.open({:nameserver=>[nameserver]}) do |r|
 ctr = 0
loop do
 n = r.getresource("walzen-#{ctr}.dockermaze", Resolv::DNS::Resource::IN::TXT).data.to_i
 rescue Resolv::ResolvError
bf = BFBASE.dup
 found_chunks = 0
 rotors[ctr] = ''
while found_chunks < n
 ck = r.getresource("walzen-#{ctr}-#{bf}.dockermaze", Resolv::DNS::Resource::IN::TXT).data.delete('"')
 rotors[ctr] << ck
 found_chunks += 1
 rescue Resolv::ResolvError
ctr += 1


docker inspect schibstedchallenge/dockermaze-stout

Relevant info:

"Entrypoint": [
"ExposedPorts": {
 "31337/tcp": {}

But an error is raised when trying to run the docker image:

Captura de pantalla 2015-11-22 a las 0.06.51

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-stout
docker cp stout:/usr/local/bin/stout.py .
#!/usr/bin/env python
import os
import sys
import socket
import base64
from datetime import datetime
from dns import resolver
from flask import Flask, request, make_response
app = Flask('stout')
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')
 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 resp
if __name__ == '__main__':
 if not PORTER_HOST:
 sys.exit('error: cannot get key')
 app.run(host='', 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.


docker inspect schibstedchallenge/dockermaze-porter

Relevant info:

"Entrypoint": [
"ExposedPorts": {
 "53/tcp": {}

As suspected providing the info obtained from the «stout» and «weisse» containers, the porter looks like a DNS server.

Captura de pantalla 2015-11-22 a las 13.08.35

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).


docker inspect schibstedchallenge/dockermaze-ipa

Relevant info:

"Entrypoint": [
"ExposedPorts": {
 "6060/tcp": {}
"Env": [

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:


Captura de pantalla 2015-11-22 a las 13.34.52

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!

var AesKey = os.Getenv("AES_KEY")
func main() {
ln, err := net.Listen("tcp", ":6060")
func handleConnection(conn net.Conn) {
 defer conn.Close()
br := bufio.NewReader(conn)
 line, err := br.ReadString('\n')
data, err := base64.StdEncoding.DecodeString(line)

 decdata, err := decrypt(data, []byte(AesKey))
transdata, err := transform(decdata)
ret := base64.StdEncoding.EncodeToString([]byte(transdata))
fmt.Fprintln(conn, ret)
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:

  1. 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.
  2. 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.
  3. 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».
  4. The «ipa» base64-encodes the response and returns it to «stout».
  5. 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"

Captura de pantalla 2015-11-22 a las 19.02.35

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:


BFBASE = 'aaa'

def get_rotors(nameserver)
 rotors = []
Resolv::DNS.open({:nameserver=>[nameserver]}) do |r|
 ctr = 0
loop do
 n = r.getresource("walzen-#{ctr}.dockermaze", Resolv::DNS::Resource::IN::TXT).data.to_i
 rescue Resolv::ResolvError
bf = BFBASE.dup
 found_chunks = 0
 rotors[ctr] = ''
while found_chunks < n
 ck = r.getresource("walzen-#{ctr}-#{bf}.dockermaze", Resolv::DNS::Resource::IN::TXT).data.delete('"')
 rotors[ctr] << ck
 found_chunks += 1
 rescue Resolv::ResolvError
ctr += 1

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
- 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!!!


Anuncio publicitario

Escalada de privilegios en sistemas Windows (I)

En esta serie de posts hablaremos de cómo realizar una escalada de privilegios en un sistema Windows, es decir, llegar a ser SYSTEM desde una cuenta de usuario sin privilegios.

En ocasiones la principal estrategia utilizada se basa en probar exploits para la versión de windows del objetivo, y aunque esto puede ser efectivo un gran numero de veces, queremos presentar una breve guía divida en fases que permitan al pentester realizar la escalada de privilegios de una forma ordenada, eficiente y probando diferentes vectores de ataque.

Remarcar que actualmente existen muchas referencias en Internet que tratan este tema siendo algunas de las principales las mencionadas a continuación: 

  1. FuzzySecurity
  2. Encyclopaedia Of Windows Privilege Escalation – Brett Moore
  3. Windows Attacks At Is The New Black – Rob Fuller And Chris Gates
  4. Windows Privilege Cheatsheet
  5. Windows_Services – All roads lead to SYSTEM
  6. Windows privilege escalation

En nuestro caso queremos hacer una síntesis de ellas y explicarlas paso a paso, sin embargo, señalar que queda fuera del alcance de este post como conseguir la Shell en el sistema.

Aclarado todo, empecemos, tenemos una Shell en una maquina Windows, molto benne…¿y ahora que demonios hacemos?

¿Dónde estoy? ¿Qué es ESTO? – Information gathering

Bien, en estos momentos, disponemos de una Shell en un sistema Windows. Antes de lanzarnos al ataque y disparar a todo lo que se mueva, es esencial realizar la fase de Information gathering. 

Lo principal es no obcecarse con ser SYSTEM, primero hay que conocer el entorno, cuanta más información  se tiene del activo más fácil es detectar un posible fallo de seguridad.

Información general

Sin ninguna duda, lo primero es obtener la versión exacta de Windows (OS Version) y (OS Name)  y información genérica. Para este propósito, se ejecuta el siguiente comando:

  • systeminfo



  • Otra posibilidad: systeminfo | findstr /B /C:»OS Name» /C:»OS Version» (ojo con los idiomas)



Ok, ahora vamos a saber como se llama el host, que aunque parezca no relevante, siempre nos puede aportar información o alguna pista.

  •  hostname



Finalmente, es el momento de saber con que usuario estamos logged en el sistema, a lo mejor ya somos admin y no hace falta hacer nada más, aparte de celebrar una gran fiesta.

  • echo %username%



  • whoami


Información sobre usuarios

Siguiente paso, todo sistema operativo tiene usuarios que lo utilizan, miremos que usuarios tiene nuestro objetivo:

  • net users – net user $name_user


Vaya vaya Joe, además del usuario «Administrador» también existe el usuario «Nyanyi» que pertenece al grupo «Administradores»…..uhmm….interesante. Con este simple comando acabamos de ampliar las opciones de ataque.

Información de red

¿Está el host solo en el mundo? ¿en que red está? ¿con que máquinas habla?.  Tener la respuesta a estas preguntas podría ser la puerta de acceso a otras máquinas del entorno, imaginar que se puede alcanzar el ansiado SYSTEM en esta máquina pero si dirigir el pentest a otras máquinas .

Por otra parte, es muy útil conocer que servicios están a la escucha en el activo,que conexiones hay con otras máquinas. Quién sabe, a lo mejor algunos de los servicios publicados es vulnerable…

Los comandos a ejecutar serían los siguientes:

  • ipconfig /all
  • route print
  • arp -A
  • netstat -ano







Nota: A partir de XP SP2 utilizar los siguientes comandos para obtener información sobre el Firewall de la máquina:

  • netsh firewall show state
  • netsh firewall show config


Información sobre los servicios

Hasta este punto, se ha hablado sobre cómo obtener información general del sistema, que usuarios tiene y que comunicaciones hay a nivel de red. Uno de los últimos puntos a tratar en esta introducción  son las «tareas» o «servicios» existentes en la máquina.

De momento, sin querer entrar en detalle, un servicio no es más que la ejecución, en segundo plano, de un binario. Por lo tanto, hay 3 conceptos claves:

      • Binario que determina que acciones realizara el servicio.
      • Usuario que ejecuta el servicio.
      • Los privilegios del servicio, por ende, serán los mismos que los del usuario.

Los comandos a ejecutar para obtener la información relacionada con los servicios son los siguientes:

  • schtasks /query /fo LIST /v | more (tareas programadas)


  • tasklist /SVC (servicios relacionado con su proceso)


  • net start


  • sc queryex type= service state= all | find «$_NAME» (hablaremos más adelante de este comando (thanks P4chul0).

Conclusiones de la fase I

Con toda la información que hemos obtenido es el momento de realizar una primera iteración con el objetivo de lograr System, o en su defecto, un usuario administrador.

Pruebas a realizar:

  1. Tenemos el nombre de los usuarios, a lo mejor, hay alguno de ellos sin contraseña o que ésta sea su mismo nombre. O inclusive, que la contraseña sea el nombre del hostname….por qué no?.
  2. Se puede buscar su nombre de usuario en Checkusernames con la idea de obtener aún más información de redes sociales.
  3. Probar los usuarios en otras máquinas de la red.
  4. ¿Hay algún servicio publicado vulnerable?
  5. Imaginar

Si nada de esto funciona, pasaremos a la fase II. Es esencial recopilar toda la información obtenida en esta fase, porque cualquier dato obtenido puede ser la clave que nos ayude en procesos futuros más complejos, por ejemplo, la búsqueda de un exploit o una reverse shell por un puerto que no este cerrado por el firewall…


Using LXC containers to (partially) replace Virtual Machines

Note: This post is the first that we write in English and even though till now all of them were written in Spanish, from now on we will publish content in both languages.

It doesn’t matter if it’s for doing pentests or participating in CTFs, preparing Virtual Machines for different systems and tools is a recurrent task.

For full blown virtualization the two main options are Virtual Box and the multiple flavors of VMWare, but (being an Ubuntu fan) I’ve been lately experimenting with LinuX Containers (LXC), a technology for Linux-based systems sometimes described as:

«something in the middle between a chroot and a full fledged virtual machine»


«lightweight virtualization technology. They are more akin to an enhanced chroot than to full virtualization like VMware or QEMU. They do not emulate hardware and containers share the same operating system as the host.»

Each option has its advantages and disadvantages:

  • There is almost no overhead in running a container, since everything is managed by the host kernel.
  • LXC containers use the host kernel and they are limited to Linux, so no Windows or OSX containers are feasible.

After this short introduction, in this post I will describe:

  • How to create a Kali-like unprivileged container starting from a Debian container.
  • How to «passthrough» devices to a container, like for example an USB RTL-SDR.
  • How to run GUI applications in a container.
  • Some general tips & tricks.

Everything explained here assumes that you are running an Ubuntu 14.04 (or a 12.04 with the 3.13 kernel) based host using the 1.0.x LXC branch (use this ppa for 12.04).

Most of the information showed here is just a recompilation from all this sources:

Configuring the host

We are gonna need at least to install this packages to host containers:

sudo apt-get install lxc systemd-services uidmap

And to be able to use unprivileged containers, we will have to follow the instructions posted by Stéphane Graber, one of the main maintainers of the project, in this post:

That can be resumed in:

Adding sub-UIDs & sub-GIDs for the current user with the following commands:

sudo usermod --add-subuids 100000-165536 $USER && \
sudo usermod --add-subgids 100000-165536 $USER && \
sudo chmod +x $HOME

Setting the default configuration for LXC in file ~/.config/lxc/default.conf:

lxc.network.type = veth
lxc.network.link = lxcbr0
lxc.network.flags = up
lxc.network.hwaddr = 00:16:3e:xx:xx:xx
lxc.id_map = u 0 100000 65536
lxc.id_map = g 0 100000 65536

And allowing the use of 10 virtual network-interfaces in the non-privileged containers adding this to file /etc/lxc/lxc-usernet:

$USER veth lxcbr0 10

Container creation

Now that our system is ready to create unprivileged containers, we can do create our first one. For example, we can download a image from the official repository to create our container with:

lxc-create --template download --name wheezy-kali

And choose, for this example: debian as distribution, wheezy as release and amd64 as architecture.

Once the image has finished downloading and the container has been created, we can start it in non-interactive mode with:

lxc-start --name wheezy-kali --daemon

And then install some basic packages, like OpenSSH and support for X11 forwarding, directly from the host:

lxc-attach --name wheezy-kali -- apt-get update
lxc-attach --name wheezy-kali -- apt-get dist-upgrade -y
lxc-attach --name wheezy-kali -- apt-get install openssh-server xauth -y

We can list the basic information from containers (like their IPs) with this command:

lxc-ls --fancy

Transforming a Debian container into Kali

To access the container we can use SSH, but first we will need to access it this way:

lxc-attach --name wheezy-kali

And set a password for the root user.

Once connected (or attached) to the Debian container, we can proceed with the apt sources modification, editing the /etc/apt/sources.list file to add the Kali repositories:

#deb [arch=amd64] http://http.debian.net/debian wheezy main contrib non-free
#deb [arch=amd64] http://security.debian.org/ wheezy/updates main contrib non-free
deb [arch=amd64] http://http.kali.org/kali kali main non-free contrib
deb-src http://http.kali.org/kali kali main non-free contrib
deb [arch=amd64] http://security.kali.org/kali-security kali/updates main contrib non-free

And then updating our local copy with:

apt-get update

But an error will tell us that we don’t have the public key ID to verify the signatures of the packages in that repositories, so we should import and add it to apt with these commands:

gpg --keyserver pgp.mit.edu --recv-keys ED444FF07D8D0BF6
gpg --armor --export ED444FF07D8D0BF6 | apt-key add -

If we update the software sources now, the error will be gone and we can finally turn the container into a Kali one:

apt-get update && apt-get install kali-archive-keyring && apt-get dist-upgrade -y

Hardware passthrough

As explained in multiple sources:

To passthrough devices we have to add lines like these ones in the config file of the containers (.local/share/lxc/container_name for unprivileged containers):

lxc.cgroup.devices.allow = c X:* rwm
lxc.mount.entry = /host_dir none bind,optional,create=dir

Using the minor and major nodes of the device/s that we want to grant access to.

Note: To find out the minor and major nodes of a device we can execute this on the host:

ls -lisah /sys/dev/*

For example, for using a RTL-SDR USB inside a container the following lines need to be added:

# RTL-SDR device
lxc.cgroup.devices.allow = c 189:* rwm
lxc.mount.entry = /dev/bus/usb/002 dev/bus/usb/002 none bind,optional,create=dir
lxc.mount.entry = /dev/rtl_sdr dev/rtl_sdr none bind,optional,create=file

Note: In the case of the RTL-SDR we will first have to configure the udev rules in the host system for it to work as a SDR:

And for an USB-to-serial converter I did have to add:

# USB-to-serial device
lxc.cgroup.devices.allow = c 188:0 rw

The only caveat with containers hardware passthrough is that anything that needs a modified kernel will only work if the host Kernel is modified.

Running GUI applications

Apart from running X11 applications trough a SSH we can also do it the «native» way, letting the unprivileged container access to the video-card devices (and even the audio server). For more information check this sources:

Tips & Tricks

Systemd based guests

When trying to containerize systemd based guests (like Arch Linux or Debian Jessie) we will need to use the current version of LXC (1.1.2 as of right now) and additional tools (like lxcfs). To get all those in supported versions of Ubuntu we will need to use the following PPA:

It should be noted that unprivileged containers and systemd are not working flawlessly right now, but as stated here:

More recent Debian is hitting a few systemd issues along the way but it eventually boots and seems functional, this will get resolved as Debian either updates to a more recent systemd or cherry-picks the various container fixes we committed to systemd upstream.

It should improve over time.

Offering network services from a container

To allow a service running inside a container to be reached from a network were the host is connected, we should add an iptables rule like this one in the host:

iptables --table nat --append PREROUTING --protocol tcp --in-interface eth0 --destination-port host_port --jump DNAT --to-destination $CONTAINER_IP:$CONTAINER_PORT

Bug in ZAP starting script (and maybe other Kali applications)

ZAP in Kali contains a bug that prevents it from starting in a host with a kernel different from the one that comes with Kali. In the file /usr/bin/zap the architecture is obtained with:

ARCH=`uname -r|cut -d "-" -f 3`

But a better way would be:

uname -m

But until they fix it (https://bugs.kali.org/view.php?id=2238), we can modify the corresponding comparison for our architecture:

-elif [ $ARCH == amd64 ]
+elif [ $ARCH == x86_64 ]

Recommended packages (for the forgetful)

In every Debian-based system that I use I like to install some essential packages to fight my poor memory:

apt-get install bash-completion command-not-found

Write-up VODKA – Final CTF NCN 2014

¡Buenas! Primero de todo me presento: mi nombre es Marc Peña (@p4chul0) y también soy miembro del equipo 0xB33r$. Hoy, continuando con las publicaciones sobre los retos de la final del CTF de la No cON Name, publicamos otro write-up.

Uno de los retos con los que estuve enfrascado durante el CTF fue VODKA (https://github.com/ctfs/write-ups/tree/master/ncn-ctf-2014/Vodka); en el mismo se obtenía un archivo con ese mismo nombre, que tras un primer análisis con file:

root@wheezy-kali:~/ctf_NCN/vodka# file vodka
vodka: bzip2 compressed data, block size = 900k

Parecía que se trataba de un archivo comprimido; tras extraerlo:

root@wheezy-kali:~/ctf_NCN/vodka# bzip2 -d vodka
bzip2: Can't guess original name for vodka -- using vodka.out

Obteníamos un archivo con una captura de tráfico de red:

root@wheezy-kali:~/ctf_NCN/vodka# file vodka.out
vodka.out: pcap-ng capture file - version 1.0

Que pasábamos a analizar con Wireshark:


Donde enseguida veíamos que se trataba de la transferencia de una imagen OpenWRT a través del protocolo TFTP.

Tras buscar como extraer el binario con el propio Wireshark nos encontramos con esto:

Que nos da a entender que la funcionalidad está implementada, pero no en la versión de Wireshark que tenemos instalada en nuestra Kali (1.10.2), por lo que tendríamos que compilar el trunk de Wireshark. Con el siguiente comando:

  • Instalaremos los paquetes necesarios para la compilación.
  • Clonaremos el repositorio de Wireshark.
  • Configuraremos y compilaremos el trunk.

apt-get install autoconf bison flex libtool libgtk2.0-dev libpcap-dev libc-ares-dev libsmi2-dev libgnutls-dev libgcrypt11-dev libkrb5-dev libcap2-bin libgeoip-dev libortp-dev libportaudio-dev qt4-dev-tools && \
apt-get build-dep wireshark && \
cd /opt/ && \
git clone https://code.wireshark.org/review/p/wireshark.git && \
cd /opt/wireshark && \
./autogen.sh && \
./configure --enable-dumpcap --enable-setcap-install --with-dumpcap-group=wireshark && \
make -j 8

Si todo ha ido bien ya podremos abrir el archivo con la última versión de Wireshark:

root@wheezy-kali:~/ctf_NCN/vodka# /opt/wireshark/wireshark vodka.out

Y exportar el archivo (File -> Export Objects -> TFTP):


Ahora tocaba lidiar con la imagen, por lo que instalamos el binwalk (https://github.com/devttys0/binwalk) del gran devttys0 (http://www.devttys0.com/):

apt-get install binwalk

Una vez hecho esto ya se podían observar las características de la imagen:

root@wheezy-kali:~/ctf_NCN/vodka# binwalk openwrt-wrtsl54gs-squashfs.bin
32 0x20 TRX firmware header, little endian, header size: 28 bytes, image size: 1323008 bytes, CRC32: 0x6CAC483 flags: 0x0, version: 1
2296 0x8F8 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
517152 0x7E420 Squashfs filesystem, little endian, version 2.1, size: 805671 bytes, 269 inodes, blocksize: 65536 bytes, created: Wed Oct 29 18:53:25 2014

Y extraer el sistema de archivos Squashfs (por defecto en el directorio «_openwrt-wrtsl54gs-squashfs.bin.extracted»):

root@wheezy-kali:~/ctf_NCN/vodka# binwalk -e openwrt-wrtsl54gs-squashfs.bin

Una vez dentro de este ya podíamos pasar a navegar por el sistema de archivos en busca de la flag:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root# ls
bin dev etc jffs lib mnt proc rom sbin tmp usr var www

En el directorio que miramos primero (/bin) encontramos un archivo con una fecha de modificación muy cercana a la de creación del sistema Squashfs:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root# ls -lisah bin/
total 596K
3670108 4.0K drwxr-xr-x 2 root root 4.0K Oct 29 18:50 .
3670107 4.0K drwxr-xr-x 14 root root 4.0K Jan 30 2007 ..
3670142 8.0K -rwxr-xr-x 1 root root 4.2K Oct 29 18:52 nc

Por lo que parecía un buen candidato para empezar a buscar. Si abríamos el archivo con un editor de texto veíamos que se trataba de un script en bash que muestra un «Nyan cat» en ASCII Art:

# --------------------------------------------------------------------------
# (c) 2012 BruXy Version: 1.0 http://bruxy.regnet.cz/
# --------------------------------------------------------------------------
# switch off cursor, set blue background, clear screen
echo -e "\E[?25l\E[44m\E[2J"
# Play music
#[ ! -f $M ] && wget http://nyan.cat/music/original.mp3 -O $M >/dev/null 2>&1
#while true; do mplayer $M > /dev/null 2>&1; done &
# easy way to reset terminal and exit subprocesses
trap "reset;killall nc" 2
## Nyan cat ANSI picture data, my own creation :P, size 38 x 11
# Compressed version of picture

Sabiendo esto vamos podíamos ir a buscar la versión original del mismo:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root/bin# wget http://bruxy.regnet.cz/linux/nyan_cat/nyan_cat.sh

Para analizar las diferencias:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root/bin# diff nyan_cat.sh nc
< M=/tmp/cat_orig.mp3
< [ ! -f $M ] && wget http://nyan.cat/music/original.mp3 -O $M >/dev/null 2>&1
< while true; do mplayer $M > /dev/null 2>&1; done &
> #M=/tmp/cat_orig.mp3
> #[ ! -f $M ] && wget http://nyan.cat/music/original.mp3 -O $M >/dev/null 2>&1
> #while true; do mplayer $M > /dev/null 2>&1; done &
< trap "reset;killall nyan_cat.sh" 2
> trap "reset;killall nc" 2
< printf "%*s" $[X*Y] BruXy
> file="/etc/banner"
> za="N"
> t1="C"
> drink="$(md5sum $file | grep -o ^[^\ ]*)"
> msg_="${za}${t1}${za}dead${drink}face"
> printf "%*s" $[X*Y] ${msg_}

¡Obteniendo lo que parece el código que genera la flag!

Creamos un nuevo archivo con este código (con la única modificación de la ruta del fichero, para convertirla en relativa):

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root/bin# cat vodka_flag.txt
drink="$(md5sum $file | grep -o ^[^\ ]*)"
printf "%*s" $[X*Y] ${msg_}

¡Y lo ejecutamos  para obtener la flag!:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root/bin# chmod +x vodka_flag.txt && ./vodka_flag.txt

Aunque tampoco pudimos resolver este reto dentro del CTF. no quiero terminar sin felicitar a los organizadores por unas pruebas de lo más originales.


Write Up 5h311 – Final CTF NCN 2014


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:

Ejecución 5h311

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 .

Permission Denied

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:

String put

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”.

puts command

Miramos las Xrefs del offset correspondiente a “aPuts” (x Key):

xrefs puts

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:

puts code

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.


gdb debug



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.

Captura de pantalla 2014-10-31 a la(s) 11.40.01


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».

Captura de pantalla 2014-10-31 a la(s) 11.46.07

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.

Captura de pantalla 2014-10-31 a la(s) 12.08.57

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:

IDA GDB Config


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.

Captura de pantalla 2014-10-31 a la(s) 12.27.40Captura de pantalla 2014-10-31 a la(s) 12.28.17Captura de pantalla 2014-10-31 a la(s) 12.27.57









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.

Captura de pantalla 2014-10-31 a la(s) 12.30.13

Captura de pantalla 2014-10-31 a la(s) 12.31.24

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.

Captura de pantalla 2014-10-31 a la(s) 12.32.00


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”.

Captura de pantalla 2014-10-31 a la(s) 12.35.58


Si una de las variables se llama “puts” entonces compara su valor con “printf”.

Captura de pantalla 2014-10-31 a la(s) 12.36.48


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.

Captura de pantalla 2014-10-31 a la(s) 12.37.36


Probando ahora el comando cat con un fichero cualquiera del directorio desde donde ejecutamos la shell vemos que nos devuelve “error: permission denied”

Captura de pantalla 2014-10-31 a la(s) 12.38.58

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!

Captura de pantalla 2014-10-31 a la(s) 12.51.08


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


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:

Cabecera LUKS


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 :

  1. 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),
  2. 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!! 🙂

acONOnado con el nuevo servicio de Wi-Fi gratis de ONO

Andaba yo tranquilamente viendo la televisión un rato, cuando veo un fantástico anuncio de la compañía ONO en la televisión en la que se ofrece a los clientes móviles acceso a Internet de alta velocidad mediante Wi-Fi. Rápidamente caí en la cuenta de que esta misma semana (que estaba experimentando problemas con la Wi-Fi de mi casa) había visto una red Wi-Fi rara: «_AUTO_ONOWiFi», y me temía lo peor…

Al acceder a la página de ONO para consultar acerca del servicio me he encontrado perlas como esta:

Captura de pantalla 2014-07-04 a la(s) 19.30.53



Vaya, un servicio que pueden utilizar incluso no clientes… mmm, cómo lo ofrecerán, habrán puesto antenas por ahí? veamos más… por ejemplo las condiciones legales del servicio…

Captura de pantalla 2014-07-04 a la(s) 19.35.21

WTF! Red doméstica formada gracias a la reconfiguración de los cable módems de nuestros clientes!!!! seguro que les habrán avisado…

pues no! resulta que mi cable módem era uno de los bonitos que estaba ofreciendo este servicio por la cara, y sin avisarme previamente… desde luego que mis días como cliente de ONO están contados.

Si sois usuarios de ONO chequead que vuestro cable módem no esté publicando una Wi-Fi con el SSID mencionado antes, y si lo está y no estáis de acuerdo (yo desde luego NO cedo MI INFRAESTRUCTURA sin haber dado NINGÚN TIPO DE  CONSENTIMIENTO PREVIO y SIN HABER SIDO NOTIFICADO), podéis solicitar la baja en la propia página de ONO. Yo comprobé de forma fácil que mi cable módem era un «lila» porque la intensidad de la Wi-Fi «pa la peña» esa era la misma que la de mi Wi-Fi; sin complicarme más apagué mi cable módem para ver desaparecer ambas Wi-Fi a la vez: la de mi casa y la otra de mi casa que ONO utiliza para invitar a navegar a la gente.

Captura de pantalla 2014-07-04 a la(s) 19.41.30

He ido tan rápido y malhumorado a deshabilitarlo que no me ha dado ni tiempo a pegarle un vistazo a lo que se podía hacer desde ahí…

Captura de pantalla 2014-07-04 a la(s) 19.43.31


Los muy majos además te ponen la desactivación del 2º SSID desde «Mis productos», en fin…

Después de deshabilitarlo he googleado un poco y había gente que lo advertía ya desde hace tiempo.

Espero que no os hayan dado el palo como me lo han dado a mí.

Buen fin de semana!


«Kicking around SCADA!» en RootedCON 2014

Los pasado días 6, 7 y 8 de Marzo se celebró en Madrid la V edición de las RootedCON. En ella, nuestro compañero Juan Vázquez (@_juan_vazquez_) y yo mismo (@julianvilas) tuvimos la oportunidad de presentar el resultado del trabajo de investigación sobre SCADA que llevábamos realizando los últimos meses.

La ponencia se tituló «Tú a Boston Barcelona y yo a California Tejas. A patadas con mi SCADA!», y en ella explicamos las vulnerabilidades que encontramos en el producto Yokogawa CENTUM CS3000, un Sistema de Control Distribuido (DCS/SCADA) desplegado en más de 7.600 instalaciones a lo largo del mundo (según el fabricante), utilizado en refinerías, petroquímicas, sector energético, oil&gas, y un largo etcétera de entornos considerados infraestructuras críticas.

Se encontraron vulnerabilidades a nivel de configuración del entorno / software base, a nivel de diseño de los protocolos (ausencia de cifrado, autenticación, control de integridad, etc.), y a nivel de implementación. Estas últimas se corresponden con los advisories publicados por el fabricante y por el ICS-CERT (CVE-2014-0781, CVE-2014-0783, CVE-2014-0784), vulnerabilidades provocadas por desbordamientos de buffer en el stack y en el heap que permiten ejecución remota de código, para las cuales ya se han publicado tanto parches como pruebas de concepto (exploits) en Metasploit Framework.

También hicimos una demostración de posibles acciones de post-explotación una vez comprometido el sistema, en la que troyanizábamos las comunicaciones entre las estaciones de operación (HIS) y el controlador (FCS). Para finalizar la charla contamos también los resultados de escanear internet gracias a la colaboración de Rapid7 y su proyecto Sonar, que realiza este tipo de escaneos.

Podéis ver las slides de la charla en Slideshare, y tan pronto como la organización de RootedCON publique los vídeos actualizaremos el post.

Agradecer desde aquí a la RootedCON y a todos sus asistentes el habernos permitido pasar un tan buen momento.


Solución reto Australia – Final CTF NcN 2013

A continuación la solución al reto de Australia, que por desgracia no nos dio tiempo a resolver en el mismo CTF, pero que hemos resuelto posteriormente y ahora os exponemos.

Al acceder a la IP del servidor correspondiente al país «Australia», se podía descargar un binario para proceder a su análisis. El binario era un ejecutable de Linux (ELF), que pedía introducir una clave que, principalmente, consistía en el flag que debíamos introducir para obtener la puntuación del juego.

Screen Shot 2013-11-30 at 10.11.14 AM

En el CTF optamos por hacer un reversing estático del programa con IDA, y para ganar tiempo, se obtuvo el código C mediante el empleo de HexRays:

signed int __cdecl main()
 signed int result; // eax@2
 int v1; // [sp+1Ch] [bp-4h]@1
 v1 = malloc(goodboy_len);
 if ( v1 )
 if ( fgets(v1, goodboy_len - 1, stdin[0]) )
 if ( check_buffer(v1, goodboy_len - 2) )
 puts("Winner! Post your flag.");
 fwrite("Sorry, that is not correct.\n", 1, 28, stderr);
 result = 0;
 fwrite("Could not read user input.\n", 1, 27, stderr);
 result = 2;
 fwrite("Could not allocate buffer.\n", 1, 27, stderr);
 result = 1;
 return result;
signed int __cdecl check_buffer(int a1, unsigned int a2)
 unsigned int i; // [sp+Ch] [bp-4h]@1
for ( i = 0; i < a2; ++i )
 if ( not_flag[i] != (*(_BYTE *)(a1 + i) ^ 0xCC) )
 return 0;
 return 1;

Si analizamos el código, se puede observar que el resultado del programa depende del valor de retorno de la función check_buffer(), en la cual el valor del flag XOR’ed con el valor 0xCC debe ser igual al array «not_flag»:

 not_flag[i] != (*(_BYTE *)(a1 + i) ^ 0xCC)

Por lo que para calcular el valor del flag, no hay más que conmutar la función XOR:

0xCC ^ not_flag[i] != (*(_BYTE *)(a1 + i)  

Cabe considerar que la entrada se comprueba BYTE a BYTE, pero eso ya lo analizaremos con detalle más adelante.

Después de varios intentos, pudimos comprobar que el flag no era correcto, por lo que algo fallaba.

Por lo que vamos a utilizar GDB para hacer un análisis dinámico y ver realmente que es lo que se estaba fallando.

Desensamblamos la función check_buffer:

Screen Shot 2013-11-30 at 10.43.11 AM

Analizamos el punto donde se realiza la XOR:

Screen Shot 2013-11-30 at 10.52.05 AM

El BYTE con el cual se realiza una XOR con la entrada del usuario se almacena en la posición -0x7(%ebp).

El siguiente código corresponde al cálculo del valor  que será utilizado para la operación XOR:

0x08048433 <+25>: movl $0xcd000000,-0xc(%ebp) --> -0xc(%ebp) = 0xcd000000
0x0804843c <+34>: mov -0xc(%ebp),%eax --> EAX = 0xcd000000
0x0804843f <+37>: shr $0x18,%eax --> Shift_Right(EAX,0x18) EAX = 0xCD
0x08048442 <+40>: mov %al,-0x7(%ebp) --> -0x7(%EBP) = 0xCD
0x08048445 <+43>: movzbl -0x7(%ebp),%eax --> %eax = 0xCD
0x08048449 <+47>: and $0xf,%EAX--> %eax = 0xd
0x0804844c <+50>: mov %al,-0x5(%ebp) --> -0x5(%ebp) = 0x0d
0x0804844f <+53>: movzbl -0x7(%ebp),%eax --> %eax = 0xcd
0x08048453 <+57>: and $0xfffffff0,%eax --> %eax = 0xc0
0x08048456 <+60>: mov %al,-0x6(%ebp) --> -0x6(%ebp) = 0xc0
0x08048459 <+63>: movzbl -0x6(%ebp),%eax --> %eax = 0xc0
0x0804845d <+67>: mov %eax,%edx --> %edx = 0xc0
0x0804845f <+69>: shr $0x4,%dl --> %dl (0-7bit) = 0xc
0x08048462 <+72>: movzbl -0x5(%ebp),%eax --> %eax = 0x0d
0x08048466 <+76>: shl $0x4,%eax --> %eax = 0xd0
0x08048469 <+79>: add %edx,%eax --> %eax = 0xdc
0x0804846b <+81>: mov %al,-0x7(%ebp) -->0x7(%ebp) = 0xdc

Con GDB no es necesario realizar todos los cálculos, sino únicamente con insertar un breakpoint en el punto en el que se realiza la XOR y ver qué hay almacenado en el registro %eax:

Screen Shot 2013-11-30 at 11.04.07 AM

Por lo que, en lugar de hacer una XOR con el valor 0xCC como se indicaba en el código, realmente se hace una XOR con el valor 0xDC.

Llegados a este punto, únicamente nos queda definir el formato mediante el cual se ha de introducir el flag. 

Según el código analizado, los valores introducidos por el usuario se almacenan en el registro %eax como resultado de la operación XOR, y los valores son comparados byte a byte mediante el uso del registro %al.

Screen Shot 2013-11-30 at 1.23.41 PM

Screen Shot 2013-11-30 at 11.04.07 AM

Los valores son comparados en formato hexadecimal, en cambio los valores son obtenidos de la entrada del usuario mediante la función fgets, por lo que los datos son obtenidos en formato ASCII. Por este motivo, para obtener los valores del flag hay que hacer una XOR del byte de la variable «not_flag» con el valor 0xDC y hacer una conversión a ASCII, tal y como se muestra a continuación:

Screen Shot 2013-11-30 at 1.35.17 PM

Así que para finalizar, solo hay que obtener los bytes de la variable «not_flag»:

Screen Shot 2013-11-30 at 1.38.48 PM

Y automatizar el proceso para obtener el valor del flag:

not_flag = [0xeb, 0xe8, 0xbf, 0xe4, 0xea, 0xbe, 0xba, 0xe4, 
 0xe5, 0xea, 0xe8, 0xea, 0xe8, 0xee, 0xe9, 0xba, 
 0xea, 0xe8, 0xeb, 0xba, 0xbf, 0xba ,0xeb, 0xea,
 0xe8, 0xef, 0xbd, 0xba, 0xed, 0xe9, 0xba, 0xee,
 0xe9, 0xed, 0xbe, 0xed, 0xe4, 0xea, 0xbe, 0xba, 
 0xe9, 0xe4, 0xbd, 0xea, 0xb8, 0xe9, 0xb8, 0xbf, 
 0xeb, 0xb9, 0xbe, 0xe4, 0xbe, 0xba, 0xe5, 0xbf, 
 0xba, 0xbf, 0xe5, 0xb8, 0xec, 0xe8, 0xbf, 0xb8]
puts "Solucion: "
not_flag.each { v | 
 p (0xdc ^ v).chr

Y finalmente, podremos verificar que el flag introducido es correcto 🙂

Screen Shot 2013-11-30 at 1.45.23 PM

Disfrutamos mucho del CTF. Esperamos ansiosos poder participar en otro bien pronto.


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?

  1. 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
  2. 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):

Captura de pantalla 2013-11-07 a la(s) 00.19.04

Lo codificamos en base64:

Captura de pantalla 2013-11-07 a la(s) 00.24.28

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!