DEV Community

loading...
Cover image for Linux/Talking to the dead 1-4 @ Hacktober CTF 2020 write-up

Linux/Talking to the dead 1-4 @ Hacktober CTF 2020 write-up

igotinfected profile image Jason Rebelo ・4 min read

hacktoberCTF

Hacktober CTF logo

This post is part of my Hacktober CTF 2020 writeups series. To check out the entire series, read the post below.

Talking to the dead 1 (30 points)

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

Password: hacktober-Underdog-Truth-Glimpse

challenge author: syyntax

Analysis

So here we are given access to a server and are supposed to find a few important files denoted flagX.txt, X being 1 to 4.

The first thing to do is to connect to that server and do some file discovery.

Discovery

ssh

Connecting to the server

After connecting to the server, since we know what files we are looking for,
we can simply run find to see if all 4 files show up in our search.

discovery

Finding the files we're looking for

There we go, now we know exactly where the files we need are located.

To break down the above command into simple terms first though:

  • find is a command that allows us to look for different kinds of files, anywhere on the system. It comes with some neat features such as looking for files with a specific name, or files with a specific extension, and so on.
  • the / character indicates to the find command that we want to search everywhere on the system.
  • the -name "*flag*.txt"* argument indicates to the find command that we are looking for files with a name that has "flag" in its name, and ends with the extension ".txt".
  • 2>/dev/null redirects all error output outside of our view. This makes it so we don't see a bunch of errors while trying to find files in folders that we don't have permission to see.

Solving

From here, we can simply read the file since we know its location:

flag1

Here's the flag: flag{cb07e9d6086d50ee11c0d968f1e5c4bf1c89418c}

Talking to the dead 2 (30 points)

There's a hidden flag that belongs to luciafer. Submit the contents of the hidden flag2.txt.

ssh hacktober@env.hacktober.io

Password: hacktober-Underdog-Truth-Glimpse

challenge author: syyntax

Analysis

The challenge here was that this file is a hidden file (it starts with a ., this makes it so that the file is usually hidden from searches, unless we are specifically looking for hidden files, which we are!).

Since we expected this from the start, we made find look for this kind of file, too.

Solving

Once again, we can simply read the file since we know its location:

flag2

Here's the flag: flag{728ec98bfaa302b2dfc2f716d3de7869f3eadcbf}

Talking to the dead 3 (100 points)

Submit the contents of flag3.txt from the remote machine.

ssh hacktober@env.hacktober.io

Password: hacktober-Underdog-Truth-Glimpse

challenge author: syyntax

Analysis

We already know where this file is, but we don't have the rights to read it:

permissiondenied

The logical next step here is to find a way to either get access to that user's
login credentials, or to find an application that allows us to bypass our insufficient permissions.

Discovery

To achieve this, I ran LinEnum, a script that automatically checks the entire system for potential ways of gaining higher privileges. Nothing interesting showed up though in terms of privilege escalation, other than potential applications with the SUID bit set.

The SUID bit allows any user to run an application with elevated privileges.

In order to find these kinds of applications, that potentially allows us to escalate our privileges, we can also use the find command:

suid

Most of these applications look and are quite normal, they are part of the packaged linux applications. One of these stands out though: ouija. It's not a standard application, so let's see what it's all about.

ouija

Oh. This application lets us read files in the root directory, regardless of whether we have the right to or not.

The problem now though, is that the file we want to open right now, is not in the root directory.

Solving

We first try to pass the full path to the flag3.txt file to ouija:

fullpath

We notice that it doesn't work, but we also notice immediately that the program simply takes the path we provide, and appends it to /root, so maybe we can just do some simple path traversal to get to the file we want to read?

traversal

There we go! Simple as that 😎

Here's the flag: flag{445b987b5b80e445c3147314dbfa71acd79c2b67}

Talking to the dead 4 (300 points)

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

Password: hacktober-Underdog-Truth-Glimpse

challenge author: syyntax

Analysis

Looking at the point difference in "Talking to the dead" 3 and 4, we come to the realisation that ouija was probably supposed to be part of "Talking to the dead 4" only, and the path traversal trick was an unintended solution to "Talking to the dead 3". I'm guessing that there was a way to find the password for the spookyboi user, maybe from another challenge.

Either way, there is no big secret about solving this challenge anymore 😛

Solving

flag4

Here's the flag: flag{4781cbffd13df6622565d45e790b4aac2a4054dc}

Conclusion

That's it for the "Talking to the dead" challenges. A pretty easy linux challenge that required some knowledge about finding files, path traversal tricks, SUID bits, and maybe some effort into finding spookyboi's password? We'll never know!

If you're interested in other writeups for this CTF, check out the post below.

Discussion

pic
Editor guide