OWASP Top 10 Deeper Dive – A5: Cross-Site Request Forgery (CSRF)

Interested in formal OWASP Top 10 Training? Check out our  OWASP Top 10 Training course OWASP Top 10 Training.

Description: Parsing the OWASP Top Ten with a closer look at Cross-Site Request Forgery (CSRF)

Introduction

Our discussion of OWASP Top 10 Tools and Tactics garnered enough interest to warrant a closer look at each vulnerability as a separate entity with a specific example for deeper analysis. Forgive me in advance for conveying said deeper analysis out of sequence as defined by the Top 10; I'm beginning with #5 as it is part of active research and thus timely for me.

Fifth on the 2010 OWASP Top 10 Web Application Security Risks is:

• A5: Cross-Site Request Forgery (CSRF)
  

  • "A CSRF attack forces a logged-on victim's browser to send a forged HTTP request, including the victim's session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim's browser to generate requests the vulnerable application thinks are legitimate requests from the victim."

As discussed in the parent guide for each of these deeper dives, I suggested tools to help you identify and mitigate these risks within your organization's web applications and services. Tamper Data was described as an ideal tool with which to explore CSRF issues, and you'll soon see why as we dig in.

CSRF explored

The standard caveats apply here: test on systems you own, and first, do no harm.

Obviously CSRF is a prevalent enough flaw to justify fifth on the OWASP Top 10 list; it goes without saying that there are numerous applications that have been susceptible to CSRF. Sadly, you'd be surprised how many remain vulnerable, particularly in situations where the flaw has been noted on applications running as part of firmware on devices. We'll focus on just such a finding in DD-WRT; specifically, CVE-2008-6974. From the DD-WRT website: "DD-WRT is a Linux based alternative OpenSource firmware suitable for a great variety of WLAN routers and embedded systems. The main emphasis lies on providing the easiest possible handling while at the same time supporting a great number of functionalities within the framework of the respective hardware platform used." All true, but the "great number of functionalities", like many a well-intended "feature", present certain opportunities for attackers.

First disclosed December 11, 2008, the DD-WRT CSRF vulnerability overview is as follows:

Multiple cross-site request forgery (CSRF) vulnerabilities in apply.cgi in DD-WRT 24 sp1 and earlier allow remote attackers to hijack the authentication of administrators for requests that

1. execute arbitrary commands via the ping_ip parameter;
   
2. change the administrative credentials via the http_username and http_passwd parameters;
   
3. enable remote administration via the remote_management parameter; or
   
4. configure port forwarding via certain from, to, ip, and pro parameters.

I recently loaded the most bleeding edge version of DD-WRT available for my Linksys WRT160N, a device for which I'd already disclosed a CSRF vulnerability noted in the Linksys-provided firmware. DD-WRT offers a much wider range of features than the default firmware, and I quickly noticed CSRF flaws while poking around, having not yet read the already disclosed bug posts. Unfortunately, unrelated to the DD-WRT upgrade, the Linksys WRT160N quietly bricked one night, much to my chagrin. I wanted to confirm that the latest versions of DD-WRT continued to exhibit the disclosed CSRF vulnerabilities given that DD-WRT project developer would not reply to email requests to discuss the issue. To do so I borrowed a Buffalo AirStation Wireless-G WHR-HP-G54 and loaded the latest recommended firmware:

DD-WRT v24-sp2 (08/07/10) mini (SVN revision 14896)

Note: Should you choose to make use of DD-WRT to replace firmware on a supported wireless router, please exercise all recommended caution regarding hardware versions and the appropriate firmware version. Failing to ensure an exact match can easily render an innocent victim (your router) completely comatose. Also note, regardless of persistence of an unmitigated CSRF vulnerability, DD-WRT is an excellent upgrade for supported devices; don't expose its web management interface to the Internet, and practice due caution to avoid one-click attacks.

Buffalo device at the ready, I opened Firefox, enabled Tamper Data (Tools --> Tamper Data), and browsed to http://192.168.1.1/, the default web administration interface for a new DD-WRT installation.

Figure 1 shows the expected Router Management page.

Figure 1: DD-WRT router management

I selected one of the management page's radio buttons randomly (just checking functionality at this point), clicked Start Tamper in the Tamper Data UI, then clicked Apply Settings on the DD-WRT page.

After clicking the Tamper button when prompted for confirmation via "Tamper with request?" as applicable to http://192.168.1.1/apply.cgi, I was presented with the Tamper Popup as seen in Figure 2.

Figure 2 : DD-WRTtamperPopup

You'll note that I highlighted the above-mentioned remote_management parameter as discussed in CVE-2008-6974. Keep in mind we're discussing a vulnerability disclosed more than two years ago.

Figure 2 indicates a rich feature set with multiple parameters populated via form fields.

The first warning sign that the CSRF vulnerability remains actively exploitable is the fact that there is no reference to a token. If the application required a unique token as part of submittal validation you'd note a Post Parameter Name that might be named CSRFToken along with a Post Parameter Value resembling a randomly generated hash value such as OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTViMGYwMGEwOA==.

Given the absence of the token I made immediate haste in creating a test exploit that included content bound for only a few parameters; those that I assumed were required, and those I wished to manipulate. As seen in Figure 2, the first four parameters include submit_button, action, change_action, and submit_type. I've learned over the years that most exploit attempts will not succeed when submitted to the application without parameters populated for some semblance of submit and action (varies per application, that's why we use Tamper Data for reconnaissance). Additionally, based on the disclosure per CVE-2008-6974, I tweaked remote_management and remote_mgt_telnet just for grins, and saved my payload as HTML as seen in Figure 3.

Figure 3: DD-WRT CSRF payload

When I'm testing payloads, I simply work from my local host and open the saved HTML file in the browser. It will then render the arbitrary message (tagged via H1 in Figure 3) followed by posting the content of my choosing to the parameters defined. Figure 4 shows the results.

Figure 4: DD-WRT remote management manipulated

Compare Figure 4 against Figure 1 and you'll recognize that the exploit worked as intended. What's even more troubling is that it did so with a minimum of defined parameters with content submitted. I've tested other applications where, while still vulnerable to CSRF, you had to submit an entry for ALL parameters (even if blank) in order for the application to accept the submission. For the DD-WRT management script as submitted via apply.cgi this would require that the exploit payload be quite lengthy and complete (see Figure 2). Poor man's mitigation to be certain, but at least it's a bit of validation. But no such requirement exists per DD-WRT, a minimum payload is all that is necessary to manipulate DD-WRT functionality via CSRF.

The only difference between testing my HTML/JavaScript mashup on my local LAN and utilizing it against a remote target is where the exploit script is hosted and the fact that I victimized myself as opposed to someone else via social engineering. Trick a vulnerable application administrator into clicking a URL that points to a specially crafted script that targets their vulnerable application and it's game over.

One added element; you can conduct cross-site scripting attacks via CSRF attacks. Imagine, where you a particularly evil person, instead of flipping simple binary bits (1 vs 0) for a given parameter, you submit JavaScript to embed an IFRAME in a page utilized by multiple users thus subjecting them all to persistent malicious content of your choosing.

CSRF vulnerabilities truly are problematic and useful for nefarious and malicious purposes.

I'm hopeful you now understand why it ranks fifth on OWASP's Top 10.

It's unfortunate that some development teams continue to ignore this vulnerability and write it off as too burdensome to repair or prevent.

Resources

I can't speak highly enough of the OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. It will help you better understand mitigations; pay close attention to the declaration that "developers are encouraged to adopt the Synchronizer Token Pattern. The synchronizer token pattern requires the generating of random "challenge" tokens that are associated with the user's current session."

I'm of the opinion that, at this time, this is generally the most successful CSRF mitigation, allowing for variations on the theme as you consider different platforms and code bases.

Inevitably, you will hear developers complain about the overhead tokens put on their application, particularly firmware developers who have limited memory resources with which to operate.

Summary

I'll argue with almost anyone who claims that their automated scanning mechanism readily and easily identifies CSRF vulnerabilities. There are claims of exceptions to this stance with regard to certain commercial platforms whose development teams are claiming continued improvement and detection, but as I am not a consumer of such products I can neither confirm nor deny. Ask the question as you consider commercial products; how the vendor answers should help you make your decision. No freely available or open source tools "automagically" discovers CSRF vulnerabilities; you have to step through the app as described above and test against locally installed vulnerable applications and devices unless you have explicit permission to test remote applications per an approved penetration testing engagement. As always, let me know if you have questions via russ at holisticinfosec dot org.

Cheers, and good luck.