CSRF attack: How hackers use trusted users for their exploits

Simple CSRF attack

It’s common knowledge that images make webpages, email footers and other similar elements more presentable and attractive. But a simple image containing a malicious link can be a serious threat. For example, consider an image embedded within a webpage. This image could be crafted to link to a URL as follows:

<img src=http://bankwebsite/accounts?amount=abc&FromAccNum=pqr&ToAccNum=xyz>

If a user innocently clicks on that image in an authenticated environment (say, the user has logged in to his e-banking session), he would be firing a GET request in the background to the bank site, which would sense nothing amiss and complete the request.

Preventing a CSRF attack has been a major concern since its discovery in 2001. CSRF attacks were at a peak around 2006-2007 and security researchers have established several techniques to mitigate this menace. A common one is to check the referrer in the http header, which will tell the new webpage where the request has originated. In the above example, when the victim clicks the image that redirects him to the bank site, the referrer tells the bank site that the request originated from the webpage on which the image has been embedded.

Most of the time, a CSRF attack occurs if the Web application has no authorization checks for actions that are vulnerable, and also if it is based solely on automated submission of requests. For example, cookie-based logins; the ‘remember me’ browser feature; and, a Kerberos token if part of an intranet.

Advanced CSRF attacks

For a CSRF attack, attackers have found different methods to bypass mitigating techniques. According to OWASP, bypassing referrer checks can be done in two ways. The first is via the CRLF (carriage return line feed) vulnerability that could allow the http client to spoof the headers and the referrer. The second method is by using XSS (cross site scripting), that allows the attacker to make requests using forms (POST method based). This is also known as the HTTP parameter pollution technique that results in a CSRF attack.

Many Web applications have forms similar to those that allow users to update their primary email ids. For a CSRF attack, if an attacker can get the victim to update the primary email to that of the attacker’s, then the password could be reset by the attacker in order to gain access to the account. Here’s how this could be done:

<form method=”POST”>

<input type=”text” name=”email” value=””/>

<input type=”hidden” name=”csrf-token” value=”xxxxxx”/>

</form>

Suppose this form is available at http://website/updateEmail.jsp, we note that since the action attribute is missing in the form tag, the form will be submitted to the URL in the address bar itself.

Suppose updateEmail.jsp has the code that checks if the request contains a valid CSRF token. If true then the form is updated, else the form is displayed to the user. A CSRF token sent by the attacker to the victim uses various vulnerabilities such as a session fixation vulnerability. This allows the attacker to set a victim’s session identifier and manipulate data.

For a CSRF attack, a commonly used exploit of this kind is done by clickjacking (UI redressing). Using this technique, the attacker includes an iframe tag as:

<iframe src=http://website/[email protected]></iframe>

When this form is submitted using clickjacking, the CSRF token remains valid, and at the backend in the updateEmail.jsp, the request.parameter(“email”).isSet() function finds email in the POST body as empty and email in the query string as [email protected]. Since the form has the action attribute missing, the value for the email attribute will be set to [email protected] from the current URL in the address bar.

XSS vulnerability can facilitate iframe injections such as the above and also simple CSRF attacks where the URL is hidden in the XSSed attribute and redirected to perform the request forgery. Any XSS vulnerability in any part of the system can potentially pose a CSRF attack threat to the entire system.

CSRF attack to change DSL router configuration

Another form of CSRF attack is to change the victim’s DSL routers. Most of the routers around the world are configured with the default username and password. A simple img tag in the html can achieve the needed action:

<img src=http://admin:admin@ipaddress/>

<img src=”http:// ipaddress/changeDNS?newDNS=ipaddress”/>

Once the DNS is changed, the user can never access the site securely again.

To sum up

We can conclude from the above discussion that a CSRF attack combined with XSS can be lethal. A Web application should not rely solely on credentials that are automatically submitted, but a custom token that the browser will not remember should be provided. Combining this with a POST request instead of a GET request is a better option for security.

Patching an application from XSS (persistent or non persistent) reduces the risk drastically. Another strategy that can be used is transaction signing or re-authentication.

References:

1. OWASP testing guide v3.
2. Secunia Web advisories on CRLF in http clients.
3. Attack and defense labs repository for scenarios.
4. Talk by Jeremiah Grossman at the Black Hat conference: “Hacking intranet sites from outside.”

About the author: Karthik Ranganath is a member of the Indian open security community NULL community (www.null.co.in). He holds the EC-Council Certified Ethical Hacker certification, and is at present pursuing his final year of B.Tech in Information Technology, from National Institute of Technology, Surathkal.

Ranganath has published advisories on Web application security in International portals. He blogs at http://epsilonlambda.wordpress.com, and can be contacted at [email protected].

You can subscribe to our twitter feed at @SearchSecIN