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.

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.

Summary

Google Scholar was vulnerable to minor but potentially annoying CSRF vulnerabilities in two different pages. The regular search equivalents of both of these pages used CSRF tokens to mitigate these problems.

Vulnerability #1

There was no CSRF protection used when saving preferences in Google Scholar. So, browsing to the following URL used to set your language on Google Scholars to Arabic and set your search results to return papers written in Chinese: http://scholar.google.com/scholar_setprefs?hl=ar&lang=some&lr=lang_zh-CN&submit. As of right now, the URL no longer updates user preferences (although it does change the language for the current page, and any page accessed from links/forms off of that page).

Vulnerability #2

There was no CSRF check in place for setting up email alerts in Google Scholar. A simple POST to http://scholar.google.com/scholar_alerts?view_op=list_alerts&hl=en where the POST data was

1
2
3

alert_query=[SOME QUERY]&
alert_max_results=10&
create_alert_btn=Create+alert

would have resulted in an alert being created for the currently logged in user (there was a parameter, email_for_op, that was passed in during a real request: removing it seemed to cause the system to default to the currently logged in user’s email address).

More Information

The vulnerabilities mentioned here have all 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.

To see more posts I’ve written about vulnerabilities reported under Google’s Vulnerability Reward Program, please click here.