Disclaimer!!!
The information provided in this blog is to be used for educational purposes only. All of the information in this blog is meant to help the reader to develop a hacker defense attitude in order to prevent the attacks discussed. In no way should you use the information to cause any kind of damage. Hacking is a crime and I am not responsible for the way you use it.
Welcome back to the second part of ZTH room on tryhackme. Today we will learn a little bit about CSRF. As with the previous post, I will just paste here my notes I made during the room and say few words about it.
[Section 2 – CSRF]: What is CSRF
Cross Site Request Forgery (CSRF): attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing.
For instance, let’s say a user clicks a link to a website created by a hacker, on the website would be an html tag such as <img src=“https://vulnerable-website.com/email/change?email=pwned@evil-user.net“> which would change the account email on the vulnerable website to „pwned@evil-user.net“. CSRF works because it’s the victim making the request not the site, so all the site sees is a normal user making a normal request.
This opens the door to the user’s account being fully compromised through the use of a password reset for example.
[Section 2 – CSRF]: Manual exploitation of CSRF
Let’s use the example from TryHackMe.
Let’s pretend that Bob is the victim.
The app looks like the following once Bob authenticates to it:
As you can see, the application has two input fields and a submit button. You specify account that you want to send funds to and the amount. Once you click on ‚Transfer‘ button, the funds are transferred.
So if Bob wants to send 100 to Alice’s account, the request will look like the one below:
If we know this, we can create vulnerable site that can contain malicious link. And every time someone visits it, funds are sent to our account.
Let’s pretend that we (as an attacker) are Alice.
We can put malicious link to <img> tag:
<img src="http://localhost:3000/transfer?to=alice&amount=100">And we host this on our own webserver:
The code of the website looks like the following:
You can see that there is only <img> tag containing our malicious link. So when the image is interacted, the amount of funds is sent to our account that is specified in the link. So we could just send this link to Bob and once he clicks on it, the malicious link is loaded and funds are transferred to our account.
Thank you Bob 😉
[Section 2 – CSRF]: Automatic exploitation
xsrfprobe: advanced CSRF (Cross Site Request Forgery) Audit and Exploitation Toolkit. This tool, written in Python and equipped with a powerful crawling engine, it’s able to detect most cases of CSRF vulnerabilities and their related bypasses.
Basic syntax:
xsrfprobe -u <url>/<endpoint>We can also use –crawl option if we want to crawl the whole <url> and find all the endpoints for us.
Another useful option is –malicious which will create PoC.
All the found vulnerabilities are stored in vulnerabilities.log file:
Warning: Do not use this tool on a live site! It is because this tool is designed to perform all kinds of form submissions automatically which can sabotage the site. Sometimes you may screw up the database and most probably perform a DoS on the site as well.
[Section 2 – CSRF]: Challenge?
If you need CSRF vulnerable machine, look at DVWA.
After you log in, you can find CSRF option on the left menu:
Navigate there and you will see the following form that will allow you to change your password.
Url looks like the following when changing password:
http://10.10.23.152/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change#The interesting part is:
?password_new=password&password_conf=password&Change=Change#This is changing password to whatever we put to password_new and password_conf.
So we can change the password_new and password_conf parameters to our own choosing and send the link to the victim directly:
http://10.10.23.152/vulnerabilities/csrf/?password_new=hacked&password_conf=hacked&Change=Change#But when he sees a link like the one above, he might probably figure out that something bad is going on.
Let’s create our own webpage and hide the link inside it:
This is simple webpage that contains two visible input boxes and one submit button. What is the most important is ‚action‘ attribute in <form> tag. It is containing our malicious link so once the Submit button is submitted, the link in ‚action‘ attribute will be loaded and the password will be changed to our own choosing (hacked in our case).
Let’s host this webpage:
And the webpage looks like the following:
So we send the link of our webpage to the victim. He reads the title and figures out that it’s only about changing his password. So he types his very secure password and clicks ‚Submit‘.
But remember that form action is set to the malicious link that changes his password to ‚hacked‘.
So he is redirected to changing password page. It says ‚Password Changed.‘. Nothing extraordinary.
But when he logs out and tries to log in back with his super secure password, it says that login failed:
Because ‚hacked‘ password is the right one and we are the only one who has access to his account now. His account has been fully compromised.
That’s it for this part. Thank you for reading this and see you at the next blog post!
All credits go to Paradox (https://tryhackme.com/p/Paradox) who has created this excellent room. You can find it at https://tryhackme.com/room/zthobscurewebvulns