htb – Offensive IT

As usual we start with a Nmap scan to find open ports on the target system. As we can see in figure 1 we only detect port 22 for SSH and 80 for HTTP with a quick scan.

When we visit the website it says something about DOS-Protection by IP banning as shown in figure 2.

Since we do not want to get our IP banned at the first few minutes by starting any enumeration scan we take it slow. A nice way to gather some useful information is by searching for a sitemap or robots.txt.

The robots.txt contains a new directory called /writeup. By browsing the directory we see multiple blog entries, all writeups on Hack the Box challenges as shown in figure 4.

On the /writeup directory we see just 4 interactive links which lead to writeups on different hack the box machines. There is nothing interactive beside one parameter inside the URL which is ?page. We quickly try some local file inclusions and other things but nothing seems to work. By taking a look on the source code of the page we see a hint that the open source content management system CMS Made Simple is being used as shown in figure 5.

5. Checking source code to gather information about CMS

Searching on Google for “CMS Made Simple exploit” we find a blog entry on packetstormsecurity.com about a SQL injection vulnerability. We copy the exploit and run it and are able to pull the hashed password and username off the system as shown in figure 6.

python cmsSQLi.py -u http://10.10.10.138/writeup

The script offers to decrypt the hashed and slated password. But since running decryption on a single kernel inside a VM is not that efficient
we switch to a proper machine and use Hashcat. When we take a look inside the source code of the SQL-injection exploit script to see how the hashing algorithm works.

Inside the script we find a function for cracking the salted hashes by calculating a MD5 sum for the salt and password strings.
When we take a quick look on the example hashes for Hashcat and search for MD5 we see that the exact same mode is already implemented as hash-mode 20.

So we start Hashcat with the salted password and the rockyou.txt dictionary and get the password as shown in figure 8.

One important thing to know is that even if the hashed password is being hashed by the format salt:password we have to store the hash and salt in the format hash:salt for Hashcat being able to process the data.
Now we can use SSH to connect to the system and are able to access the user flag.

The next goal is to escalate our privileges. But since kernel is up to date, no cronjobs seem to be misconfigured or any other easy to guess things seem to be leaking information we enumerate further and find a note on /etc that informs us about a known security issue where users have more permission on files and directories as the should have.

So we check what privileges we have and search for all writeable directories to see if anything is unusual. We see that we are a member of the group staff which allows us to write inside /usr/local/bin which is part of the PATH variable.

11. Group membership and writeable directory

12. Directory /bin is affected by security flaw

One way on how to exploit this misconfiguration is by executing a PATH injection attack by finding any process that calls a file from a relative path and by replacing the intended file with a malicious file with the same name and put it inside a directory which is part of the PATH environment.
But to find such a process that uses a file with a relative path can be tricky.
One way of doing so us by using PSPY to monitor all processes executed by root.
Using PSPY we see that every time the SSHD process handles a new established connection a process calls for a file called 10-uname.
When we take a look inside that file we see that it is a bash script running uname -rnsom as shown in figure 13.

When we login to the system via SSH as we did earlier on figure 9, we can see that the output of that command gets printed as the message of the day / welcome message for the SSH connection.
Since we are able to override everything inside the /usr/local/bin we could potentially replace the uname binary with a malicious one which would get executed every time a successful connection via SSH gets established.
So we create a simple bash script that prints the root flag and call it uname.

14. Malicious uname file

Afterwards we place the file inside the /usr/local/bin directory. Afterwards we try to login to the system via SSH and as figure 15 shows the script gets executed and we obtained the root flag.

15. Root flag gets used as message of the day

So instead of only printing the root flag we could also replace the uname binary with a reverse TCP shell to get root access to the system as shown in figure 16.

16. Access to target system with root privileges

First off we use Nmap to scan for open ports on the target system. Figure 1 shows all open ports including the results of a version scan with Nmap (-sv). As we can see the target machine offers a ftp service with anonymous login being enabled.

2. Already got the user-flag

Due to the anonymous login we can logon to the system by using ftp with the username anonymous and an empty password. After the authentication we are able to see multiple directories as shown in figure 1. Inside the Users directory we find the home for user Public. Inside /Users/Public find the user.txt flag which we download via get user.txt onto our local system, which gives us access to the first flag as shown in figure 2. The next step is to take a look at the HTTP server on port 80 that we saw in figure 1. When we browse the website we see a login mask for an application called PRTG Network Monitor.

3. Login Interface on http://10.10.10.152/

Now we start to do a little bit of research on Google to find any useful information about the application. Things that we might want to look up are default credentials and known vulnerabilities for PRTG.

Finding the default credentials for PRTG on the web is pretty easy but wont grant us any access to the application. Furthermore there are two interesting vulnerabilities that can be found online. The first one is about a credential leak where the application might store the password of any user that runs the application database in backup files of the configuration (LINK). The second vulnerability is a command injection that allows an authenticated user to execute local commands on the underlying system (LINK). Furthermore if the application is vulnerable to the command injection vulnerability we might gain system access with the highest privileges right away. This is due to the fact that if PRTG is being installed with the default configuration the vulnerable service runs as local system (LINK).

4. FTP – Searching for backups of configuration files

5. Password stored in old configuration file

The first thing that we want to do is to check if we are able to get access to the application by finding any stored passwords in backups of the configuration file. To do so we use ftp with an anonymous login once again and browse the directory that we found in the article that described the vulnerability (LINK) and indeed we find a backup of an old configuration file called “PRTG Configuration.old.bak”. We download the backup file to our machine and search for any stored passwords. As figure 5 shows the backup file contains a cleartext password for the user prtgadmin which is the default administrative user for the application. But when we try to use the username and password on the website we fail to login. Since the password is from the year 2018 we do what users usually do and increase the number that is being used in the password. So when we use prtgadmin as username and PrTg@dmin2019 as password we are able to successfully login to the application.

The next step is to find out whether the command injection vulnerability is working on the target machine. After reading through the article that describes the vulnerability (LINK) we create a notification called add_user_off that executes a ping request to our attacking machine as shown in figure 6.

6. Test command injection vulnerability by using ping

7. Recieving ICMP echo requests from target system

After running the notification the command gets executed and we receive icmp echo requests from the target system as shown in figure 7.

8. Create new local user on target system

At this point we have verified that the target system is vulnerable to the command injection but we still have to find a way to exploit it in a way that gives us access to the machine itself. One thing that the author of the original article that described the vulnerability did was to create a new local user. So we might do that as well and create a new user called oit with the password OffensiveIT! as shown in figure 8. One thing that was already mentioned is that by default the vulnerable service of the PRTG application runs as local system which means that if this is the case in this scenario we can switch our new user to the administrators group. We test this right away by creating a new notification with the name changetoadm which executes the command as shown in figure 9.

If everything worked as intended we should be able to execute commands on the target system by using Psexec. One way to do so is by using the corresponding module in Metasploit as shown in figure 10.

But using Metasploit only for Psexec is a bit like bringing an assault rifle to a knife fight. So another way of doing it is by using the psexec.py module from Impacket as shown in figure 11.

Tag: htb

Hack The Box – Writeup

Hack The Box – Netmon