002#:TryHackMe - Whiterose
Back again with another TryHackMe room, this time Whiterose by ngn. I found this room pretty hard but I learned a lot about Server Side Template Injections which was cool. I had some frustration with the server because it would lock up when trying different exploits and I would have to restart the room to get back into it again.
Looking over the details of this room we see we are given some credentials:
Olivia Cortez:olivi8
As for our goals, we need to acquire Tyrell Wellick’s phone number, user.txt, and root.txt. As always, let’s start with an nmap scan.
While that gets going I check out the ip in a browser to see if we are working with a website. A site didn’t load but my browser changed it to cyprusbank.thm. Lets add that to our hosts file and try to reach it again.
Appears that we have an under-maintenance site. I got a gobuster scan running but it didn’t find anything.
I checked the source code for the site while and then reviewed the nmap results. Nmap is just showing port 80 and 22 though so there isn’t much interesting there.
I remembered that I have the credentials for Olivia Cortez so I tried to log in with SSH. No luck though. I decided to run another gobuster scan using a bigger wordlist but still nothing useful. I even downloaded the pictures from the tryhackme page and checked them out because I’ve found hidden clues in them. Not this time though. Lets try fuzzing subdomains with ffuf.
We discovered the admin subdomain! If we try to navigate to http://admin.cyprusbank.thm right now it won’t load, that is because we need to add this to our hosts file first. Once that is done we find we are faced with a login portal. First thing to do is try our credentials for Olivia Cortez and sure enough we are in.
I started looking around the site and also got another gobuster scan going against this new subdomain. The gobuster scan didn’t reveal anything beyond the tabs we could already click around to though. Two things I noticed were that the Settings tab was restricted to us and that there was an Admin Chat portal in the Messages tab. I see three new users here that I added to a users.txt file; Gayle Bev, Greger Ivayla, and Jemmy Laurel.
Since I have these users and a restricted tab I want to access, lets try to brute force the login page with Hydra. I already have the site pulled up in my BurpSuite browser so I logout, turn on intercept, and enter some fake login credentials before hitting Login. This allows me to capture the values we will be using in the brute force attack. We then turn off intercept so we can see the error message that is displayed on the page. Using those two bits of information, we launch our attack.
This failed though, showing that numerous passwords were correct for each user. Looked into this issue and saw suggestions of passing any session cookies along with the brute force. Tried and failed again.
At this point I looped back and started checking the source code of pages Olivia has access to. I noticed in the messages tab that the URL had an IDOR vulnerability. I saw the “?c=5” and just added a 0 to make it “?c=50” which resulted in us viewing a different conversation than before. It also happens that we discover the password for Gayle Bev and a new user DEV TEAM. Added DEV TEAM to our users.txt file and log in as Gayle Bev.
Clicking through the pages as Gayle I noticed we are looking at a list of phone numbers under the Search tab and for our first flag we need to find out “Tyrell Wellick’s phone number”. Entering that name into the search bar gives us our first flag.
Continuing on, we now have access to the Settings tab as Gayle and it allows us to reset a customer’s password. I tried changing the password of one of the other admin accounts and it appeared to work. I also noticed it displayed the password I just set on the screen which was odd.
When I tried to login to the other admin account it failed though. I tried to reset Tyrell’s password and log in but that failed too. Spent some time testing for SQL Injection attacks against the target. At this point I was really stuck. I had gone over all my findings, tested a few more things that failed as well, and decided to get a hint from a walkthrough. I had spent hours at this point across multiple nights without making progress so I took a peak at this great article by SuNnY to see what direction I should be going with this. I got enough info to know I should be manipulating the password parameter of a logon request in Burpsuite and that I should be looking into EJS and SSTI vulnerabilities.
I won’t be going very deep into either EJS or SSTI’s in this article, but I do recommend reading up on it. I found a good article from Geeks for Geeks about EJS and one from PortSwigger about Server Side Template Injection. The essence of what we should understand for this room is EJS allows for dynamic webpages by allowing a variable to be input into code the generates the HTML that comprises the page. Also, this quote from the front page of ejs.co makes it sound like there is the potential for command injection if this is configured incorrectly.
“If you give end-users unfettered access to the EJS render method, you are using EJS in an inherently un-secure way. Please do not report security issues that stem from doing that.
EJS is effectively a JavaScript runtime. Its entire job is to execute JavaScript. If you run the EJS render method without checking the inputs yourself, you are responsible for the results.”
In our case, it appears that the password field of the Settings may be using EJS to show the customer password on screen after we set it. Looking into SSTI (Server Side Template Injection) it looks like our suspicions were correct. The template refers to an HTML template engine which dynamically generates HTML code in response to changing variables. In this room we are abusing a Server Side Template Injection vulnerability in this implementation of EJS.
Now that we have read up on the subject, let’s take a stab at it. I pull up the Settings page in my Burpsuite browser and capture a fake password reset attempt that I send to Repeater. I had seen in SuNnY’s article that he was playing with the password parameter. I just deleted the equals sign between the password parameter and the password string that resulted in an error that mentions the use of EJS. This is how I should have come across this naturally if I was familiar with these attacks beforehand.
I decided to start by googling “ejs vulnerabilities” which landed me on a page from Snyk that listed an RCE vulnerability. That sounds promising so let’s take a look. They show a proof of concept for getting a reverse shell, but lets keep it simple and just start with a whoami. I copied everything after “id=2” and replaced the netcat payload with whoami. Pasted this directly after the password parameter and sent it.
This didn’t give us anything though. I played around with the payload a bit but got nothing. Stuck again so I begin reviewing the data I already have. The hint for question two states “Get your payload right, or you may face unexpected obstacles.”. Back to google it is then. The next article I found was the Github page for Issue 720. The proof of concept here looks similar to what we were trying before so I’m sure I am on the right track. They use it to launch calc but I replaced this with whoami again.
Again, this didn’t run the command though. I hit another wall. I reviewed my findings again and changed my google search from “ejs vulnerabilities” to “ejs server side template injection”. First handful of results weren’t helpful but further down we discover a vesion of the attack we tried earlier, this time in Issue 735. Modified this payload to run whoami and cross my fingers.
Finally, we have gotten remote code execution. We also found out the user is named web. Added that to my users.txt and got a netcat listener started on my machine.
We will want to use this RCE vulnerability to establish a reverse shell, so I replace the whoami in our payload with ‘python3 –h’ to see if python is installed on the target. It looks like it is installed so I attempted to get a reverse shell using a python payload. No luck though.
I checked if netcat was installed and tried that to connect instead. Got another error though. I thought maybe this needed to be URL encoded so I retried but it still failed. The error was different though, instead showing a syntax error for netcat. I tried a URL encoded mkfifo nc reverse shell which worked!
A good tool for generating reverse shell payloads is RevShells.com. It allows you to select the type of shell but also if you want to encode it. Makes the process of testing different shells easy.
Now that we are in, let’s just try to stabilize our shell. You can find a good explanation of this process from this article. Also, I found this article about how mkfifo netcat shells work interesting.
Poking around with our new account and I quickly discovered our second flag in the /home/web directory.
Check what sudo rights our new account has. We see that we can run sudoedit as root under against a specific file. This is interesting so I pull up GTFObins but didn’t see anything for sudoedit. I ran the command to see what happens and it looks like we can edit a file for the server. Once this was open though my connection to the server locked up and I had to completely restart the room to get back in.
I ran the command again and unfortunately it locked up again. It’s a bit frustrating so I left it be for now and checked searchsploit for a sudoedit exploit. It did find some, but we will need to know the version of sudoedit we are attacking. Once I was reconnected to the target I ran sudoedit –V to get the version info.
I wasn’t familiar with the sudoedit command so it was at this point that I realized it was actually a part of sudo (since the version results said it was sudo 1.9.12p1). Now that I know I’m looking at sudo in general and not just sudoedit, I loop back and do another searchsploit query against sudo 1.9. Looks like we have a privilege escalation exploit for our version of sudo. I copied the payload to my pwd, spun up a python http server to transfer the file, and ran it on the target. This failed so I tried tinkering with it a bit but I couldn’t get it to work.
This exploit is unverified but the code does mention the CVE it is abusing so I started looking into CVE-2023-22809. Beginning on NIST’s post about the issue I saw the third link down mentions sudoedit in the URL.
This POC mentions it is a metasploit module so I pulled up metasploit, got my session established again, and attempted the exploit. This failed though so I went back to NIST. Skipping over the the next two articles since they seemed Cisco specific landed me on this article from Openwall.
They show a proof of concept where we can abuse our sudoedit privileges to read files. I used this to read /etc/shadow and tried to crack the root password but I was having issues there. At this point I was frustrated but was inspired by the last post I made where I applied a similar solution. Instead of reading /etc/shadow I used to read /root/root.txt to capture the last flag.
[CATZ….HACKS]