Details

Created: 16 March 2015

There is a feature active in the Google Chrome browser that could make Google links unsafe to visit. Below, I will discuss traditional methods for determining safe links, how Google links could bypass these methods, how this could impact users, and what users can do about it.

 

Is a link safe or unsafe?

When you receive an email or see a facebook post with a link, it is always important to check the link to make sure it is safe. The current method people use is to hover the mouse over the link:

 

The reason you need to hover is because a link can be disguised as something else. Only once you've hovered over the link can you determine the true destination of the link. Once you've hovered over the link, you can determine whether the link really is to woodgrovebank.com or not. Further details can be found here.

This problem we are faced in this situation is that most people would consider google.com safe to visit and would therefore click on the link. The next section will describe why you may want to think twice before clicking a google.com link.

How are Google links potentially unsafe?

 

How could this impact me?

 

What can I do to protect myself?

Prerendering is a feature that is active by default in the latest versions of Google Chrome. The purpose of the feature is to speed up browsing by trying to predict what you are going to click on next. Chrome will visit a webpage that it thinks you will click on, even if you never click on it. It does this in a hidden tab so the user never sees that it is happening. If you do click on the link, the hidden tab is immediately swapped in and the page seems to load instantly. However, even if the user doesn't click on the link, the web resources are already fetched and then discarded after a certain time. It is during this fetching process that malicious things could be happening. In order to stop this from happening, you can go to Chrome preferences and uncheck the option for "Predict network actions" under the privacy section.

Details

Created: 10 March 2015

If you are on a Mac or Linux machine and don't want to install software just to burn a large file across multiple DVDs, here's the simplest solution to accomplish this.

 

You can use the following command to split your large file into chunks:

split -b4000m <large file name> <prefix>

This command will split your file into 4G files. Each file will be named <prefix>aa, <prefix>ab, <prefix>ac, etc.

Burn each file to a single DVD. (You can use -b8000m or 8G chunks if you have dual layer DVDs)

 

Load all the files on the destination machine and reconstruct the file from the chunk files.

If the destination machine is Linux or Mac use:

cat <prefix>aa <prefix>ab ... > <original filename>

So if the <prefix you chose was "chunk" and the original filename was "Ubuntu.vmdk", the command would be:

cat chunkaa chunkab chunkac ... > Ubuntu.vmdk

 

If the destination machine is Windows, from cmd prompt use:

type chunkaa chunkab chunkac ... > Ubuntu.vmdk

The "type" command behaves just like the "cat" command in Linux.

Details

Created: 18 November 2013

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/

 

Details

Created: 18 October 2013

Let's say you need to buy a lawn mower. So you open a Google Chrome browser up and do a search for lawn mowers. You might get a page that looks like this:

The problem with this Google search is that without having clicked on anything, Chrome is sending me to homedepot.com automatically. See the pcap capture below: 

This apparently is due to a feature in Chrome called prerendering. Google is making our life better by predicting what link we will click next and visiting the page automatically so that when we click on the link, it will load immediately. The problem is, Chrome will visit the page even if you do not ever click on the link.

I don't know about you, but I don't like the idea that I am visiting web pages that I don't intend on visiting. This "feature" is active by default in Chrome but can be turned off in the Advanced Settings.