这里有一个有点不正统的问题：
我目前正在尝试用一些自定义模块来破坏 Apache。
引发测试的原因是 Apache 在内部将它认为太大的请求（例如 1 MB 垃圾）转发到适当挂钩的模块，迫使它们处理垃圾数据 - 而自定义模块中缺乏处理导致 Apache 整体上火上浇油。哎哟，哎哟，哎哟。
幸运的是，这个特定问题已得到解决，但问题是是否还存在其他类似的漏洞。
现在，我有一个可以使用的工具，可以让我向服务器发送原始 HTTP 请求（或者更确切地说，通过已建立的 TCP 连接发送原始数据，如果它遵循某种形式，则可以将其解释为 HTTP 请求，例如“GET ...”）我正在尝试提出其他想法。 （像 Slowloris 和 Nkiller2 这样的 TCP 级攻击不是我目前的关注点。）
有没有人有一些好主意如何混淆服务器的自定义模块以达到服务器自检的目的自焚？
- UTF-8 损坏？ （虽然我怀疑 Apache 是否关心编码 - 我想它只是在处理原始字节。）
- 仅仅太长的东西，后面跟着一个 0 字节，后面跟着垃圾？
- 等等，
我不认为自己是一个很好的测试人员（我这样做是出于必要且缺乏人力；不幸的是，我什至对 Apache 内部结构没有基本的了解，这对我有帮助），这就是为什么我希望得到一两个或三个富有洞察力的回应。也许你们中的一些人为自己的项目做过一些类似的测试？
（如果 stackoverflow 不是解决这个问题的正确地方，我深表歉意。不知道还能把它放在哪里。）
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.)
发布评论
评论（2）
Apache 是地球上最坚固的软件项目之一。在 Apache 的 HTTPD 中找到漏洞绝非易事，我建议您尝试一些更简单的方法。相比之下，其他 HTTPD 中的漏洞更常见，例如 Nginx 中的漏洞我今天看到了（不是开玩笑）。还有其他非常相似的源代码泄露漏洞，我会查看 这是另一个。 lhttpd 已在 sf.net 上被废弃近十年了，并且已知存在影响它的缓冲区溢出，这使得它成为一个有趣的测试应用程序。
当攻击一个项目时，你应该看看过去发现了什么样的漏洞。程序员很可能会一次又一次地犯同样的错误，并且经常会出现一些模式。通过遵循这些模式，您可以发现更多缺陷。您应该尝试搜索漏洞数据库，例如 Nist 的 CVE 搜索。您将看到的一件事是 apache 模块最常受到损害。
像 Apache 这样的项目已经被严重模糊了。有一些模糊测试框架，例如 Peach。 Peach 在很多方面帮助您进行模糊测试，其中一种可以帮助您的方式是为您提供一些令人讨厌的测试数据来使用。对于成熟的项目来说，模糊测试并不是一个很好的方法，如果你走这条路，我会瞄准 apache 模块，下载次数尽可能少。 （警告下载量非常低的项目可能会损坏或难以安装。）
当公司担心安全性时，他们通常会花很多钱购买自动源分析工具，例如 Coverity。国土安全部为 Coverity 提供了大量资金来测试开源项目，Apache 就是其中之一。我可以直接告诉你，我发现了 缓冲区溢出，其中模糊测试是 Coverity 没有选择的向上。 Coverity 和其他源代码分析工具（例如 开源 Rats）将产生大量误报和漏报，但它们确实有助于缩小影响代码库的问题范围。
（当我第一次在 Linux 内核上运行 RATS 时，我差点从椅子上摔下来，因为我的屏幕列出了数千个对 strcpy() 和 strcat() 的调用，但是当我深入研究代码时，所有调用都使用静态文本，这是安全的。）
漏洞研究和漏洞利用开发非常有趣。我建议利用 PHP/MySQL 应用程序并探索The Whitebox。这个项目很重要，因为它表明存在一些现实世界中的漏洞，除非您手动逐行阅读代码，否则无法发现这些漏洞。它还具有非常容易受到攻击的现实世界应用程序（博客和商店）。事实上，这两个应用程序都因安全问题而被放弃。像 Wapiti 或 acuentix 这样的 Web 应用程序模糊器会强奸这些应用程序和类似的应用程序。博客有一个技巧。全新安装不会受到太多影响。您必须稍微使用一下该应用程序，尝试以管理员身份登录，创建博客条目，然后扫描它。当测试 Web 应用程序的 SQL 注入时，请确保错误报告已打开。在 php 中，您可以在 php.ini 中设置
display_errors=On。祝你好运！
Apache is one of the most hardened software projects on the face of the planet. Finding a vulnerability in Apache's HTTPD would be no small feat and I recommend cutting your teeth on some easier prey. By comparison it is more common to see vulnerabilities in other HTTPDs such as this one in Nginx that I saw today (no joke). There have been other source code disclosure vulnerablites that are very similar, I would look at this and here is another. lhttpd has been abandoned on sf.net for almost a decade and there are known buffer overflows that affect it, which makes it a fun application to test.
When attacking a project you should look at what kind of vulnerabilities have been found in the past. Its likely that programmers will make the same mistakes again and again and often there are patterns that emerge. By following these patterns you can find more flaws. You should try searching vulnerablites databases such as Nist's search for CVEs. One thing that you will see is that apache modules are most commonly compromised.
A project like Apache has been heavily fuzzed. There are fuzzing frameworks such as Peach. Peach helps with fuzzing in many ways, one way it can help you is by giving you some nasty test data to work with. Fuzzing is not a very good approach for mature projects, if you go this route I would target apache modules with as few downloads as possible. (Warning projects with really low downloads might be broken or difficult to install.)
When a company is worried about secuirty often they pay a lot of money for an automated source analysis tool such as Coverity. The Department Of Homeland Security gave Coverity a ton of money to test open source projects and Apache is one of them. I can tell you first hand that I have found a buffer overflow with fuzzing that Coverity didn't pick up. Coverity and other source code analysis tools like the open source Rats will produce a lot of false positives and false negatives, but they do help narrow down the problems that affect a code base.
(When i first ran RATS on the Linux kernel I nearly fell out of my chair because my screen listed thousands of calls to strcpy() and strcat(), but when i dug into the code all of the calls where working with static text, which is safe.)
Vulnerability resarch an exploit development is a lot of fun. I recommend exploiting PHP/MySQL applications and exploring The Whitebox. This project is important because it shows that there are some real world vulnerabilities that cannot be found unless you read though the code line by line manually. It also has real world applications (a blog and a shop) that are very vulnerable to attack. In fact both of these applications where abandoned due to security problems. A web application fuzzer like Wapiti or acuentix will rape these applications and ones like it. There is a trick with the blog. A fresh install isn't vulnerable to much. You have to use the application a bit, try logging in as an admin, create a blog entry and then scan it. When testing a web application application for sql injection make sure that error reporting is turned on. In php you can set
display_errors=Onin your php.ini.Good Luck!
根据您挂接的其他模块，以及还有什么激活它们（或者只是太大的请求？），您可能想尝试以下一些操作：
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: