Intuition HTB Writeup | HacktheBox

Intuition HTB Writeup

Intuition Hack The Box Writeup

Intuition.htb: In this post, Let’s see how to CTF the codify htb and if you have any doubts comment down below 👇🏾

Intuition HTB Writeup | HacktheBox

In Season 5 of Hackthebox, the second machine is another Linux system. I’ll skip images of some routine processes for experienced CTF players.
User I won’t dive into Port Scanning, Directory Enumeration, and Subdomain Enumeration because there’s nothing note worthy in this instance. We discovered:
Port scanning result Cmd For port scanning (nmap -sSVC 10.10.13.15)
Port 22 is open. -Port 80 is open.

Subdomain Enumeration
Cmd For Subdomain Enumeration (gobuster dns -d comprezzor.htb 
-w=/usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt)
comprezzor.htb -report.comprezzor.htb -auth.comprezzor.htb -dashboard.comprezzor.htb
In the report subdomain, we can submit a bug to manager, which is a great way to interact with the website.
Usage HTB Writeup | HacktheBox

Before reporting a bug, we need to register ourselves an account in the auth subdomain. Get one and we will see a form which is suspicous to be a classic XSS.


After some test, I found out there’s an inject point in the title entrance. We can just input a classic XSS image tag payload. And the manager for the website will then read our urgent bug submission.


In a matter of moments, a generous individual takes the time to review our report and graciously offers their own cookie as a token of appreciation for our efforts.


Alright, this scenario seems like a typical activity on Hack The Box. We can utilize the obtained cookie to gain access to the web development dashboard subdomain, assuming the identity of Adam. To proceed effectively, it’s advisable to employ browser plugins such as cookie managers, although I won’t delve into their specifics in this post.

Upon accessing the dashboard, we’re presented with a list of reports tailored to our account, complete with their respective details and priorities. Clicking on a Report ID grants us access to further contents and information.

We observe that Adam has permissions to resolve, delete, and adjust the priority of the report. Priority adjustments can set the priority to 0 for low or 1 for high. It’s noteworthy that only reports marked as high priority will undergo review by the Admin. This revelation marks our next significant step in the exploit process: obtaining the Admin’s cookie through the same technique for further progression.


Submit a bug report as Adam by repearting the XSS injection again. Then we can use the webdav privillege to modify the report priority to 1 in the dashboard. After a few seconds, Admin will review our report and sends back his/her cookie back nicely.


OK, now we have a different cookie as admin. We use it to access the dashboard and we will find out more functionalities to play with.

In this section, we have the capability to generate PDF reports, reminiscent of a previous challenge we’ve encountered. This functionality involves converting a URL into a PDF file using the wkhtmltopdf application.


Hence, there’s a significant possibility for us to execute Server-Side Request Forgery (SSRF) on this functionality. By inputting a URL (in this instance, it must be a local network domain, as Hack The Box machines cannot access the internet), the PDF file will be automatically downloaded. Upon examining the metadata of the PDF, I discovered that it’s generated using wkhtmltopdf version 0.12.6, which indeed is susceptible to the same vulnerability.


However, this turns out to be a dead end. While we can apply the same technique to execute SSRF, we require another vulnerability to circumvent the server’s checks. Consequently, we can carry out the attack without relying on the wkhtmltopdf CVE.
Given that we’re able to input a URL into the form, I opted to test it using our machine’s address to gauge the response from the target. I set up a netcat listener and soon received some unexpected responses:

The response we receive includes an HTTP header, revealing that the User-Agent is identified as python-urllibc/3.11. This version is vulnerable to CVE-2023–24329, as it inadequately handles schemes commencing with ASCII digits, ‘+’, ‘-‘, and ‘.’ characters. Consequently, by appending a blank space ‘ ‘ before the URL, we can effectively bypass the backend check in this scenario. This enables us to easily obtain an SSRF primitive.

Now we can play around with SSRF. We have an LFI vulnerability to read files when we know its path and name. and we will reuse this primitive frequently in the following exploitation.
Based on our observations, it’s evident that this machine utilizes Python at the backend. Therefore, it’s likely that there’s an app.py serving as a Flask server in the webroot folder. To conduct basic enumeration, we can employ file:///proc/self/cmdline as the SSRF payload to inspect the currently running processes on the Linux machine:

To be frank, this is quite straightforward. However, the credentials obtained cannot be used to log in via SFTP. Thus, we must devise a strategy to capitalize on this foothold. We’ll employ the SSRF primitive once more to gain access to the FTP server within the machine, enabling us to extract the desired information.

Cool. Then we can enumerate the private-8297.key, welcome_note.pdf and welcome_note.txt. It turns out the first document is an Openssh Private Key, and the last one reveals its Key Phase:

Futher, we have enough information to leak the user for the private key by using the trick of Key-Rephasing on the rsa key:


Now we have everything prepared to ssh login the machine to take the flag.


Conclusion

According to me this is the easiest box in this open beta season hope you liked it, Please do share with your friends, See you later ❤️

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top