Cordian – Page 9 – Offensive IT

Machine: SickOs1.1
IP: 10.0.2.9
Difficulty: Easy
Goal: Get /root/7d03aaa2bf93d80040f3f22ec6ad9d5a.txt
Link: https://www.vulnhub.com/entry/sickos-11,132/

As usual we start by performing a Nmap-scan to search for any open ports. As figure 1 shows there is no reachable service on port 80 or 443 while at the same time there seems to be a http-squid-proxy on port 3128 which is pretty odd.

As shown in figure 2, browsing the proxy URL won’t give us any new information.

Since the system is offering a http-proxy-service why not use it? So we set up our Firefox to use the http proxy as shown in figure 3 and search for any new information.

Browsing the http service on port 8080, which was marked as state closed in the initial Nmap-scan, still wont work. But when we browse the target on the default http port 80 we see a new page as shown in figure 4.

Unfortunately, the new discovered site does not contain any useful information which is why we use Gobuster to search for other directories on the web server while using the http-proxy.

As figure 5 shows Gobuster is able to find four new directories. Inside the /robots directory we find an entry for /wolfcms and browsing the /connect directory gives us an odd-looking python script which is displayed in figure 6.

6. Strange Python file inside /connect directory

At this point we could try to find any vulnerabilities for the CMS that we have identified. But since it is pretty helpful to have some automated scans running in the background to gather more information, we use Nikto to search for any vulnerabilities that the web server might have.

nikto -host http://10.0.2.7/ -useproxy http://10.0.2.7:3128

And indeed one of the outputs produced by Nikto looks very promising:

+ OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the ‘shellshock’ vulnerability

We use Google to search for a Shellshock exploit and modify it for our case by adding the proxy. Afterwards we verify whether the system is vulnerable to Shellshock by using Curl and indeed the output file includes the content of the passwd file of the target system.

curl -A “() { :; }; echo; /bin/cat /etc/passwd” http://10.0.2.7/cgi-bin/status –proxy http://10.0.2.7:3128 > out.txt

The next step is to get a reverse shell connection as shown in figure 7.

Since this initial connection gives us only the limited privileges for the user www-data we must do some kind of privilege escalation to access the root flag. When we look at the configured cron jobs we a custom entry called automate as shown in figure 8. This cron job runs the connect.py file that have already found earlier (figure 6) as user root. Because the python file already seemed suspicious in the first place, we now take a closer look to it.

9. Validate write-permission on connect.py

As figure 9 shows we actually have write access for that file so we are able to place code for a reverse TCP connection inside the python file. And since the cron job runs the python code as user root we should gain a root shell if everything goes as planned.
We create a local file on our attacking system which contains the python code for a reverse connection and host it on a http server. Afterwards we download the file to the target machine as shown in figure 10 and write its content into the connect.py file.

10. Download python reverse-tcp-shell-code and place it inside connect.py

The last step is to set up a listener and wait for the cron job to run the connect.py file which gives us root access to the system as shown in figure 11.

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.

Author: Cordian

Vulnhub – SickOs 1.1

Hack The Box – Netmon