SSO Sloppy, SSO Suspect, SSO Vulnerable- 16 min read - Text Only
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.
This year, Jenko presented about risks on protocol complexities, trust chains, attack chains, and cobbling together web APIs.
He warned that it would be 80 minutes of content in a mere 39. We had a lot to go through.
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.
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.
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?
This next detail took me by surprise: the AWS CLI dynamically registers an OIDC client. This makes forensic analysis difficult and introduces more complexity.
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.
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.
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.