ALBeast Security Advisory by Miggo Research

Miggo Research identifies over 15,000 potentially impacted applications using AWS ALB

For a more detailed technical analysis of how we hunted down ALBeast, please visit The Hunt for ALBeast: A Technical Walkthrough.

Executive Summary

Miggo Research identified a critical configuration-based vulnerability, dubbed ALBeast, affecting applications that utilize AWS Application Load Balancer (ALB) for authentication. This flaw can facilitate authentication and authorization bypass in applications exposed to the internet that relies on ALB’s authentication mechanisms.
‍

This AuthN/AuthZ bypass can compromise affected applications' confidentiality, integrity, and availability. Threat actors can exploit impacted applications by leveraging this configuration-based vulnerability, leading to unauthorized access to business resources, data breaches, and data exfiltration.
‍
On April 6th, Miggo Research reported the issue to the AWS security team and has been collaborating with AWS throughout the disclosure and mitigation process.
‍
On May 1st, AWS updated the authentication feature documentation and added new code to validate the signer—the AWS ALB instance that signs the token. This new code requires impacted customers to take steps to implement the change. AWS also updated the documentation with the following:
“To ensure security, you must verify the signature before doing any authorization based on the claims and validate that the signer field in the JWT header contains the expected Application Load Balancer ARN.”
‍
‍On July 19th, 2024, AWS updated the authentication feature documentation to clarify best practices for Security Groups:“Also, as a security best practice we recommend you restrict your targets to only receive traffic from your Application Load Balancer. You can achieve this by configuring your targets' security group to reference the load balancer's security group ID.”
Since discovering ALBeast, Miggo Research has identified over 15,000 (out of 371,000*) potentially vulnerable ALBs and applications using AWS ALB’s authentication feature. We arrived at the 15,000 instance conservative estimate by scanning all IPv4 addresses in the AWS public range that responded with ALB headers and with an indication that the authentication feature of the ALB was enabled. This scan revealed 15,000 potentially vulnerable unique IP addresses; we assume there are more. We’ve done our best to contact each affected organization with our findings and provide support where needed.
‍
Since Miggo publicly disclosed ALBeast on August 20, AWS has asserted that it is incorrect to call ALBeast an authentication and authorization bypass of ALB or any other AWS service because the technique relies on a bad actor having access to a misconfigured customer application that does not authenticate requests.

We agree! That’s why we call it a configuration-based vulnerability. The problem remains that even with the suggested configuration changes that AWS added to the documentation, customers still need to change their code implementation to be protected. This exemplifies the cracks in the shared responsibility model, which is the “lightning in the cloud” that no one wants to talk about. If possible, CSPs should amend their product to minimize the required customer modifications. Just updating the documentation is not enough. Simply put, if an application uses the ALB authentication feature and does not follow the two new best practices added to the documentation, then it remains vulnerable.

‍

How Can An Attacker Exploit ALBeast?

The animation below demonstrates how an attacker can exploit ALBeast against an organization and achieve an authentication bypass with the highest permissions.

First, the attacker creates their own ALB instance with authentication configured in their account. The attacker then uses this ALB to sign a token they fully control. Next, the attacker alters the ALB configuration and sets the issuer field to the victim's expected issuer. AWS subsequently signs the attacker's forged token with the victim's issuer. Finally, the attacker uses this minted token against the victim's application, bypassing both authentication and authorization.

‍

Are You Vulnerable To ALBeast?

AWS does not consider issuer forging an ALB vulnerability and has stated that the service operates as intended. They highlighted the shared responsibility model, suggesting that customers should ensure their code and configurations are up-to-date to mitigate this issue.

‍

What Should You Do To Mitigate The Risk Of ALBeast?

To mitigate the risk of ALBeast, Miggo Research recommends following these two important configuration requirements:

Verify that every application using the ALB authentication feature checks the token signer.
Restrict your targets to accept traffic only from your Application Load Balancer.

AWS has updated their ALB authentication docs to reflect these new configuration requirements.

‍

Where Does ALBeast Fall Within The Shared Responsibility Model?

The shared responsibility model divides security responsibilities between cloud providers like AWS and their customers. Within this framework, AWS is responsible for securing the infrastructure that runs all offered services, while customers are responsible for securing their data, managing user access, and configuring AWS services. Over the years, the shared responsibility model has drawn criticism for the confusion it creates over where cloud provider responsibilities end and those of customers begin.

You Are Responsible For Ensuring Your Apps Adhere To The Updated AWS docs

For ALBeast, AWS has stated that the shared responsibility model places the onus on customers to ensure their applications comply with the updated documentation. Applications still using AWS’s previous guidance remain vulnerable.

‍

All Applications Using ALB User Authentication Are Potentially Vulnerable to ALBeast

Issuers are not meant to be secret. To exploit the vulnerability, an attacker only needs to know the claims and issuer expected by the target application. This information is often easily accessible through an application’s publicly available /.well-known/openid-configuration endpoint.

Any application that has not been updated using the ALB user authentication with direct access could be vulnerable. Even applications not exposed to the internet can potentially be attacked by an entity with network access, compromising internal network authorization mechanisms.

For these reasons, Miggo Research strongly appeals to AWS users to follow the new AWS user authentication docs. If you need assistance mitigating their vulnerability or would like us to perform a security scan, we invite you to schedule a meeting with one of our experts.

“ALBeast underscores the risks associated with distributed application architecture and the need for a new class of detection methods to prevent similar exploits." - Daniel Shechter, CEO and Co-founder, Miggo

How Distributed Architecture Creates New Avenues for Attack

Microservice architecture delegates many responsibilities and functions to non-native infrastructure components and third-party services. While this approach simplifies and accelerates the development process, it also poses several new security challenges.

Security teams must ensure that all functionalities are correctly implemented across all applications to reduce the potential for repeated errors in distributed architectures. However, this complicates an application’s trust model. For example, risk arises when one component assumes that another has adequately validated inputs. This assumption may result in inconsistencies between expected and actual data handling or infrastructure and deployment configurations. Given the ever-changing nature of modern applications, these discrepancies pose significant risks.

"Without Miggo Security, I can’t help but wonder how long ALBeast would have remained undetected. Given the source of this vulnerability and the fact that ALBeast impacted thousands of customers is an industry wake-up call while further highlighting the danger of supply chain vulnerabilities.

We need to be vigilant in understanding and applying good security practices ourselves, but also be realistic that companies like large cloud providers can have flaws that have devastating effects on their customers. Adopting security by design, implementing guardrails against risky configurations, and continuously learning and adapting remain key tenets of defense strategy.

In a sea of application security specialists, Miggo has proven capable of supporting these principles while helping to uncover many oversights."- Han Chae, Head of Security at HyperScience

How Can You Detect And Respond to Exploitable Attack Chains Before An Attacker Reaches Them?

The ALBeast vulnerability discovered by Miggo Research poses a considerable threat, yet it remained undetected across thousands of applications behind AWS ALB for years. Most security tools are blind to applications' inner workings during runtime and cannot map out interactions between an application's distributed services or pinpoint potential weaknesses.

The challenge lies in the decentralized nature of modern applications, where multiple microservices interact across numerous networks and environments.

This distribution makes monitoring and correlating application activities difficult, obscuring possible security threats that can exploit crucial components within their architectures. It doesn’t help that many attacks are propagated through seemingly benign interactions across multiple services.

Traditional tools can’t separate these fragmented signals and their malicious intent from legitimate traffic.

‍

Discover Your Application Flows and Map Weaknesses in Minutes with Miggo

The only way to catch security issues like ALBeast and attackers across today’s distributed application architecture is by understanding application behaviors from within.

Miggo’s Application Detection and Response (ADR) platform is the first solution to address these challenges. We’ve accomplished this by offering real-time insights and context-aware analysis into the live application.

Miggo surfaces your applications' inner architecture, maps how components interact, and detects possible weak areas. Miggo also detects attacks as they happen without false positives by leveraging a deep comprehension of application behavior.

Book a demo to learn more, or contact us today for emergency application breach support.

"Traditional security practices—monitoring network, endpoint, and host activity—have long been the cornerstone of enterprise defense. But in the absence of real-time, comprehensive application visibility, they keep falling short against sophisticated application layer threats like authentication bypasses and supply chain attacks. Miggo addresses this gap with its Application Detection and Response solution, delivering the critical defense mechanism we need to secure vital applications against emerging threats." - Matt Hurwitz, Director of Application Security at Best Buy

‍

*According to Censys, there are over 371,000 instances of AWS ALB worldwide.

Want to learn more? Find more materials about ALBeast, the shared responsibility model and how Miggo can help: