Base

Linux, Very Easy (08/20/2023)

Introduction

As recommended by the Hack the Box Certified Penetration Testing Specialist (CPTS) path, it is important to supplement readings with practice and proof of concept work. This starting point machine, in addition to others, allow for a beginner/intermediate ethical hacker like myself to learn reoccurring enumeration principles that I will utilize countless times in future engagements. This engagement was guided with questions about specific ports, version numbers of services, and key artifacts that would allow for eventual exploitation of a machine to obtain both user and root flags following privilege escalation.

Enumeration

First I began the engagement by connecting via VPN to the same subnet as the machine, as boxes are not directly connected to the internet. This is accomplished with the secure OpenVPN protocol. I begin with an nmap scan utilizing options for Version enumeration, standard scripts, and the allotted IP address for the Base machine. I did not see a need to use evasive techniques as this box is geared towards beginners and would likely not involve a Web Application Firewall (WAF). In a legitimate engagement I would err on the side of caution from the start just as any capable threat actor would. Below are the nmap scan results:

As we can see, ports 22 SSH TCP and 80 HTTP TCP are open, and

As we can see, ports 22 SSH TCP and 80 HTTP TCP are open, and we have some version information in regards to both services. This Linux web server is running Apache httpd 2.4.29 on Ubuntu, and OpenSSH 7.6p1. These version numbers are relevant to searching for exploits, so I will notate them for later enumeration. Knowing this box has port 80 open, I will attempt to visit it in the Firefox web browser.

I arrive at the Base webpage, and start enumerating by testing items to click on, redirects, and overall displayed information. Out of all the links displayed at the top of the webpage, the Contact page appears most interesting, as it led me to a domain name for IP address resolution. I will add the domain base.htb to my machine's /etc/hosts file before enumerating further.

Email domain is "*@base.htb"

base.htb added to /etc/hosts

The page source did not contain any useful information or accidental usernames/credentials, so I begin to examine the login button in the top right of the page. I tried a few basic and common credential combinations, but to no avail. I then began a GoBuster scan to locate any hidden and useful directories. The results are listed below:

assets appears to be a key item to examine further

There is a slight discrepancy between the URL in the browser versus the directory listed in the GoBuster search. Upon navigation to the /login directory, some files are present and viewable from the browser.

The login button on the homepage takes me to /login/login.php

Accessing /login only without the PHP file brings me to the file directory

Foothold

The config.php file did not contain anything useful, and I have already viewed the login.php file, so clicking on the login.php.swp file initiated a download. I then examined this file further in the terminal. Performing the cat command was not super useful, as the text output was a mess to comb through, so I elected to utilize the strings command to see if anything useful could be examined.

At this point in my studies, I was unclear on how to proceed. Considering Hack the Box's user friendly education platform, a walkthrough was available to consult. My instinct has always been to utilize one as a last resort, as I value my ability to research and critically think to overcome roadblocks. I researched a lot about the output, but as I am still learning web vulnerabilities, the walkthrough pointed me to some peculiarities about the strings output I was looking at.

The output from running strings on the login.php.swp file looks a bit odd, so I used a pipe in order to run the tac command (which is just cat backwards) to reverse it. This made the code sequential and easier to read to determine its function. The walkthrough then made mention of a function called strcmp() as insecure, so I began to research it for any known vulnerabilities. At this point I closed the walkthrough, and began to research the function for possible exploits.

Here we can see the strcmp() function

The man page states, "The strcmp() function compares the two strings s1 and s2. It returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be less than, to match, or be greater than s2." Basically this function was utilized for login procedure comparing strings such as usernames and passwords. The way it is written, a proper combination of username and password compared to the config file would return 0. However, because there are only 2 equal signs (==), this means PHP will only compare the entered strings against the stored credentials. However, modifying the entries into empty arrays ($username[] = "string") will return NULL, which NULL == 0. To modify this request, I now fire up BurpSuite.

Utilizing FoxyProxy and BurpSuite, I intercepted a login attempt and sent the HTTP request to Repeater. The output is as follows:

The unchanged request where "username" and "password" will be exploited

Making changes to the parameter username=admin&password=admin, I was now able to test if this strcmp() vulnerability was valid. I modified the parameter as follows:

username[]=admin&password[]=admin

I got a response code 302 found, and the output from Repeater points toward this exploit being successful. I utilized the login admin:admin, but because I am changing how the strcmp() function assess the input, the empty array addition makes the actual entries negligible (because with the array, NULL == 0). Going back to BurpSuite's Proxy tab, I can now modify the request and forward it on to achieve a successful login.

Forwarding the requests obtains successful login to file upload page

I was greeted with a file upload page, and since the page is running PHP, I attempted the upload of a web shell. Keeping file upload restrictions in mind, I established my web shell payload and uploaded it.

This will allow for different cmdlets to be run in the browser

I received the message "Your file has been uploaded successfully!", and I did not have to circumnavigate file upload restrictions. I had to run GoBuster again with a larger wordlist, however, as the directories I originally obtained did not contain the location uploaded files would reside in.

I immediately noticed the /_uploaded directory! Navigating to that in Firefox, so I navigated to that page. Lo and behold, there was my uploaded shell.php file!

http://base.htb/_uploaded

Utilizing the URL search bar, I added the ?cmd=id parameter to test the web shell's efficacy.

Success

This showed successful interaction, but it is time consuming and not stable. I modified the request in BurpSuite again in order to obtain a more interactive reverse shell.

Initial request before modification

The parameters that will be changed involve the GET request becoming a POST, and the "cmd" parameter being set to a bash one liner reverse shell obtained from pentestmonkey.net. The one liner has to be in single quotes and prefaced by /bin/bash -c in order to tell the remote system to execute the command as a binary.

Almost done with the payload

I was not quite done at this point, however. This payload needed URL encoding because of bad characters like spaces and ampersands. The final payload is below after URL encoding:

URL Encoded Payload

With the following payload, I could now send the modified request with my netcat listener up to obtain a reverse shell. And just like that, I'm in.

I'm in

Privilege Escalation

First taking a look where I was located, I resided in the /_uploaded directory. I decided to move up to the /home/john directory to locate the user.txt flag.

User.txt is MINE

Now that I had the user flag, it was time to start digging through the filesystem in order to escalate privileges and locate any more noteworthy information. Referring back to the files located on the /login page, there was a useful artifact called config.php that I wanted to take more of a look at. After all, I did bypass the strcmp() function with a NULL value, so maybe that file held some useful login information like usernames and passwords!

Is it really a good password though???

Sure enough credentials have been located! Considering this is an admin user, there was definitely potential for escalation of privilege. Recalling open ports from the initial nmap scan, could these have been SSH credentials? It was time to find out.

After trying admin and the discovered password via SSH, I was informed that the password was incorrect. In my haste, I overlooked that there was actually no admin user on the box at all. Deductive reasoning pointed towards the discovered John user as being the system admin. A login attempt with his name and the discovered password proved to be successful.

NOW I'm in

Now the true privilege escalation could begin with this admin user John. First I run a sudo -l command to see if he has any granted privileges.

sudo -l command

As it turns out, John can run sudo on the find command. Consulting the trusty site GTFOBins, I could run a search for find and select the sudo function to discover how to escalate privileges.

GTFOBins Results

By entering the following command into John's SSH session, my privilege escalates to Root immediately.

I am root

Simple as that, the exploit worked and I was able to gain root level privileges! I could truly do anything from this point, but the important part was securing the root.txt flag within the /root directory. Mission accomplished, and all flags are secured for this box.

/root/root.txt

After Action Report

This box was designed to showcase useful skills in web application enumeration, in addition to the power in your hands with the use of BurpSuite. Being able to modify requests on the fly via a web proxy is truly invaluable, and has many use cases in both penetration testing and bug bounty alike. The foothold took some research, as I am still learning web application hacking strategies. I truly appreciate how Hack the Box provides walkthroughs for early machines, as it makes a difference in the learning process when I can obtain bread crumbs to point me in the right direction. Everything I end up looking up, I know I will remember 100 times over as well! Below I listed some remediation strategies for the vulnerabilities I encountered along the way.

1. strcmp()

For this function, everything I discovered pointed towards a solution being that the == needs to be swapped for a === instead. This comparison is more strict an will ensure the username and password strings entered have to be a direct match to those listed in the config.php file. Ippsec has a fantastic video explaining this Type Juggling located here.

1. Upload Restrictions

File upload restrictions may eliminate the ability to upload something like a web shell so easily in the future. Depending on how the site was supposed to function, I suggest a whitelist of file types that are supported so that only necessary types make it to the server. Combining this remediation with the strcmp() one listed above should eliminate that original foothold that allowed for the creation of a shell for the www-data user.

1. Easily Located Credentials

This goes without saying, credentials stored in plaintext are a HORRIBLE IDEA. Always be sure to practice secure methods of data obfuscation through hashing functions, while also implementing strong password policies and rotation. I wholeheartedly believe a month is enough time to rotate, but the average employee may argue the point. Security best practice dictates policies that will reduce the risk and attack surface of an organization.

1. SSH Password Entry

In the SSH config file, it is important to ensure security by turning off password entry for SSH. If credentials are leaked, it won't matter for breached credentials because their unique id_rsa key will be the only allowed item necessary to log in via SSH. This will secure a login better than any password will because the key cannot be bruteforced.

1. Privileged Permission Audit

When granting permissions to an Admin, especially in a Linux environment, it is always important to follow the concept of least privilege. With a free to use website such as GTFOBins, proper measures need to be ensured by the sysadmin to ensure there are no insecure binaries that allow an escape to a root shell. When granting sudo access, be sure that the commands granted are secure, and whether or not the Admin truly requires access to such a binary.