Google has patched a bug in its feedback tool incorporated across its services that could be exploited by an attacker to potentially steal screenshots of sensitive Google Docs documents simply by embedding them in a malicious website.
The flaw was discovered on July 9 by security researcher Sreeram KL, for which he was awarded $3133.70 as part of Google’s Vulnerability Reward Program.
Many of Google’s products, including Google Docs, come with a “Send feedback” or “Help Docs improve” option that allows users to send feedback along with an option to include a screenshot — something that’s automatically loaded to highlight specific issues.
But instead of having to duplicate the same functionality across its services, the feedback feature is deployed in Google’s main website (“www.google.com”) and integrated to other domains via an iframe element that loads the pop-up’s content from “feedback.googleusercontent.com.”
This also means that whenever a screenshot of the Google Docs window is included, rendering the image necessitates the transmission of RGB values of every pixel to the parent domain (www.google.com), which then redirects those RGB values to the feedback’s domain, which ultimately constructs the image and sends it back in Base64 encoded format.
Sreeram, however, identified a bug in the manner these messages were passed to “feedback.googleusercontent.com,” thus allowing an attacker to modify the frame to an arbitrary, external website, and in turn, steal and hijack Google Docs screenshots which were meant to be uploaded to Google’s servers.
Notably, the flaw stems from a lack of X-Frame-Options header in the Google Docs domain, which made it possible to change the target origin of the message and exploit the cross-origin communication between the page and the frame contained in it.
While the attack requires some form of user interaction — i.e. clicking the “Send feedback” button — an exploit could easily leverage this weakness to capture the URL of the uploaded screenshot and exfiltrate it to a malicious site.
This can be achieved by embedding a Google Docs file in an iFrame on a rogue website and hijacking the feedback pop-up frame to redirect the contents to a domain of the attacker’s choice.
Failing to provide a target origin during cross-origin communication raises security concerns in that it discloses the data that’s sent to any website.
“Always specify an exact target origin, not *, when you use postMessage to send data to other windows,” Mozilla documentation states. “A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using postMessage.”