This is a whitepaper I started in March 2011 that has taken the back burner. But the main concepts are captured here. I posted it incomplete for documentation purposes.

 

Abstract

 

Without implementing specific defensive measures, websites by default are vulnerable to Cross Site Request Forgery (CSRF) attacks.  The preferred approach for defense against CSRF is to include a random token in a hidden field for all form submissions.  We introduce a method that employs a variation of this defense, allowing a website to seem vulnerable while remaining protected from CSRF.  We reverse engineered the CSRF exploit planning process to understand how to effectively lure an unsuspecting attacker.  In addition, this method provides the ability for IP trace back.  When the attacker tries to exploit the "vulnerability", a planted signature will link the attack to the original IP address from which the exploit was crafted.

 

1 - Introduction

 

Cross-Site Request Forgery is an attack that performs an unwanted action on a vulnerable website on behalf of a victim. It occurs when the victim visits a web page containing the attacker’s exploit code.  CSRF has been a growing threat and, according to OWASP, is considered the 5^th most critical web vulnerability of 2010 [3]. This is partly due to the inherent vulnerability of websites that do not specifically implement CSRF prevention techniques.  Additionally, it is not a difficult vulnerability to exploit and, combined with other attacks, can have devastating consequences.

 

      Much work has been done in defending and detecting attacks as more and more high profile organizations fall victim to CSRF. As awareness increases, detection tools are being created [6] and frameworks are adding CSRF prevention modules [7]. The next logical step is to move from a defensive posture to a more aggressive stance.  In this paper, we introduce a method that allows a website to maintain protection while luring attackers and eventually identifying the originating IP address of the attack.

 

      The recommended approach for preventing CSRF is to use a unique token value in a hidden field of a form that can not be guessed by an attacker [1,4].  We offer a variation of this approach which provides the necessary protection while leaving the website appearing to be vulnerable.  As the attacker crafts the exploit, a signature is planted that will allow us to trace back to them. We will have obtained the IP address, username, and password that were used by the attacker while crafting the exploit.

Contributions

Our major contribution is the introduction of a method containing three major components:

 

1. Bait – Exploring common techniques for discovering CSRF vulnerabilities, we will exploit these techniques in order to mislead an attacker into believing a website is vulnerable when it is not. Since the recommended defense of CSRF is to have a randomized hidden token in all forms, attackers will be looking for forms that do not have this. The randomized token is usually entered in the “value” of a hidden field and is long, randomized and unreadable (ie XEFS12T35DS).  Our method enters the random token in the “name” of a hidden field and avoids the use of long, obviously random tokens.

 

2. Block – Since we expect to be attacked, the website must be properly designed to prevent an attack.  Because we are avoiding long, randomized tokens, we run the risk of the attacker being able to guess it. 

 

3. Backtrace -

 

2 - Background

 

 

 

Cross-Site Request Forgery is an attack that performs an unwanted action on a vulnerable website on behalf of a victim that visited a web page containing the attacker’s exploit code. According OWASP, CSRF is considered the 5^th most critical web vulnerability of 2010 [3].

 

Consider anyone who can trick your users into submitting a request to your website. Any website or other HTML feed that your users access could do this.        Attacker creates forged HTTP requests and tricks a victim into submitting them via image tags, XSS, or numerous other techniques. If the user is authenticated, the attack succeeds.     CSRF takes advantage of web applications that allow attackers to predict all the details of a particular action.

 

Since browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones.

 

Detection of CSRF flaws is fairly easy via penetration testing or code analysis.   Attackers can cause victims to change any data the victim is allowed to change or perform any function the victim is authorized to use       Consider the business value of the affected data or application functions. Imagine not being sure if users intended to take these actions.

 

The following is an example of a form that is vulnerable to CSRF:

 

<form action=”bank.com?transfer” method=”POST”> <input type=”text” name=”account”> <input type=”text” name=”amount”> </form>

Fig 1 - Example of a form vulnerable to CSRF

 

3 - Prevention of CSRF using form keys

Random Nonce

 

<form action=”bank.com?transfer” method=”POST”> <input type=”text” name=”account”> <input type=”text” name=”amount”> <input type=”hidden” name=”key” value=”[xyz]”> </form>

Fig 2 - Example of CSRF prevention using nonce

4 - Lure Method

Detection method - referrer

 

Social engineering

 

5 – Bait and Block

 

Defense - Pseudorandom field name

Lure – obfuscation of field names and input types

 

Defense - Pseudorandom Field Name

 

Pseudo random name

How to generate this

For simplicity in explaining the method, we will only be randomizing the name field. Ideally the value field would be pseudorandom as well (see Security Details section).

 

Lets choose name = “ext_irs_lan” for this particular example

 

Defend using a variation on form key implementation

Include form key

 

<form action=”bank.com?transfer” method=”POST”> <input type=”text” name=”account”> <input type=”text” name=”amount”> <input type=”hidden” name=”ext_irs_lan” value=”1”> </form>

Fig 3 – pseudorandom field name

 

Bait – Obfuscation of field names and input types

 

Lure Obfuscation Step 1 – alter names to have similar syntax as pseudorandom names

 

<form action=”bank.com?transfer” method=”POST”> <input type=”text” name=”acct_num”> <input type=”text” name=”trf_amt”> <input type=”hidden” name=”ext_irs_lan” value=”1”> </form>

Fig 4 – obfuscate names to match pseudorandom name  syntax

 

Lure Obfuscation Step 2 – add distraction input fields

 

<form action=”bank.com?transfer” method=”POST”> <input type=”text” name=”acc_num”> <input type=”text” name=”trf_amt”> <input type=”hidden” name=”pdf_or_txt” value=”txt”> <input type=”hidden” name=”xfer_ref_on” value=”on”> <input type=”hidden” name=”ext_irs_lan” value=”1”> <input type=”hidden” name=”amt_dis_pdf” value=”0”> </form>

Fig 5 – obfuscate pseudorandom name

 

 

<iframe width=”0” height=”0”> <form action=”bank.com?transfer” method=”POST”> <input type=”text” name=”acc_num”> <input type=”text” name=”trf_amt”> <input type=”hidden” name=”pdf_or_txt” value=”txt”> <input type=”hidden” name=”xfer_ref_on” value=”on”> <input type=”hidden” name=”ext_irs_lan” value=”1”> <input type=”hidden” name=”amt_dis_pdf” value=”0”> </form> <script> document.forms[0].submit(); </script> </iframe>

Fig 5 – Example of attacker exploit code

 

6 - Traceback

 

Field Name	IP Address
ext_irs_lan	1.1.1.1
qrc_ext_rest	2.2.2.2
	3.3.3.3
….	….

Table 1 - Example of field name and IP database

 

 

7 – Protection Details

Protects against login CSRF [5]

Name Field, Value Field, index, IP, first_seen, last_update

8 - Conclusion

 

References

 

[1] William Zeller and Edward W. Felten. Cross-Site Request Forgeries: Exploitation and Prevention. Technical report, Princeton University, 2008.

[2] Johannes Ullrich, Ph.D. Software Security Awareness. Training course, SANS AppSec Summit, 2011.

[3] OWASP Top 10 Application Security Risks, 2010. http://www.owasp.org/index.php/Top_10_2010-Main

[4] 2010-A5-Cross-Site Request Forgery, 2010. http://www.owasp.org/index.php/Top_10_2010-A5

[5] Adam Barth, Collin Jackson, John C. Mitchell. Robust Defenses for Cross-Site Request Forgery, CCS’08, 2008.

[6] Testing for CSRF (OWASP-SM-005), 2010.  http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005)

[7] Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet, 2010.  http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

[8] Michael Brooks.  CSRF Bouncing, Defcon 16 presentation, August 2008.

http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-brooks2.pdf

[9] Paul Asadoorian, CSRF Testing with Pinata

http://www.youtube.com/watch?v=EmmNn1FRYm4&feature=player_embedded#at=18

[10] piñata-csrf-tool, 2010. http://code.google.com/p/pinata-csrf-tool/

 

• < Prev
• Next >