A serious cross-site scripting (XSS) vulnerability plaguing the Google Apps administrator console was patched by the search giant a few months ago.
The Google Apps console allows administrators to manage their organization’s account. Admins can use the console to add new users, manage security settings and enable Google services. The feature is utilized by many businesses that use Gmail as their email service.
When users access a service that hasn’t been configured for their domain, they are presented with a “ServiceNotAllowed” page. This page allows users to switch between accounts (they must be logged into at least two) in order to log in to the service.
The problem, according to security researcher Brett Buerhaus, was that when one of the accounts was selected, a piece of JavaScript code was executed in order to redirect the Web browser. JavaScript code could be supplied by the user in the “continue” parameter of the URL, which allowed XSS attacks.
“The continue request parameter is fairly common request variable in the Google login flow. This is the only page that I could find that did not validate the URL passed into it,” Buerhaus explained in a blog post published on Wednesday.
According to the expert, an attacker could have exploited this vulnerability to perform various actions. He could have forced an administrator to create new users, disable security settings for individual accounts (including two-factor authentication), and modify domain settings. An attacker could have also hijacked accounts by resetting their password, disabling two-factor authentication, and removing login challenges temporarily (for 10 minutes).
Buerhaus identified the flaw on the admin.google.com domain on September 1 and reported it to Google on the same day. The company confirmed the existence of the vulnerability a few days later and fixed it on September 18. Google rewarded the researcher with $5,000 for responsibly disclosing the bug.
“Cross-Site Scripting (XSS) is generally perceived to be a weaker attack than higher severity vulnerabilities such as Remote Code Execution, SQL Injection, etc. Rightfully so, as those vulnerability types can generally cause more damage and are more likely to give attackers sensitive information or complete access to your systems. But that perception has made a lot of developers underestimate the potential harm that can be caused by XSS,” Buerhaus told SecurityWeek.
“With this specific vulnerability, there’s a little bit of social engineering involved to convince an admin, who is actively logged in, to visit a page with a malicious payload or to convince them to click on a link to your malicious payload. But despite that, the outcome is devastating as it completely bypasses the security that Google provides to its accounts and gives the attacker complete access to either your admin panel or any user’s email, calendar, or any other Google service associated with it,” the researcher noted.
In an attack scenario described by the expert, the hacker knows that the targeted company’s employees are registered behind Google Apps and they use Gmail for company communications. The attacker can determine this through a domain scan or a DNS lookup.
Buerhaus explained, “If your end-goal were to target the CEO of their company and you know the email name convention that they use — most companies use a naming convention that makes this very easy (e.g. first letter of first name, last name, @ company.com) — you could construct the attack this way:”
“When the admin loads a link containing the JavaScript payload that you constructed, it would reset the password on the CEO’s account to whatever you supply and also disable 2FA and login challenges. This would allow you to log into the account and bypass any security measure that usually exists for all regular Google accounts,” he added. “At this point you can read all of their emails, their calendar, etc.”