Hacking Beep (hackthebox)
I started with the usual nmap enumeration of all the ports on the beep box. Lots of open ports were returned, so I had a look to see if any seemed to be a good starting point. My attention was first of all drawn to the obvious services running on ports 22 and 80, but I was also interested in the Simple Mail Transfer Protocol service which was running on port 25. The -sV -A flags in my nmap scan had executed lots of default scripts from the Nmap Scripting Engine and therefore discovered which commands could be used with the SMTP service. The VRFY command stood out as being of some use.
The actual NSE script being run in order to enumerate the SMTP commands available is smtp-commands
I also noticed the domain was revealed as beep.localdomain so I added it to my /etc/hosts file.
It is useful to enumerate commands and authentication methods available on an SMTP service as they can possibly reveal usernames and / or passwords. We can use the NSE script as shown above, or we can use a service such as telnet to initiate a connection to the SMTP service and then use the EHLO command to discover available commands and authentication methods. We can use any string after the EHLO command - in this example I just use world
As mentioned earlier in this post, I was interested in the VRFY command as it can be used to attempt to retrieve valid user accounts. If the EXPN command had been available, I could also have used it to attempt to enumerate user accounts. The VRFY command verifies if a user account is available or not. I used it to look for common user accounts. I could have done this for many more possible accounts, but I stopped once I had verified the existence of the root user account as I assumed I would be able to use it to gain a foothold on the beep box somehow.
The EXPN command expands on user accounts and can be used in a similar way to the VRFY command. It is often the case, however, that the EXPN and VRFY commands have been configured so they do not leak information regarding valid accounts. If this appears to be the case, we can try to use a different way to find them. In this method, we use MAIL FROM:user@domain (this does not have to be a valid account) and then try RCPT TO:potential_user_account_name We should be able to see from the result if the user account is valid or not.
Here is an example of using the same method but with a non-existent account in the MAIL FROM:user@domain part of the attack:
Now that I had a valid user account name, I searched online to see if I could find a default password. I found something relating to the elastix service (I searched for this as I had navigated to the webpage being served and found an elastix login page). The default password I found online did not work with the username root
My next thought was to search for an exploit for the elastix service. searchsploit returned a few results. The Python Remote Code Execution one looked good, so I had a look at it and amended some of its source code to suit my network addresses. Unfortunately, it did not work. I guessed it was something to do with the default extension number and therefore searched for a way to find the correct one. I did find a tool, but I soon ran into problems getting the exploit to run once I had found a new extension number. I therefore decided to go back to the searchsploit results to try a different exploit.
The next exploit I noticed was one which exploited a Local File Inclusion vulnerability. An LFI is an example of a Path Traversal attack (also known as a dot dot slash attack).
A Path Traversal attack lets us move up a file system in order to access files we should not be able to. These can occur when a web application needs to access resources on the file system and uses parameters to find them. The problem occurs if the parameters can be controlled by an attacker and they are not sanitised properly. As an attacker, we can try this type of attack if we suspect the above conditions to be true. I will move away from the beep box for the moment in order to better illustrate what I mean. In the example below, the web application is using the fileurl parameter to retrieve a .php file which specifies a language.
As the parameter can be controlled via the URL bar, I tried an LFI attack. Since I did not know where in the file system I was, I used lots of ../ (hence the name dot dot slash attack!) to get to the top level and then /etc/passwd to attempt to find usernames.
In this particular example, the output rendered in the browser was limited in how many rows it could show as it was in a textarea. I therefore had a look at the response using Burpsuite in order to see all of the users contained in the /etc/passwd file.
Sometimes, the . and / characters are filtered out, so we can try URL encoding to bypass filters. The encoding for . is %2e and the encoding for / is %2f We can try different combinations of these URL encodings (and even the . / characters themselves) to try and bypass filters if we suspect they are being used.
Coming back to the beep box, the proof of concept provided in the LFI exploit was a simple dot dot slash attack which targeted a configuration file.
The one different part of this exploit is the use of the null-byte %00 The null-byte is used to terminate the string. We can use it if we think trailing code is messing up our attack. This could be the case if the source code is something like:
<?php
include($_GET['language'] . "/template.html");
?>
In this case, the concatenated string /template.html would mess up our ../ attack so a null-byte %00 can be used to terminate the string and therefore effectively remove the "/template.html" part of the string.
Once I used the LFI attack, I saw the contents of the amportal.conf file - it contained lots of credentials! I therefore used the find command in the browser to find each password. I made a note of each password, but noticed that one in particular (jEhdIekWmdjE) seemed to be used lots.
Now that I had found some passwords and a possible username, I had a look again at the initial nmap scan to see where I could try them. The most obvious was the SSH service running on port 22. I therefore gave this a go using the credentials root:jEhdIekWmdjE
Due to the age of the beep box, I did run into some problems with the key exchange method and the host key type, but it didn't take long to find workarounds for these problems online. I had a feeling that the credentials wouldn't work, and that I would have to try to find more users. I felt this because if I could get onto the box using the root user, I wouldn't have to do any privilege escalation and in my experience of Hack-the-Box machines this is usually necessary. To my surprise (and joy!) the root:jEhdIekWmdjE credentials worked!
It didn't take long to find the root flag, and not much longer to find the user flag.
Even though the box had been pwnd, I tried another LFI attack to see if I could access the /etc/passwd file. I did this just out of interest to see if I could get it to work. This would have been my next step if the discovered passwords had not worked with the user root I would have then tried the passwords with other user names. When I changed the path to /etc/passwd first of all, I got an error message telling me that I was trying to access a restricted file. I therefore just added more ../ to the path before the /etc/passwd part and found this to work.
One more point to note is that we can use SMTP to attempt to enumerate networks via Non Delivery Notifications received when we send a message using swaks to a non-existent account. The NDN messages can reveal information about the network and the path the message took. This was not necessary for this box, but it is worth bearing in mind. We need to find the mail servers for domains using a command such as dig +short mx targetdomain.com We can then send a message to a non-existent account using the mail server we have discovered. The email account we use needs to allow us to receive NDN messages, and the domain needs to let us send email from different sources i.e. it does not use Sender Policy Framework records. If these conditions are met, we can try a command such as: swaks -n -hr -f attackeraccount@somemail.com -t test@beep.localdomain -s beep.localdomain:25 We can then take a look at the NDN messages which we (hopefully!) receive in order to learn more about the target network.
I enjoyed working on beep, as I learned more about SMTP and LFI attacks.
Thanks to ch4p for creating it, and thank you for reading my write up of (a part) of it.
Post Hack
I came back to this box the following day to see if I could get the Python Remote Code Execution exploit to work. The proper extension was found using the svwar tool from sipvicious - this can be installed with apt install or by using git clone and then running the install.py file.
The extension needed to be changed in the source code, and we need to make sure that the highlighted line of code is included to get around certificate errors.
I now tried to run the exploit again. The previous night, this is where I had run into problems and I had moved to a different way to exploit the machine. It didn't take me long this time to see that it was more than likely just a matter of needing to run it with Python2 instead of Python3. Yes, simple and obvious, but I had been tired and on the vodka the first time I hacked the box so I'm not overly surprised that I wasn't thinking super clearly! Running it with Python2 worked just fine.
To do the privilege escalation, I first of all tried the command sudo -l which lists any commands which can be run by the user as root but without needing to provide a password. Often, this doesn't return anything, but in this case lots of binaries were listed.
nmap stood out to me first of all, as I had used it before to escape a shell. It is an easy method, and is detailed on GTFOBins. We merely need to start nmap in its interactive mode and then issue a command to start a shell. This will open a root shell as nmap is running as root.
A command which had looked interesting when I ran the sudo -l command was chmod This command lets us change the access permissions of files. Briefly, in Linux, we can set a file to read, write and / or execute for its owner, a group and other users. Based on bits, the read bit is 4, the write bit is 2 and the execute bit is 1 This means if I want a binary to be able to be read, written to and executed by its owner, group and other users, I would use chmod 777 (4 + 2 + 1 = 7 The first number is for the owner of the file, the second is for its group and the third is for other users). If I want it to have read, write and execute permissions for its owner and only read permissions for the group and other users, I would use chmod 744 We can, however, set the user id of the file to be the same as the owner by setting the SUID permissions. We can do this with chmod 4000 If we do this, we will see an s where there would normally be an x for execute in the owner part of the file permissions:
Normally, we cannot set SUID permissions on a file owned by root unless we are operating with root privileges ourselves. On this box, we can run chmod as root without needing to use a password. This means that we can set SUID permissions on a binary (such as /bin/bash) which is owned by root, and then any user will be able to execute it with the same privileges as its owner (root!) If this is a little confusing, I hope the picture below helps clarify it all. We need to use sudo when we use the chmod command to set SUID on /bin/bash and we need to remember to use the -p flag (this makes sure the elevated permission is retained during the bash session) when we run bash after setting SUID on it.
On this box, we are able to change the file permissions using chmod as root without needing to specify a password. This is unusual, however, and a more useful way to attempt privilege escalation on a Linux machine is to search for files which are owned by root and already have SUID set on them. We can then either search on GTFOBins for ways to exploit them, or have a look at them using strings to see if we can perhaps use them to abuse a shared object or other binary called by them. These are privilege escalation techniques which are out of the scope of this post, but it is worth keeping in mind that we can find SUID files using the command:
find / -perm -u=s -type f 2>/dev/null
Going back to the nmap scan, I saw that there was an open port at 10000 serving a webpage. I had a look at this and found it to be a login panel for Webmin. I thought I would try the root credentials I had already discovered, but intercepted the request with Burpsuite just in case they did not work and I needed to fuzz them.
The credentials worked, and I gained access to an administrative panel which seemed to give me pretty much complete control of the box. I could have changed passwords or scheduled commands to run. I didn't progress further with this way of exploiting the machine, but I could easily have got bash to run as root as a scheduled task.
I was more interested in the path I had noticed the login request was being posted to /session_login.cgi This made me think of shellshock. Previously, I had exploited the Shocker machine using a metasploit module. This time, I thought I would try to do it manually by amending the User-Agent header in Burpsuite. I used the shellshock malformed User-Agent header of () { :; };sleep 5 The sleep command was just to see if the exploit work - it did! I therefore inserted a reverse shell payload as the command instead and gained a reverse shell via a netcat listener. The shell was root and therefore shellshock was (and is) one more way to exploit the beep box.
