A researcher revealed on Wednesday that he discovered a blind cross-site scripting (XSS) vulnerability that could have been exploited to attack Google employees and possibly gain access to invoices and other sensitive information.
Thomas Orlita, a 16-year-old bug bounty hunter from the Czech Republic, analyzed the Google Invoice Submission Portal hosted on gist-uploadmyinvoice.appspot.com, where vendors can submit invoices to Google.
During the process of submitting an invoice, users are asked to provide various types of information via several text fields. However, Orlita found that these inputs were properly sanitized and they could not be abused for XSS attacks.
However, he noticed that the feature designed for uploading the actual invoice in PDF format could be abused to upload HTML files. An attacker simply had to intercept a request and change the uploaded file’s filename and Content-Type properties to HTML.
During his tests, Orlita uploaded an HTML file containing an XSS payload that, when triggered, would send him an email every time it was loaded.
The researcher believes the vulnerability could have been exploited to execute arbitrary code on behalf of Google employees and gain access to invoices and other sensitive information. He also believes that since the targeted Google employee would have been logged in using their company account, it should have also been possible to access other internal sites on their behalf.
“Depending on how they have cookies configured on the server (most likely the cookies are shared between all the subdomains so they don’t have to login into all the different subdomains all the time – we can’t know that for sure tho), it should be as well possible to send requests to other googleplex.com subdomains. There’s a list of perhaps hundreds of different subdomains on this domain. The amount/serverity of the gained data is of course depending on how well it can be exploited. For example an attacker might try to do a phishing attack on the employee,” he added.
Google was informed of the vulnerability on February 21 and implemented a patch roughly one month later. The internet giant initially assigned a P2 priority level (severe) to the flaw, but later changed it to P1 (critical). The company has the following description for P1 issues: “The issue identified in the submission has the highest priority and should be assigned to major blockers. Typically, submissions with a P1 priority cause the application to be unusable and requires immediate attention.”