Question

Slightly unorthodox question here:

I’m currently trying to break an Apache with a handful of custom modules.

What spawned the testing is that Apache internally forwards requests that it considers too large (e.g. 1 MB trash) to modules hooked in appropriately, forcing them to deal with the garbage data – and lack of handling in the custom modules caused Apache in its entirety to go up in flames. Ouch, ouch, ouch.

That particular issue was fortunately fixed, but the question’s arisen whether or not there may be other similar vulnerabilities.

Right now I have a tool at my disposal that lets me send a raw HTTP request to the server (or rather, raw data through an established TCP connection that could be interpreted as an HTTP request if it followed the form of one, e.g. “GET …”) and I’m trying to come up with other ideas. (TCP-level attacks like Slowloris and Nkiller2 are not my focus at the moment.)

Does anyone have a few nice ideas how to confuse the server’s custom modules to the point of server-self-immolation?

• Broken UTF-8? (Though I doubt Apache cares about encoding – I imagine it just juggles raw bytes.)
• Stuff that is only barely too long, followed by a 0-byte, followed by junk?
• et cetera

I don’t consider myself a very good tester (I’m doing this by necessity and lack of manpower; I unfortunately don’t even have a more than basic grasp of Apache internals that would help me along), which is why I’m hoping for an insightful response or two or three. Maybe some of you have done some similar testing for your own projects?

(If stackoverflow is not the right place for this question, I apologise. Not sure where else to put it.)

Answer 1

Depending on what other modules you have hooked in, and what else activates them (or is it only too-large requests?), you might want to try some of the following:

• Bad encodings – e.g. overlong utf-8 like you mentioned, there are scenarios where the modules depend on that, for example certain parameters.
• parameter manipulation – again, depending on what the modules do, certain parameters may mess with them, either by changing values, removing expected parameters, or adding unexpected ones.
• contrary to your other suggestion, I would look at data that is just barely short enough, i.e. one or two bytes shorter than the maximum, but in different combinations – different parameters, headers, request body, etc.
• Look into HTTP Request Smuggling (also here and here) – bad request headers or invalid combinations, such as multiple Content-Length, or invalid terminators, might cause the module to misinterpret the command from Apache.
• Also consider gzip, chunked encoding, etc. It is likely that the custom module implements the length check and the decoding, out of order.
• What about partial request? e.g requests that cause a 100-Continue response, or range-requests?
• The fuzzing tool, Peach, recommended by @TheRook, is also a good direction, but don’t expect great ROI first time using it.
• If you have access to source code, a focused security code review is a great idea. Or, even an automated code scan, with a tool like Coverity (as @TheRook mentioned), or a better one…
• Even if you don’t have source code access, consider a security penetration test, either by experienced consultant/pentester, or at least with an automated tool (there are many out there) – e.g. appscan, webinspect, netsparker, acunetix, etc etc.