Support Challenge — TryHackMe Walkthrough
Pentest the Support Ops platform to exploit vulnerabilities and achieve RCE.
Description: A new internal Support Operations Platform has been deployed to assist IT and helpdesk teams. The application handles user management, internal APIs, and system-level operations. However, security was not the primary focus during development. Several features rely on user-controlled input and weak trust boundaries. Can you pentest the platform and escalate your access to achieve RCE on the server?
What is the flag value after logging in as admin?
What is the content of the file /home/ubuntu/user.txt?
According to the description, it has given that there is a internal support platform which has been deployed to assist IT. Let’s dive deep into the challenge.
Phase 1: Reconnaissance
The first phase is always reconnaissance, we know nothing about the platform, all we have is IP address (Note: Consider change in IP address in your case) of the machine where the internal support operations platform has been deployed. Let’s find out the services and the open ports.
nmap -sC -sV -p- -T4 10.114.152.236
TCP ssh at port 22 is open, TCP http at port 80 is open. Let’s find out and check the http at port 80.
The webpage showing support operational panel is being served by the server at port 80. We cannot see other pages, links apart from the web page alone. Next red team mindset is to find out the hidden directory and files with Gobuster.
Phase 2: Enumeration
Use gobuster in directory mode to see what can we enumerate and hope to find something interesting.
gobuster dir -u "http://10.114.152.236" -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 64 -x .php,.pdf,.xml,.txt,.js
From the enumeration output we can see some interesting hidden files which was surfaced by gobuster. Tried to visit the enumerated list, but couldn’t really find anything.
We can only see the php file which change the color. We could move to next phase. Since, we have the email and password phase, lets try brute force.
Phase 3: Brute Force and Password Rate Limiting
For brute force attack, we have different choices. We could use ffuf or hydra. I am using ffuf.
ffuf -w /usr/share/wordlists/john.lst -X POST -d "email=help@support.thm&password=FUZZ" -H "Content-Type: application/x-www-form-urlencoded" -u http://10.114.152.236 -fc 200
The brute force attack with ffuf was success, we have a password for help@support.thm as snoopy, we can see that in above screenshot. Let’s try the credentials and see the page.
We can see the dashboard with the currently logged in user, there is nothing to see much, just the welcome message and the tab to change the colour which we have identified by navigating to /skins but since the user is authenticated, there must be cookie and session stored in the browser, let’s see that.
Phase 4: Cookie Manipulation
As a pentester, the next step is to check the status of cookie or session. When we check the cookie, we see something juicy, it was showing isITUser cookie.
By looking at the cookie, it seems it is some sort of hash value. We decode the hash with the help of crackstation.
The hash value is md5 hash of the text false, let’s manipulate the cookie by giving the hash value of text true.
After copying the cookie and manipulating it, we see the admin panel.
We can also see the response of API. Let’s try to see if BOLA(Broken Object Level Authentication) is working or not.
Phase 5: BOLA (Broken Object Level Authentication)
Get S4F4L’s stories in your inbox
Join Medium for free to get updates from this writer.
Let’s use burp suite and then see BOLA is working or not. First, we will try up to 10.
We can see the change in length in the burp suite intruder output. We can see the email of admin when we navigate to the /user/1. Now we have email of the admin, since we don’t have the password yet. Let’s try to navigate to other files that we enumerate with gobuster. We will use the query parameter skin, since that is the only parameter we have in the url for now, we go out from one directory outside from skins.
Phase 6: Local File Inclusion
After going one directory outside from skins.
http://10.114.152.236/dashboard.php?skins=../config
When we put the config file in query parameter, we can see the change is UI and something is not normal, let’s see the page source.
Seems like the config file unfold the credentials of the master. The support@110 is the password, let’s try this one.
At first I try the password, but it says invalid credentials.
After countless attempt, I figured out the problem signing in giving us a sign of @, so let’s remove that @ sign from password.
With this, we are able to login as admin. And we see the flag.
Phase 7: Remote Code Execution (RCE)
In this admin dashboard page, there is this dropdown date, which shows the date and time. And it has id sysForm. Seems like it is having the system call and showing the date and time.
Let’s inject the command and see RCE is working or not. First, we will add just ls for testing purpose.
Seems like command injection is working, the output of ls command verifies it.
After reading /home/ubuntu/user.txt, we can see the flag.
Answer one: THM{I_AM_ADMIN999}
Answer two: THM{GOT_THE_FLAG001}
Takeaway
This challenge covers the domain of multiple web application vulnerabilities from not implementing the password limiting to broken object level authentication, how cookie when it is weak can be manipulated and could lead to privilege escalation in web application, how from local file inclusion unfold the internal information and improper sanitisation leads to RFI.
