The year in review: the most interesting Single Sign-On vulnerabilities of 2023

Check out a summary of 2023’s most interesting Single Sign-On vulnerabilities, and make sure your company is not vulnerable to last year’s security misconfigurations.

Single Sign-On cybersecurity threats landscape in 2023

Setting New Year’s resolutions is a time-honored tradition. Yet, my approach is somewhat different — instead of planning for next year, I prefer to reflect on the past one. Looking back to 2023, I have noticed a lot of intriguing vulnerabilities related to Single Sign-On, which I have decided to summarize in this article. It will feature:

• Two security misconfigurations in cloud environments,
• An unpatched design flaw in GCP,
• Two cases of web application vulnerabilities in OAuth and OpenID Connect integrations,
• A GCP vulnerability leading to the creation of unremovable trojan apps,
• A cryptographic vulnerability allowing for Azure B2C authentication bypass,
• My favorite vulnerability I found during a pentest in 2023 — Okta misconfiguration.

BingBang in Microsoft Entra ID Single Sign-On

Type: Security misconfiguration
Exploitation conditions: The target application must use Microsoft Single Sign-On with the multitenant option enabled.
Exploitation results: Authentication bypass
References: BingBang: AAD misconfiguration led to Bing.com results manipulation and account takeover | Wiz Blog
Keywords: Microsoft Entra ID (Azure Active Directory), authentication bypass, multitenant

When configuring Single Sign-On with Microsoft Entra ID, it is possible to choose who will be able to access the target application:

Whereas only users from a specific organization will be able to log in to a single tenant application, configuring a multitenant application means users from other organizations will also be able to authenticate. If this is not our desired outcome, we should validate a user’s identity or a token’s issuer in the application.

The BingBang research showed that 25% of identified multitenant applications were vulnerable to authentication bypass, including a Bing Trivia app, which allowed to alter Bing search results.

DeleFriend — a hidden security threat in Google Cloud’s Domain-Wide Delegation

Type: Design flaw (unpatched)
Exploitation conditions: A GCP user with iam.serviceAccountKeys.create permission (e.g., Editor).
Exploitation results: Privilege escalation from GCP to GWS with an access to scopes of the compromised Domain-Wide delegation.
References: DeleFriend: Severe design flaw in Domain Wide Delegation could leave Google Workspace vulnerable for takeover (hunters.security)
Keywords: Google Cloud Platform (GCP), Google Workspace (GWS), privilege escalation

DeleFriend resolves around Google’s Domain-Wide Delegation feature, which makes it possible for GCP identities to perform actions in GWS applications, such as Gmail, Google Calendar, or Google Drive.

Due to a design flaw, a GCP user with an Editor role can compromise existing delegations by creating new access keys for service accounts.

Even though scopes available for a specific delegation are not listed for the Editor, it is possible to brute-force their names and request a valid token, leading to unauthorized access to GWS APIs.

nOAuth — the case of mutable OAuth claims

Type: Application vulnerability
Exploitation conditions: The target application must use Microsoft Single Sign-On with the multitenant option enabled and identify the user based on email claims.
Exploitation results: Authentication bypass
References: nOAuth: How Microsoft OAuth Misconfiguration Can Lead to Full Account Takeover (descope.com), Migrate away from using email claims for user identification or authorization — Microsoft identity platform | Microsoft Learn
Keywords: Microsoft Entra ID (Azure Active Directory), OpenID Connect (OIDC), authentication bypass, multitenant

According to the OAuth specification, the user should always be identified by the sub (subject) claims. The Identity Provider (IdP) is obliged to provide an identifier that is immutable and unique. Using any other claims, such as email or name, can lead to major security concerns, as they might be unverified, changed over time, or reused by different users.

Although it was discouraged in the Microsoft documentation, numerous cases were found in which vulnerable applications would use email claims to identify the user.

Since then, Microsoft has mitigated the issue for all new multitenant integrations. As of June 2023, email addresses with unverified domain owners are removed from the tokens by default. For older multitenant integrations, it is recommended to verify whether proper claims are used for authorization.

Misconfigured GitHub Actions in AWS and GCP

Type: Security misconfiguration
Exploitation conditions: Improper configuration of an OIDC integration between a CI/CD pipeline and a cloud provider.
Exploitation results: Unauthorized access to cloud resources.
References: Identifying vulnerabilities in GitHub Actions & AWS OIDC Configurations | by Tinder | Tinder Tech Blog | Medium, From GitHub to Account Takeover: Misconfigured Actions Place GCP & AWS Accounts at Risk — Rezonate
Keywords: OpenID Connect (OIDC), Google Cloud Platform (GCP), Amazon Web Services (AWS), GitHub Actions

Modern CI/CD pipelines, including GitHub Actions, are no longer integrated using access keys. Instead, they often utilize OIDC — which eliminates long-lived secrets and allows granular access management. To do so, we need to establish a trust relationship between a cloud provider and GitHub Actions by allowing the cloud to accept JWTs issued for a specific repository.

However, if the subject is not verified properly, we might end up giving access to our cloud to any GitHub Actions pipeline. Unfortunately, a secure setup can be counterintuitive, leading to exposed AWS and GCP resources.

After reading the above articles, I wondered why none of them mentioned Azure. I decided to check it by myself. The reason is that Azure provides a custom federated credential scenario for GitHub Actions, which makes you specify both the organization and the repository, leaving no room for a mistake.

Azure B2C Crypto Misuse leading to SSO bypass

Type: Cloud vulnerability (patched)
Exploitation conditions: The target application must use Azure B2C authentication. The attacker must know B2C tenant details (usually disclosed in the application’s JavaScript) and the victim’s email address.
Exploitation results: Access to any account in the application.
References: Azure B2C Crypto Misuse and Account Compromise — (praetorian.com), DEF CON 31 — Azure B2C 0Day — An Exploit Chain from Public Keys to Microsoft Bug Bounty — John Novak — YouTube
Keywords: Azure B2C, OAuth, cryptography, authentication bypass

Due to improperly applied cryptography, it was possible to craft a refresh token with any data for an Azure B2C instance. If set up with asymmetric keys (RSA), which is the most popular configuration, the refresh tokens are encrypted but not signed, providing confidentiality without integrity. A common practice would be to encrypt a JWS, known as Nested JWT, which also provides integrity.

Consequently, if the attacker knew the public key, they could generate a refresh token for any account and exchange it for an access token. However, public keys are not available publicly in Azure B2C — but it was possible to exfiltrate them using a time-based technique. The attack would take about 37 hours, which is entirely reasonable compared to the lifespan of a refresh token or the associated key.

The vulnerability has been patched in such a way that it is no longer possible to extract the public keys. However, rotating the previous key or switching to symmetric cryptography instead is still worth considering.

GhostToken — a trojan horse in Google accounts

Type: Cloud vulnerability (patched)
Exploitation conditions: The victim must authorize a third-party OAuth application to access their account.
Exploitation results: Unremovable and invisible backdoor to the victim’s account, with access depending on permissions that the victim gave to the malicious application.
References: GhostToken — Exploiting GCP application infrastructure to create invisible, unremovable trojan app on Google accounts — Astrix Security, DEF CON 31 — GhostToken Exploiting Google Cloud Platform to Create Unremovable Trojan Apps — Skverer — YouTube
Keywords: Google Cloud Platform (GCP), post-exploitation

As we know, it is important to verify the OAuth permissions we grant to third-party applications, ensuring that they are not excessive, and that an application is trustworthy. We also rely on the ability to revoke access at any time if we stop using the application or simply change our mind. However, there was a flaw in Google’s process. The GhostToken vulnerability allowed attackers to conceal their malicious application from the victim’s application management page by deleting the associated GCP project. This action caused the app to enter the pending deletion state, but it could be restored. Afterward, the attacker could request a new access token with the previous refresh token and hide the application again.

The vulnerability has been fixed. Currently, the application management page also includes apps that are pending deletion.

Oh-Auth and the importance of verifying audience in SSO integrations

Type: Application vulnerability
Exploitation conditions: The victim must enter the attacker’s website and log in using Single Sign-On (e.g., with Facebook).
Exploitation results: The attacker can gain authenticated access to the target application, impersonating the victim.
References: Salt Labs | Oh-Auth — Abusing OAuth to take over milions of accounts
Keywords: OAuth, OpenID Connect (OIDC), authentication bypass

When an application uses JSON Web Tokens (JWTs), it is a common procedure to verify the signature and ensure it was signed by a trusted party. However, the same key can be used to sign all tokens issued by a specific Identity Provider. It means that different applications may receive tokens signed with the same key. Therefore, it is crucial to verify the audience of the token.

In this case, it led to the possibility of impersonating the victim by convincing them to authenticate in a different, seemingly harmless application and then reusing their token — which was possible in applications such as Grammarly or Vidio. Another possible outcome would be lateral movement between different corporate applications.

Bonus: Okta permission misconfiguration

As I was summarizing last year’s Single Sign-On vulnerabilities, I also decided to include the favorite one I found during my penetration test. It allowed me to escalate my privileges in a web application from a standard user to an administrator.

The application in scope used Okta Single Sign-On. There were multiple roles available (User, Manager, Admin). All actions, such as password change or MFA setup, were managed directly in the application. However, I knew that most Identity Providers have some kind of an Account Portal available for users. In the case of Okta, it is called Okta End-User Dashboard and can be accessed at the following URL address: https://{realmName}.okta.com/. It allows you to manage your credentials, request additional apps, or change your personal details.

This time, something was different — instead of a standard set of information, I could also change my role, which I immediately set to Admin:

The modification was successful. After I logged in again, I was granted administrative access, effectively escalating my privileges.

The cause of the above issue was due to incorrectly set user permissions on a custom user attribute. The screenshot below features possible configurations:

It turns out that the user permissions were incorrectly set to Read-Write instead of Read Only or Hide, making it possible for a user to change their role by themselves.

Key takeaways from 2023’s Single Sign-On vulnerabilities

Reflecting on the Single Sign-On vulnerabilities of 2023, we can certainly observe an upswing in cloud security misconfigurations, leading to a significant risk impact. While cloud deployments might appear simple at a first glance and allow for a quick setup, they sometimes prove to be counterintuitive in terms of security. A proper configuration often requires a deep understanding of the product, particularly as the out-of-the-box solutions may not always meet our specific needs.

Moreover, authentication and identity management solutions are becoming increasingly complex. With all systems being interconnected, it is especially important to protect your primary accounts, as they can often provide access to a wide range of services.

It is no longer sufficient to analyze applications individually, as no system is an island anymore. We need to thoughtfully manage the whole archipelago.

It is crucial to follow best practices as well as refrain from using shortcuts and temporary fixes. Instead, try to automate, aiming towards Infrastructure-as-a-Code.

Given that each case and deployment is unique, it is important to stay vigilant and perform regular penetration testing assessments regarding both Single Sign-On integrations and cloud configuration.