OverTheWire’s Leviathan Challenge
Collection of screenshots and notes
Password directory: /etc/leviathan_pass/ Server: http://leviathan.labs.overthewire.org: 2223
Challenge notes and hints will all be in the home directories of the current level.
Level 0:
SSHed as leviathan0 and found a folder containing a simple HTML file of a bookmarks export.
Could have tried other keywords to locate the password, but one of the most obvious ones to me was “leviathan”, since the password is likely stored in the leviathan server:
Level 1:
Found a file with SUID (s
) privileges and a prompt for a password.
It appears to be an executable program written in C where you input the correct password to get a shell; the strings are compared using the strcmp function, and there are a couple of keywords right before you input the password:
Grepped for the word “love” in the program, which originally didn’t return anything because of binary matches, so I allowed the binary matches via -a parameter and got 4 potential keyword matches:
And one of the keywords did end up being the correct one, so we got a shell and catted the password:
Level 2:
There’s a program with SUID privileges that appears to print out a file you specify, so just in case, I tried to retrieve the password through it, but it unsurprisingly requires you to have the right permissions for access:
What’s interesting is that even if the current user owns the file, we get a “Permission denied” message.” Only files within the current directory are successfully printed out.
Through online research, I discovered a program called ltrace
that can trace library calls made within a program, but it didn’t return anything interesting, so I just eyeballed the program’s strings and located a keyword of interest, “access”, since I didn’t recognize it as a command or typical C function.
I looked in the man pages in case it was a command of some sort and discovered that it is actually a C library that checks whether the calling process can access a given file:
This suggests that there is likely not input sanitization, so I tried to create an empty with a filename that attaches the bash command to the end of it, then referenced that file as the argument to the printfile program, and it ran exactly as input, opening a bash shell as leviathan3:
Level 3:
The file “level3” seems to open a shell if you input the right password.
Running an ltrace again on the program (starting to LOVE this new command!), we see that a strcmp is run, comparing the input with a plaintext value “snlprintf.”
So, we run the program again and enter this as the password and get a shell as leviathan4.
Note to self: why did you run the program with a filename? You’re still stuck on the previous level -_-
Level 4:
There is a simple file in the “.trash” directory that contains binary.
We just crack the binary with CyberChef and it looks like the password:
But it can’t be that easy, right?
Yep…..it is certainly that easy.
Level 5:
There’s a program “leviathan5” with the owner set to “leviathan6”, and it looks like it just opens a particullar file “/tmp/file.log”, but the file doesn’t currently exist:
I created a file at that exact path and it looks like the program does indeed read what’s in there.
We can actually create a Symlink (with the ln -s command) between “file.log” and the password file, run the program, and it (hopefully) will print out the password file:
Logic: basically, file.log is a link to the password file, so when fopen tries to retrieve the file.log, it in fact prints out the file it links to.
Level 6:
Pretty straightforward program that asks for a 4-digit code:
This is probably a matter of using a simple bruteforce script that I wrote in Bash (not the prettiest, but it was functional, except for not exiting after the else condition was met…)
#!/bin/bash
cd ~
for num in {1000.9999}
do
if ./leviathan6 $num | grep -q "Wrong"; then
echo $num
continue
else
echo "Correct: " $num
exit 1
fi
done
And it stopped right before the correct code, which we plug into the program and get a shell.
And that’s it! Kind of wish this one went on a bit longer…