ALBeast: a simple misconfiguration to a complete authentication bypass

Organizations are increasingly relying on services like AWS Application Load Balancers (ALBs) to manage their web traffic and secure their applications. AWS ALB provides a functionality for administrators to integrate with OAuth and OpenID compliant Identity providers(IdPs) to easily implement authentication and authorization for their applications.

However, recently Miggo Research discovered a new vulnerability, dubbed ALBeast, that allows threat actors to bypass these security controls on poorly configured applications hosted behind AWS ALB. The team has identified 15K applications that are susceptible to this vulnerability. In this blog, we will walk through the vulnerability, potential attack vector and discuss remediation strategies.

‍

AWS ALB Authentication Flow

AWS ALB provides a functionality to integrate social & corporate IdPs (Identity Providers) along with AWS Cognito, to perform authentication and authorization on behalf of the application.

Once the application administrator has created an OpenID Connect (OIDC) client on their IdP of choice and configured the AWS ALB to use the newly created client, the application flow is as follows

1. An unauthenticated user makes a request to the application. AWS ALB intercepts the requests and redirects the user to the configured IdP using OAuth code grant flow.
2. Once the user completes the authentication and approves the requested scopes, they are redirected back to the AWS ALB with the Oauth response code.
3. AWS ALB uses the OAuth response code to retrieve the access token and user details from the IdP.
4. AWS ALB sets an authentication cookie AWSELB and redirects the user to the original URI.
5. The Application Load Balancer validates the cookie and forwards the authenticated user info to the target application in the X-AMZN-OIDC-* HTTP headers. 
6. Step 5 repeats for the subsequent authenticated requests

‍

One of those headers, X-AMZN-OIDC-DATA is an base64 encoded JWT with the following format

{

   "alg": "<JWT algorithm>",

   "kid": "<unique identifier for JWK used to signing the JWT",

   "signer": "arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id", 

   "iss": "<issuer for example okta,google,etc>",

   "client": "<client for example ios, apk etc>",

   "exp": "<expiration time in ms>"

}

The Jason Web Token (JWT) payload contains the user claims received from the IdP user info endpoint.

{

   "sub": "<subject>",

   "name": "<user name>",

   "email": "<user email>",

   ...

}

JWT validation

There are three interesting aspects in the x-amzn-oidc-data JWT that are relevant to the vulnerability.

1. signer: Signer claim identifies that AWS ALB that signed the JWT token. This claim plays a significant role in this vulnerability as described below.
2. issuer: Issuer claim identifies the IdP that authenticated the user and provides the claims in the JWT body like sub, name and email.
3. (lack of) aud: According to the RFC 7519, the aud claim identifies the recipient of the JWT. While the claim is OPTIONAL, aud claim is important to differentiate the application for whom the JWT was created. This claim helps an application hosted at say, example.com to reject an otherwise valid JWT created for notexample.com

‍

When the target application receives the X-AMZN-OIDC-DATA header it must perform the standard JWT validations.

1. It MUST retrieve the JSON Web Key (JWK) identified by key-id (kid), and validate the JWT signature.
2. It MUST retrieve the expiry claim and ensure that the JWT hasn’t expired
3. It MUST validate the issuer and client before it can trust the user claims like sub, name and email.

Attack Vector

The ALBeast vulnerability stems from the improper validation of the AWS-specific header claim signer and misconfigured security groups. Since AWS ALB uses the common set of JWK Set (https://public-keys.auth.elb.region.amazonaws.com/<kid>)for all its customers, what stops an attacker to use their own AWS ALB to create an authorization JWT and use it on another application? 

Therein lies the attack as shown below.

‍

‍

An attacker can configure their own AWS tenant using AWS ALB and forge a token containing user claims of their choice. They will be able to use the forged token on the victim’s target application if it fails to

1. Configure their application to only accept traffic from its Application Load Balancer. AWS has recently provided the following recommendations - “Also, as a security best practice we recommend you restrict your targets to only receive traffic from your Application Load Balancer. You can achieve this by configuring your targets' security group to reference the load balancer's security group ID.” src
2. Implement additional JWT validation to ensure that the signer is an expected AWS ALB. AWS has recently added the following recommendation “To ensure security, you must verify the signature before doing any authorization based on the claims and validate that the signer field in the JWT header contains the expected Application Load Balancer ARN.” src

‍

Unless AWS customers that use AWS ALB for Authentication and Authorization follow these recommendations, they remain susceptible to the ALBeast vulnerability. 

In addition to that, there are some general best practices that can help mitigate this class of vulnerabilities:

1. aud claim:JWT tokens should use the aud claim to identify the target application (the Resource Server in OAuth terms). This allows the target application to verify that the JWT presented by the user was specifically created for it.
2. Separate JWK Set per customer: Creating separate JWK Set per customer would also help isolate JWTs per AWS tenant. Most IdPs already do that.

Impact

The ability to forge a JWT token presents a significant security risk with potentially devastating consequences. If an attacker is able to forge a valid token, they can impersonate any user, effectively gaining the same access and permissions as that user. This opens the door to a range of malicious activities, such as performing actions on the victim's behalf . They can also elevate a user’s permission/scope or impersonate a user with administrator privileges to exfiltrate sensitive data and perform unauthorized operations. Depending on the target application, this vulnerability can potentially be used to completely bypass all authentication and authorization controls.

Recommendations

Applications that use AWS ALB for authentication and authorization should immediately update their AWS configurations to restrict traffic from their Load Balancers only, and update their application code to validate JWT, especially the signer claim.

‍

At Traceable, we are continuously monitoring for the latest Application Security threats to ensure that our customers are protected against those vulnerabilities or attacks. When the vulnerability was announced, we rapidly developed and deployed appropriate protection mechanisms. As of 22nd November, 2024, all Traceable customers are protected against ALBeast. Customers can also look for blocked exploitation attempts via our OmniTrace Engine.