CVE-2024-37082 - How Custom HAProxy Config Can Let Attackers Bypass mTLS in Cloud Foundry

In 2024, a tricky vulnerability (now logged as CVE-2024-37082) was discovered in deployments of Cloud Foundry using the haproxy-boshrelease. This security issue isn’t just a small config mistake. If you use route-services and set a certain custom property in HAProxy, someone could send specially crafted HTTP requests that skip mTLS (Mutual TLS) authentication—potentially letting unauthorized users talk to your apps as if they’d passed the right certificates.

Let's break it down step by step, see how it happens, and learn how you can keep your CF deployment safe.

You _might_ be vulnerable if

- You use Cloud Foundry with the haproxy-boshrelease.

Route-services are enabled (routing-release).

- HAProxy is set with ha_proxy.forwarded_client_cert: forward_only_if_route_service in your BOSH manifest.

What’s the Risk?

Anyone who can talk to your HAProxy (for example, the external world—usually via the public internet or your API gateway), could:

Technical Root Cause

Cloud Foundry’s default mTLS design expects the client certificate to be passed along if and only if the request is mTLS-authenticated. Route services sometimes require custom behavior, so forwarded_client_cert options let operators tweak how the X-Forwarded-Client-Cert (XFCC) header is handled.

When you set ha_proxy.forwarded_client_cert to forward_only_if_route_service, HAProxy will only forward the XFCC header if it detects a route service. But _the identification logic is weak_: attackers can craft a request making HAProxy believe it’s for a route service, even if it’s not. This allows them to sneak in a forged or blank XFCC header, sidestepping client cert validation.

Real-World Example: Attack Walkthrough

Let's walk through the dangerous config and see how an attacker could exploit it.

If you have something like this in your deployment manifest

jobs:
- name: ha_proxy
  properties:
    ha_proxy:
      forwarded_client_cert: forward_only_if_route_service

And your routes use route-services (e.g., for logging, header injection, etc.), you are potentially open to this bypass.

If request is for a route-service, HAProxy includes XFCC header (with the client cert chain).

- CF app/application uses the header to verify the client.

2. Bypassing mTLS with a Crafted Request

- Attacker crafts a HTTP request with a header or path suggesting it’s for a route-service (can be done multiple ways).

Suppose the following custom route exists for a route-service

GET /some-app-path HTTP/1.1
Host: my-app.system.example.com
X-Cf-Forwarded-Url: http://target-app/
X-Forwarded-Client-Cert:

If HAProxy mishandles the above route (by believing it’s a route-service request based on headers or pattern), the XFCC header passes along even for attackers who never presented a valid client certificate.

Simulated Exploit

Here’s a curl command that simulates a request _without_ any client certificate but with headers mimicking a route-service request:

curl -k -H "X-Cf-Forwarded-Url: http://target-app/" \
     -H "X-Forwarded-Client-Cert:" \
     https://my-app.system.example.com/

If the backend application correctly validates the header (preventing blank or forged XFCC), this fails. But if not, and your HAProxy passes XFCC in the above config, you’re wide open.

References

- CVE-2024-37082 – NVD Entry
- HAProxy BOSH Release Documentation
- Cloud Foundry Release Notes – Security Advisory
- Routing Release Config and Route-Services
- Cloud Foundry XFCC Header Docs

## What Should You Do? (Fix/Remediation)

1. Set ha_proxy.forwarded_client_cert to sanitize_set (the default)

ha_proxy:
  forwarded_client_cert: sanitize_set

This ensures XFCC is only set if there’s a real mTLS connection and automatically drops/overwrites any forged headers coming from outside.

Look for the latest fixes

- haproxy-boshrelease > v11.4.
- routing-release with mitigations for this bug

3. Audit Downstream Apps

Verify that backend apps don’t blindly trust XFCC or other identity headers—they must be validated securely!

Final Thoughts

Misconfiguration of Cloud Foundry and its HAProxy layer can have broad consequences. Mutual TLS is only secure if all hops enforce it and no free-passing of trusting headers happens between the entry proxy and the downstream applications.

This bug is a perfect reminder: double-check every "advanced" auth setting, especially in complex microservices and PaaS setups like Cloud Foundry. When in doubt, stick to secure defaults—and always follow the Cloud Foundry Security Updates.

Stay patched, safe, and double-check those headers!

*If you want a deeper code analysis, read the HAProxy BOSH source for forwarded client cert logic.*

Timeline

Published on: 07/03/2024 06:15:03 UTC
Last modified on: 07/12/2024 17:15:10 UTC