Using Subdomain Takeovers to Attack SSO

SAML is used to implement SSO—or Single-Sign-On. SSO allows users to access a variety of services throughout an organization without logging into each one individually. For example, if you were logged into your Facebook account you wouldn’t need to reenter your password to access Messenger. 

It is in this way that companies can have a centralized source of user credentials as opposed to tracking users on each site. This also keeps users from having to log in multiple times when they use a variety of applications and services within the same organization. 

This post is going to go over options (other than SAML) that you can use to implement SSO, along with the vulnerabilities that come with each of them.

The Tale of Three SSOs

Cookie sharing, SAML, and OAuth are the three most common ways of implementing SSO.

Cooking Sharing Between Subdomains (Shared-Session SSO)

One way that applications can implement SSO is by sharing cookies across subdomains. Browser cookies can be shared across subdomains if their domain flag is set to a common parent domain. In this case, the cookie will be sent for any subdomain of facebook.com.

Set-Cookie: cookie=abc123; Domain=facebook.com; Secure; HttpOnly

This is the simplest SSO setup. But with its simplicity, this approach also comes with a unique set of vulnerabilities.

The Achilles’ heel of cookie sharing is subdomain integrity. If attackers can steal the shared session cookie by compromising a single subdomain, all the SSO sites would be at risk. Usually, hackers steal the session cookies by finding a subdomain takeover, RCE, XSS, or any other vulnerability that would expose the user’s cookie.

Because the compromise of a single subdomain can mean a total compromise of the entire SSO system, using shared cookies as an SSO mechanism greatly widens the attack surface for each individual service.

SAML

Another common SSO mechanism is SAML. SAML enables SSO by facilitating information exchange between three parties: the user, the identity provider, and the service provider. The user obtains an identity assertion from the identity provider and uses that to authenticate to the service provider.

Since the identity assertion is used to prove the identity of the user, its integrity is critical. Applications signs these identity assertions to ensure that no one can tamper with them.

SAML can be secure if the SAML signature is implemented correctly. However, its security breaks apart if attackers can find a way to bypass the signature validation.

OAuth

Finally, OAuth is a way of granting access to certain user resources without providing a password. It is essentially a way for users to grant scope specific access tokens to service providers through an identity provider.

Typically, hackers bypass OAuth protection by stealing critical OAuth tokens through open redirects.

Subdomain Takeovers

So how can subdomain takeovers help hackers bypass SSO protection?

Subdomain takeover is when a hacker takes control over a company’s unused subdomain.

Let’s say a company hosts its site on a third-party service, such as AWS or Github Pages. When this third-party site is deleted, a CNAME record that points from the company’s subdomain to that third-party site will remain unless someone removes it.

But since the third-party site is now unclaimed, anyone who registers that site on the third-party service gains control over the company’s subdomain.

For example, an organization hosts its subdomain, abc.example.com, on the Github page abc_example.github.io. The company later decides to delete the Github page but forgets to remove the CNAME record pointing abc.example.com to abc_example.github.io.

Since abc_example.github.io is now unclaimed, an attacker can create a GitHub page at abc_example.github.io. And because abc.example.com still points to abc_example.github.io, the attacker now has full control over abc.example.com.

Shared-Session SSO Scenarios

Now imagine that example.com implements a shared-session based SSO system. Its cookies will be sent to any subdomain of example.com, including abc.example.com.

In this case, attackers can take over abc.example.com and host a malicious script there to steal session cookies. She can then make the user access abc.example.com by hosting it as a fake image or sending the link over to the user.

As long as the victim has already logged into the SSO system once, the hacker can steal the victim’s shared session cookie and log in as the victim to all services.

Preventing Subdomain Takeover Session Theft

So what can you do to prevent these attacks from happening?

Monitor and Remove Subdomain Takeovers

If your application implements shared-session SSO, it is essential that you protect it against subdomain takeovers.

You can lower the possibility of a subdomain takeover attack by monitoring your DNS records, keeping track of third-party hosting services and routinely scanning for subdomain takeovers. More on monitoring for subdomain takeovers in later posts!

Avoid Shared-Session SSO, Use OAuth or SAML Instead

Finally, you can avoid using shared-session SSO altogether. The nature of sharing session cookies across subdomains means that the possibility of compromise is higher.

OAuth and SAML are more mature SSO solutions. Although they each have their own unique security issues, they have improved a lot over the last few years. Out-of-the-box authentication services offered now tend to be much more reliable in the long run compared to a naive shared-session solution.