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

Single Sign-On cybersecurity threats landscape in 2024 

Having completed my list of New Year’s IAM resolutions, it’s time to look back at the past year. 2024 was another interesting year for Single Sign-On (SSO) and Identity and Access Management (IAM). From a penetration tester’s perspective, things keep getting more exciting, as I love exploring complex vulnerabilities. However, this also means we need to take a closer look at our IAM practices, as creating secure systems and applications is becoming increasingly more complex and demanding. 

In this article, I will cover a bunch of different vulnerabilities, more or less related to Single Sign-On. This includes multiple security misconfigurations that you should definitely avoid in Microsoft Entra ID, as well as a new clickjacking technique targeted especially at OAuth consent prompts. I hope you will enjoy it! 

Connect with the author on LinkedIn!

UnOAuthorized: Privilege Elevation Through Microsoft Applications 

Every Microsoft application, like Exchange Online, is identified by a multi-tenant App Registration in Microsoft Entra ID. In the customers’ tenants, these applications are represented by corresponding Service Principals.  

Entra ID permits storage of credentials both in the App Registration (in this case, managed by Microsoft) and in the Service Principal (managed by the customer). They both can be used to perform an OAuth 2.0 client credential grant flow and then call Microsoft Graph using the acquired JWT. 

The research identified multiple cases of Microsoft App Registrations with excessive permissions that were not even listed among the available scopes, effectively leading to privilege escalation and gaining Global Administrator access. 

To mitigate this, it is possible to disable the client credentials flow for Service Principals using a feature called app instance property lock. 

When “Phish-Proof” Gets Hooked: Bypassing phishing resistance of Okta FastPass 

Okta Verify is a multifactor authentication app used to sign in to Okta or Okta-protected resources. It offers phishing resistance, meaning it should only proceed with authentication if the request is sent by a trusted origin. 

The research reviews the authentication flows used by the Okta Verify desktop app, including Loopback and Custom URL. In the Loopback flow, which is the default one, Okta Verify properly checks the Origin header in the HTTP request, which is supplied by the browser and cannot be changed using JavaScript. However, the fallback Custom URL flow, which is not based on an AJAX request and does not include the Origin header, failed to properly verify the origin of the request, making a phishing attack possible. 

As we are talking about Okta, there were also two other intriguing vulnerabilities discovered in 2024. The first one allowed attackers to bypass Single Sign-On policies with user agents that were classified as unknown (such as an uncommon browser or a Python script). The second vulnerability enabled complete authentication bypass if a username exceeded 52 characters and authentication cache was used, due to the fact that bcrypt was utilized in the cache. 

Meet Silver SAML: Golden SAML in the Cloud 

Many organizations use Entra ID as their identity provider, primarily relying on SAML for integrations. By default, Microsoft provides a self-signed certificate for signing SAML responses, which is non-exportable. However, it is also possible to opt for externally generated certificates, which are often not managed securely. It is common to generate certificates on client machines or web servers, as well as share them using insecure channels, like Teams or Slack. Gaining access to an externally generated certificate makes it possible to forge SAML responses and impersonate any account. 

The Silver SAML persistence technique has effectively shown us that, when it comes to SAML, we should exclusively use Microsoft-signed certificates generated within the Azure Portal. Since it’s not possible to export the private key, potential attackers won’t be able to steal it and use it for impersonating other accounts. 

Arbitrary 1-click Azure tenant takeover via MS application 

This is a new perspective on excessive redirect URIs in OAuth applications. A Microsoft first-party application was discovered to use an unregistered URL. It was a particularly interesting finding, since Microsoft applications often come pre-authorized and they don’t trigger the consent prompt. By taking control of the vulnerable domain, an attacker could achieve a tenant takeover if the victim with Global Admin privileges clicked the malicious link. 

Another interesting 2024 research about redirect URI takeover can be found here. 

DoubleClickjacking: A new era of UI redressing 

DoubleClickjacking is a new technique that can lead to victim unknowingly accepting an OAuth authorization prompt or performing one-click account changes. It exploits the brief interval between the first and second clicks in multiple windows. After the first click, the attacker’s site swaps in a sensitive window (e.g., an OAuth prompt), hijacking the victim’s second click. Surprisingly, the speed of the double-click doesn’t impact the success of the attack. 

The best way to understand the attack is by watching the demos included in the referenced blog post, which provides all the explanation one might need. I must say, the CAPTCHA Proof-of-Concept looks really convincing.  

From Zendesk to Slack 

Remember Ticket Trick? Here we go again!  

1. When a new email arrives at your company’s Zendesk, a ticket with an incremental ID is created. 
2. An attacker could gain access to any ticket if they knew its ID. They exploited this by CC’ing themselves on the email thread due to insufficient protections against email spoofing. 
3. Many companies use the same email domain for both employee and support emails (e.g., support@company.com), which can also be used to log in with Single Sign-On if an application uses Just-In-Time provisioning. 
4. You can sign up for other applications (e.g., Slack) using the company email. However, email confirmation is needed, which requires access to the inbox. Note that emails from noreply addresses are ignored by Zendesk, so it is not possible to register for Slack using standard registration. 
5. Attackers could bypass this restriction by creating a new Apple ID account. Apple sends confirmation emails from appleid@id.apple.com. Zendesk didn’t ignore such emails, so it was included in a new support ticket. An attacker could hijack this ticket, confirm the email, and gain access to the company’s Slack.

Really interesting, isn’t it? And so many Single Sign-On plot twists!

Google Email Verification bypass

To create a new Google Workspace account, you need to verify that you own the domain. However, a business logic vulnerability allowed attackers to bypass this step by registering the victim’s email and then using a different domain for verification. If the victim didn’t have a Google Workspace account before, the attacker could create one and log in on their behalf.  

After creating a new Google Workspace account, the attacker could use it to log in to other websites using Sign in with Google. If the victim was already registered, the attacker could take over their account. 

The vulnerability highlights the risks associated with applications that do not require Multi-Factor Authentication during the SSO logins. 

From ChatGPT plugins to account takeover 

The research explores the topic of ChatGPT plugins, focusing on the Single Sign-On aspect.   

Installing malicious plugins on ChatGPT users 

At the beginning of the OAuth login process, a random state value is generated. Once the user returns with an authorization code, the website should verify this state to make sure that the process was indeed started by the same user in the same place. In many cases, lack of state verification only allows an attacker to manipulate the victim into logging in with the attacker’s account if they click the link. However, in the case of ChatGPT plugins, clicking an attacker-supplied URL could result in installing a ChatGPT plugin on the victim’s account and linking it to attacker’s account. As a result, the malicious plugin could forward all victim’s conversations to the attacker. 

0-click account takeover on multiple plugins 

Due to an access control issue, it was possible to gain access to other users’ plugin integration details, including their OAuth authorization codes.  

Various SAML vulnerabilities in GitLab, GitHub Enterprise Server, Keycloak, and Ivanti 

It appears that SAML vulnerabilities don’t get old. They usually result either from misconfiguration or improper implementation of SAML integration in the client application (e.g., forgetting about XML comments—I still find such cases during pentests!). It gets even more interesting if we take a look at SAML libraries that deal with XML directly, as there are a lot of twists and turns. 

Check out the most interesting SAML CVEs from 2024: 

• GitLab: CVE-2024-45409 (Blog) 
• GitHub Enterprise Server: CVE-2024-4985 and CVE-2024-9487 (Blog), CVE-2024-6800 
• Keycloak: CVE-2024-8698 
• Ivanti: CVE-2024-21893, CVE-2024-22024 (Blog), CVE-2024-22023 

SAML – what can go wrong? Security check

Natalia Trojanowska-Korepta 2021.09.01 ·12 MIN czytania

Key takeaways from 2024’s Single Sign-On vulnerabilities 

Creating this list gave me a great chance to review Single Sign-On blog posts and make a list of my personal favorites. Some of these posts focus directly on SAML, OAuth, or OpenID Connect, while others use Single Sign-On to increase the impact of a vulnerability, changing the nature of the finding.  

This once again proves that Identity and Access Management security should be analyzed within the context of the entire system, rather than separately. I hope you enjoyed this (slightly long) list of great Single Sign-On vulnerabilities of 2024, and you are looking forward to next year—I know I do! 

Connect with the author on LinkedIn!

Natalia Trojanowska-Korepta Senior IT Security Consultant