# Base ## 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 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.

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.

The [man page](https://man7.org/linux/man-pages/man3/strncmp.3.html) 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:

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!

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

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.

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](https://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet). 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.

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:

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.

## 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.

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!

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 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.

As it turns out, `John` can run `sudo` on the `find` command. Consulting the trusty site [GTFOBins](https://gtfobins.github.io/), I could run a search for `find` and select the `sudo` function to discover how to escalate privileges.

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

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.

## 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](https://www.youtube.com/watch?v=idC5SAsKhlE\&list=PLidcsTyj9JXJrgTzRYdwnUhUThb9bL9py\&index=16). 2. 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. 3. 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. 4. 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`. 5. 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.