Full Report
As a precursory, I really don't like how this article is written. It takes more time to hype up the bug and the companies work than actually explain the vulnerability. Additionally, the vulnerability write up is all over the place and hard to fully grasp. Most of the time, I wouldn't write up an article like this but given that its an interesting JWT issue within AWS, I felt it was worth having around. Please don't write articles that are this vendor heavy, name the bug and/or over hype the issue; I just want to understand the vulnerability and move on with my day. The Amazon Application Load Balancer (ALB) is used to distribute app traffic to various services on EC2, operating at Layer 7. AWS allows developers to configure the ALB to do the authentication for them through various different methods. For the application, it ends up verifying a JWT signed by AWS in some capacity. This was after a request was made to the SSO provider itself. When looking at the example code for the JWT verification, they noticed that this was using a region specific JWT. Given that all apps built on the ALB would use the same signer, this was a little off-putting. A common JWT issue with SSO is not checking the aud field, which this did not have. According to the documentation, developers should verify the signer and iss (IdP URL) field within the JWT to determine if it's the proper application. When submitting the JWT in the x-amzn-oidc-data header, the ALB simply removes and strips the header making this an unviable attack. They realized that direct requests to the server instead of going through the ALB were susceptible to this attack. All they had to do was get a JWT for an application in one region then use this JWT on a different application, using the ALB as a signing oracle. The authors were curious if they could forge the issuer of the request in some way. Changing the issues in the OIDC configuration failed but they noticed an interesting quirk of how the system worked. There are multiple requests being made: one for the session between the ALB and the user and the headers derived from the session/configuration sent from the ALB to the application. Their goal was to desync the users session from the application receiving after the ALB. The load balancer creates an encrypted cookie called the AWSELBAuthSessionCookie that corresponds to a particular user and app. If a cookie was gathered and the ALB configuration was changed, then the cookie expired, it would have to mint a new token. Crazily enough, the issuer was taken from the new configuration and not from the cookie itself. This allowed the, to forge the issuer, bypassing an existing protection of the JWT. What are the full exploit steps? Assuming an application that was exposed to the internet and didn't check the signer fields, this is what you would do: Create an ALB with the target region with one IdP. Mint a token with the desired OIDC claims with our controlled IdP. Reconfigure the ALB to use the target applications issuer. Once the token expires (only a single minute), refresh it to get a JWT with the incorrect issuer. Send the token to the target application and circumvent the IdP. App validates the JWT and we're operating with a forged token. Overall, a good find but way overhyped tbh. It's always fun to see the ol' switcheroo work on an application though. It's worth checking out these types of bugs even in modern apps!
Analysis Summary
# Vulnerability: ALBeast - AWS ALB Authentication Bypass
## CVE Details
- **CVE ID**: N/A (AWS primarily addressed this through documentation updates and service-side hardening rather than a specific CVE assignment).
- **CVSS Score**: Estimated 8.1 (High)
- **CWE**: CWE-287 (Improper Authentication), CWE-345 (Insufficient Verification of Data Origin)
## Affected Systems
- **Products**: Applications using AWS Application Load Balancer (ALB) for Authentication (OIDC or Amazon Cognito).
- **Versions**: All implementations prior to the May 1, 2024 documentation update.
- **Configurations**:
- Applications exposed directly to the internet (bypassing the ALB).
- Applications that do not validate the `signer` field in the `x-amzn-oidc-data` JWT header.
- Applications missing strict Security Group rules to only allow traffic from the ALB.
## Vulnerability Description
ALBeast is a technical flaw in how applications verify JWTs signed by AWS ALB. Because all ALBs in a specific region use a shared public key server to sign tokens, an application cannot rely solely on the token's signature to prove it came from *their* ALB.
Key technical issues include:
1. **Signing Oracle**: An attacker can spin up their own AWS ALB, configure a malicious Identity Provider (IdP), and "mint" a validly signed AWS JWT containing arbitrary claims.
2. **Issuer Forgery**: By manipulating the ALB configuration and timing the token expiration (1-minute window), an attacker can force the ALB to sign a token where the `iss` (issuer) field matches the victim's expected provider, even if the underlying session was controlled by the attacker.
3. **Lack of Audience (`aud`) Field**: AWS ALB JWTs lack an `aud` field, which standard OIDC implementations usually use to ensure a token was intended for a specific application.
## Exploitation
- **Status**: PoC available (detailed in research).
- **Complexity**: Medium (Requires AWS infrastructure to act as a signing oracle and precise timing).
- **Attack Vector**: Network (Remote).
## Impact
- **Confidentiality**: High (Bypass authentication to access sensitive data).
- **Integrity**: High (Assume arbitrary user identities and modify data).
- **Availability**: Low (Primary impact is unauthorized access).
## Remediation
### Patches
- This is a configuration and implementation flaw. AWS updated service documentation and best practices on May 1, 2024. Developers must update their code manually.
### Workarounds
- **Security Groups**: Configure application instances to **only** accept traffic from the ALB’s Security Group. This prevents "direct-to-task" attacks where the attacker bypasses the ALB entirely.
## Detection
- **Signer Validation**: Ensure code explicitly validates that the `signer` field in the JWT header matches the expected ALB Amazon Resource Name (ARN).
- **Audit Logs**: Review access logs for requests to application ports originating from IPs outside the expected Load Balancer range.
## References
- AWS ALB User Authentication Documentation: [https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#user-claims-encoding](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#user-claims-encoding)
- Miggo Research: [https://www.miggo.io/post/uncovering-auth-vulnerability-in-aws-alb-albeast](https://www.miggo.io/post/uncovering-auth-vulnerability-in-aws-alb-albeast)