A vulnerability in Amazon Web Service’s Application Load Balancer could allow an attacker to bypass access controls and compromise web applications, new research highlights. This issue arises not from a software defect, but from the manner in which AWS users configure authentication with Application Load Balancer.
Security experts argue that the setup of implementation measures is critical to cloud security, similar to how an unsecured safe offers no protection despite its robust build. Researchers at security firm Miggo discovered that the configuration of the Application Load Balancer’s authentication might allow an attacker to manipulate its connection to third-party corporate authentication services, thereby accessing the target web application and potentially viewing or stealing data.
According to the researchers, over 15,000 publicly accessible web applications potentially have such vulnerable configurations. However, AWS contends that this figure is an overestimate, claiming that only “a small fraction of a percent” of AWS customers might have such misconfigurations. AWS has reportedly contacted each affected customer to recommend safer configurations. It is important to note that AWS does not have direct access to its clients’ cloud infrastructures, hence these figures are purely estimative.
The issue was flagged by Miggo researchers while assisting a client. “This was discovered in real-life production environments,” stated Miggo CEO Daniel Shechter. He described observing “weird behavior” in a customer’s system where the validation process appeared incomplete, highlighting the complex interdependencies between customers and vendors.
To execute the attack, an attacker would first create an AWS account and an Application Load Balancer, then proceed to sign their own authentication token. Subsequently, they would modify settings to make it appear as if the victim’s authentication service endorsed the token. Afterward, the attacker would trick AWS into authenticating the token as genuinely issued by the victim’s system, allowing unauthorized access to the application. This tactic hinges on finding a misconfigured, publicly available application or one to which the attacker already has access, aiming to elevate their system privileges.
Amazon Web Services states that token forgery is not considered a vulnerability in the Application Load Balancer, attributing it to an anticipated result when authentication is set up in a specific manner. Nevertheless, after Miggo researchers reported their findings in early April, AWS updated their documentation to refine their Application Load Balancer authentication guidance. Updates included advice issued on May 1 about adding validation steps before token signing. On July 19, AWS further advised customers to restrict their systems to only accept connections from their Application Load Balancer using “security groups.”
AWS spokesperson Patrick Neighorn conveyed in a WIRED interview: “Referring to this as an authentication and authorization bypass of AWS Application Load Balancer (ALB) or another AWS service is misleading because it requires the bad actor to have direct access to a misconfigured application that doesn’t authenticate incoming requests. We urge customers to set up their applications only to accept requests from their ALB and to follow the ALB security best practices.”
The adjustments AWS introduced are considered effective against the attack vector outlined by the Miggo researchers. However, these are dependent on AWS customers adjusting their own setups, as they are not automatic updates like software patches that could be globally applied by developers. AWS users with susceptible configurations need to become aware of the new guidelines, acknowledge their relevance, and implement the necessary changes themselves.
Under what’s known as the Shared Responsibility Model, these situations often reside in a murky area between what a cloud platform provider is expected to handle for its clients and what users must manage on their own. Although this ambiguity has been around for years, there are instances where no clear-cut solution exists to ensure every cloud customer maintains the precise security measures they need and desire.
