To start working on this box, we'll first run an nmap scan against it to see what ports are open and what services are running on them:
We see we have SSH and HTTP available. Let's try navigating to the target IP via the browser:
We see that it tries to resolve to precious.htb, so let's modify our /etc/hosts file:
Now when we try navigating to http://precious.htb, we get the following webpage:
If we enter a webpage, like www.google.com, we get the following:
I then decided to stand up a server on my pwnbox and try to reach that. I stood up the server using python:
python3 -m http.server 1337
And then gave precious.htb the address to my host:
When we open the PDF, we just see a directory listing of the directory I was running the http server from. Not much information there. However, there is useful information if you take a look at the properties of the PDF:
We see that the file was generated by something called pdfkit v.0.8.6. From here, we can pivot over to some research and see if any exploits exist. A convenient trick I learned recently is that if you want to find actual exploit code as opposed to generic reports detailing the severity of the exploit, just append "github" to your google search. For now, I just want to see if this software and version are vulnerable:
Success! We can now pivot from enumerating to attempting to exploit.
Let's look for a PoC for this exploit. Using the search methodology I mentioned previously, I found this exploit on GitHub:
It requires you to be running an HTTP server and a netcat listener on your pwnbox, and has you generate a curl request with some modifications specific to your instances.
When you run the curl command, you will get a connection on your netcat listener:
From here, you should enumerate with your newly gained access and see if there are any interesting files. Make sure you are fully enumerating, meaning also looking at hidden directories and files for potentially useful information.
In doing so, you'll see there is another user on the box named "henry." The user.txt flag file resides in his home directory, but in the context of the user "ruby" you are unable to view it. You will also identify a file in /home/ruby/.bundle called "config." If you cat that, you will gain the credentials to henry's user account.
At this stage, instead of switching users within this limited shell, I highly recommend you open a new terminal and establish an ssh connection to the target box. Full disclosure, I was so absorbed in the way I gained access that I lost sight of the opportunity of pivoting over to an SSH instance, which would've saved me a ton of time, rabbit holes, and frustration.
SSH into the target box using henry's credentials and grab the user.txt flag.
With a new user context may come new privileges, so with that, I give you the following pro tip:
PRO TIP: Run sudo -l whenever you switch to a new user to see what sudo privileges they may have on the target
If you ran this command under the context of the user ruby in the previous steps, you would've observed that ruby had no sudo privileges. However, henry does have some:
A very specific one, but he has one. We can run ruby pointed at that file. This serves as a hint with where to go next. Let's take a look at what that update_dependencies.rb file contains:
Here's the top portion of that file. We can see that it's reading from a file called dependencies.yml. This file is located in /opt/sample/dependencies.yml and contains just a few lines of text. At this stage we have some context for an opportunity. We have sudo privileges to run this file, and it's reading from a yml file in order to execute. Back to google:
Lots of information regarding an opportunity for exploitation here. We've already gained access to the box, so what are we trying to achieve? We want the root flag, so we're looking to perform privilege escalation. Let's better tailor our google search and see if we get more pointed results:
We got some repeat results, and we also got some new ones. After reviewing several, I found one I felt comfortable executing and proceeded with it, and it's linked here:
Make a dependencies.yml in your home directory and paste in it the contents of the code at the link above, making sure to modify the local host and port parameters
Set up a listener on your pwn box matching the parameters you provided in the exploit code
Execute sudo ruby /opt/update_dependencies.yml from your home directory (where you wrote the .yml file)
Check your listener and profit