In early 2024, a new security vulnerability, CVE-2024-24795, was discovered in the widely-used Apache HTTP Server. This issue lets attackers use a technique called HTTP response splitting. The bug can lead to HTTP desynchronization attacks if an attacker manages to insert malicious response headers into backend-talking applications or modules.

Severity: High
Fixed in: Apache HTTP Server 2.4.59

What Is HTTP Response Splitting?

HTTP response splitting happens when user-supplied data (like form fields or headers) aren't properly sanitized. An attacker tricks the server into injecting unexpected headers, or even content, in the response stream. This can cause clients or proxy servers to see two (or more) responses, one crafted by the attacker.

The danger escalates with HTTP desynchronization attacks: A client or proxy gets tricked by these split responses, opening paths for session hijacking, cache poisoning, web socket injection, and more.

Who’s At Risk?

If your Apache HTTP Server is linked to a backend app or a load balancer that might emit unsanitized headers—you are at risk. This bug affects various modules, including popular reverse proxy modules like mod_proxy, mod_proxy_fcgi, etc., when backends can be influenced to provide dangerous header values.

Let's break down an example

Scenario:
A backend app mistakenly lets user input set a response header, such as a cookie value. It doesn't sanitize for newline characters (\r\n).

Suppose you have a backend that sends

HTTP/1.1 200 OK
Set-Cookie: sessionid=abc\r\nX-Evil: hacked
Content-Type: text/html

<html>Safe content here</html>

But the value for sessionid came from unchecked user input. An attacker sends this crafted request

https://example.com/path?sessionid=1234\r\nX-Evil: hacked

Apache (before 2.4.59) doesn’t detect/remove the embedded newline (\r\n). So, the proxy passes the whole string as literal headers, sending:

Set-Cookie: sessionid=1234
X-Evil: hacked

This means the attacker injects a new response header! Downstream proxies or clients see ambiguous responses, leading to:

1. Vulnerable Backend Flask Application

from flask import Flask, request, make_response

app = Flask(__name__)

@app.route('/')
def index():
    sessionid = request.args.get('sessionid', 'guest')
    resp = make_response('<h2>Hello, user!</h2>')
    resp.headers['Set-Cookie'] = sessionid  # ⚠️ DANGEROUS!
    return resp

if __name__ == '__main__':
    app.run(port=900)

Simple config

ProxyPass / http://localhost:900/
ProxyPassReverse / http://localhost:900/

Send

GET /?sessionid=legituser%d%aX-Desync:attack HTTP/1.1
Host: victim.com

Decoded, %d%a → CR (\r) and LF (\n). It means the value is

Set-Cookie: legituser
X-Desync:attack

4. Result

The attacker has now inserted a rogue header (X-Desync: attack) into the Apache server's response. Depending on client/proxy setup, this can break sessions or inject harmful headers.

To see if you’re vulnerable

1. Use a proxy (like Burp Suite) to inject encoded CR/LF (%d%a) into params that end up as HTTP headers.

Apache Security Advisory:

https://httpd.apache.org/security/vulnerabilities_24.html

CVE Report:

https://nvd.nist.gov/vuln/detail/CVE-2024-24795

HTTP Response Splitting OWASP:

https://owasp.org/www-community/attacks/HTTP_Response_Splitting

Upgrade Announcement:

https://httpd.apache.org/docs/current/new_features_2_4.html

1. Upgrade Apache HTTP Server to 2.4.59 NOW!

sudo apt-get update && sudo apt-get install apache2
# Or download and build the latest from source

Never let user input get into HTTP headers unescaped.

- Add WAF rules to detect/control for CR and LF in values.

Strip or encode any CR (\r) and LF (\n) in backend data.

- Consider header whitelist/blacklist rules for reverse proxies.

Conclusion

CVE-2024-24795 is a critical issue for anyone running Apache HTTP Server with backend connectivity. If you let user input into backend-generated headers, and your web server is not patched, you open yourself to HTTP response splitting/desynchronization attacks.

Patch now, audit your backend apps, and always remember: validate and sanitize ALL user input!

For more info and updates, keep an eye on the Apache security page.

Timeline

Published on: 04/04/2024 20:15:08 UTC
Last modified on: 11/12/2024 20:35:08 UTC