The Practicality and Danger of Cross-Site Request Forgery (CSRF) attacks

I usually encounter a discussion with software development teams regarding a Medium risk defect finding – Cross-Site Request Forgery (CSRF). A medium-risk would mean persistent attempts may lead to a compromise. The prerequisite for launching a CSRF is quite complicated. I am always bombarded with so many questions and disputes on why we flag this defect.

The Danger

In a nutshell, CSRF is an attack that leverages trust. Burp Suite (Portswigger) explains it in detail. Imagine a phishing email enticing to click on a link that will redirect you to a website you supposedly wanted to visit. But upon clicking, the link triggers a transaction from a website where you have an active session with values on all parameters preset. Without you knowing and without any credentials stolen, a transaction is successfully executed.

An example simulation is shown below using a DVWA (Damn Vulnerable Web Application) and Burp Suite (proxy tool).

In this scenario, the attacker’s target is to be able to change the password of the account in DVWA by setting values on the parameters on the change password function. The victim does not have to go to that specific page. He/she only needs to have an active session when the phishing link is clicked.

When we said the request to the proxy, a GET request to the server looks like this:

The highlighted portion contains the parameters such as the password_new (New Password) and password_conf (Confirm New Password), and Change (Change Password Action). Assuming that the attacker has an idea on this specific request, he can create a prefilled transaction that he will use in his phishing email.

Burp Suite Pro has a Generate CSRF POC feature that will create the transaction:

You can then put the values in the parameters of the change password function. In this simulation, we changed the password to ‘test.’ The parameters and values are highlighted below:

You can test the Generated POC in the web browser. It will be loaded in the browser, similar to a link that you will include in a phishing email.

When you click the button and send it to the proxy tool, you will see the CSRF POC that we created, and the server with a legitimate request will accept it.

The application will tell you that the password has changed.

When validated during a new session (logout then login), the new credentials are accepted.

That’s how the usual CSRF attack will look like. What are the issues then, and why are there discussions on CSRF attacks’ relevance with the development teams?

The Practicality

In the simulation shown in the first part, there are a lot of assumptions.

  1. The assumption that the user has an active session

We are assuming that the user is currently using the session that we are targeting to exploit. Even if the user clicks the link, but the session is not active, the attack will not be successful.

  1. The assumption that the user will fall for the phishing email and click the link

We are also assuming that we can lure the user into clicking the link.

  1. The assumption that 1 and 2 are happening at the same time. This is self-explanatory. They need to co-exist so that the attack will be successful.

The developers, project managers, or even application owners’ argument is the practicality of the CSRF. As mentioned in the introduction, this attack leverages trust, and there is no single successful formula in exploiting the user’s trust. So with a valid argument from the developers, why are we still flagging it as a defect?

The Judgment 

The rating that is given for each defect depends on its severity. Even if there are so many assumptions and prerequisites before successfully launching the attack, the application is still at risk with CSRF. The probability that it will always happen is still there. On the side of security, we know that it is easy to launch an attack; therefore, we say it is medium. It means that persistent attempts may lead to compromise.

Furthermore, security best practices will tell you that CSRF can be mitigated through the code-level layered defense. One of the best mitigations is deploying an Anti-CSRF token generated by the server that the application will use for validation when a transaction is executed. Burp Suite (Portswigger) has a good article about CSRF Tokens.

Here is a code snippet from a remediated change password function in DVWA. It will show you that there is a token validation to the server to check if the user intentionally made the request. At the end of the code, you will see that a generate token function is called to be used for the next transaction.

Conclusion

CSRF attacks are prevalent in applications, and at the same, it is not easy to exploit. However, the security tester’s role is to exhaust all possible ways of controlling the application and checking if there are ways to improve its security. Thorough CSRF checks are done in the admin panel, where a lot of CRUD actions are done with an escalated privilege (such as admin or super admin). Once the defect is exploited, it is imperative that remediation activities be done in the soonest possible time.

Bypassing SSL Pinning and Traffic Redirection to Burp Suite using MobSF and Genymotion

In the usual web application security testing, testers take advantage of proxy tools such as Burp Suite or OWASP Zap to tamper with the parameter of HTTP requests to the server and observe the traffic. There are also built-in scanning tools and add-on/plugins that can be integrated for more specific tests. For a web application that uses certificates, the resolution is to add Burp’s certificate to the trusted certificates so the traffic can still pass through the proxy.

However, when doing security tests in mobile apps, this can be a problem. A lot of mobile apps that use certificates implement SSL pinning, thus, it will not connect to the proxy as it doesn’t recognize it as a legitimate connection. Installing Burp’s certificate in the browser will not do any good as the mobile app does not pass through the mobile browser. There are different approaches to resolving this issue. One is to root the OS and install Burp’s certificate in the System Certificate list. By default, Burp’s certificate can only be installed in the User Certificate list if the OS is not rooted. The other approach is to disassemble the .apk file (assuming Android) using apktool and Frida, then disabling the SSL pinning there or referring to Burp’s Certificate as valid.

Depending on the setup, approach 1 or 2 may work. But the steps and tools may be complex as you need to disassemble and assemble the code back again. There are times when you need to do trial and error just to find out which approach or tweaks will work.

MobSF Dynamic Analysis

One of the tools I found is the Mobile Security Framework. It is a security tool that contains both static and dynamic analysis for Android, iOS, and Windows. What I like about the tool is that it automates the disassembling part and analysis of the Manifest and other parts of the code. It also has a risk scoring based on OWASP Mobile Top 10 and CVSS.

One of the more important features is the dynamic analysis. It can execute the uploaded APK to an emulator and execute runtime tests. Note that for dynamic analysis to work, MobSF must be installed in the host and not in a Guest/VM.

Bypassing SSL Pinning

Bypassing SSL Pinning is easy once you have set up the Dynamic Analysis feature of MobSF. Frida is already built-in and you can see the logs. In the example, we uploaded Wikipedia’s APK for static and dynamic analysis. When you start to. There are default settings such as API Monitoring, SSL Pinning Bypass, Root Detection Bypass, and Debugger Bypass.

Go to Frida Live Logs to see the status of the functions implemented. Browse through the mobile app in Genymotion and see the updates in the Frida Live Logs. It will also indicate if SSL Pinning has been bypassed.

Sending the HTTP/S Requests to Burp Suite

After bypassing SSL Pinning, we can now redirect the traffic to a proxy such as Burp Suite. You can go to Generate Report and go to HTTP(S) traffic to verify whether requests and responses are recorded. Once verified, you can go to Start HTTPTools to send the repeat the request to a proxy.

From there you can send the captured traffic to the Fuzzer by setting the IP and port used by the proxy (usually localhost:8080). Just make sure that you have the same set up in the proxy and toggle the Intercept button to “off” and you’re good to go.

Conclusion

These key features of MobSF will help security testers in analyzing the traffic of mobile applications. The tedious task of manually disassembling and assembling the app is resolved and more time can now be allocated to testing the logic and flow of the application.