Irked — Hackthebox Writeup

Jake Flint
5 min readApr 30, 2019

I posted my writeup of the active HTB machine ‘Help’ and was asked to take it down because it was still active… Oops. This time I chose a retired challenge.

Starting off with nmap, I can see that some common ports 22, 80, 111 are open.

nmap -v -sV -A -oN nmap.txt 10.10.10.117

First thing to do is see what’s going on at port 80.

Investigating port 80 in our browser

“IRC is almost working!” implies that there’s some kind of IRC service running somewhere, but nmap didn’t pick anything like that up.
First, I waste too much time with gobuster. I don’t find any files or directories on port 80 except a /manual directory which sends me to the Apache 2.4 docs.

The second nmap scan on all ports

I figure that I should try and find this IRC service, so I scan all TCP ports. If this doesn’t find anything I’ll move on to UDP. However, this comes up with 3 ports that “UnrealIRCd” is listening on.

I’d never heard of UnrealIRCd before, but it turns out that version 3.2.8.1 had a backdoor built in to it from November 2009 until June 2010. Nmap didn’t tell me what version of UnrealIRCd was running, but I give it a go.

Using the metasploit module that takes advantage of UnrealIRCd’s backdoor

Metasploit has a module that takes advantage of the exploit, so all I have to do is set the target IP and port (I choose 6697 first, but any of the 3 UnrealIRCd ports work) and we get a reverse shell as the user ‘ircd’. I feel bad about how easy that was, but that’s just the way backdoored software is I guess.
Searching around, I find that we have access to the other user on the machine ‘djmardov’.
In the user’s ‘Documents’ folder I can see some files. I ignore the linenum.sh scripts because obviously somebody else has used them to enumerate; they aren’t part of the challenge. Apart from those, there’s the user flag ‘user.txt’, but we can’t read the file.

Got our reverse shell, but couldn’t read the user flag yet

While I’m there, I change to the Documents directory and run ‘ls -alh’. The -a flag lists files starting with ‘.’, or hidden files in Linux, and -l and -h just make it look nicer.
I don’t know why I picked up this habit, but this time it pays off. There’s a file called ‘.backup’ there that just ‘ls’ missed earlier.

Finding the hidden file ‘.backup’ in djmardov’s Documents folder

“Super elite steg backup pw” huh? If steganography is involved, I’ve seen literally one media file this challenge, when I visited http://10.10.10.117:80.

This image contains some hidden data

I’ve used steghide before, so I run:
steghide — extract -p UPupDOWNdownLRlrBAbaSSss -sf irked.jpg

Putting your SSH password in image on your web server isn’t smart

First guess is that this is djmardov’s SSH password, we are correct. Now that we’re in, we can get the user flag.

djmardov@irked:~/Documents$ cat user.txt

I submit it and it’s correct, now it’s time to finish the second half of the challenge and root the machine. I like the thinking of whoever was on before, LinEnum.sh is very comprehensive. Unfortunately, the person who was using it before cleaned up after themselves; the files are gone.
I try getting the script directly from the Internet but github won’t resolve, so I copy the files over from my machine.

Getting LinEnum.sh on to the machi

I run the script (with g0tmi1k’s awesome Linux privesc guide open) and scan through it. The kernel version is pretty old and there seem to be a lot of privesc vulnerabilities, so I note that down.
The crontab don’t contain anything interesting to me, and neither do the running processes.

A list of programs that run as root

I note down the SUID files and start throwing searchsploit PoCs at the kernel. Without any blue team experience, I know this is a terrible approach and luckily for me, I’m not rewarded for it. Back to SUID the SUID files!

I investigate ‘exim4’ and can’t find any privesc-related information. I skip through uninteresting/binaries that I can’t run, and find /usr/bin/viewuser.

Finding the most interesting one

The program’s text sounds like the kind of thing we need to exploit. At the bottom, we can see that the program is trying to access a file called /tmp/listusers, which doesn’t exist.
I create an empty file with that name and run ‘viewuser’ and get “Permission denied”. I didn’t make the file executable because I thought ‘viewuser’ only reads from it, but this makes it sound like it executes it.

I make the /tmp/listusers executable and run ‘viewuser’ again and it finishes successfully. Because ‘viewuser’ seems to be running the file (and remember, running it as root), I make it run bash.
I quickly learn that ‘’ quotes are better than “” quotes, need to find out why echo doesn’t like shebangs in “” quotes later... I update the file and run ‘viewuser’ again, and now we’re root.

Privilege escalation complete!

I find the ‘root.txt’ file in the root directory and submit the flag successfully.

Overall I think this was a pretty easy machine, but it taught me a few things:

  1. Be more mindful of reducing my footprint (network traffic and copying files to disk). I definitely need to learn how to do this better.
  2. Maybe it’s best to not continue jumping straight to gobuster or copying exploitdb PoCs over straight away.
  3. The overuse of the phrase “enumerate, enumerate, enumerate.” seems to be justified. I need to better understand machines I’m working on BEFORE acting. This’ll help me improve in the previous two points too.

--

--