[Traditional Chinese version | English Version ]

Hey there! This is my research on Apache HTTP Server presented at Black Hat USA 2024. Additionally, this research will also be presented at HITCON and OrangeCon. If you’re interested in getting a preview, you can check the slides here:

Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!

Also, I would like to thank Akamai for their friendly outreach! They released mitigation measures immediately after this research was published (details can be found on Akamai’s blog).

TL;DR

This article explores architectural issues within the Apache HTTP Server, highlighting several technical debts within Httpd,including 3 types of Confusion Attacks, 9 new vulnerabilities, 20 exploitation techniques, and over 30 case studies. The content includes, but is not limited to:

How a single ? can bypass Httpd’s built-in access control and authentication.

How unsafe RewriteRules can escape the Web Root and access the entire filesystem.

How to leverage a piece of code from 1996 to transform an XSS into RCE.

Outline

Before the Story

How Did the Story Begin?

Why Apache HTTP Server Smells Bad?

A Whole New Attack — Confusion Attack1. Filename ConfusionPrimitive 1-1. Truncation1-1-1. Path Truncation

1-1-2. Mislead RewriteFlag Assignment

Primitive 1-2. ACL Bypass

2. DocumentRoot ConfusionPrimitive 2-1. Server-Side Source Code Disclosure2-1-1. Disclose CGI Source Code

2-1-2. Disclose PHP Source Code

Primitive 2-2. Local Gadgets Manipulation!2-2-1. Local Gadget to Information Disclosure

2-2-2. Local Gadget to XSS

2-2-3. Local Gadget to LFI

2-2-4. Local Gadget to SSRF

2-2-5. Local Gadget to RCE

Primitive 2-3. Jailbreak from Local Gadgets2-3-1. Jailbreak from Local Gadgets

2-3-2. Jailbreak Local Gadgets to Redmine RCE

3. Handler ConfusionPrimitive 3-1. Overwrite the Handler3-1-1. Overwrite Handler to Disclose PHP Source Code

3-1-2. Overwrite Handler to ██████ ███████ ██████

Primitive 3-2. Invoke Arbitrary Handlers3-2-1. Arbitrary Handler to Information Disclosure

3-2-2. Arbitrary Handler to Misinterpret Scripts

3-2-2. Arbitrary Handler to Full SSRF

3-2-3. Arbitrary Handler to Access Local Unix Domain Socket

3-2-4. Arbitrary Handler to RCE

4. Other VulnerabilitiesCVE-2024-38472 - Windows UNC-based SSRFTriggered via HTTP Request Parser

Triggered via Type-Map

CVE-2024-39573 - SSRF via Full Control of RewriteRule Prefix

Future Works

Conclusion

Before the Story

This section is just some personal murmurs. If you’re only interested in the technical details, jump straight to — How Did the Story Begin?

As a researcher, perhaps the greatest joy is seeing your work recognized and understand by peers. Therefore, after completing a significant research with fruitful results, it is natural to want the world to see it — which is why I’ve presented multiple times at Black Hat USA and DEFCON. As you might know, since 2022, I have been unable to obtain a valid travel authorization to enter the U.S. (For Taiwan, travel authorization under the Visa Waiver Program can typically be obtained online within minutes to hours), leading me to miss the in-person talk at Black Hat USA 2022. Even a solo trip to Machu Picchu and Easter Island in 2023 couldn’t transit through the U.S.(

To address this situation, I started preparing for a B1/B2 visa in January this year, writing various documents, interviewing at the embassy, and endlessly waiting. It’s not fun. But to have my work seen, I still spend a lot of time seeking all possibilities, even until three weeks before the conference, it was unclear whether my talk would be cancelled or not (BH only accepted in-person talks, but Thanks to the RB, it could ultimately be presented in pre-recorded format). So, everything you see, including slides, videos, and this blog, was completed within just a few dozen days.

As a pure researchers with a clear conscience, my attitude towards vulnerabilities has always been — they should be directly reported to and fixed by the vendor. Writing these words isn’t for any particular reason, just to record some feelings of helplessness, efforts in this year, and to thank those who have helped me this year, thank you all :)

How Did the Story Begin?

Around the beginning of this year, I started thinking about my next research target. As you might know, I always aim to challenge big targets that can impact the entire internet, so I began searching for some complex topics or interesting open-source projects like Nginx, PHP, or even delved into RFCs to strengthen my understanding of protocol details.

While most attempts ended in failure (though a few might become topics for next blog posts ), reading these codes reminded me of a quick review I had done of Apache HTTP Server last year! Although I didn’t dive deep into the code due to the work schedule, I had already “smelled” something not quite right about its coding style at that time.

So this year, I decided to continue on that research, transforming the “bad smells” from an indescribable “feeling” into concrete research on Apache HTTP Server!

Why Apache HTTP Server Smells Bad?

Firstly, the Apache HTTP Server is a world constructed by “modules,” as proudly declared in its official documentation regarding its modularity:

Apache httpd has always accommodated a wide variety of environments through its modular design. […] Apache HTTP Server 2.0 extends this modular design to the most basic functions of a web server.

The entire Httpd service relies on hundreds of small modules working together to handle a client’s HTTP request.Among the 136 modules listed by the official documentation, about half are either enabled by default or frequently used by websites!

What’s even more surprising is that these modules also maintain a colossal request_rec structure while processing client HTTP requests. This structure includes all the elements involved in handling HTTP, with its detailed definition available in include/httpd.h. All modules depend on this massive structure for synchronization, communication, and data exchange. As an HTTP request passes through several phases, modules act like players in a game of catch, passing the structure from one to another. Each module even has the ability to modify any value in this structure according to its own preferences!

This type of collaboration is not new from a software engineering perspective. Each module simply focuses on its own task. As long as everyone finishes their work, then the client can enjoy the service provided by Httpd. This approach might work well with a few modules,but what happens when we scale it up to hundreds of modules collaborating — can they really work well together?🤔

Our starting point is straightforward —the modules do not fully understand each other, yet they are required to cooperate. Each module might be implemented by different people, with the code undergoing years of iterations, refactors, and modifications. Do they really still know what they are doing? Even if they understand their own duty, what about other modules’ implementation details? Without any good development standards or guidelines, there must be several gaps that we can exploit!

A Whole New Attack — Confusion Attack

Based on these observations, we startedfocusing on the “relationships” and “interactions” among these modules. If a module accidentally modifies a structure field that it considers uniform, but is cruel for another module, it could affect the latter’s decisions. Further, if the definitions or semantics of the fields are not precision enough, causing ambiguities in how modules understand the same fields, it could lead to potential security risks as well!

From this starting point, we developed three different types of attacks, as these attacks are more or less related to the misuse of structure fields. Hence, we’ve named this attack surface “Confusion Attack,” and the following are the attacks we developed:

Filename ConfusionDocumentRoot ConfusionHandler ConfusionThrough these attacks, we have identified 9 different vulnerabilities:

CVE-2024-38472- Apache HTTP Server on Windows UNC SSRF

CVE-2024-39573- Apache HTTP Server proxy encoding problem

CVE-2024-38477- Apache HTTP Server: Crash resulting in Denial of Service in mod_proxy via a malicious request

CVE-2024-38476- Apache HTTP Server may use exploitable/malicious backend application output to run local handlers via internal redirect

CVE-2024-38475- Apache HTTP Server weakness in mod_rewrite when first segment of substitution matches filesystem path

CVE-2024-38474- Apache HTTP Server weakness with encoded question marks in backreferences

CVE-2024-38473- Apache HTTP Server proxy encoding problem

CVE-2023-38709- Apache HTTP Server: HTTP response splitting

CVE-2024-??????- [redacted]

These vulnerabilities were reported through the official security mailing list and were addressed by the Apache HTTP Server in the 2.4.60 update published on 2024-07-01.

As this is a new attack surface from Httpd’s architectural design and its internal mechanisms, naturally, the first person to delve into it can find the most vulnerabilities. Thus, I currently hold the most CVEs from Apache HTTP Server . it leads to many updates that are not backward compatible. Therefore, patching these issues is not easy for many long-running production servers. If adm