A vulnerability related to Amazon Web Service’s traffic-routing service known as Application Load Balancer could have been exploited by an attacker to bypass access controls and compromise web applications, according to new research. The flaw stems from a customer implementation issue, meaning it isn’t caused by a software bug. Instead, the exposure was introduced by the way AWS users set up authentication with Application Load Balancer.
Implementation issues are a crucial component of cloud security in the same way that the contents of an armored safe aren’t protected if the door is left ajar. Researchers from the security firm Miggo found that, depending on how Application Load Balancer authentication was set up, an attacker could potentially manipulate its handoff to a third-party corporate authentication service to access the target web application and view or exfiltrate data.
The researchers say that looking at publicly reachable web applications, they have identified more than 15,000 that appear to have vulnerable configurations. AWS disputes this estimate, though, and says that “a small fraction of a percent of AWS customers have applications potentially misconfigured in this way, significantly fewer than the researchers’ estimate.” The company also says that it has contacted each customer on its shorter list to recommend a more secure implementation. AWS does not have access or visibility into its clients’ cloud environments, though, so any exact number is just an estimate.
The Miggo researchers say they came across the problem while working with a client. This “was discovered in real-life production environments,” Miggo CEO Daniel Shechter says. “We observed a weird behavior in a customer system—the validation process seemed like it was only being done partially, like there was something missing. This really shows how deep the interdependencies go between the customer and the vendor.”
To exploit the implementation issue, an attacker would set up an AWS account and an Application Load Balancer, and then sign their own authentication token as usual. Next, the attacker would make configuration changes so it would appear their target’s authentication service issued the token. Then the attacker would have AWS sign the token as if it had legitimately originated from the target’s system and use it to access the target application. The attack must specifically target a misconfigured application that is publicly accessible or that the attacker already has access to, but would allow them to escalate their privileges in the system.
Amazon Web Services says that the company does not view token forging as a vulnerability in Application Load Balancer because it is essentially an expected outcome of choosing to configure authentication in a particular way. But after the Miggo researchers first disclosed their findings to AWS at the beginning of April, the company made two documentation changes geared at updating their implementation recommendations for Application Load Balancer authentication. One, from May 1, included guidance to add validation before Application Load Balancer will sign tokens. And on July 19, the company also added an explicit recommendation that users set their systems to receive traffic from only their own Application Load Balancer using a feature called “security groups.”
AWS spokesperson Patrick Neighorn tells WIRED in a statement: “It is incorrect to call this an authentication and authorization bypass of AWS Application Load Balancer (ALB) or any other AWS service because the technique relies on a bad actor already having direct connectivity to a misconfigured customer application that does not authenticate requests. We recommend customers configure their applications to only accept requests from their ALB by using security groups and by following the ALB security best practices.”
Taken together, the two changes AWS made effectively address the attack path the Miggo researchers proposed. But since they involve changing how AWS customers have set up their own systems, the fixes aren’t like a software patch that a developer can push out to all users. Instead, AWS users with vulnerable configurations must hear about the updated guidance, realize it is relevant to their configurations, and make the changes themselves.
Under what’s known as the Shared Responsibility Model, such situations often sit in the gray area between what a cloud platform provider should address for its customers and what users need to be in charge of managing themselves. And while this ambiguity has existed for years, there are some cases where there is still no obvious single solution for making sure that every cloud customer has the exact security setup they need and intend.
