Neal Poole

Summary

Certain sections of the Google Support Forums (hosted on google.com) were vulnerable to a persistent XSS attack. An attacker could submit posts containing JavaScript URIs in specific locations, triggering the execution of arbitrary JavaScript.

How did it work?

A few of Google’s support forums (for instance, Webmaster Central) allow users to embed external content in their posts. This content includes links to external websites, search results, YouTube videos, etc. When the post is actually submitted to the server, the URL to the content is included in one of the POSTed fields, called wpiprsi (one example looked like 1%26asdf%26%26%26asdf%26http%253Awww.google.com%26%26%26%26%26%26%26%26%26%26%26%26%26%26%26%26). By manipulating the URL that was submitted, it was possible to execute JavaScript.

The simplest example involved links to websites. By modifying the URL in the example above, changing it from http://www.google.com to javascript:alert('works'), it was possible to create a link that would execute JavaScript when clicked. Of course, an XSS vulnerability that requires user interaction like that is less than ideal.

The clickable XSS vulnerability in action.

The other, more useful attack I found involved the ability to embed videos. All I needed to do was send a request with the URL for a video swapped out with a JavaScript URI. The malicious URI was put into the src attribute of an embed tag, which allowed it to be executed for anyone who viewed the page.

JavaScript alerts could also be executed on page load in certain browsers

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills.

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.

Summary

Jaiku was vulnerable to a persistent XSS vulnerability. It would detect and linkify URLs using certain protocol handlers (ie: javascript, data) that could take malicious actions on behalf of an attacker.

How did it work?

The commit that patched the vulnerability can be seen at http://code.google.com/p/jaikuengine/source/detail?r=157.

Jaiku used an overly broad regular expression in an attempt to detect URLs to turn into links. That regular expression allowed people to create links using a number of protocols, including javascript: and data:, which can be used by an attacker to take malicious actions.

The malicious comments, with their evil URLs

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills.

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.

Summary

Aardvark contained several reflected, DOM based XSS vulnerabilities. Due to CSRF protections, exploiting these vulnerabilities remotely was non-trivial.

How did it work?

1. “Topics” profile page

When adding a new topic to your profie via the Topics page, the text of the new topic was parsed as HTML, which caused any JavaScript contained in the text to be executed.

I tracked down the relevant function (add_interest_to_interface) in the JavaScript and ran it through a pretty-printer. Here’s what it looked like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

var add_interest_to_interface = function (user_term) {
    user_term = $.trim(user_term);
    if (user_term.match(/any (.*) question/)) {
        user_term = user_term.replace(/any (.*) question/, "$1");
    }
    if (interest_is_active(user_term)) {
        return false;
    };
    user_interests[user_interests.length] = user_term.toLowerCase();
    tmpl = '<li class="interest" style="display:none">' +
    '<form class="delete_interest" title="Remove this topic" method="post" action="/interests/destroy_by_user_term">' +
    '<input type="image" src="/images/blank.png"/>' +
    '<input type="hidden" value="#{escaped_user_term}" name="user_term"/>' +
    '</form>' +
    '<span class="user_term">' +
    '#{user_term}' +
    '</span>' +
    '</li>'
    $('#user_interests').append($.tmpl(tmpl, {
        'user_term': user_term,
        'escaped_user_term': $.escapeHTML(user_term)
    }, {
        escape: false
    }));
    $('#user_interests li:last').fadeIn();
    $('.topic-menu').each(function () {
        add_styles($(this));
    });
    return true;
};

The code was generating a fragment of HTML to be used as a template (look at the variable tmpl). The vulnerability was caused by the use of a non-escaped version of the user’s input within the template (#{user_term} versus #{escaped_user_term}). The fix was simple: always use the escaped version.

When the page was refreshed, the new topic was loaded from the database, causing it to be sanitized properly.

The first XSS vulnerability, on the topics page

2. “Questions you’ve asked” page

This vulnerability functioned in almost exactly the same way as the one above. It occurred on the Questions you’ve asked page when updating the topic for an existing question (“Question about…”). There were two separate locations on the page where the un-sanitized user input was used.

The second XSS vulnerability, when changing the topic of a question

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills.

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.

Summary

Google Baraza (www.google.com/baraza/) and Google Ejabat (ejabat.google.com) were vulnerable to a persistent XSS attack. A malicious user could create a post that would trigger JavaScript when an image or link was clicked on.

How did it work?

These Google services allow users to supplement their replies with external links, videos, and other content. When the reply is actually submitted to the server, this extra data is encoded separately from the rest of the message. By manipulating the encoded data in the request to use a javascript URI (ie: javascript:alert(1)) as the link to a video, it was possible to create a post with a link that would execute JavaScript when clicked on.

The XSS vulnerability in Google Baraza. Clicking on the image or the link resulted in JavaScript being executed.

The XSS vulnerability on Google Ejabat. Exactly the same attack vector as in Google Baraza.

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills.

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.

[Note: According to Google, I was not the first person to report this vulnerability to them. If the original reporter cares to come forward, I’ll be more than happy to cite their work in this writeup ]

Summary

Blogger’s Design Preview functionality served up author-generated content in the context of blogger.com, allowing an author to perform an XSS attack against a blog administrator.

How did it work?

Blogger is designed to allow authors to include arbitrary content in their blog posts. As the Google Security Team explains

Blogger users are permitted to place non-Google as well as Google JavaScript in their own blog templates and blog posts; our take on this is that blogs are user-generated content, in the same way that a third party can create their own website on the Internet. Naturally, for your safety, we do employ spam and malware detection technologies — but we believe that the flexibility in managing your own content is essential to the success of our blogging platform.

Note: when evaluating the security of blogspot.com, keep in mind that all the account management functionality – and all the associated HTTP cookies – use separate blogger.com and google.com domains.

So, for an attack on Blogger to be anything more than an annoyance, the attack has to target blogger.com or google.com as opposed to the subdomain where the blog is hosted.

In this case, there was a vulnerability in how user-generated content was presented on Blogger’s backend, which is served from blogger.com. The vulnerability involved Blogger’s Design Preview functionality, which is used by administrators to test layout changes. The preview of the blog’s content was being served from blogger.com, not from the blog’s (sub)domain. As a result, any JavaScript or other malicious content contained on the page (for instance, from a post written by an author) would be run in the context of blogger.com, exposing cookies and other sensitive information.

The JavaScript in the post creates an alert box with the value of document.location. As you can see, the JavaScript was executed on blogger.com

Same JavaScript as the example above, but executed using the Preview button on the Edit HTML page of the Design section

This vulnerability required the attacker to have author level (or higher) privileges on the same blog as the target, limiting its effectiveness. However, a malicious author could have used this vulnerability to perform privilege escalation via a CSRF attack, giving themselves administrator level privileges on the blog.

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills.

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.

Summary

Google Code contained a static HTML page that was vulnerable to a reflected, DOM-based XSS vulnerability.

How Did It Work?

The page in question is located at http://code.google.com/testing/iframe_example.html. I originally came across it when I was performing a Google search for an unrelated vulnerability: I’m not sure how I would have found it otherwise.

The page itself is fairly straightforward. It uses JavaScript to parse the query string and extract key/value pairs; it then document.write to add the data provided by the user directly to the page. If you look at the HTML on the page right now, you can see that user input is sanitized using JavaScript’s escape function: in the past, that was not the case. That lack of sanitization is what allowed the vulnerability to occur.

JavaScript could be executed by entering HTML in the url field, for example.

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills (and for putting up with me even when I report vulnerabilities that, unlike this one, affect only IE 6 / 7  )

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.

Summary

Feedburner accounts were vulnerable to a CSRF attack against certain services (MyBrand and FeedBulletin). An attacker could cause a user to enable or disable these services (potentially disrupting end-user access to content, in the case of MyBrand).

How Did It Work?

This vulnerability was fairly straightforward. To activate/deactivate MyBrand/FeedBulletin, you sent a simple POST request (to http://feedburner.google.com/fb/a/mybrandSubmit for MyBrand and to http://feedburner.google.com/fb/a/feedbulletinSubmit for FeedBulletin). Neither of those requests required a CSRF token to be processed. Accordingly, an attacker could trick a user into submitting a request without their consent.

Consider a possible attack. The target, Alice, owns a blog located at AliceAppSec.org. Alice provides an RSS feed for her blog (http://feeds.aliceappsec.org/AliceAppSec) using FeedBurner’s MyBrand service. The attacker, Marvin, is a jealous competitor; he wants to disrupt Alice’s RSS feed. To do so, he crafts a page that automatically submits a malicious MyBrand-disabling POST request to FeedBurner. Once that’s done, all he needs to do is convince Alice to look at the page: if she’s signed in to FeedBurner, the POST request will disable MyBrand for her account, causing her feed to return a 404.

Since the vulnerability is now patched, the proof of concept I sent to Google no longer functions. However, I’ve made the code (a simple HTML page) available for anyone who wants to check it out.

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills (and for responding to my many emails, even late at night on Sundays).

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.

Summary

One page in Google’s Help Center was vulnerable to a reflected cross-site scripting attack.

How did it work?

The page in question contained the following snippet of JavaScript embedded within its HTML:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

/*
function fileCartReport(form) {
    var comment = form.elements['body'].value;
    var entityStrEscaped = 'entity text';
    var entityStr = entityStrEscaped.replace(/"/g, '"');
    var client = '0' * 1;
    cartReporter().fileCartReport(entityStr, getAbuseType(), comment, client, function () {
        form.submit();
    });
}
*/

function fileCartReport(form) {
    var entityStrEscaped = 'entity text';
    var entityStr = entityStrEscaped.replace(/"/g, '"')
    var report = {
        entityId: entityStr,
        abuseCategory: getAbuseType(),
        comment: form.elements['body'].value,
        applicationId: '0' * 1,
        language: 'en'
    }
    cartReporter().fileCartReport(report, function () {
        form.submit();
    });
}

In the real code, the string entity text was actually the value of a parameter named entity passed in the URL. In normal links to the page, the entity parameter was a JSON-encoded string, which the rest of the JavaScript would then submit back to Google. However, since the data was being passed in the URL, it was possible to change the value placed in the JavaScript.

Of course, the value wasn’t fully under my control: for instance, there was still some input escaping that turned single quotes and double quotes into HTML entities. As a result, I couldn’t find a way to inject arbitrary JavaScript into the uncommented function. However, I realized that it was possible to inject it into the commented function: all I needed to do was begin my payload with */ and end it with /*, to preserve the existing block comment. At that point, I could write just about any JavaScript I wanted in the middle (keeping in mind the restrictions imposed by input escaping).

The vulnerability in action

I remembered to grab a screenshot of the vulnerability as I was testing for it, and I’ve reproduced it below;

The XSS vulnerability in action (in Google Chrome)

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills.

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.

Over the past several weeks, I’ve been an active participant in Google’s Web Vulnerability Reward Program. I’ve been writing blog posts about each of the vulnerabilities I’ve reported, publishing them once I’m told that the vulnerability has been patched. I’ve also been keeping up with posts that others have written and submitted to places like /r/netsec, /r/xss, and Hacker News. The posts, in aggregate, have explored many areas of web application security: XSS attacks of varying design, CSRF vulnerabilities, HTTP response splitting, clickjacking, etc. However, the program has attracted quite a large number of participants; I’m sure that I’ve seen only a small fraction of what people have posted.

Thus, the idea for this post came into being. My intention is to find and link to reports that people have written about vulnerabilities found as a part of this program. I’ve done a bit of searching and compiled a few links to start with (I’ve ordered them by the date they were posted). If anyone has suggestions for links to add, post in the comments and let me know: I’ll update the post with them.

Let me know what you think in the comments!

Update (12/21/2010): The comments have spoken and I’ve added a new vulnerability to the list.

Update 2 (12/21/2010): Adding another vulnerability that I reported to the list.

Update 3 (1/6/2011): fb1h2s emailed me about a vulnerability he reported. It has been added to the end of the list.

Update 4 (1/27/2011): We have another vulnerability report submitted via the comments.

Update 5 (2/3/2011): Five new reports have been added to the list, all of them XSS vulnerabilities!

Update 6 (3/4/2011): Three new reports have been added to the list.

Update 7 (3/7/2011): Added a cool new report about an XSS vulnerability in the Android marketplace

Update 8 (3/10/2011): Nir Goldshlager has written in with a link to his first report, an authentication bypass / HTTP Parameter Pollution vulnerability in Blogger.

Update 9 (3/30/2011): New Gmail XSS. Super happy fun time.

Summary

The new Google Groups interface contained an XSS vulnerability in its search functionality. The vulnerability required some user interaction to be activated.

How Did It Work?

The search box at the top of the new interface is designed to provide some type-ahead functionality: as the user types, his/her input is scanned and used to create a drop down menu of choices. Unfortunately, user input was not properly sanitized; for instance, typing <u> into the search box caused drop down menu items to become underlined. As a result of this oversight, it was possible to type arbitrary HTML/JavaScript into the search box and have it executed by the page.

The new interface’s type-ahead functionality, hard at work

My next step was to find a way to pass a malicious search string to a user. As it turned out, the interface provided a way to link to search results: visiting https://groups.google.com/forum/?fromgroups#!searchin/googlegroups-announce/<script>alert(document.cookie)<$2Fscript> would put <script>alert(document.cookie)</script> into the user’s search box.

Executing that malicious string required a little user interaction, however. The drop down box (and accordingly, the XSS) would only be activated when the user interacted with the search field. It was possible for a user to avoid the XSS by clicking in the box, highlighting the text, and deleting the entire string (or changing a character in the string so that the script failed to run). However, any other kind of interaction would have triggered the script’s execution.

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills.

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.