Thousands of Web Apps at risk due to AWS configuration issue

Amazon web services has revised its guidelines for customers to implement AWS’s Application Load Balancer (ALB) more securely. However, it remains uncertain whether all users will be informed of these changes. Recent research has highlighted a vulnerability in the ALB service that could allow attackers to bypass access controls and compromise web applications. This issue arises from how customers configure the service, rather than a software flaw. Specifically, the vulnerability is linked to the way AWS users set up authentication with the ALB.
Implementation issues are crucial in cloud security, much like an armored safe is ineffective if left unlocked. Security firm Miggo discovered that depending on the ALB’s authentication setup, an attacker could manipulate the handoff to a third-party authentication service, potentially gaining access to sensitive web applications and data. The researchers identified over 15,000 web applications with potentially vulnerable configurations. However, AWS disputes this figure, claiming that only a small fraction of their customers might be affected. AWS has reached out to these customers to suggest more secure configurations. Since AWS lacks direct access to clients’ cloud environments, the exact number of vulnerable setups remains an estimate.
Miggo researchers encountered this issue while working with a client, observing unusual behavior in a system’s validation process. This discovery underscores the complex interdependencies between customers and vendors. To exploit the vulnerability, an attacker would create an AWS account and ALB, sign their authentication token, and then alter configurations to mimic the target’s authentication service. This would allow the attacker to have AWS sign the token as if it originated from the target’s system, granting them access to the application. The attack requires targeting a misconfigured, publicly accessible application or one to which the attacker already has access, enabling them to escalate privileges.
AWS maintains that token forging is not a vulnerability within ALB, as it results from specific authentication configurations chosen by users. After Miggo disclosed their findings in April, AWS updated its documentation twice to enhance ALB authentication recommendations. On May 1, AWS advised adding validation before ALB signs tokens, and on July 19, they recommended using “security groups” to restrict traffic to only their ALB. AWS spokesperson Patrick Neighorn stated that the issue is not an authentication bypass of ALB or any AWS service, as it requires a bad actor to have direct connectivity to a misconfigured application. AWS advises customers to configure applications to accept requests solely from their ALB and follow ALB security best practices.
The changes AWS implemented address the attack path identified by Miggo researchers. However, since these involve altering customer configurations, they are not akin to a software patch that can be universally applied. Customers with vulnerable setups must learn about the new guidance, recognize its relevance, and implement the changes themselves.
This situation highlights the complexities of the Shared Responsibility Model, where the division of security responsibilities between cloud providers and users can be ambiguous. While this model has been in place for years, it continues to present challenges in ensuring all cloud customers achieve the desired security configurations.