关于 Shellshock Bash 漏洞的所有你需要知道的事项

关于 Shellshock Bash 漏洞的所有你需要知道的事项

还记得Heartbleed吗？如果你相信今天的炒作，Shellshock和Heartbleed一样，属于同一等级，名字也同样酷，尽管缺少一个炫酷的logo（这些漏洞的营销部门确实需要加把劲）。但说实话，它确实有可能成为一个大问题，正如我在处理Heartbleed时所做的，我也希望为自己整理出一份权威内容，既帮助我理解这个情况，也让其他人能够从真正的风险中剖析炒作。

为了给大家提供一些背景信息，下面是来自Robert Graham的博客的内容，他在这方面做了很好的分析。假设有一个HTTP请求，如下所示：

target = 0.0.0.0/0
        port = 80
        banners = true
        http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
        http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
        http-header = Host:() { :; }; ping -c 3 209.126.230.74
        http-header = Referer:() { :; }; ping -c 3 209.126.230.74
        

当这个请求针对一系列易受攻击的IP地址发出时，会得到如下结果：

简而言之，Robert通过精心构造一个请求，使得一群外部机器向他发送Ping请求。更令人担忧的是，他实际上使这些机器执行了一个任意的命令（虽然只是一个相当无害的ping命令），而这打开了一个充满严重可能性的世界。让我来解释一下。

什么是Bash，为什么我们需要它？

如果你已经知道这些内容可以跳过，但对于那些不熟悉Bash的人，了解一些背景知识非常重要，因此让我们先建立一个基本的理解。Bash是一个*nix shell，换句话说，它是一个解释器，允许你在Unix和Linux系统上执行命令，通常是通过SSH或Telnet连接。它也可以作为Web服务器上CGI脚本的解析器，就像我们通常在Apache上看到的那样。Bash自80年代末以来就已经存在，它是从早期的shell实现演变而来的（名字来源于Bourne shell），并且非常受欢迎。虽然Unix的其他变种也有shell，Bash的特别之处在于它是Linux和Mac OS X的默认shell，而这两种操作系统显然非常普及。这是这个风险如此严重的主要因素——Bash的普及性，它被描述为“任何Linux系统上最常安装的工具之一”。

你可以通过查看最新的Netcraft web服务器统计数据来了解Bash的影响：

当互联网上有一半的系统在运行Apache（通常运行在Linux上），这意味着一个非常大的市场份额。那篇Netcraft文章还报告说，全球网站数量刚刚突破十亿，虽然其中很多网站共享相同的主机，但这仍然意味着有大量的Bash安装。而且——这些只是Web服务器，别忘了还有大量其他服务器在运行Linux，稍后我们还会讨论其他使用Bash的设备。

Bash可以用于执行各种典型的管理任务，从配置网站到控制嵌入式设备上的软件，例如网络摄像头。自然，这些功能不应对外公开，并且理论上，我们是在讨论经过认证的用户执行他们被授权执行的命令。在理论上。

漏洞是什么？

让我从NIST漏洞数据库中的CVE开始，因为它清楚地表达了漏洞的严重性（高亮部分为我添加的）：

GNU Bash 直到4.3版本，在函数定义后的环境变量值中处理尾随字符串，这允许远程攻击者通过构造的环境执行任意代码，如OpenSSH sshd中的ForceCommand功能、Apache HTTP服务器中的mod_cgi和mod_cgid模块、由不明DHCP客户端执行的脚本以及其他在Bash执行过程中设置环境发生在权限边界跨越的情况所示。

他们进一步将其严重性评为“10分满分”，也就是说，这是最糟糕的情况。这一点由于攻击执行的简单性（访问复杂度低）而更加严重，或许最值得关注的是，通过CGI脚本利用Bash时无需身份验证。不过，以上总结有点复杂，让我们简化一下，直接来看漏洞的机制。

风险集中在能够在Bash shell中任意定义环境变量，这些环境变量指定了一个函数定义。问题出现在Bash在函数定义后继续处理Shell命令，导致我们称之为“代码注入攻击”。让我们再看一下Robert的示例，我们只取这一行：

http-header = Cookie:() { :; }; ping -c 3 209.126.230.74

函数定义是() { :; };，而Shell命令是ping语句及其随后的参数。当在Bash shell中处理时，任意命令被执行。在Web上下文中，这意味着通过诸如CGI脚本这样的机制，并不一定是请求头。值得一读的是seclists.org的通告，他们对此进行了更详细的讨论，包括指出路径和查询字符串可能是攻击的潜在向量。

当然，一种缓解这种攻击向量的方法就是简单地禁用任何调用Shell的CGI功能，事实上，有些人建议这样做。然而，在许多情况下，这将是一个严重的破坏性更改，至少在某些情况下，需要进行大量测试，以确保它不会在网站中引发即时问题，而在许多情况下，它确实会。

上面的HTTP示例是一个简单而有效的例子，尽管它仅是通过常见协议实现的一种方式。一旦加入Telnet、SSH，甚至是DHCP，范围就会显著增加，所以我们不仅仅是在谈论利用Web应用服务器。（显然，SSH后认证时才存在此风险，但在公开披露的初期阶段，我们不可避免地会看到其他攻击向量的出现。）

你还需要记住的是，潜在损害的范围远远超出了像Robert示例中那样仅仅是ping一个任意地址，这只是一个巧妙的小证明，表明他可以操控机器发出Shell命令。问题变成了这样：当攻击者能够在任何易受攻击的机器上执行任意Shell命令时，他们能造成什么样的损害？

可能的后果是什么？

潜在的后果巨大——“获得Shell”一直是攻击者的一项重大胜利，因为它使攻击者能够控制目标环境。访问内部数据、重新配置环境、发布他们自己的恶意代码等。这几乎是无限的，而且也很容易自动化。已经有很多漏洞利用示例，这些示例可以很容易地针对大量机器发动攻击。

不幸的是，当涉及到在互联网上多达一半的网站上执行Shell中的任意代码时，潜在风险非常广泛。其中一个明显（且特别恶心）的问题是将内部文件转储供公众获取。密码文件和包含凭据的配置文件是最显而易见的，但也可能扩展到系统上的任何其他文件。

同样，同样的方法也可以应用于写入系统文件。这可能是我们见过的最容易的网站篡改向量，更不用说它还是分发恶意软件的一个非常简单的方式。

或者这样想：有一个词我看到得非常多，那就是“蠕虫”：

当我们在恶意计算环境中谈到蠕虫时，我们指的是一种自我复制的攻击，其中恶意行为者创建能够在目标之间传播的代码。例如，我们在Samy的MySpace XSS蠕虫中看到了这种攻击的一个非常有效的实现，其中一些精心制作的JavaScript成功地在不到一天的时间里“感染”了100万个受害者的页面。

Shellshock的担忧在于，这种性质的攻击可能以惊人的速度复制，特别是在大多数机器仍然处于风险之中时。理论上，这可以表现为一台受感染的机器扫描其他目标并将攻击传播给它们。这绝不仅限于面向公众的机器；如果这发生在企业防火墙后面，后果将不堪设想。

人们正在着手利用这个漏洞。这就是为什么这些早期阶段如此有趣的原因，因为修补漏洞和发动攻击的人之间的军备竞赛正在加剧。

哪些版本的Bash受到影响？

新闻标题中提到，所有版本直到4.3，换句话说，约有25年的Bash版本。鉴于大家一直将这个问题与Heartbleed进行比较，请考虑到OpenSSL受影响的版本仅跨越了两年，这与Shellshock相比简直是九牛一毛。是的，人们会升级他们的版本，但他们并不一致地这么做，无论从哪个角度看，Shellshock的受影响机器的范围将会比Heartbleed时大得多。

但是，风险可能不仅仅局限于4.3版本。我们已经看到补丁未完全有效的报告，考虑到它们推出的速度，这并不令人惊讶。对于那些受影响的人来说，这种事情需要非常密切地关注，而不是“修补后忘记”。

我们何时首次得知这个问题，且我们已经面临风险多久了？

我找到的第一条公开提及是在 seclists.org上的这篇简短总结，大约是在格林威治标准时间周三下午2点（对我们这些在澳大利亚东部的人来说，大约是今天凌晨）。详细信息则出现在我之前提到的公告中，约一小时后发布，因此在欧洲是周三的下午，而在美国则是早晨。这个消息仍然非常新鲜，伴随着所有常见的媒体猜测和小鸡丽塔的预言；现在还太早，无法观察到广泛的恶意利用，但如果风险如预期那样扩展，这种情况可能会很快发生。

如果回顾一下公开披露之前的情况，这个漏洞显然是在上周由Stéphane Chazelas，一位来自英国的“Unix/Linux、网络和电信专家”发现的。尽管如此，在Akamai关于该漏洞的博文中，他们提到这个漏洞已经存在了“很长一段时间”，而且Bash的易受攻击版本已经有二十多年了。就像Heartbleed一样，问题在于恶意攻击者是否在此之前就已经意识到这个漏洞，甚至是否已经在积极利用它。

我们的“设备”是否受到影响？

这就变得有趣了——我们有很多“设备”可能在运行Bash。当然，当我提到这个词时，我指的是“物联网”（IoT），即将IP地址和无线适配器嵌入从我们的餐具到我们的门锁，再到我们的灯泡等各类物品中的普遍现象。

许多物联网设备运行嵌入式的Linux发行版，且包含Bash。这些设备已经显示出在其他方面存在严重的安全漏洞，例如，几个月前，LIFX灯泡就被发现泄露Wi-Fi凭证。虽然这不是像Shellshock那样的Bash漏洞，但它向我们展示了通过连接这些设备，我们正在进入一个充满漏洞的新世界，原本这些地方并不面临风险。

编辑：一些人提到了在移动设备上运行BusyBox的Ash shell。运行这些的设备似乎不受Shellshock的影响。消费者面临的困难在于，他们不知道设备上运行的是什么，包括像路由器这样的更传统的“设备”。由于这个漏洞的历史悠久，意味着我们已经有了数十年的设备，经历了不同嵌入式操作系统的演变，而现在我们拥有一个非常多样化的设备和shell环境，跨越了很长的时间跨度。

这带来了许多新挑战；例如，谁会积极考虑定期更新他们的灯泡固件？还要考虑的是这些设备的使用寿命，以及它们是否在持续维护中。在像几年前的Trendnet摄像头漏洞这种情况下，毫无疑问，仍然有大量设备留在网络上，因为从补丁的角度来看，它们几乎是一个“设定好然后遗忘”的选项。事实上，在那个案例中，有一个专门的Twitter账号，它专门发布受害者的影像，展示那些使用易受攻击版本的用户。这是一个没有简单解决办法的大问题，它将持续存在非常长时间。

但Bash shell也存在于许多更常见的设备中，例如我们的家庭路由器，这些设备通常是面向互联网的。还记得上次给你的路由器打补丁是什么时候吗？好的，如果你正在阅读这篇文章，那么也许你是那种会实际更新路由器固件的技术人员，但换位思考，站在普通消费者的角度，再问一次自己这个问题。正是如此。

所有我们的设备都在微软技术栈上，是否存在风险？

简短的回答是“没有”，长回答是“有”。我先来处理简单的部分——Bash 在 Windows 上并不原生存在，尽管有一些 Windows 的 Bash 实现，但它并不常见，也不会出现在消费级 PC 上。并且，目前也不清楚像 win-bash 这样的产品是否会受到 Shellshock 的影响。

更长的回答是，仅仅因为你在一个主要是微软环境的环境中工作，并不意味着你在该环境中运行的所有机器都没有 Bash。回想我曾经写过的 关于 Heartbleed 的文章，我提到了 Nick Craver 在 推动 Stack Overflow 向 SSL 过渡 的文章，并且引用了他们基础设施的这张图：

在他们的微软应用栈之前，有一些非微软组件，这些组件需要通过这些组件的流量才能到达 web 服务器。这些组件在防火墙后面可能具有更高的权限——如果 Shellshock 在这些组件上被利用，会有什么影响呢？这可能会很严重，这就是我在这里要强调的重点；Shellshock 在更广泛的其他机器生态系统中存在时，有可能影响的不仅仅是易受攻击的 Bash 实现。

我是系统管理员——我该怎么办？

首先，发现自己是否存在风险非常简单，因为这是一个很容易重现的风险。The Register 提供了一个非常简单的测试，只需在你的 shell 中运行以下命令：

env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
        env X="() { :;} ; echo busted" 'which bash' -c "echo completed"

如果你看到“busted”被回显出来，那么你就成功地利用了这个漏洞。

当然，最优先的任务是给存在风险的系统打补丁，补丁的关键就是确保 Bash 函数结束后无法执行代码。像 Red Hat 等 Linux 发行版已经发布了补丁指导，因此请优先关注这方面的更新。

我们也将不可避免地看到入侵检测系统的定义，并且肯定会有常见的模式可以供大家关注。对于很多组织来说，这可能是一个很好的短期解决方案，特别是在需要繁琐测试才能发布补丁到存在风险的系统时。Qualys 正在努力提供一个快速检测攻击的定义，其他入侵检测系统供应商也在不间断地工作。

其他更为极端的选择包括用其他 shell 实现替换 Bash，或者隔离存在风险的系统，这两者可能带来深远的影响，并且不太可能轻易做出这些决定。但这可能就是许多人在面对这个漏洞时的处境——做出艰难决定以避免可能带来更大影响的后果。

另一个现在开始频繁出现的问题是，Shellshock 是否已经在某个环境中被利用。这个问题如果没有攻击向量的日志记录（如果是通过 HTTP 请求头或 POST 主体传递，通常是没有日志的），可能很难确定，但与 Heartbleed 相比，它更有可能被捕获，因为除非是完整的网络抓包，否则 Heartbleed 的心跳负载通常不会被记录。尽管如此，“我们是否被 Shellshock 攻击过”这个问题的最常见回答将是 这段话：

不幸的是，这并不是“没有，我们有证据表明没有发生过泄露”；而是“我们没有证据可以追溯到这个漏洞的生命周期”。我们怀疑很少有人能做到——这让系统所有者处于一个不舒服的境地，他们不知道是否发生了任何泄露。

让关于 NSA 是否参与其中的猜测开始吧……

我是消费者 – 我能做些什么？

这要看情况。Shellshock 影响 Mac，因此如果你使用的是 OS X，目前来看是有风险的，这一方面因为 OS X 的普及性，但另一方面也因为它有一个非常有效的更新机制（也就是说，苹果可以远程推送更新到你的设备），因此有望得到快速修复。

如果你使用的是 Mac，风险可以很容易地通过以下在 Stack Exchange 的回答 中描述的测试来检测：

这是一个简单的测试，尽管我怀疑一般的 Mac 用户会感到不舒服，因为修复过程涉及重新编译 Bash。

更大的担忧是那些没有简单修补路径的设备，例如你的路由器。如果没有查看制造商网站获取更新的固件，这将是一个非常难以解决的问题。通常，ISP 提供的路由器会被锁定，以防止消费者随意更改配置或固件，而且它们并不总是有远程升级路径可以触发。再加上各种设备的多样性和它们的使用年限，这可能尤其棘手。当然，这也不是普通消费者会轻松处理的事情。

简而言之，对消费者的建议是：关注安全更新，尤其是在 OS X 上。还要关注你的 ISP 或其他嵌入式软件设备提供商可能提供的任何建议。务必小心要求提供信息或指示你运行软件的电子邮件 – 像这样的事件通常会伴随着钓鱼攻击，利用消费者的恐慌情绪。当前的恶作剧让 人们把 iPhone 放进微波炉，所以不要以为他们不会通过电子邮件发送“修复”Shellshock 的随机软件给你！

总结

很可能我们还没有开始了解这个漏洞的广泛性。 当然，很多人将其与 Heartbleed 进行比较，且我们从那次事件中学到了很多东西。一个教训是，当我们意识到我们有多依赖 OpenSSL 时，花了一些时间才彻底明白。另一个教训是，它有一个非常长的尾巴 – 在它发生几个月后，仍有成千上万的主机处于易受攻击状态。

但从某种意义上来说，将它与 Heartbleed 相比较并不公平 – 这可能要更糟。Heartbleed 允许远程访问受影响机器的少量内存数据。而 Shellshock 允许未经身份验证的远程代码注入，可能 更为严重。在这方面，我不得不同意 Robert 的观点：

现在还处于非常非常早期的阶段——在写这篇文章的时候，距离它第一次出现在电视广播中只有半天的时间——我怀疑到目前为止，我们只是揭开了即将到来的事情的表面。