During their penetration tests (pentests), our security analysts at usd HeroLab repeatedly uncover vulnerabilities that pose significant risks to corporate security. They increasingly encounter the same vulnerabilities. Our blog series "Top 3 Vulnerabilities" presents them and provides tips on how to avoid them - for #moresecurity across all IT assets.
Today we look at the three most common security-critical vulnerabilities that our analysts have identified in single sign-on (SSO) penetration tests in recent years.
Why SSO Pentests?
More and more companies are using single sign-on (SSO) to manage access to their services and applications. This involves outsourcing the authentication or authorization process to a trusted third party. In a typical use case, this enables end users to log in to different services with the same access data. This offers the advantage that users do not have to remember different access data for each service.
Security gaps in the set up single sign-on infrastructure can have serious consequences. In the worst case, an attacker can bypass the entire authentication process, posing a significant risk to the confidentiality and integrity of the data processed by the applications. Reputational and image damage, as well as compensation payments, are possible consequences. In the worst case, this can bankrupt a company.
Security vulnerabilities in single sign-on implementations usually arise because developers lack an in-depth understanding of the internal workings of the various SSO technologies, such as OAuth, OpenID Connect or SAML. If you try to develop the complex standards of SSO technologies yourself, security gaps are usually inevitable. Therefore, various off-the-shelf solutions are often used that have already implemented the functionalities. However, in our SSO pentests, we found that such solutions often contain security vulnerabilities as well. For example, they are increasingly used in an insecure configuration. In addition, additional security features are often disregarded because the solution works fine without them.
Through our SSO pentesting, we have already helped many customers identify security issues in their SSO implementations and take appropriate countermeasures. We have compiled the vulnerabilities that we have identified most frequently in recent years in this article.
Insufficiently Validated Redirect URI
In OAuth and OpenID Connect, a user who wants to log in to an application is directed to an Identity Provider or Authorization Server via an Authorization / Authentication (AuthN) request. This is where the actual login process is carried out. The AuthN request contains a redirect URI that determines which endpoint the user should be redirected to after logging in. An example AuthN request for an identity provider might look like this:
https://idp.com/auth/protocol/openid-connect/auth?client_id=hb1L0ayT5mOagt10Ct&redirect_uri=https%3A%2F%2Fexample.com%2Fredirect&response_mode=query&response_type=code&scope=openid
The redirect URI is set to https://example.com/redirect. After a successful login, the user would be redirected to this endpoint. If this URL is not configured sufficiently strictly, or is not sufficiently checked by the identity provider, then this results in a serious security problem, as sensitive OAuth parameters are transmitted to this URL. Depending on the chosen OAuth flow, the identity provider will generate an OAuth 2.0 code or an access token and send it to this URL. In the following example, the redirect URI in the AuthN request is set to a domain controlled by the attacker:
https://idp.com/auth/protocol/openid-connect/auth?client_id=hb1L0ayT5mOagt10Ct&redirect_uri=https%3A%2F%2Flshthge0o7ngx81uryuse61mbdh45utj.burp.usd.de%2Fredirect&response_mode=query&response_type=code&scope=openid
If an attacker manages to get a legitimate user to call this AuthN request, the sensitive OAuth parameters are transmitted to the attacker. In the example shown, it can be seen in the logs of the server controlled by the attacker that the code parameter was successfully transmitted.
If an attacker obtains another user's code, this poses a security problem because an attacker could try to exchange this code for an access token with the identity provider or authenticate himself to the application as the other user. This is possible if no other protection mechanisms are used to prevent such an authorization code injection attack. An example of this is described in the section Lack of PKCE protection mechanism for public clients.
Security tip: To protect against this attack, the identity provider should always be configured so that forwarding is only permitted to a fixed URI. Wildcards should always be avoided in the URL.
Missing PKCE Protection Mechanism for Public Clients
PKCE (Proof Key for Code Exchange) is a protection mechanism for OAuth and OpenID Connect that prevents Authorization Code Injection attacks by creating a link between AuthN Request and the redemption of codes in the Token Request. Without PKCE, it is possible for anyone to redeem a code via a token request in a public client. This allows attackers to exchange a stolen code for an access token for the compromised user without any further hurdle. This is particularly possible because a public client does not use client secret, or this is publicly known. For example, a token request in which a code is exchanged for an access token looks like this:
As can be seen in the request, no other secret values are needed to redeem the code. If an attacker gets hold of another user's code, he can simply redeem it himself. The code can be stolen in various ways, such as inadequate referrer configurations, cross-site scripting attacks, or an insufficiently validated redirect URI. If the code was stolen by an administrative user, then the attacker has access to all resources of that admin through the access token obtained.
PKCE can complicate or prevent such an authorization code injection attack by having to send an additional secret, the code_verifier, with the token request. This is the original image of its counterpart code_challenge, which is the SHA256 hash of the code_verifier. The code_verifier itself is initially randomly generated by the service provider. During the AuthN request, the service provider then calculates the code_challenge and transfers it as a parameter. In addition, the code_challenge_method parameter is transmitted with the value S256 (for SHA-256). One such AuthN request, which uses PKCE, is shown below:
https://idp.com/auth/protocol/openid-connect/auth?client_id=app&redirect_uri=https%3A%2F%2Fvulnerable-service-provider.com%2Fauth&response_mode=query&response_type=code&scope=openid&code_challenge=6BAUM6cUUJUniEQGssx1Zu-NDFxs7buuZaNIpRaEy8k&code_challenge_method=S256
A request to redeem a code would then have to look like this in order for it to be accepted by the identity provider:
The identity provider would only accept the token request if the SHA256 hash matches the code_verifier dercode_challenge originally transmitted in the AuthN request. Through this mechanism, an attacker is unable to exchange a stolen code for an access token, as an attacker usually has no knowledge of the code_verifier.
Security tip: We recommend using the PKCE mechanism in OAuth and OpenID Connect implementations. There are already many libraries and frameworks that provide an easy way to do this. Depending on the respective implementation, it must also be configured on the identity provider that PKCE is to be used and enforced.
Unvalidated SAML Response
The Security Assertion Markup Language (SAML) is a standardized single sign-on protocol that uses XML signatures and can be used to authenticate end users. Similar to OpenID Connect, a service provider can outsource the login process to an identity provider (IdP). After the user has authenticated with the identity provider, the latter generates a SAML response, which the end user then transmits to the service provider. This SAMLResponse contains all the necessary authorization information for the service provider. This includes, for example, the user's name and other attributes such as group memberships or permissions. To ensure the integrity and authenticity of the SAMLResponse and the information it contains, the SAMLResponse is signed in whole or in part by the IdP. In this way, after the signature(s) have been correctly verified, the service provider can be sure that the user attributes contained there are correct and trustworthy.
However, if the service provider does not properly verify the signature(s), attackers can create their own SAML responses and control their contents in whole or in part. This can allow attackers to gain unauthorized access to applications or escalate their privileges by changing their attributes.
We regularly identify that an application does not validate the SAMLResponse correctly in our pentests. A typical attack scenario is to remove the signature element from the SAML response.
A SAMLResponse issued by the IdP can look decoded as follows (abbreviated):
This SAMLResponse contains an <Signature>element that signs the elements to be protected, such as username or permissions. Since this signature is sent by the user to the service provider independently, it can be removed by an attacker. In addition, the user's permissions can be changed via his group membership. In the following example, this has been set to ADMIN.
If the service provider accepts this manipulated SAMLResponse and thereby authenticates and authorizes the user, there is usually a critical vulnerability in which attackers can escalate their privileges at will.
Security tip: It is essential for security that service providers check the signature of a SAMLResponse correctly. The user may only be authenticated and authorized if the signature is correct.
Let's Sum It Up
Protecting single sign-on solutions is key in the context of enterprise cybersecurity. Misconfigurations or vulnerabilities in the implemented solution can have far-reaching consequences, including loss of confidentiality, integrity, and availability of application and user data. Fixing vulnerabilities such as insufficiently validated redirect URI, missing PKCE protection mechanism for public clients, and unvalidated SAMLResponse is therefore essential.
Our Single Sign-On penetration tests (SSO Pentest) are specifically designed to uncover and mitigate these and other vulnerabilities. They provide the necessary expertise and proactive measures to improve security and resilience against evolving cyber threats. Contact us, we will be happy to help you.
