The Office: Doomsday Device Writeup

Disclaimer: This post demonstrates hacking techniques and could be considered dangerous. I’m doing this for my own personal research using freely available tools and information, and testing against a vulnerable machine specifically designed for security assessments that has been installed in my own personal lab isolated from the public Internet. Please do not use these techniques against any computer system that you either do not own or do not have permission to work on.

It’s been a few weeks since I’ve done one of these. I found this box on Vulnhub, and considering I’m a big fan of The Office, I had to give it a go.

This vulnerable machine is based on an episode of The Office where Dwight Schrute implements a Doomsday device to send incriminating information to Robert California about his fellow Dunder Mifflin employees in an attempt to get them fired. Let’s see if we can stop Dwight by hacking into the Doomsday Device.

I’ve booted the machine into VirtualBox along with my Kali Linux Machine, scanned the network with NetDiscover and found the IP 10.0.2.46. Opening up a Web browser I can see this page.

Dunder Mifflin Website

Nmap shows the usual FTP, SSH and HTTP ports open with an interesting entry in the robots.txt file. SSH shows as filtered, so there might be a firewall here, or something restricting access.

Unfortunately ‘/nothingtoseehere’ really does seem to be nothing. Anonymous FTP didn’t work either.

I’ll do another port scan on all ports, and run gobuster to check for any hidden content on the web server.

Nmap found two additional ports, 18888 and 65533. Port 18888 seems to have a web server running.

Opening it up in the browser shows a separate web application.

And port 65533 also looks like a web server, but one that is not currently accessible.

On the first application, running on port 18888, if I navigate to http://10.0.2.46:18888/admin/ there is an admin login interface, the application looks to be running a CMS called Koken. Some digging, by using ‘View Source’ and Wappalyzer, shows that Koken is a PHP app, with a MySQL database.

I could try logging in, or brute force, but I don’t really know enough yet for it be worthwhile, other than when I tried to login with admin:admin I got this message.

So I know the CMS requires an email address to login. Recall before when I tried connecting to port 18888 with telnet I found a server response with www.dundermifflin.com in the body of the response. I’m going to guess that email addresses for the system use @dundermifflin.com, but I still don’t know any valid users yet. Moving on.

I did a quick Google search for ‘koken 0.2.24 exploits’ and found an entry on Exploitdb for an authenticated arbitrary file upload which looks promising and might give us a shell once we’ve gotten access to the CMS.

Clicking around the frontend of the CMS at port 18888 I found the page /essays which has Angela’s email address in the information. This confirms my assumption that we need to use @dundermifflin.com to login to the CMS and I now have an email address for a user.

I tried to login using Angela’s email address and from watching the show so many times, I know Angela loves cats, so I tried one of the cat’s names, ‘sprinkles’ as a password. Not surprisingly it failed, that would have been too easy ;-).

At this point I think it might be time to turn on BurpSuite.

Trying the [email protected]:sprinkles combination again with Burp running I got an error that I didn’t expect.

Notice in the response panel, ‘User not found’. Which is interesting. I thought for sure Angela’s email address would be a valid user seen as she looks like the one who’s managing this application.

I loaded a list of email addresses using Office character names into Burp and sent the login request to Intruder.

In this case I wasn’t trying to login, I wanted to see if I could find a valid email address by getting a different server response. Unfortunately I got 404 errors for all the email addresses in my list.

There’s still FTP to check out, so I tried to login to ftp://[email protected] with the ‘sprinkles’ password. That didn’t work, so I’ll run hydra against FTP with the rockyou.txt wordfile.

At this point I was starting to run out of things to try, but as I was clicking around I opened the Chrome inspector and on the main webpage I noticed some Base64 in a HTML comment.

Copy and paste that into CyberChef and I found some Morse Code.

So I added the ‘From Morse Code’ to the CyberChef recipe and found some text.

It’s a message from Dwight with the first flag.

#FLAG1:8CAF9C64F9D1181206FEC7F40A7524B3

I already started a Gobuster scan earlier and left it running (which I forgot about). Gobuster found a directory called /nick sitting on the main website and also a folder called /staffblog.

/nick has some interesting files.

The farewell.txt file is a note from Nick the IT guy to Michael. Looks like Creed uses a weak password so that’s something to keep in mind.

The PCAP file though is a network Packet Capture showing captured traffic that someone has obviously saved. Opening the file in Wireshark didn’t take long to find a successful login from Creed to FTP.

I tried to login to FTP using creed:creed but it didn’t work.

I’ll check the /staffblog directory now.

The CreedThoughts.doc is a document written by Creed for his Blog. In the doc, Creed mentions the IT guy has told him his password is weak so he’s added 3 digits to the end of it. I tried a couple different combinations like creed123, creed321 etc but then I got bored. I wrote a python script to generate a list of passwords using ‘creed’ plus 3 numbers and redirected the output to a file.

!/usr/bin/env python3
for i in range(100,999):
    print("creed{}".format(i))

With that file of potential creed passwords, I can use Hydra to try and crack it. After a minute or so, I found Creed’s password and was able to login to FTP.

There’s two files in Creed’s FTP folder. archive.zip and reminder.txt.

reminder.txt has another flag and a message about a forgotten password that made Michael laugh.

#FLAG4: 4955cbee5a6a5a48ce79624932bd1374

This was easy. There’s an episode of The Office when they get locked out of their server and end up figuring out the password that offended Pam. Extracting the archive.zip with the password (Google for it, ends with a z). There’s two files, an email and a file called ‘michael’.

This is interesting. I was trying the cat’s name ‘sprinkles’ earlier, maybe it’s one of her other cats names. This also confirms that Angela does have an account in the CMS.

The file called ‘michael’ is a private key. However, my excitement was shortlived, SSH is still blocking connections.

Knowing now that Angela’s password is definitely one of her cats names, I made a list that I got from Google of all of her cats and tried Burp Intruder again against the web application.

302 redirect. That looks promising.

Success! I’ve got access to the CMS as Angela. Now I can try the exploit from Exploitdb. It requires creating an image.php.jpg file and uploading it to the CMS but intercepting with Burp and changing the filename to image.php. I followed those instructions but changed the payload to a reverse PHP shell.

Completing the upload, I started netcat in Kali and navigating to the image in the browser I got a reverse shell.

Now for some privilege escalation. First I’ll grab the /etc/passwd file and start looking around.

Looking around the filesystem, I found a folder /var/www/html2/secret with some files, including an index.html and index.html.bak containing another flag. That’s interesting. I checked the apache2 config files and found that /var/www/html2 is the webroot of the application running on port 65533, so I tried it in the browser.

#FLAG2: 0a9025f72493da059a26db3acb0e2c42.

I also found a _hint_ folder under the /var/www/html folder, which is the main website on port 80.

No doubt Dwight has hidden something here. I’ll download the images and look at them shortly.

I’ve started a Python web server on my Kali machine and uploaded LinPeas.sh to the target.

As always, LinPeas found A LOT of stuff. A few interesting things include a Database password:

The file /var/www/koken/storage/configuration/database.php has some database credentials. I can dump the database to try and see if there’s anything else of use in there, like other user accounts or passwords that could be useful elsewhere.

Unfortunately I could only see Angela’s account details and I already have those. I’ll save the dump anyway.

Linpeas also found some service running called knockd. I don’t know what that is.

I searched Google for ’linux knockd’ and found out that it’s a port knocking daemon, apparently to ‘add an extra layer of security’ which sounds interesting.

Before I do anything else, I realised I still had a crappy shell. So I upgraded to a TTY shell.

If you recall, I found that folder on the server called ‘__hint__’ with some images side by side saying corporate needs to find the difference between them. Well, I think a folder called ‘__hint__’ is a pretty big hint, and the images themselves are a knock knock joke. This makes me wonder whether it has something to do with the knockd service that I found running on the server?

Using the strings tool, I opened up knockknock1.jpg and found nothing.

knockknock2.jpg was more interesting though.

FLAG6: c9db6b7cad326cab2bcf0d2a26f7832d

And a comment saying: Open sesame with 3 numbers. The knock tool needs 3 port numbers.

I tried using knock a few times and nothing happened. I also tried to login as michael to FTP using the password I found and it looks like Michael doesn’t have FTP access.

I checked knockknock3.jpg just in case I got hack-happy and jumped the gun but nothing was there.

I did a bit of research on knockd and turns out I was getting hack-happy. I wrongly assumed that because I had (non-privileged) shell access to the target server, and knockd was running there that I needed to run the knock command on the target, you know, to unlock from the inside.

That was wrong.

I installed knockd on my Kali machine with apt.

$ sudo apt install knockd

And ran knock from Kali.

Running nmap again showed SSH was now open.

I tried to SSH to Michael using the key I discovered earlier in the archive.zip. Unfortunately it needs a passphrase.

I ran Michael’s key through ssh2john and then through john the ripper and found a password.

Now I can ssh into the machine to Michael’s account using the ssh key and Michael’s passphrase.

In Michael’s home directory there’s a copy of his script for Threat Level Midnight, and a hidden file containing another flag.

#FLAG7: 76a2ecd19b04acb89b7fe8c3d83296df

I checked Michael’s bash history and ran sudo -l to see what he can do and looks like he can run a ‘defuse’ command from Creed’s home directory.

I looked around a bit and couldn’t find any defuse\* file. Having the \* wildcard after the filename could mean that defuse could be any type of file. This next bit took me a little while to figure out. There was no defuse file anywhere that I could see, but I do have FTP access to Creed so I can probably upload files. Michael’s sudo permissions allowing him to run ANY defuse file in Creed’s home as root is a little bit over-permissive, so I created a defuse.sh file with the following:

#!/bin/bash
/bin/bash -i

And uploaded it. Trying to run it did nothing because of course the defuse.sh file wasn’t executable. I tried to re-upload it with the execute bit set and still nothing.

After a bit more research and poking around, I discovered the file /etc/vsftpd.conf is writable by everyone. I changed the line CHMOD=NO to YES and had to reboot the server for the changes to take affect. Once that was done, I could FTP back into Creed’s account and chmod +x the defuse.sh file. I did that with FileZilla just because it was easier.

Confirming the script is now executable, I can execute it with sudo from Michael’s account and get a root shell.

#FLAG8: ebadbecff2429a90287e1ed98960e3f6

By my count, I’ve only found 6 of the 8 flags.

I tried using ‘find’ to look for anything I missed and nothing came up. Being root, I can go anywhere, so I jumped into Dwight’s home which I hadn’t looked at yet. There was nothing immediate sitting there, but looking through the various files I found a .mysql_history file with something interesting.

There’s a table in the database called ‘flag’ with a row for Flag5. I dumped the entire database earlier when I was looking for credentials, but admittedly I wasn’t looking for flags.

#FLAG5:d2d1b5f66d0e00b35fe2bdee7ffcb398

One more to go.

After a bit of searching, I realised I’d actually already found the last flag, FLAG3. It was in CreedThoughts.doc, I just disregarded it at the time because I was too busy worrying about breaking in.

#FLAG3: 50f1ff7bc72bb24c0082be83a8b8c497

That’s all 8 flags and root.


See also