Google's vulnerability reward programme gets a lot of attention, and includes not just Google's main websites, but also those of acquisitions older than 6 months. With this in mind, I thought I'd venture off the beaten path and take a look at Admob, one of the world's largest mobile advertising platforms according to Wikipedia.

Admob was acquired by Google for $750 million in November 2009, putting it well beyond the 6 months Google ask to patch up new arrivals, but also giving plenty of time for vulnerabilities to be found and fixed. At first glance things looked fairly good for Admob, but there was a nice little stored XSS waiting a little way under the surface.

Application logic

The process of creating an Admob advert is as follows:

1. Create a new advert, set dates and daily budget and add any notes
2. Target the advert by mobile platform and give the ad group a name
3. Select specific devices, set the advert's geographic and demographic scope and minimum per-click bid
4. Choose an advert type, either Text or Image, and upload any creatives

The interesting part of the process is the last step, uploading creatives. The process follows a pattern I've seen before, which is to perform an AJAX image upload when a file is selected, then take the image path returned by the AJAX script and store it in a hidden input field ready to be saved when the form is submitted.

With this knowledge in hand, I uploaded an image and started manipulating the form data to test different image URLs.

The attack

With some experimentation it was clear that there were no filters on the image URL saved with the advert, allowing images from any domain to be embedded on advert page, a clear breach of privacy if nothing more. But further checks revealed that there was no character escaping either, allowing HTML and JavaScript to be injected into the page.

By interrupting the form POST or altering the page before saving, it was possible to inject arbitrary content. JavaScript execution was possible by manipulating the URL to break out of the enclosing <img src="…" /> tag attribute:

"><script>alert(document.cookie)</script>

Because this is a static cross-site scripting attack (i.e. the server is providing the content, not the browser), no browser-side XSS filters are triggered and the code is executed regardless of browser security settings. The moral of the story? Don't hand your data to the browser and expect it to get sent back to the server without any tampering!

Timeline

1. 2013-05-28 Vulnerability reported to Google
2. 2013-05-29 Bug filed by the Google security team
3. 2013-06-04 Notification that the bug qualified for a reward