Hack The Box :: Inject :: Walk-through
The HTB Machine "Inject" is rated as an easy machine and for some it is as easy as they come and for beginners, it may seem impossible. This walkthrough will guide beginners through the direct scenario of owning this machine while outlining some additional paths that may have been taken by individuals during their first attempts.
Recommended readings:
It Is Okay To Use Write-Ups!
Starting out with any machine, you should begin by performing an NMAP scan to determine what services are running on that box. So, that's where we will start. You should already be familiar with NMAP at this point and know what switches to use in most cases, so we won't explain the details behind the scan at this time.
Okay, so we got our NMAP scan results. Let's discuss those first. Typically, unless the SSH version is extremely out of date, we typically just ignore this. We don't want to connect to this port and raise any red flags.
Next, we can see that port 8080 is open and identifies as "nagios-nsca Nagios NSCA". If we do a little research we can see that "NSCA is a Linux/Unix daemon allows you to integrate passive alerts and checks from remote machines and applications with Nagios. Useful for processing security alerts, as well as redundant and distributed Nagios setups." This gives us a general idea that this may be a Linux server. In some cases, I have had my scan return http-proxy, telling me that the web port 8080 may be proxied to another service. So, lets make another check to see if this is likely a Linux or Windows machine by performing a ping.
From the ping we can see that the TTL (Time To Live) is 63. Windows machines usually set it to 128, Linux ones to 64. So, we know this is most likely a Linux machine based on the TTL from our ping results.
Now, lets visit the machines website and see what intel we can gather.
If we hover over each of the links in the navigation, we can see the only accessible pages are Home, Blogs, and Upload. If you have any web development experience, then you know this is true because the other URLs direct to "#something-here" which is just a point or anchor in the current page. Clicking them will scroll you down to that anchor point on the current page.
So, lets visit each of the URLs that actually lead to a new page. Let's start with Blogs, for example. Clicking "Blogs" in the navigation takes us to a page displaying 3 Blogs. If we pay attention to these blogs, we have two possible usernames that we should save, "admin" and "Brandon Auger". We should note these for later, and in case it comes down to some brute-forcing, which is usually difficult due to login timeouts and security policies.
Clicking on the blog pages or reviewing the URL, we will notice the blogs don't take us anywhere.
Let's go back to the Home page and then visit "Upload" in the upper right-hand side of the navigation. Oh?! What is this, we have a page where we can upload a file. If we first attempt to upload any type of file, we will notice that we are only allowed to upload images.
At this point you may be tempted to try the following:
- Upload various file types.
- Upload images that have been injected with a reverse shell or PHP code.
- Try LFI attacks (local file inclusion)
- Get pissed off and flip your desk, from all your failed attempts!
Let's have a closer look here. if you attempted the first 3 bullets from above, then you may have noticed that we can inject reverse shells and code into an image and get a successful upload, but nothing ever happens...or you simply get errors.
But, what happens when we try an LFI attack. Shall we see?
Humm, seems we got an error but let's double-check the response using Burp.
Okay, so firing up Burp and using the Proxy while setting our browser to route through Burp's the proxy and viewing the HTTP Historys Raw data we can see that we do actually get back the /etc/passwd file. That's Great!
If we save the /etc/passwd contents to a file and then grep it for "bash" we will notice there are 3 users on this system. Those users are root, frank and phil. So what now?
Let's browse the server using Burp and see what else we can identify. We can't see the /etc/shadow file, so we are going to start taking a look at the users home directories. So, from Burp's Proxy -> HTTP History, right-click on the request made to /etc/passwd and select "Send to Repeater". From the repeater, begin editing the request and looking at the results.
If we pay attention here, we will notice most of these files are common files of a Linux user's home directory, with exception to the .m2 directory. Wonder what we can find in here?
Awesome! We got a username, password and possibly a Private Key. Let's check if we can access that key file, shall we?
Okay, so /home/phil/.ssh don't really exist. No luck there! ..but we do notice the /home/phil/user.txt here that we need as part of this machine's flags.
Let's start looking for the web application files.
Okay okay, so we found the WebApp directory and noticed the pom.xml file. This file seems to have some intel we can use to do some additional research about the web service. What can we find?
We notice the words "spring boot" and "spring cloud" mentioned quiet a few times. Let's look this up. Doing a Google search we can see that "Java Spring Boot is an open-source tool that makes it easier to use Java-based frameworks to create microservices and web apps."
So what can we find if we search for vulnerabilities and exploits related to Sprint Boot or Spring Cloud?
Take a closer look by running "searchsploit -x 46772.rb" from your command line.
If you looked close enough attention to pom.xml then you will notice that this exploit should work against this version of Spring Cloud running on our target machine....version 1.2.0. So let's fire up Metasploit and check out this exploit module.
Load the multi/http/spring_cloud_function_spel_injection module, set your options and run it!
BOOM! We got a shell into the target machine. Now, let's get that user.txt we are after and that we saw in the /home/phil directory.
If upload linpeas.sh to the target and run that, we can hopefully get some more usable intel.
With linpeas.sh running, we should log all the important findings. These will typically appear in RED/YELLOW. First thing we will notice are the CVEs Check, the root and readable by me (we done found this).
Next we want to do a Google search for CVE-2021-3560, this is the first CVE linpeas says the target is vulnerable to. You should find a github for CVE-2021-3560-Polkit-Privilege-Esclation. Git clone that sucker and upload poc.sh to the target using your meterpreter session, then drop to a shell.
chmod +x poc.sh, and run it as seen below.
POW! We got access to phil. Run "cat /home/phil/user.txt and log that flag in the HTB website.
Now, how do we get root? Let's have a look around and see if we can identify any 3rd party software that may be installed by looking at /opt.
Humm, we found an Ansible playbook task title playbook_1.yml under the /opt/automation/tasks directory. What could we do with this?
Copy the contents of playbook_1.yml to your machine and edit it to look like the following. If you are not familiar with Ansible, you can read about the syntax online.
Once the file is uploaded, give it 60-120 seconds to run, and it will disappear. once the file is ran and removed, then continue with the steps below.
Congratulations, you should have now hacked the "inject" machine challenge!
