AWS Amazon Vulnerability CVE-2024-8901 and CVE-2024-10125

 AWS Amazon Vulnerability

CVE-2024-8901 and CVE-2024-10125 highlight significant vulnerabilities related to the AWS Application Load Balancer (ALB) and its integration with OpenID Connect (OIDC) authentication mechanisms in various applications, including Kubeflow and ASP.NET Core deployments. Below is a detailed examination of these vulnerabilities, their implications, and examples of how they can be exploited.

Overview of Vulnerabilities

CVE-2024-8901

• Affected Component: AWS ALB Route Directive Adapter for Istio
• Integration: Utilized in the open-source Kubeflow project for OIDC authentication.
• Issue: The adapter employs JSON Web Tokens (JWT) for authentication but lacks adequate validation for the signer and issuer.
• Impact: In scenarios where ALB endpoints are exposed to the internet, an attacker could craft a JWT signed by an untrusted entity. This would allow them to spoof OIDC-federated sessions, thereby bypassing authentication completely.

CVE-2024-10125

• Affected Component: Amazon.ApplicationLoadBalancer.Identity.AspNetCore Middleware
• Integration: Can be used in any ASP.NET Core deployment scenario, including Fargate, EKS, ECS, EC2, and Lambda.
• Issue: While this middleware performs signature validation on JWTs, it fails to validate the JWT issuer and signer identity.
• Impact: Similar to CVE-2024-8901, if the infrastructure allows internet traffic to the ALB targets (which is not recommended), an attacker could exploit this oversight to mimic valid OIDC-federated sessions.

Technical Details

How JWT Authentication Works

JWTs are widely used for authentication due to their compact nature and ease of use. They consist of three parts: header, payload, and signature. The signature is crucial as it verifies that the sender of the JWT is who it claims to be and ensures that the message wasn't changed along the way.

1. Header: Typically consists of two parts: the type of token (JWT) and the signing algorithm being used (e.g., HMAC SHA256 or RSA).
2. Payload: Contains claims about the user and other data.
3. Signature: Created by taking the encoded header, encoded payload, a secret key, and signing it using the specified algorithm.

Exploitation Scenario

In both vulnerabilities:

1. An actor sends a crafted JWT signed by an untrusted entity.
2. The application accepts this JWT due to inadequate validation checks on the issuer and signer.
3. The actor gains unauthorized access to resources or functionalities that should require valid authentication.

For example, in a Kubeflow deployment using CVE-2024-8901:

• An attacker could send a malicious JWT to access sensitive data or perform actions as if they were a legitimate user.

In an ASP.NET Core application using CVE-2024-10125:

• An attacker could impersonate a user by sending a forged JWT to gain access to restricted functionalities.

Mitigation Strategies

To mitigate these vulnerabilities:

1. Implement Stronger Validation:
   • Ensure that both issuer and signer are validated against trusted sources before accepting any JWT.
2. Restrict Internet Access:
   • Avoid exposing ALB targets directly to the internet unless absolutely necessary. Implement proper network security measures such as firewalls and VPNs.
3. Regular Security Audits:
   • Conduct regular audits of your authentication mechanisms and libraries in use to identify potential vulnerabilities.
4. Update Dependencies:
   • Keep all libraries and dependencies up-to-date with security patches provided by maintainers.

Conclusion

CVE-2024-8901 and CVE-2024-10125 underscore critical security flaws in AWS ALB's integration with OIDC authentication mechanisms in various applications. By understanding these vulnerabilities and implementing effective mitigation strategies, organizations can better secure their applications against potential exploitation.