OAuth Phishing Threat
People are gradually growing more careful about phishing schemes that impersonate websites and ask for their passwords. But what if they don’t have to give a password to let an unauthorised party get at their data? That’s exactly what happened in a recent phishing campaign aimed at Google users. Hard numbers aren’t available on how many people were affected, but Google said the number was “fewer than 0.1% of Gmail users,” which could be as many as a million.
The Google Docs spoof
People received a message on their Gmail accounts, usually from an address they knew, asking them to open a “Google Doc.” If they did, it asked them to give Google Docs certain permissions, including permission to “read, send, delete, and manage your email.” No password confirmation was necessary, since the victim was already logged in. The only trouble was that the application wasn’t Google Docs but a malicious lookalike web app.
If the victim gave permission, the attacker could then use the account to send the same email to the victim’s contacts. This could have spread without limit if Google hadn’t promptly shut the application down.
The deception took advantage of design and implementation weaknesses in the widely used OAuth2 specification, which allows one Web application privileged access to another. Researchers had warned in 2011 that this kind of spoofing was possible, creating a proof-of-concept application. The 2017 attack may have drawn directly on that code.
What made the attack plausible
A combination of design issues with OAuth, social factors, and implementation choices by Google made the spoofing plausible to anyone without a strong understanding of security issues. The application was in fact hosted on Google, which lets users develop applications for public use. It was a reasonable imitation of Google Docs; the URL was wrong, but it was a Google URL. The mail came from trusted accounts.
The application was called “Google Docs.” Until very recently, Google didn’t prevent user applications from using its name. It still doesn’t provide any warning when an application making this type of request isn’t under Google’s control.
There’s no good reason Google Docs should ask for access to the user’s Gmail account, but people are used to wildly excessive requests for authorization. Websites that let your account connect to a LinkedIn account often ask for permission to post on your behalf. Most people apparently grant it without worrying.
The trouble with OAuth
The deeper problems, which aren’t restricted to Google, lie in the OAuth standard. It’s an authorization system which is weak on authentication. Without strong protections, it makes it easy to trick users into giving untrustworthy applications access to their private data.
In brief, OAuth2 lets a client application request permissions from a server. Only authorized applications can make requests. An application that’s allowed to use OAuth receives a client ID, which is public information, and a client secret (or key), which is confidential.
When the client app invites the user to give it permission, it redirects the user to a server URL. The server will inform the user of the request and give a choice of denying or allowing authorization. If the user allows it, the server redirects back to the client and sends an authorization code, which the client has to retain for as long as it wants to keep the permission. This could be just for a session or permanent. The server can limit its duration.
An obvious problem with this arrangement is that the server needs to trust a client over which it has no control. The client might be trustworthy at the time it gets permission, but a change of policy or a malware infection could change that. Theoretically, users should trust only applications in which they have very high confidence, but many people are far too trusting. The organization operating the server needs to carefully limit the clients it will give access to.
A poor implementation lets a client pretend to be a trusted application. The server has some control over this, since it knows what application is making the request, but it may or may not make it obvious to the user. If it just displays the application’s self-selected name, that’s weak protection.
Users who authorize a rogue application may not even realize there’s a problem. Google and other sites that use OAuth normally make a list of authorized applications available to the user and allow revocation, but it’s buried somewhere in the user settings.
Future risks
It’s a lucky thing that the Gmail attack apparently did little damage. One thing Google did right was to catch the rogue application and revoke its credentials within an hour. We can be sure others will try similar tricks, sometimes with services that don’t react so quickly. Any organization that uses OAuth to grant third-party applications access to its site should review its implementation and policy to make sure it isn’t vulnerable.
The most important precaution is to screen applicants for credentials carefully. A lot of users will give permission to any application that seems to do something useful, so it isn’t enough to trust them to exercise discretion.
Even if what an application currently does is legitimate, the applicant’s reputation needs to be good enough that it isn’t likely to misuse its authorization in the future. Clients should be periodically reviewed to make sure they still deserve trust. If there’s any sign they don’t, it’s important to follow up quickly and, if necessary, revoke authorization. Even an honest organization could have its credentials stolen or its code infected.
The organization should think carefully about what kinds of access it should authorize. The power to speak for the user can be used for fraudulent purposes. The power to read private data could allow theft of secrets. There needs to be a convincing case that the benefits from the application justify the risks.
Authorizing third-party applications can greatly increase the value of a service, but it carries serious responsibility. Anyone who implements it needs to be aware of its dangers and make choices that minimize the chances of abuse.
If you’re concerned with the security of your planned website, OrangeWebsite will provide hosting that will satisfy your needs. Contact us to learn more.
Recent Comments