Google has addressed a bug in its feedback tool incorporated across its services that could have allowed attackers to view users’ private docs.
Google has addressed a flaw in its feedback tool that is part of multiple of its services that could be exploited by attackers to take screenshots of sensitive Google Docs documents by embedding them in a malicious website.
The vulnerability was discovered by the security researcher Sreeram KL, he demonstrated how to exploit it to hijack Google Docs screenshot of any document due to postmessage misconfiguration and browser behavior.
The issue affected the “Send Feedback” function that is included in most Google products. The ‘Send Feedback’ feature was implemented to allow users to submit feedback to Google. The function implements a feature that allows users to add screenshots to the feedback with a brief description of the problem.
The feedback feature is deployed in Google’s main domain (“www.google.com”) and is integrated into other domains by including an iframe element that loads the pop-up’s content from “feedback.googleusercontent.com” via PostMessage.
The Iframe loads the screenshot of the document you were working on. The expert pointed out that the origin of the iframe (www.google.com) is different from the Google docs (docs.google.com) and the cross-origin communication to render the screenshot is possible through PostMessage.
When a screenshot of the Google Docs window is included in the feedback, the rendering of the image is done by transmitting RGB values of every pixel to google.com, which in turn redirects those RGB values to the feedback’s domain, which constructs the image and sends it back in Base64 encoded format.
Sreeram discovered a bug in the transmission process of the messages to “feedback.googleusercontent.com.” He explained that an attacker could modify the frame to an arbitrary, external website, to steal Google Docs screenshots.
for which he was awarded $3133.70 as part of Google’s Vulnerability Reward Program.
The flaw is caused by the lack of X-Frame-Options header in the Google Docs domain.
“After watching the video, I learned a new trick that I didn’t knew before. That is, you can change the location of an iframe which is present in cross origin domain (If it lacks X-Frame-Header). For example, if abc.com have efg.com as iframe and abc.com didn’t have X-Frame header, I could change the efg.com to evil.com cross origin using, frames.location.” wrote the expert.
“The final postmessage on submitting feedback was configured like, windowRef.postmessage(“<Data>”,”*”); as there is no domain check the browser happily sent the data to my domain, which I was able to capture and hijack the screenshot. But wait! I said the parent domain shouldn’t have X-Frame header, how am I going to achieve that? Luckily Google docs didn’t have one.”
Below the video PoC published by Sreeram KL:
An attacker could embed a Google Docs file in an iFrame on a malicious website and hijacking the feedback pop-up frame to redirect the screenshots to a domain under his control.
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – hacking, Vermont Medical Center)
[adrotate banner=”5″]
[adrotate banner=”13″]
