Pentesting ELBs – Where Vulnerabilities Hide in Plain Sight

One of the hardest parts of AWS pentesting is accounting for the complexities of each service. This is especially true for Elastic Load Balancers (ELBs), which despite having a straightforward attack surface, still have several nuances that can create serious security vulnerabilities.

Even in mature environments, we frequently find application components unintentionally exposed via these mechanisms.

What are Elastic Load Balancers?

Load balancers are used to distribute network and application traffic to targets within an AWS workload. They provide an easy and scalable way to route traffic across multiple resources such as EC2, ECS, EKS and more.

ELB vs ELBv2

ELBv2’s, also referred to as ALBs, provide a number of functional improvements over ELB “Classic” load balancers. These new features are a key focus of today’s topic.

Notable features include:

• Path-based routing.
• Parameter based routing.
• Hostname routing.
• Source IP based routing

The Overlooked Attack Surface

ELBs support HTTP(S), Websocket, and TCP interfaces, but finding them all so they can be properly pentested can be tricky.

Failing to analyze ELBs is the first common mistake in AWS pentests. Listing IP addresses is not a sufficient way to pentest AWS workloads.

A First Step to Analyze ELBs

When creating an inventory of load balancers, it’s important to make sure of the following:

• List both elb and elbv2 assets configured as public-facing.
• List those assets in all other active regions.
• Fully construct all listeners with [scheme + elb + port]

But we still have a few more important steps..

Extracting Virtual Hosts

It’s also critical to be aware that ALBs support host-based routing, effectively creating virtually-hosted applications. These can only be found by listing all ALBs and analyzing the rules associated with each listener.

One ALB can route traffic to multiple targets using names such as:

https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com
https://my-load-balancer.example.com
https://secret-admin-dashboard.example.com

Listing Path-based Routes

In addition to host-based routes, ALBs support routing based on URL paths and query parameters. URL routes can be used to serve completely different targets in a workload:

https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com
https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com/interesting-app/
https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com/secret-admin-dashboard/

Query-based Routing

It’s also possible to create query-based routes as well as IP-based, so looking out for these lesser used options is important as well.

https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com
https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com/?secret-admin-dashboard

Pentesting ELBs the Right Way

With an understanding of these features, we can now properly include the assets into a pentest.

List all Classic ELBs

Listing all ELBs is a region can be done simply with the following command:

aws elb describe-load-balancers

Note: this must be combined with a script to execute in all available regions. More on that below.

List all ALBs, Listeners, and Rules

Listing all ALBs will follow the same process using classic ELB. However, several more steps are needed:

1. List all load balancers
2. List all listeners for each load balancer
3. Describe rules for each listener https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-rules.html

Here’s a basic script to perform the steps above:

regions=$(aws ec2 describe-regions --query 'Regions[*].RegionName' --output text --profile $profile)
for region in $regions; do
    echo "Region: $region"
    load_balancer_arns=$(aws elbv2 describe-load-balancers --region $region --query 'LoadBalancers[*].LoadBalancerArn' --output text --profile $profile)
    for lb_arn in $load_balancer_arns; do
        dns_name=$(aws elbv2 describe-load-balancers --region $region --load-balancer-arns $lb_arn --query 'LoadBalancers[*].DNSName' --output text --profile $profile)
        echo "DNSName: $dns_name"
        echo "Load balancer ARN: $lb_arn"
        listener_arns=$(aws elbv2 describe-listeners --region $region --load-balancer-arn $lb_arn --query 'Listeners[*].ListenerArn' --output text --profile $profile)
        for listener_arn in $listener_arns; do
            aws elbv2 describe-rules --region $region --listener-arn $listener_arn --profile $profile
        done
    done
done

Other ELB Vulnerabilities

Care should also be taken to check load balancers for some other configuration issues.

Public-facing Load Balancer

Application components can be unintentionally exposed to the internet via this misconfiguration. ELBs support two modes, public-facing and private, where public-facing

ALB Does not Drop Invalid Headers

ALBs can be configured to normalize HTTP headers, adding a valuable security layer to prevent request smuggling attacks. Failure to enable this feature (disabled by default) can lead to potential abuse of downstream application layer components.

Weak Encryption Profile Supported

TLS policies can be customized for HTTPS listeners. ALBs allow for a selection of pre-defined schemes, while classic ELBs allow for more custom policies. Each of these should be evaluated to ensure the protocols and ciphers use strong encryption.

Failure to Implement Logging

ALBs are a valuable point of visibility to audit potential abuse of application components. Logging traffic is strongly recommended for maintaining comprehensive audit logs.

Conclusion

ELBs are just one of many AWS services commonly overlooked during security audits. Staying up to date on the nuances of each service is important to finding meaningful vulnerabilities in each workload.

For an overview of other AWS services, our complete guide can provide a better view of other AWS pentesting topics.