This is a writeup of the challenge Zozo from the 2016 Whitehat Contest 11.

The challenge

We were given shell access to a server. On that server we can see two files, ~/signal and ~/flag.txt

Signal is a suid binary that runs with permissions of a user that can read the flag. It is pretty obvious that we are supposed to exploit signal in order to run code and read the flag.

The first part of the challenge is to get the binary off of the server - scp doesn’t work because it tries to open /dev/null and we don’t have permission to read /dev/null

My solution was to use xxd to dump the binary as text and then xxd -r to recover it. However, at this point I started thinking about how the server was kind of messed up and how maybe I could find something else interesting on it.

The binary looked relatively simple, with both a stack overflow and format string vulnerability jumping out. But rather than working on exploiting the vulnerabilities, I decided to have a look around.

Looking at the server

The first thing I decided to check was to see if there were any interesting files lying around. I ran find /home and found a bunch of interesting files that the organizers forgot to hide/deal with their permissions. There were a bunch of other users with various files:

The file to set up the permissions on the server:

/home/ubuntu/set_per.sh

A random binary that seems to just run a shell:

/home/ubuntu/a.out

And, a potential goldmine, the bash history of the shared user:

/home/pwnguest/.bash_history

That’s right. All teams’ commands were written into a shared .bash_history, for anybody else to read and inspect.

After running unset HISTFILE to make sure that my commands were not written in the file, I read the file to see if there was anything interesting.

There wasn’t much - one other player used base64 to copy the binary from the server (later revealed to be one of my own teammates), and one player used nc to his own server (the ip was of course saved in plain for all to see).

All of this unprofessional setup got me thinking that maybe I didn’t need to solve the challenge at all.

The lazy solution

I ran uname -a on the server and found out that the kernel version was:

Linux ubuntu 3.13.0-32-generic #57-
Ubuntu SMP Tue Jul 15 03:51:08 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux

A quick search on exploit-db led to this link for a PE on Linux Kernel <= 3.13. The PE allows me to change the permissions of any file on the system.

Even though the user we are given has no permission for /tmp or most other folders in /, the directory ~/.cache was writable, so I created the file exploit.c in there. I didn’t want to set suid on a file that other teams were likely to use (like /bin/sh), but luckily I had already discovered by chance the file /home/ubuntu/a.out which simply ran a shell and was owned by the group pwnreader, the same as the group that owns the file flag.txt. How convienient.

Using the linux vulnerability I added the setgid bit to the binary, and it worked! I ran the binary, obtained a shell with the group pwnreader, read the flag, and changed the permissions back!

Wait, what?!?!

Yup, I solved this solution by completely pwning the server with a public privilege escalation instead of looking at the intended challenge. Good times.