SSO Sloppy, SSO Suspect, SSO Vulnerable

Single Sign On (SSO) improves security for organizations and org members in their routine access to applications required by their role. While SSO providers resolve many authentication risks with policies and configuration, new forms of phishing through providers is possible, and should be addressed.

AWS is an Identity Provider (IdP) which grants access to AWS accounts through web and command line applications. AWS fails to authenticate command line applications with the individual, mixes authentication and authorization protocols by misusing device codes which are phishable, the AWS SDK client dynamically registers itself as an OpenID Connect (OIDC) application, and exposes secrets in plain text to users to authorize arbitrary command line applications.

Other large organizations such as Facebook employ complex chained interactions during authentication and authorization. These complex implementations are difficult to analyze and secure by their implementers. Cross-functional researchers and threat actors find vulnerabilities in these complex systems that chain and mix many protocols together.

This talk summary is part of my DEF CON 31 series. The talks this year have sufficient depth to be shared independently and are separated for easier consumption.

This was one talk I had to attend. Last year, I enjoyed the dense content from Jenko Hwong about OAuth abuse.

At the time, I remarked: I am planning to implement an OAuth service, after all. OpenID too, maybe. — DEF CON 30 - Hacker Summer Camp in 2022

How did that go?

I did make progress, though my domain got marked as malware because it was new and only had authentication mechanisms.

I lost a lot of motivation after appealing that to Google — only to find other services have no appeal mechanism.

This year, Jenko presented about risks on protocol complexities, trust chains, attack chains, and cobbling together web APIs.

What's a trust chain? And, what about attack chains?

Sometimes these identity and trust systems are managed by different parties which have some established trust with one another. For example, I trust that if you sign in with Google, there is a low risk of me authenticating someone who Google does not trust to hold that identity.

Many attacks jump from vulnerability to vulnerability to break a security goal of a holistic system. They chain attacks together across behaviors, applications, systems, networks, and trust boundaries.

He warned that it would be 80 minutes of content in a mere 39. We had a lot to go through.

I love dense presentations! I love it when I cannot capture everything, it shows me where my knowledge gaps are and where I can learn on my own time.

We started by establishing a shared understanding of what Single Sign On (SSO) brings:

• it aligns individuals with security by making it easier for everybody
• it reduces the attack surface of every connected service down to one: the SSO vendor
• it reduces cognitive load around credentials
• allows for stronger consistent policies used to authenticate with the SSO vendor

SSO, by design, mitigates several weaknesses found in cross-application identity. At the same time, the feature set of established SSO vendors enable new risks that should be considered.

Individuals are trained to think their SSO vendor is secure, and that every destination it forwards them to is also trustworthy. When interacting with an SSO vendor, they should expect that all subsequent destinations are also trusted. It is easier for individuals to delegate trust and critical examination to their IT department than make a risk analysis every time they use SSO.

If only the SSO tax wasn't a thing.

Malicious use of SSO vendor features

SSO vendors are multi-tenant. Your organization is just one tenant of the many that the SSO vendor serves. Threat actors can sign up and make their own organizations and multi-tenant applications with SSO vendors like Okta. They can easily send a legitimate email from Okta to a victim which invites the victim to use their malicious application. The victim will see a legitimate email from Okta with the usual verbiage and click the link.

An especially wary victim would see the email link goes to ….okta.com and trust the destination. Then, because Okta allows tenants to host their own credential entry, the victim is redirected to a malicious webpage from Okta. They may not notice the URL has changed, as SSO and IdP is built upon redirecting between websites and applications. In other words, the mechanism that forwards victims to a false Okta login screen is normal behavior when originated from an Okta web page.

Phishing victims with a malicious login screen is an old tactic. The new tactic is tricking victims through the trust relationship they have with a familiar SSO vendor and then doing some sleight of hand.

This attack is mitigated with WebAuthn and passkeys. We really should stop using passwords and TOTPs (archived). Password managers will not suggest a password for a domain not recognized, but that will not stop the individual from searching for it and copying it out-of-bounds into the official looking experience.

Should the victim normally use TOTPs, or no second factor at all, the threat actor will succeed and gain access to applications and resources accessible to the victim.

Some SSO vendors allow for another Identity Provider (IdP) to participate in the authentication process (see below). Normally, with this extension, the authenticating individual is redirected from the SSO vendor to another site for credential entry. After successful credential verification, the individual is redirected back to the SSO portal to access their applications and resources. All these redirects are confusing, difficult to follow for the individual, and enable novel phishing techniques that abuse trust.

AWS as an IdP, SSO, and application

We briefly covered how AWS can be an identity provider, SSO portal, and be an application in its own SSO portal. This relationship is somewhat unique in its concerning execution. When an individual selects an AWS Account, role, and clicks on command line setup, a modal comes up that shows secrets in plain text with intent to copy and paste elsewhere. While the instructions are clear and convenient, it enables out-of-bounds credential sharing of AWS resources.

How does AWS authenticate that a CLI process is tied to the same individual that authenticated in the browser?

It cannot.

This next detail took me by surprise: the AWS CLI dynamically registers an OIDC client. This makes forensic analysis difficult and introduces more complexity.

I can only guess that AWS uses dynamic registration to avoid having to create any special handling for the AWS CLI SDK — it can be treated just the same as any other application. It feels over engineered to me.

By denying preferential treatment to the AWS CLI SDK, the individual user has no way to differentiate authorizing an honest application and malicious application. That said, public clients cannot strongly attest to being honest or malicious.

In the last section on AWS, Jenko showed how the AWS CLI SDK misuses device auth codes to authenticate and authorize the process (see above). Not only are device auth codes phishable, there are safer ways to exchange access credentials.

It would be safer if AWS switched to using a localhost redirect with PKCE. However, it would make life difficult for engineers that are three layers deep with SSH to authorize their sessions to use AWS resources.

And for that, I recommend AWS invest in OpenSSH and AWS SSM mechanisms to extend trust within bounds, instead of out-of-bounds. Google Cloud Platform's cloud shell provides a safer environment to run command line applications authenticated and authorized with resources you can access. AWS has a CloudShell too, but hardly anyone knows it exists.

Complexity intensifies

At the end, Jenko brought up a slide that looked like a network cabinet.

He shared how a serious Facebook vulnerability was found because of multiple cross-protocol and cross-domain interactions.

Combining technologies together like this increases complexity and makes it harder for implementers to examine the security of the whole process. Implementers are focused on the small connections rather than the overall authentication picture. It takes a cross-functional security engineer, security researcher, or threat actor to find vulnerabilities in complex systems that chain many parties and protocols together.

Final thoughts

Authentication and Authorization frameworks are complicated piecewise standards designed by committees to assemble into a whole that appears compatible with internet technologies. While each piece has its own security review and considerations, it is up to the implementor to examine the security of the whole system.

Large organizations have not been proactive at reviewing the security of their whole implementations. They have a tendency to make complex solutions which increase the difficulty of internal review. Without cross-functional analysis and accountability, large organizations will continue to create systems that can be misused and vulnerable to new threats. Cross-functional principal security engineers with complete technical reach and understanding should oversee and regularly assess the security risks of their identity systems. If they can motivate their organization to produce simpler systems, they will better understand and address the risks of the whole implementation.

Complexity must be reduced and new protocols should be researched to facilitate and better fit existing workflows, rather than compose pieces of independently well built but unrelated components.

Talks like SSO Sloppy, SSO Suspect, SSO Vulnerable make me want to attend DEF CON again and again. It was engaging, taught me new details in areas I was already familiar with, and helped me feel better equipped to evaluate security concepts in the future.