CVE-2024-10125 in Amazon.ApplicationLoadBalancer.Identity.AspNetCore
Summary
by MITRE • 10/22/2024
The Amazon.ApplicationLoadBalancer.Identity.AspNetCore repo https://github.com/awslabs/aws-alb-identity-aspnetcore#validatetokensignature contains Middleware that can be used in conjunction with the Application Load Balancer (ALB) OpenId Connect integration and can be used in any ASP.NET http://asp.net/ Core deployment scenario, including Fargate, EKS, ECS, EC2, and Lambda. In the JWT handling code, it performs signature validation but fails to validate the JWT issuer and signer identity. The signer omission, if combined with a scenario where the infrastructure owner allows internet traffic to the ALB targets (not a recommended configuration), can allow for JWT signing by an untrusted entity and an actor may be able to mimic valid OIDC-federated sessions to the ALB targets.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2024
The vulnerability identified as CVE-2024-10125 resides within the Amazon.ApplicationLoadBalancer.Identity.AspNetCore middleware component that facilitates integration between Application Load Balancers and OpenID Connect authentication systems. This middleware serves as a critical bridge between AWS infrastructure and ASP.NET Core applications deployed across multiple compute environments including Fargate, EKS, ECS, EC2, and Lambda. The security flaw manifests in the JWT token processing logic where the middleware performs signature validation but neglects to validate the issuer identity and signer authenticity, creating a significant security gap in the authentication flow.
The technical implementation of this vulnerability stems from the middleware's incomplete validation process that focuses solely on cryptographic signature verification while completely omitting issuer validation checks. This omission creates a scenario where an attacker could potentially forge JWT tokens that appear legitimate to the middleware, as the system accepts tokens signed by untrusted entities. The flaw specifically impacts the OpenID Connect authentication flow where the ALB acts as an identity provider proxy, and the middleware is responsible for validating tokens received from the ALB before forwarding them to backend applications. According to CWE-347, this represents a weakness in cryptographic signature validation where the system fails to properly verify the authenticity of the signing entity.
The operational impact of this vulnerability is particularly severe when considering that many infrastructure deployments allow internet traffic to ALB targets, a configuration that the AWS documentation explicitly discourages. In such environments, an attacker who gains access to the ALB target network could potentially intercept and manipulate JWT tokens, enabling them to impersonate legitimate OIDC-federated sessions. This compromise allows unauthorized actors to gain access to protected resources that would normally require proper authentication through the OpenID Connect flow, effectively bypassing the security controls that should protect these applications. The vulnerability essentially creates a man-in-the-middle attack vector where an untrusted entity can produce valid-looking authentication tokens that the middleware will accept without proper issuer verification.
Security practitioners should recognize this issue through the ATT&CK framework's T1566.001 technique related to credential access through valid accounts and T1071.004 for application layer protocol usage. The vulnerability's exploitation requires minimal network access to the ALB targets and leverages the trust relationship between the ALB and the middleware. Mitigation strategies should focus on implementing proper issuer validation within the middleware, ensuring that all tokens are validated against known and trusted identity providers. Organizations should also enforce strict network segmentation to prevent direct internet access to ALB targets, implement additional authentication layers, and consider upgrading to versions of the middleware that properly validate issuer identities. Additionally, security monitoring should be enhanced to detect anomalous authentication patterns that might indicate token forgery attempts, and regular security assessments should verify that all authentication components properly validate the complete token chain including issuer verification.