Linux 无法利用所有文件的shellshock漏洞

我一直试图利用系统中的Shellshock漏洞，但遇到了一个有趣的问题。我一直在使用“wget”来利用该漏洞。我使用的命令如下：

wget -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" http://somesite.com/some-script.cgi

使用上述命令，漏洞将如预期的那样显示。但是，当我尝试创建一个不是.cgi文件的文件时，该漏洞不会出现，只会下载该文件

据我所知，wget应该将User-Agent字符串设置为命令中传递的值，该命令应该运行代码

/bin/cat/etc/passwd

，我看不出这与正在下载的文件的性质有什么关系

提前感谢。

要利用，需要执行以下步骤：

您必须让目标服务器将特定字符串注入，然后

设置环境变量后，目标必须（直接或间接）启动（易受攻击的版本）shell

一种可能发生这种情况的方法是，web服务器通过执行外部程序，而外部程序要么是bash shell脚本，要么以其他方式调用bash。这是因为CGI协议指定来自原始HTTP请求的头以前缀

HTTP\u

传递给环境变量中的外部程序（例如用户代理头的

HTTP\u USER\u AGENT

）。由于攻击者可以控制这些头，因此他们还可以直接控制这些环境变量的值

---

然而，只有在通过CGI调用外部程序时，web服务器才需要设置这些环境变量。在交付静态文件时，服务器只需要从磁盘读取该文件并将其发送回客户端；它不需要设置任何环境变量或调用任何外部工具，如bash。

somesite.com上运行的服务器是什么？我已经运行了apache2。apache2是否检查用户代理的静态页面？它是否为他们运行了一个新的shell？无论apache2在用户代理方面的行为是什么，它是否应该独立于文件类型？对。所以我的问题是，当我使用“wget”从web服务器获取文件时，它只需要读取该文件，即使该文件是.cgi文件。为什么漏洞会受到所获取文件类型的影响？CGI脚本（我假设，您的Web服务器配置为将后缀为.CGI的文件视为）不仅仅是从磁盘读取并按原样发送给您，而是由服务器执行，并将其输出发送给您。如果正在执行的文件恰好是bash脚本（即以

#！/bin/bash

开头的文本文件），则执行它将导致操作系统调用bash，从而可能触发shellshock错误。要了解CGI脚本如何工作的更多背景信息，您可能想看看我在回答中包含的维基百科链接。啊，好的。现在一切都清楚了。我有点了解cgi脚本是如何工作的，但我不知道它们是在“wget”它们并获取它们的输出时执行的。我以为文件本身被取了。