If you haven’t read about the ALBeast vulnerability and you’re using AWS ALB-protected applications, you might want to drop everything and follow along.
What is ALBeast?
In short, ALBeast is a vulnerability found in AWS Application Load Balancers (ALBs) that can expose applications to malicious use bad actors. An instance is vulnerable to ALBeast if:
- It accepts traffic from any source, not just the expected ALB.
- It skips a step when validating the authentication token from the ALB.
When this happens, attackers can bypass the ALB and directly access backend applications.
Imagine a web app running on an EC2 instance behind an ALB - that ALB is configured to authenticate users via OAuth. If the associated security group is configured to allow traffic from the public internet, an attacker could set up their own ALB and use it to mint a token that mimics a legitimate user. The attacker could send the token directly to the backend application hosted on the instance, potentially granting unauthorized access to sensitive data or or allowing attackers to take privileged actions.
How does this illegitimate token happen? After the initial OAuth flow with your IdP, the ALB issues a JSON Web Token (JWT) signed by Amazon (not your IdP) that represents that user. Your application receives these Amazon-signed tokens and must verify them before accepting traffic. With ALBeast, the attacker uses a separate ALB to mint a valid, Amazon-signed JWT that looks almost exactly like the ones from your ALB.
Per Amazon’s documentation, your application needs to check a non-standard JWT header that contains the ARN of (hopefully) your ALB. This step is easy to miss - it’s weird, as far as JWT auth goes. The more familiar a developer is with OAuth / JWTs, the more likely they are to skip this step. If they do, your application will trust JWTs minted by an ALBeast attacker, because they were signed by some Amazon ALB!
How could you prevent this behavior?
Developers aren’t always networking or security experts, and they often need help to properly configure infrastructure. As complex vulnerabilities make their way into the mix (like this one), it becomes clear that defense in depth is a necessary strategy to make sure that an incident doesn’t happen.
While ALBeast won’t impact everyone, it is easy to imagine a developer who sets up a security group incorrectly because they are assuming that the ALB’s authentication will ward off any potential attacker. As the referenced article points out, 15,000 out of 371,000 (4%) analyzed ALBs were impacted.
Two-tiered approach to defense in depth
A two-tiered approach to making sure ALB security groups were configured correctly could be implemented with Resourcely.
As a refresher, Blueprints are paved roads to production for developers. When considering a scenario where a developer is responsible for setting up an EC2 instance with an ALB, a Blueprint with security groups pre-defined for the ALB and EC2 instance could be automatically defined and linked, so that the user doesn’t need to worry about configured ingress rules correctly.
Compare and contrast this with users YOLOing random Terraform or (maybe) Terraform modules with little context, or worse yet: ClickOps (shudder).
If Blueprints proactively make sure developers are properly configuring security groups for ALBs, Guardrails are the backstop that prevent improperly configured security groups from making it into production.
Resourcely Guardrails are policies that run as part of change management, safeguarding your infrastructure. A Guardrail like the below could be implemented:
Note that this Guardrail has functionality that isn’t yet Generally Available to the public.
This Guardrail would evaluate if a security group allowed access to any traffic except for the load balancer. If that security group did, the associated PR would fail merging and the vulnerability itself wouldn’t be exploitable.
Security posture
There is no silver bullet to all of security. While Resourcely can help be a part of a proper defense in depth strategy, it would not have detected this vulnerability or automatically remediated it after it was detected (although we’re working on something for automatic remediation, and if you’re interested we want to hear from you).
However, if you had implemented these Blueprints and Guardrails, it is highly unlikely that you would ever be impacted by this vulnerability. The best kind of security, is the kind where you’re proactively mitigating risks instead of frantically responding to vulnerability findings.
To get started with Resourcely, sign up today and your first Blueprints are on us!
