blog

11 Days

d6356c408f36a4bf4b48abbee5bfffe91d196ee6

Devices can get drunk too. Fewer bytes, twice the fun!

14 Days

ee28d0be718055423ee79d89889ebe386e5b0c2d

This one didn’t even require impairing drugs, all it took was asking nicely.

31c3 CTF - safelock (signals20)

safelock
Signals (20 pts)
-------------------
This is the circuit of a safe lock. Get the key to open it!
http://188.40.18.86/safelock/

It's neither about webtronics nor ngspice. Disregard bugs in both.

If you want to write spice code directly, use something like this

cat test.cir | curl --data-binary '@-' http://188.40.18.86/safelock/contest_spice/spice.cgi

Clarification

It has come to our attention that nobody seems to have any idea what the past 4 posts have been about. In an attempt to clarify things, we have prepared a handy diagram:

Console Hacking 2013: Omake

As you’re likely aware, our team gave a lecture at the 30th Chaos Communication Congress on hacking the Wii U. This blog post is a follow-up to the talk and contains clarifications, corrections, and material that we couldn’t fit in the one-hour time slot.

If you haven’t yet, please watch the talk before reading the rest of this post:

Slides: Online · Download / source code

CVE-2012-0217: Intel's sysret Kernel Privilege Escalation (on FreeBSD)

CVE-2012-0217 was reported by Rafal Wojtczuk but ironically, it was fixed for Linux in 2006 as shown by CVE-2006-0744 without receiving much attention.

It is quite an interesting vulnerability on many aspects. Among them, and thanks to its hardware basis, it impacts many operating systems. For instance, as long as they run on a Intel processor in long mode (obviously), FreeBSD, NetBSD, Solaris, Xen and Microsoft Windows have been reported to be vulnerable. This therefore gives us quite an incentive to develop an exploit ;).

If you haven’t yet read Xen’s blog post The Intel SYSRET privilege escalation please do because we won’t go again into too much details about the vulnerability itself.

Without further delay, let’s dig right into the FreeBSD exploitation!

DCPU-16 Review

I’ve always liked the idea of building complex logic systems out of a simple primitive that is just powerful enough to construct all logic - particularly in videogames. For example, in LittleBigPlanet, you can build a Tic-Tac-Toe AI out of physical elements like pistons and magnetic switches. In Minecraft, you can build an ALU out of a primitive construction element that behaves, essentially, as a NOT gate. And, if games aren’t your thing, you can build CMOS logic out of UNIX pipes with a simple “mosfet” program.

Just a few days ago, Notch, the creator of Minecraft, revealed a new game, 0x10c. Instead of giving players a simple logic element, it will include a full-blown 16-bit CPU that can be programmed. I find this intriguing, because it allows for much more complex development yet it doesn’t step right into the boring world of “let’s just throw in a lua scripting engine and call it a day”. You’re still limited by emulation speed and by memory constraints.

However, after checking out the preliminary spec for the CPU, I was a bit disappointed.

The future of console homebrew (and a shot of Espresso)

It’s been almost 7 years since the Wii was released. Back in 2006, not many owned a living room PC. PCs were still relatively bulky, and the Chinese offerings were limited to horrible media players. At the time, the prospect of having a game console double as a HTPC and being able to browse the web, play games for older platforms with emulation, and run homebrew games on a device which you already had in the living room was rather appealing.

Fast forward to today. Mobile SoCs have made huge advances - you can get a quad-core chip in a phone these days - and have made the jump to the living room. Spend $25 and you can get a Raspberry Pi, which is about on par with the Wii at 1/10 of the launch price and 1/7th of the power consumption (with HD video). Spend $100 and you can get an Ouya, which beats the Wii U’s CPU and doesn’t have too shabby graphics at one third the cost. These mobile-derived devices aren’t quite a replacement for game consoles yet, but they’re catching up fast. They’re cheap enough that they’re almost disposable. The software ecosystem is much larger and wider than any console has ever had. More importantly, they’re open, and the development tools and environments are way better for open development than any game console ever was.

Megafail

Let’s take a break from Wii U hacking to take a quick look at Mega’s security.

In case you’ve been living under a rock the past few days, Kim Dotcom (of Megaupload infamy) has launched his new cloud storage site, Mega. Mega has an impressive sales pitch, promising secure cloud storage where only the user has the key to decrypt his or her files, and the encryption and decryption happens securely in the browser.

Today we aren’t going to take a look at their encryption or their key generation, which have already been the subject of several articles. Instead, we’re going to look at the security of the Mega website itself. As Mega themselves admit, if you use their web interface (and not a third-party client), the security of the entire ordeal depends on whether you trust them. After all, anyone with the ability to modify the site could just replace the JavaScript code with one that sends them (or anyone else) your password or master key. There’s no way around having to trust Mega for this, but you also have to trust that Mega’s site is delivered securely to you.

AT&T Microcell FAIL

One of the things we’ve been playing with recently is the AT&T Microcell. This device is intended to provide a cheap way for AT&T to increase their network coverage at the expense of their customers. The device is essentially a small cell-tower in a box, which shuttles your calls and data back to the AT&T mothership over your home broadband connection.

This kind of device is becoming more and more popular with the various mobile providers. They are commonly known as residential femtocells.

We’re curious. We love gadgets. We love to take gadgets apart and see what makes them tick. So naturally, we’ve taken a look at a number of different femtocells.

We finally got around to looking at this AT&T variant this week, and discovered that it is totally full of fail.

plaidCTF 2014 - graphs (crypto200)

This challenge was about breaking a custom public key encryption system.

graphs
Cryptography (200 pts)
--------------
In this era, block ciphers hadn't even been invented. The Plague created this
system based on problems he knew to be NP hard, but there must be something you
can do to decode his messages.

We were given a python implementation of the system, the Plague’s public key and an encrypted message. The implementation includes encryption, decryption (given a private key) and key generation.

plaidCTF 2014 - wheeeee (crypto375)

wheeeee
Crypto (375 pts)
----------------
Although it seems like The Plague's messaging service is secure, 
there are bound to be bugs in any 20th century crypto system. 
We've recovered a version of the block cipher The Plague implemented. 
Use their online encryptor tool, at 54.82.75.29:8193, to break the 
cipher and figure out Plague's secret plans. NOTE: When the service 
sends you a hex-encoded string, respond with a hex-encoded string.

plaidCTF 2014 - doge_stege (for100)

This challenge was about extracting a (not very well) hidden message out of an image file:

doge_stege
Forensics (100 pts)
--------------
You were startled to learn the The Plague has been behind many of the
most popular internet memes. We believe he hides information in these
funny pictures with steganography in order to broadcast his messages
through time without detection. Find the hidden message, stop the
signal.

Original doge_stege Image

Obvious Stego is Obvious

The first thing to do with every file you get from a CTF challenge is to run the file command on it:

% file doge_stege.png
doge_stege.png: PNG image data, 680 x 510, 8-bit colormap, non-interlaced

plaidCTF 2014 - curlcore (for250)

Last week we played plaidCTF with Eindbazen under the name 0xffa (can you figure out why that name?). Write-ups are mandatory in the rules, so let’s start with an easy one :-)

curlcore
Forensics (250 pts)
-------------------
We managed to grab a memory dump off of The Plague's computer while
he was making a secure download. We think he may have been looking
for new places to hide the Prime Factorizer. Can you figure out what
messages were sent through his computer?

For this challenge, you get 3 files:

  • capture (a network capture)
  • corefile (a memory dump)
  • coremaps (the process’s memory map)

and the shell script which helped generating those files

#/bin/sh

sudo rm /tmp/capture 2>/dev/null
sudo dumpcap -i eth0 -w /tmp/capture &
DUMPCAPPID=$!

sleep 1
OUTPUT="`/usr/bin/env -i /bin/dash -c 'ulimit -c unlimited; curl -k https://curlcore.local.plaidctf.com/flag.html & PID=$!;     sleep 5; printf "generate-core-file\ninfo proc mappings\ndetach\n" | sudo gdb attach $PID; wait'`"
sleep 1

sudo kill -INT $DUMPCAPPID
wait

sudo chown `whoami` /tmp/capture

echo "$OUTPUT"

sudo mv "`echo "$OUTPUT" | grep -o 'Saved corefile .*$' | cut -c 16-`" /tmp/corefile
sudo chown `whoami` /tmp/corefile


echo "$OUTPUT" | awk '/Mapped address spaces/,/(gdb)/' | grep -v '(gdb)' > /tmp/coremaps

rm /tmp/curlcore.tgz 2>/dev/null
tar czf /tmp/curlcore.tgz `grep -o ' /.*$' /tmp/coremaps | sort -us | tr '\n' ' '` /tmp/corefile /tmp/coremaps /tmp/capture     "$0"

Since we have a network capture of the https download, we need to find a way to decrypt the SSL communication…

plaidCTF 2014 - bbos (for350)

bbos
Forensics (350 pts)
-------------------

You have traveled back in time, but look, hunting  The Plague is tough.
You're really just going back to relax for a while  without having to
worry about all that nonsense. As you walk in the park  you stumble
across someone's BlackBerry. Wow, people still use  BlackBerry phones
(time travel gets so confusing)? You figure you should  return it to the
owner, but you have a hard time getting inside. Figure  out what's on
the phone, and maybe we'll be able to return it to the rightful owner.

BlackBerry was this fancy pager thing, right?

plaidCTF 2014 - zfs (for400)

zfs
Forensics (400 pts)
-------------------
The Plague is using state of the art systems for storing his data. 
Our operatives managed to steal a drive from one of his servers, 
but it seems like our haste may have led to some uber-corruption. 
Can you get the data off the drive to track down The Plague?

Sure we can. But where do we start?

plaidCTF 2014 - rsa (for450)

rsa
Forensics (450 pts)
--------------
Our archaeologists recovered a dusty and corrupted old hard drive used by
The Plague in his trips into the past. It contains a private key, but this
has long since been lost to bitrot. Can you recover the full key from the
little information we have recovered?

You can download the recovered information here.

plaidCTF 2014 - freya (misc250)

This challenge is part of the misc category:

freya
Misc (200 pts)
-------------------
We've traveled back far, but this protocol looks familiar...
Our reconnaissance team did a great job, they got us a data capture
from the currently running systems and a private key
from the server (shell.woo.pctf which resolves to 54.226.73.167).
Take  a look at the traffic our reconnaissance team picked up, and see if you
can get access to The Plague's server, at 54.226.73.167.

with the following four files:

  • freya.pcapng
  • freya_cert.pem
  • freya_priv.pem
  • password

The task is pretty simple - somehow get access to shell.woo.pctf, probably by using ssh.

plaidCTF 2014 - rendezvous (misc250)

This challenge was about establishing a connection to a hidden tor service which is rather picky in accepting connections. We were given the following description:

rendezvous
Misc (250 pts)
--------------
The Plague has a friend called Alice who has some secrets on a tor
service (http://6c4dm56aer6xn2h2.onion/). We think if we can talk to
her, we can learn some useful things about The Plague. Unfortunately
she will only rendezvous with "chandler" when he brings a cookie with
"beef" baked into it. Can you help us find her secret?

Getting Started

The first thing we did was of course trying to connect to the service. Whether using a tor to web gateway as for example onion.to or a local tor instance, the result was the same: no connection could be established. Using curl -v --socks5-hostname localhost:9050 http://6c4dm56aer6xn2h2.onion/ showed that curl didn’t even send the request, confirming that the problem is at the tor layer and not at the HTTP layer. Thus getting a tor connection to the hidden service is actually part of the challenge.

plaidCTF 2014 - ezhp (pwn200)

ezhp
Pwnables (200 pts)
-------------------
Luckily when you travel back in time, you still get to use all your
knowledge from the present. With that knowledge in hand, breaking
into this service (at 54.81.149.239:9174) owned by The Plague
shouldn't be hard at all.

To set the picture, let’s identify the binary

izsh@box:~$ file ezhp
ezhp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=0x5fa5bd76db306497b549ea3b0466cd9e9afa2705, stripped

izsh@box:~$ readelf -l ezhp | grep STACK
    GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

plaidCTF 2014 - __nightmares__ (pwn375)

__nightmares__
Pwning (375 pts)
-------------------
The Plague is building an army of evil hackers, and they are starting
off by teaching them python with this simple service. Maybe if you
could get full access to this system, at 54.196.37.47:9990, you would
be able to find out more about The Plague's evil plans.

This server simply evaluates any Python expression provided - with an attempt at sandboxing it.

plaidCTF 2014 - g++ (re200)

Although it seems like The Plague's projects are  open source, it's not
quite so simple to figure out what the source code  does. We believe
this project is supposed to print out secret information, but the KEY
variable in the Makefile has been lost. Find the key, build the
project, get us the information.

Oh noes, the key is gone!

plaidCTF 2014 - paris (re300)

paris
Reversing (300 pts)
-------------------
This binary was found on some of our Windows machines. It's got The
Plague written all over it. What secrets are contained inside?

We are greeted by a Windows executable. Since I hate Windows and I can’t be arsed to pull up a Windows VM and debugger, I decided to solve this one statically. Time to load it into IDA.

plaidCTF 2014 - tiffany (re300)

tiffany
Reversing (300 pts)
-------------------
We want to get access to a server used by The Plague. Maybe if you
can find out what key is accepted by this binary you can find out
where or when The Plague is...

Yay, a Linux x86_64 executable! Let’s run it and see what happens, because what could possibly go wrong when running a random binary off the internet?

$ ./tiffany
This may take a while...
.......
Please enter a string: TEST
....
Sorry, wrong.

Well, that took 3 seconds to initialize and 5 seconds per input string character. Sure seems to be doing a lot of stuff. Let’s load it into IDA to get a general idea.

plaidCTF 2014 - bronies (web800)

bronies
Web (800 pts)
-------------------
We are trying to break into eXtreme Secure  Solutions, where The
Plague works as a system adminstrator.  We have found that their
internal company login page is at
http://portal.essolutions.largestctf.com/. Recon has also revealed
that  The Plague likes to browse this site during work hours:
http://54.196.225.30/ using the username ponyboy2004.  Remember, our
main target is to break into the company portal, *not* the pony site.

Unprogramming: Intro

On Friday, the 13th of January 2012, the ACM Queue published an article by Poul-Henning Kamp entitled ‘The CRYPO-CS-SETI challenge: An Un-programmng challenge’. In this post, Kamp challenged his readers to attempt to disassemble a program for an unknown computer. In what we assume was an attempt at increased dramatic impact, he described a scenario where part of an extra-terrestrial computer is discovered, with only a memory storage device intact.

We first heard of the challenge on the morning of Saturday the 14th, and thought it sounded like fun. Within five days we had completely disassembled the program. In addition, we had accidentally identified the oh-so-terrestrial source of the code.

This is the first in a series of posts in which we’ll describe how we went about reverse-engineering the machine architecture using nothing but the binary blob and our wits.

Wii U Teaser

We finally have a YouTube channel and we thought we’d kick things off with a little teaser:

Keep in mind that this is purely a demonstration at this stage. Depending on how things progress and what direction development takes, we may or may not release something like this in this form. Please don’t ask for release dates. We’d rather spend time investigating the new system than putting together a release that may or may not end up being the Right Way to do things in the future ;).