Google WebLogin Tokens Expose Google Apps, User Data

Description

An exposure in the way Google handles authentication is an illustration of the unintended consequences of trading security for a little bit of convenience.

Craig Young, a researcher from security company Tripwire, demonstrated at Def Con over the weekend how an Android single sign-on token known as WebLogin can expose data stored in almost any Google service, regardless of platform. The tokens are meant as a convenience for users, allowing them to forego having to enter their password every time they access a Google service.

Young, however, designed an Android application that he uploaded to Google Play demonstrating how WebLogin tokens could be sent to a remote server for use by an attacker to access the Google Apps domain control panel. The tokens are sent through to the attacker without being detected and can be used to bypass password prompts, even when password re-verification is required. If the victim is a Google Apps admin with access to company data, all of that sensitive information would be in jeopardy as well. Young created a short video demonstrating the problem.

“Google Apps is particularly affected; if I get a token from an admin, I get the same permissions they have on a Google Apps domain,” Young said. “If I get a token from a regular user, I can get access to their docs, Gmail account or anything else they’ve configured.”

This isn’t limited to Android, Young said; Chrome for Windows and Mac OSX users are impacted, as likely are iPhone users on Chrome.

Young had been working with Google for months, and the company believed it had fixed the issue by April via a number of Chrome and Android updates. But Young informed Google prior to his Def Con presentation that he still could grab WebLogin tokens to access accounts.

“The design choices they made in implementing their authentication system make it so you gain access to an entire account,” Young said.

Young’s application was called Stock Viewer and posed as an app for Google Finance where users could monitor stocks in their portfolio. The app was priced at $150 so as to discourage anyone from downloading it and the description urges users not to install it ever. The application was available for a month on Google Play, meaning it passed through the initial Google Bouncer check and was likely reported as malicious leading to its takedown from the market.

“I can only speculate, but based on the server logs, there was no indication Bouncer executed the malicious parts of the application. If they’re doing behavioral analysis, they’re not doing it in an environment connected to a Google account,” Young said, adding that previous research on uploading apps to Google Play demonstrated Bouncer’s effectiveness as catching apps trying to steal data directly. “It’s quite possible Bouncer is not implemented on the AccountManager API.”

An attacker can also obtain the tokens via a root exploit, physical access to a logged-in device or browser, or in the case of law enforcement, via a forensics tool. Once an attacker has access to an account, they could do anything from disabling two-factor authentication (only with an admin token since Google update), adding super-users to a Google Apps domain, modifying privileges or roles, and even revealing temporary passwords. On personal accounts, Gmail, Drive, Calendar, photos and other data would be exposed, as was all data via Google Takeout before a Google update the Wednesday before Def Con. Young’s app was particularly crafty in that upon installation it asked for permission to find and use accounts on the device and have full network access. At runtime, it gave permission for the app to access the Google account.

“The real risk is taking an app that’s already out there with a legitimate use for real credentials. If someone were to take one of these apps and add in some of the code from the proof of concept I release on Google Play or one of the Chinese marketplaces that aren’t regulated, they could attract a lot of people with a promise of, say, free phone calls,” Young said. “They are going to find some sensitive information worth something to somebody, or that would make people look bad.”

All product names, logos, and brands are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.If you are an owner of some content and want it to be removed, please mail to content@vulners.com Vulners, 2018

Protected by

{"id": "THREATPOST:7F144DD0CFE66EECBD007C0B5A194320", "hash": "8a4aa355acf5ca676f013b027cc70e97", "type": "threatpost", "bulletinFamily": "info", "title": "Google WebLogin Tokens Expose Google Apps, User Data", "description": "An exposure in the way Google handles authentication is an illustration of the unintended consequences of trading security for a little bit of convenience.\n\nCraig Young, a researcher from security company Tripwire, [demonstrated at Def Con](<http://secur3.us/DC21Slides.pdf>) over the weekend how an Android single sign-on token known as WebLogin can expose data stored in almost any Google service, regardless of platform. The tokens are meant as a convenience for users, allowing them to forego having to enter their password every time they access a Google service.\n\nYoung, however, designed an Android application that he uploaded to Google Play demonstrating how WebLogin tokens could be sent to a remote server for use by an attacker to access the Google Apps domain control panel. The tokens are sent through to the attacker without being detected and can be used to bypass password prompts, even when password re-verification is required. If the victim is a Google Apps admin with access to company data, all of that sensitive information would be in jeopardy as well. Young created a short [video](<http://secur3.us/DC21-ShortDemo.mp4>) demonstrating the problem.\n\n\u201cGoogle Apps is particularly affected; if I get a token from an admin, I get the same permissions they have on a Google Apps domain,\u201d Young said. \u201cIf I get a token from a regular user, I can get access to their docs, Gmail account or anything else they\u2019ve configured.\u201d\n\nThis isn\u2019t limited to Android, Young said; Chrome for Windows and Mac OSX users are impacted, as likely are iPhone users on Chrome.\n\nYoung had been working with Google for months, and the company believed it had fixed the issue by April via a number of Chrome and Android updates. But Young informed Google prior to his Def Con presentation that he still could grab WebLogin tokens to access accounts.\n\n\u201cThe design choices they made in implementing their authentication system make it so you gain access to an entire account,\u201d Young said.\n\nYoung\u2019s application was called Stock Viewer and posed as an app for Google Finance where users could monitor stocks in their portfolio. The app was priced at $150 so as to discourage anyone from downloading it and the description urges users not to install it ever. The application was available for a month on Google Play, meaning it passed through the initial Google Bouncer check and was likely reported as malicious leading to its takedown from the market.\n\n\u201cI can only speculate, but based on the server logs, there was no indication Bouncer executed the malicious parts of the application. If they\u2019re doing behavioral analysis, they\u2019re not doing it in an environment connected to a Google account,\u201d Young said, adding that previous research on uploading apps to Google Play demonstrated Bouncer\u2019s effectiveness as catching apps trying to steal data directly. \u201cIt\u2019s quite possible Bouncer is not implemented on the AccountManager API.\u201d\n\nAn attacker can also obtain the tokens via a root exploit, physical access to a logged-in device or browser, or in the case of law enforcement, via a forensics tool. Once an attacker has access to an account, they could do anything from disabling two-factor authentication (only with an admin token since Google update), adding super-users to a Google Apps domain, modifying privileges or roles, and even revealing temporary passwords. On personal accounts, Gmail, Drive, Calendar, photos and other data would be exposed, as was all data via Google Takeout before a Google update the Wednesday before Def Con. Young\u2019s app was particularly crafty in that upon installation it asked for permission to find and use accounts on the device and have full network access. At runtime, it gave permission for the app to access the Google account.\n\n\u201cThe real risk is taking an app that\u2019s already out there with a legitimate use for real credentials. If someone were to take one of these apps and add in some of the code from the proof of concept I release on Google Play or one of the Chinese marketplaces that aren\u2019t regulated, they could attract a lot of people with a promise of, say, free phone calls,\u201d Young said. \u201cThey are going to find some sensitive information worth something to somebody, or that would make people look bad.\u201d\n\n_This article was updated at 4 p.m. ET to reflect clarifications throughout provided by Craig Young. _\n", "published": "2013-08-07T14:07:15", "modified": "2013-08-09T17:19:30", "cvss": {"score": 0.0, "vector": "NONE"}, "href": "https://threatpost.com/convenient-google-weblogin-tokens-can-expose-user-accounts-data/101885/", "reporter": "Michael Mimoso", "references": ["http://secur3.us/DC21Slides.pdf", "http://secur3.us/DC21-ShortDemo.mp4"], "cvelist": [], "lastseen": "2018-10-06T23:00:22", "history": [], "viewCount": 0, "enchantments": {"score": {"value": 5.0, "vector": "NONE", "modified": "2018-10-06T23:00:22"}, "dependencies": {"references": [], "modified": "2018-10-06T23:00:22"}, "vulnersScore": 5.0}, "objectVersion": "1.4", "_object_type": "robots.models.threatpost.ThreatpostBulletin", "_object_types": ["robots.models.base.Bulletin", "robots.models.threatpost.ThreatpostBulletin"]}