htb-precious

HTB Precious

Info

ip: 10.10.11.189

Path to UID 0 and the flags

1. After a simple scan we can see that port 80 and 22 are open. This is a linux machine. Port 80 is an nginx server with some website.
2. When making requests to port 80 we can see that it redirects them to precious.htb. So we can assume that Nginx is making the use of Virtual Hosts on the backend. So adding the Host: precious.htb header to the requests circunvents this. cat nc-payload-get.txt | nc 10.10.11.189 80
3. It's a website to generate PDFs from website contents. You need to make a POST request for generating this, specifying the URL you want to convert to PDK. You can make a request to generate one with cat nc-payload-post-generatepdf.txt | nc 10.10.11.189 80. It does not generate any content with a public website, but with trying with a random non existent domain name like http://googlsdf worked for me.
4. As the response of the previous POST request we are returned a PDF in the body. We can see in it Generated by pdfkit v0.8.6. After a simple google search we can see that this is a vulnerable version of a library for generating PDFs. Here we have examples of how to exploit it. It allows to do RCE, so I made a simple PoC checking if it works, and it did. You can run it with bash poc.sh.
5. So I used this exploit to make a reverse shell. On one terminal I started a listening with nc -lvnp 9010 and on another I exploited the vulnerability to use Ruby to provide me a reverse shell connecting to it with cat nc-payload-post-exploit.txt | nc 10.10.11.189 80.
6. We get a shell with the user ruby. We can do some investigation on the machine:
   • Interesting users:
     • root
     • henry
     • ruby
   • Interesting services:
     • ssh: allows connecting with user and password
     • nginx: uses virtualhosting as we already know to direct requests to the ruby based website we just exploited
   • Look into the files;
     • Everything seems normal on the system files: /etc/password, /etc/shadow /etc/hosts /etc/groups ...
     • Taking a look to the website and user directories.
       • we cannot see the flag of the user not root
       • Website directory files /var/www/* seem pretty normal
       • When taking a look to the users files there is an interesing one /home/ruby/.bundle/config which contains henry's user password!
7. SSH allowed user and password authentication so we can just open another terminal and do ssh henry@10.10.11.189 and type the pass to get a shell. Then cat user.txt to get the user flag.
8. Now we need to find a way to escalate privileges to root:

• no weird SUID files
• no weird user crons
• no weird ssytemd services
• no docker
• sudo:
  • we don't have sudo access for any command, but when doing a sudo -l to see it it allows to do something it says that it allows to run the file /usr/bin/ruby /opt/update_dependencies.rb. Seems like the way to go up.

8. This file is also readable and allows us to understand that it's used to upgrade ruby gems based on the contents of a dependencies.yml file, without specifying an absolute path. Also, there's the file /opt/sample/dependencies.yml which seems to specify the current versions of pdfkit and yaml. YAML being 0.1.1 which seems vulnerable. So we can craft the file we want and pass it to this script. After google I saw this blog about exploiting this ruby yaml deserialization. And I crafted a file to open a reverse shell. The file is available in this repo as dependencies.yml. Then open another listener shell and run the sudo /usr/bin/ruby /opt/update_dependencies.rb command to get a shell
9. We are root and just run cat /root/root.txt to get the flag.