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

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 

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 

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 

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 

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 

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 

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 

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. 

Natalia Trojanowska Senior IT Security Consultant