Security Challenge – Week 4

Oct. 16: Level 10 on the Nebula CTF. If you’re not sure what I’m talking about, I suggest reading last week’s post.

The setuid binary at /home/flag10/flag10 binary will upload any file given, as long as it meets the requirements of the access() system call.

At first, I wasn’t really sure what this was supposed to do, so I decided to put on my Black Box Tester hat; after all, that’s what I do for a living. Let’s see what just running the script does.

./flag10
 ./flag10 file host
 sends file to host if you have access to it

Cool – gives me a little context. The script expects a file as the first parameter, and a host as the second. The script claims to send the file to the host, if I have access to it. Let’s give it a try, by creating a file in Level10’s home directory.

./flag10 ~/text.txt 192.168.224.1
 You don't have access to /home/level10/text.txt

Weird, it’s MY home directory. The script is owned by my user. Near as I can tell, it’s not running as a different user.

Oct. 17: Yesterday, I spent about an hour trying to figure out this code. Decided to come at it with fresh eyes today. Noticed that Line 24 has something called access. I assumed it was some kind of file-opening command, but based on the man page, ” checks whether the calling process can access the file pathname. If pathname is a symbolic link, it is dereferenced.” Maybe a symbolic link file would do the trick.

ln -s ~/text.txt text2.txt
ln: creating symbolic link `text2.txt': Permission denied

Nope, that’s not it. Checked the port, to see if maybe there’s a vulnerable service there. Port 18211 is, at least officially, unassigned. There’s a bunch of code dealing with incorrect inputs, but I don’t see anything there that seems to hint at where the bug is. Line 54 seems to be where the file is actually opened. There’s some interesting stuff around symbolic links in the man page, and while I already know that won’t work, it brought me back to the idea that maybe the script IS running as a different user. I decided to run the top command on the Nebula VM directly, and put it on my other screen, so I could watch it as the command ran. With all the noise, I needed to filter things down a bit. Based on the information from the ls command, my hunch is that the script runs as flag10, instead of my user (level10). Unfortunately, that didn’t pay off – level10 was running sh, when I was able to catch it in top.

Decided to take another look at the list of files. I can’t access the token file to see what’s inside, but maybe I can transfer it?

./flag10 token 192.168.224.1
You don't have access to token

Damn. Tried to copy the file from ~/level10 to /home/flag10.

cp ~/text.txt text.txt
cp: cannot stat `/home/level10/text.txt': No such file or directory

Weird, I know the file is there.

cd ~
ls
test.txt x

Hmm, didn’t notice that x file before.

615a2ce1-b2b5-4c76-8eed-8aa5c4015c27

I wonder what this is? The file actually seems to have a LOT of blank lines; when I ran cat against it, I mostly got empty screen.

./flag10 ~/x 192.168.224.2
Connecting to 192.168.224.2:18211 .. Unable to connect to host 192.168.224.2

./flag10 ~/x 192.168.224.1
Connecting to 192.168.224.1:18211 .. Unable to connect to host 192.168.224.1

Ok, progress of a sort. Can’t connect to my Kali VM, or use this to connect to itself.

I finally caved, and started looking online for a solution. I found this one, but it doesn’t actually seem to track with what I’ve experienced. This one, on the other hand, makes a bit more sense to me. I had a hunch that the symbolic link thing was the trick. It’s interesting too, that the password was also stored in that x file.

flag10@nebula:~$ getflag
You have successfully executed getflag on a target account

Oct. 18: Time for Level 11! Another code-heavy one…hooray.

The /home/flag11/flag11 binary processes standard input and executes a shell command.

There are two ways of completing this level, you may wish to do both 🙂

I have to assume this is some kind of hint, because it seems like there’s more than one way to tackle most of the challenges.

Line 10 in the script is a comment that says “Return a random, non predictable file, and return the file descriptor for it.” Ok, let’s run the script with no parameters and see what happens.

Pretty much nothing. Looks like it should take a couple of arguments. Tried typing in 1.

./flag11
1
flag11: invalid header

I see where that error message comes from in the code. Not too far below, there’s mention of some colours; maybe that’s what it’s expecting?

./flag11 blue
green
flag11: invalid header

Nope. Ok, time to start again at the top of the script.

Oct. 19: 30 minutes of reading “Network Security Assessment”

Oct. 20: After a significant amount of frustration, I tried a couple of different solutions I found online. Frankly, I only partly understood what they were talking about, and I couldn’t get any of them to work. I’ve made the decision to move on to the next one, since I’m fairly certain that it doesn’t require the previous one to be complete.

Oct. 21-22: 30 minutes of reading “Network Security Assessment”