The single sign-on account hijacking threat and what can we do about it?

Single sign-on (SSO) lets users avoid creating and managing accounts across different services, but what happens when that main, identity-providing account gets compromised? Can users remediate a takeover of that account and other accounts tied to it?

As it turns out, it’s definitely not easy. In fact, according to a group of researchers from the University of Illinois at Chicago, there’s a pressing need for a single sign-off option that will allow users to initiate a chain reaction of access-revocation operations that propagate across all associated accounts.

About SSO

Single sign-on is a helpful technology that allows users who have created an account with an identity provider (IdP) to use that same account to log into other web services or mobile apps (the relying parties, or RPs).

Facebook is the de-facto most popular identity provider, but there are others like Google, LinkedIn, Microsoft, Twitter, etc.

What the researchers did

The researchers first wanted to see how widely SSO is used. They crawled the top 1 million websites according to Alexa to see whether they offer SSO support for 65 IdPs that support the OAuth 2.0 and/or OpenID Connect standards. Of the 912,206 that were processed, 57,555 (6.30%) domains offered it.

Then, they wanted to evaluate the implications of an IdP account compromise, which can happen through simple phishing, Wi-Fi sniffing (cookie hijacking), etc.

“To determine the level of access the attacker has in the RP, we manually evaluated 29 websites out of the Alexa top 500 and 66 popular iOS apps that support Facebook SSO. For each website, we create a new account using SSO and add any additional information the service requires (e.g., a phone number). After completing the account setup, we interact with the service in its usual manner, including sending messages, making purchases, or commenting on articles. Next, we log out of the website,” the researchers explained the testing procedure.

“At this point, we switch roles and consider what the attacker can do. We begin by injecting the user’s hijacked session cookie into a clean browser session, which we then use to authenticate to the IdP during the SSO flow. Next, we visit the RP where the user has an account and go through the normal ‘log in with ⟨IdP⟩’ procedure. Finally, we interact with the website to determine the attacker’s level of access. We perform a similar experiment for each mobile app.”

How does this impact compromised users?

The result? In most cases, the attacker’s level of access to the website or app was identical to the legitimate user’s.

And, in addition to this, the attack remains “invisible”, as none of the 95 RPs notify users about other devices or active sessions and only ten of them allow users to see all the active sessions.

But even if the attacker loses access to the user’s IdP account, the researchers found it’s possible for the attacker to maintain access to some RP accounts by replacing the email address and resetting the password. “As a result, the attacker can maintain access to the user’s RP account using the attacker’s email and password to log in, while the user will still be able to continue accessing the RP account over SSO,” they noted.

Other attacks are also possible:

• Account linking attacks (if the RP offers the option to de-link the IdP account)
• IdP access escalation attacks (the attacker using the hijacked cookie can reset the user’s Facebook password through a loophole in the verification process)
• Preemptive account hijacking (the attacker uses the victim’s IdP account to preemptively create an account for the victim on an RP).

Finally, there’s the additional and very serious problem of difficult post-compromise remediation. “Apart from the absence of a standardized mechanism to revoke the attacker’s access to all of the RP accounts, we find that for the majority of RPs there is no course of action available that can lock out the attacker,” they said.

Solutions for mitigating the single sign-on account hijacking threat

The researchers have proposed a protocol for universal access revocation for mitigating the threat. But, until it can be implemented, they propose a backwards-compatible extension to OpenID Connect that adds support for universal authentication revocation.

“To ease implementation, our extension adds a single callback endpoint to each RP and uses standard OpenID Connect messages and data structures,” the concluded.

They’ve also shared their findings with the various IdPs and RPs, so hopefully they’ll implement functionalities to address the various discovered shortcomings. To start, Facebook has fixed the cookie exposure flaw that could allow attackers to hijack users’ Facebook account and use it to sign on to a multitude of RPs.