According to security researchers, up to 15,000 AWS apps are vulnerable due to a misconfiguration of the Application Load Balancer. AWS provides advice on how to use the tool.

Security firm Miggo discovered the vulnerability in AWS while onboarding a customer. The vulnerability lies in the Application Load Balancer, a tool that automatically distributes incoming network traffic across web applications and servers to prevent overload. After looking deeper into the tool, Miggo researchers discovered how attackers can trigger an authentication failure via load balancers.

The vulnerability may be due to a misconfiguration of the tool on the customer side rather than a bug in the software. To exploit the system, an attacker would set up an AWS account and an Application Load Balancer and then have them sign an authentication token. The attacker then makes configuration changes to make it appear as if the target’s authentication service issued the token to access the target application.

15,000 vulnerable apps

Because the security researchers discovered this configuration in a live customer environment, they suspected that additional AWS customers might be vulnerable without realizing it. According to the researchers, at least 15,000 AWS apps are vulnerable. This is an estimate based on analysis of publicly available customer applications.

AWS somewhat disputes that this number is so high. In a response to Wired, the cloud provider said that only “a small fraction of one percent of AWS customers have applications that may be misconfigured in this way.” Again, this is only an estimate: AWS says it does not have access to its customers’ cloud environments and therefore cannot provide an exact number.

The cloud provider further explains that this is not an authentication error in the tool itself, as the attacker must have already gained direct access to the application in order to exploit the vulnerability. The problem cannot be solved with a simple patch. AWS has made some adjustments to its Application Load Balancer guide as it has been informed of possible misconfigurations.

Among other things, customers are recommended to set up additional validation before Application Load Balancer can approve authentication tokens. A final addition to the guide was made on July 19, when it added the explicit recommendation to set up “security groups” so that systems only receive traffic from their own Application Load Balancer.

Shared responsibility

The incident is a prime example of the shared responsibility model in the public cloud. Cloud providers offer the necessary tools to secure the cloud environment, but it is the customer’s responsibility to set everything up correctly.

Companies sometimes forget this and assume that the vendor is responsible for security. As a result, they open the doors of their cloud environment wide without realizing it.