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 disputes that the token forging could have been carried out in this way and says that the changes the researchers are describing are an expected outcome of choosing to configure authentication in a particular way that would not allow bypass. 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.”
