As many as 15,000 applications using Amazon Web Services’ (AWS) Application Load Balancer (ALB) for authentication are potentially susceptible to a configuration-based issue that could expose them to sidestep access controls and compromise applications.
That’s according to findings from Israeli cybersecurity company Miggo, which dubbed the problem ALBeast.
“This vulnerability allows attackers to directly access affected applications, particularly if they are exposed to the internet,” security researcher Liad Eliyahu said.
ALB is an Amazon service designed to route HTTP and HTTPS traffic to target applications based on the nature of the requests. It also allows users to “offload the authentication functionality” from their apps into the ALB.
“Application Load Balancer will securely authenticate users as they access cloud applications,” Amazon notes on its website.
“Application Load Balancer is seamlessly integrated with Amazon Cognito, which allows end users to authenticate through social identity providers such as Google, Facebook, and Amazon, and through enterprise identity providers such as Microsoft Active Directory via SAML or any OpenID Connect-compliant identity provider (IdP).”
The attack, at its core, involves a threat actor creating their own ALB instance with authentication configured in their account.
In the next step, the ALB is used to sign a token under their control and modify the ALB configuration by forging an authentic ALB-signed token with the identity of a victim, ultimately using it to access the target application, bypassing both authentication and authorization.
In other words, the idea is to have AWS sign the token as if it had actually originated from the victim system and use it to access the application, assuming that it’s either publicly accessible or the attacker already has access to it.
Following responsible disclosure in April 2024, Amazon has updated the authentication feature documentation and added a new code to validate the signer.
“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,” Amazon now explicitly states in its documentation.
“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.”
The disclosure comes as Acronis revealed how a Microsoft Exchange misconfiguration could open the door to email spoofing attacks, allowing threat actors to bypass DKIM, DMARC, and SPF protections and send malicious emails masquerading as trusted entities.
“If you didn’t lock down your Exchange Online organization to accept mail only from your third-party service, or if you didn’t enable enhanced filtering for connectors, anyone could send an email to you through ourcompany.protection.outlook.com or ourcompany.mail.protection.outlook.com, and DMARC (SPF and DKIM) verification will be skipped,” the company said.
Update
When reached for comment, an AWS spokesperson told The Hacker News that the issue is not a vulnerability and disputed Miggo’s characterization of the issue as a security bypass –
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. A small fraction of a percent of AWS customers have applications potentially misconfigured in this way, significantly fewer than the researchers’ estimate. We have contacted each one of these customers directly to share best practices for configuring applications which use ALB.
