Inline Resource XSS via Gmail Android Application
Google is the largest email provider in the world today, with close to one billion users who manage a significant part of their digital lives through their email platform. This makes the Google mail platform a main target for multiple attackers worldwide.
Success in breaking into a Google (Gmail) email account not only enables an attacker to read private emails of the user and send emails in his/her name, it also enables access to many other services that the user is registered for by reproducing the user’s password for this email account. Google invests major resources in securing all its products, with a special emphasis on its email products.
Because the Gmail system is well secured, Ysrael Gurt, BugSec’s Lead Security Research and Application Security Team Leader, decided to focus instead on the Gmail Android application. The research focused on files that are attached to email as Inline Attachments. Inline Attachments are treated in a slightly different form, making it possible to open them (and in certain scenarios also to run them) from within the email message itself.
Finding the vulnerability:
After some investigation, we discovered an unsecured method that was created by the Inline Attachment, combined with the use of an HTML page. Normally, attached files are accessible only from their Gmail sandbox domain (googleusercontent.com) and only as a downloadable file.
Image 1: The attached file in the Gmail application
Because of the use of the Inline Attachment in the Android application, the file was pulled for download from the domain mail.google.com as a regular response of the application.
Image 2: The server returns the content of the file from mail.google.com
But this is not enough, since the html page still needs a valid access key in order to access the page.
Creating the attack scenario:
The next step is to create a reasonable scenario in which an attacker can cause a malicious code to be run via the victim’s content.
Image 3: Access to the link with the Gmail application identifier (in the cookie)
Access to this address without the cookie of the Gmail application leads to a 401 (Unauthorized) response.
Image 4: Access without the cookie
After a number of attempts, we realized that it was possible to supply an authorization header to the server in order to obtain access to the address.
With our first try, we sent an authorization header with random details to analyze what was required for valid access.
Image 5: Access with authorization header
We detected that in order to avoid the need of the user having to add the header, we could use the parameter access token that enables OAuth identification for Google services, without the need for an authorization header. To obtain an access token, we built a google-api project that sent requests to the API for access to Gmail, and for it, we created an access token to the Gmail account that would enable access to the attached file.
Image 6: Authorization of request to obtain access token
This works. Now any user who accesses the site with the valid active access token will in response, receive the infected page under the domain mail.google.com, since the cookie identifies the user (mail.google.com domain).
Image 7: The final link
Since the Google access token is valid only for 30 minutes, the victim will be need to be referred to a website, which will give the user a reference (301) to a link which is valid at the right time. But this is not a problem, as it is possible to create unlimited links because the link refers to an account under our ownership (or in a malicious case, the ownership of the attacker).
There are many options for good payloads. We built code that includes an iframe that refers to the html display of Gmail. Normally it is not possible to insert the Gmail window into an iframe because of the Header: X-Frame-Options: SAMEORIGIN, but in our case the script is at mail.google.com, which is the same origin as this page.
Image 8: The messages are sent – display in the burp window
Image 9: The messages are sent – display in Chrome
We notified Google of this vulnerability, and learned that Google treats information security very seriously, providing a dedicated, convenient interface for reporting security breaches in its services. After the initial report to Google, we received a personal response within 8 hours of the report. After supplying additional details that we were asked to provide, Google’s security team opened the bug and the breach was blocked within 6 hours.
Congratulations to Google.
We did find two more severe vulnerabilities that are currently being handled by Google and we might disclose them in the future.
Ysrael Gurt is Application Security Team Leader at BugSec, specializing in advanced penetration testing of web applications and secure development. Ysrael leads application research at BugSec with many ongoing research projects.
BugSec Group is a leading offensive security consulting company, focused on ethical hacking, security research, cyber-attack simulations, SCADA, Incident Response, SOC, product security evaluation and other services to increase customer security. Since 2005, BugSec has been providing security consulting services to global companies in the fields of finance, defense, government, hi-tech, utilities and other markets. The BugSec team is made up of some of the world’s most talented offensive and defensive hacking experts and security research teams, who work together with intelligence and law enforcement organizations around the world to help our customers protect their assets.