A critical configuration bug was observed that affects applications using the AWS Application Load Balancer (ALB) for authentication, a flaw dubbed "ALBeast" that could lead to unauthorized access to business resources, data breaches, and data exfiltration.
Miggo Research said in an Aug. 20 blog post that since discovering ALBeast this spring, the research team has identified more than 15,000 potentially vulnerable apps using the AWS ALB authentication feature.
The AWS load balancer distributes incoming application traffic across multiple targets, such as AWS EC2 web services instances. The ALBeast flaw can cause authentication and authorization bypass in applications exposed to the internet that rely on ALB authentication.
Liad Eliyahu, research lead at Miggo, explained that AWS ALB has an authentication feature that was released in 2018 that includes a few features and documentation for customers on how to implement it securely. However, Eliyahu said the team discovered that the documentation was missing two crucial parts, causing applications to be vulnerable.
First, it was missing a validation of which ALB actually signed the token. Eliyahu said the Miggo team scanned numerous implementations of open-source projects as well as ALB authentication guides written by the community, and only one out of dozens mentioned this validation. “The team then assumed that almost all programmers did not include this validation in their code,” said Eliyahu.
Second, Miggo found a misconfiguration in the security groups that AWS claims to identify and notify customers about. Eliyahu said according to numerous sources, this is one of the most common AWS misconfigurations.
“We suggested that AWS perform a change in the ALB implementation that can mitigate most of the ALBeast issues on their side,” said Eliyahu. “They chose not to change their implementation, but to reach out to customers and inform them about these two actions they should take.”
A blog AWS released six days ago included these security best practices:
- Restrict ALB targets to receive traffic only from trusted sources: Configure the target’s security groups to accept traffic exclusively from the ALB. Teams can accomplish this by referencing the security group of the ALB when setting the inbound rules for the target security group. By doing so, the team can effectively restrict access to targets, thus making sure that only the ALB can initiate connections to the targets. Deploy ALB targets in private subnets without public IP addresses or Elastic IP addresses. This prevents direct access to the targets from the public internet.
- Implement signature validation for the JSON Web Token (JWT) provided in the requests from the ALB, and confirm the
signerfield from the JWT header matches with the Amazon Resource Name (ARN) of the ALB.
Jason Soroko, senior vice president of product at Sectigo, added that the configuration issue with AWS ALB arises not from a flaw in the ALB itself but from how it’s configured by users. Soroko said the issue involves improper authentication setups, where apps fail to validate the token signer or mistakenly accept traffic from sources other than their ALB, thus allowing unauthorized access to resources and data exfiltration.
“Security teams should ensure that their apps properly verify tokens and restrict traffic to only trusted sources, particularly their ALB,” said Soroko. “AWS continuously improves documentation on this to help people responsible for configuration to understand the risks, but it would be prudent to also look at diagnostic tools available from Amazon AWS as well as third party tools to help catch these kinds of configuration mistakes.”
