LaCasaDePapel Writeup

This was a pretty interesting box, and it was the first time I’d played with client certificates. PHP isn’t really my thing, so this was a bit different and I found the client certificates not working very frustrating.

Enumeration

As usual, I started by running Autorecon and waiting for a bit. A quick look at the results showed 80, 443 and 21 were open on the box. Knowing there are some classic vulnerabilities with some FTP servers I had a look at port 21 first.

Okay, so vsftpd is running and it’s version 2.3.4. This version has a backdoor that is often used as an example in training where you connect and send a username that includes :) which then opens a backdoor shell on port 6200.

At this point I have a look at the Nmap results for ports 80 & 443. Port 80 is running a fairly standard website that seems to have some signup for MFA enabled, and port 443 is requesting a client certificate for connections.

Initial Foothold

VSFTP & Psy Shell

I then give the backdoor a try and get the following:

Okay, not the type of shell I was expecting, but that might be too easy. Psy Shell is a PHP debugging shell and allows you to enter PHP code rather than normal shell commands.

The first thing I try is a call out to systems commands by using a backtick, but this fails with PHP Warning: shell exec() has been disabled for security reasons.

At this point I messed around in PHP for a while. PHP isn’t a language I’ve spent a lot of time with, but with some googling I found the file and directory PHP functions which proved handy as I could use them for reading and writing files.

I had a good nose around the system and found I could write to /home/dali/.ssh/authorized_keys which meant I could my public key and login as this account via ssh, excellent. I went through the process for this, logged in and get the same Psy Shell! Doh, rabbit hole :(

I spent a bit more time messing in the file system and following some hints in the forum took a closer look at the PHP shell. I’d noticed earlier that a variable called $tokyo was declared in the shell when I ran ls. After using help I finally managed to dump it:

Client Certificate

Okay, this looks more like it. The function signs a certificate given a CSR and CA certificate and there is a pointer to where the CA key is stored. Lets try and grab it. (I got distracted and spent 15 minutes nosing round the home directories at this point before getting back on track!)

Okay, we can get the key. Obviously this should be secured away, so this could be handy. I also grab the certificate from port 443 on the web server by downloading it from the through the browser as I haven’t come across any other certificate and maybe I can use this as the CA cert.

Using Openssl I generate a signed certificate using the captured key and downloaded certificate:

and then we need to change the format so we can import it in the browser

You don’t need to provide an export password, you can just hit enter. This can now be imported into the browser and we can try to browse to the secure website and see if the certificate will be accepted, which it wasn’t. At this point I spent an hour double-checking my OpenSSL commands, debugging the SSL connection using OpenSSL where I verified that the certificate should work as it was signed by the correct authority, and trying numerous browsers. I then took a break and came back later.

When I came back I noticed that the server had been reset and when I tried to connect to the secure site with the certificate, it worked fine! So, moral of the story, if you’re really sure what you’re doing is correct, a reset may be worth it as someone else may have broken the service.

Web Exploits

Now we’re in the secure area we seem to have some kind of episode download system.

Looking at how the path command is built for browsing the downloads, I try a local file inclusion

Yup, that works. Now I’ve already nosed around a lot using the PHP shell, but we are a different user, berlin, who I could access before. Messing around I get the idea of the directory structure

I then noticed that the links for files contained some base64 encoding which when decoded were the path to the file. Having worked out the location of user.txt using the directory enumeration above I created a base64 string using Cyberchefto try and download user.txt

Escalating Access

Getting a full shell

Now we’re running as the berlin user I wonder if I can grab their ssh private key. I base64 encode the request and manage to download it. I then try to ssh in as berlin on the off chance they logged in locally, nope. From /etc/passwd I remember another user called professor so I tried to ssh in as that user and was in with a proper shell!

With a full shell I run ls and notice amemcached.iniand memcached.js file. Looking at memcached.ini we can see the contents look interesting

Now, it’d be good if we could edit this so we can get it run a command we want but the file is owned by root and we only have read permissions, hmm.

As this script feels like something that may be called from cron, I copy PSpyacross to the box. Ideally we’d like root to be calling this script

Yup, UID 0 is running this, so anything we can put in the file will get run as root.

I create a new file called memcached2.ini with the following contents

and start a local listener with the usual nc -lvp 1234 I then copy this file over the original file with cp memcached2.ini memcached.ini As the file is in a folder my current user owns I can overwrite/delete files in the folder even if I can’t write to them directly. We then wait for the listener to catch the shell