Shellshock漏洞那些事儿
英文原文：Everything you need to know about the Heartbleed SSLbug
还记得 Heartbleed 漏洞吗？如果你相信今天这个铺天盖地的传言，那说明 Shellshock 和它是一类的，它的名字也同样令人畏惧（弹震症，一种精神疾病），就是缺了个酷点的 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 里面所看到的那样。从上个世纪 80 年代开始它就已经存在了，它是从早期的 SHELL 实现中演化而来的（名字是从 Bourne shell 衍生出来的），并且非常流行。Unix 家族里还有许多别的 SHELL，bash 的特别之处在于它是 Linux 以及 Mac OS X 系统的默认 SHELL，而它们都是非常流行的操作系统。这个漏洞的风险之所以这么大，这也是一个非常主要的因素——bash 无处不在——它被称作是"任何 Linux 系统上安装量最大的工具之一”。
看一下 Netcraft web 服务器的最近统计你可以感受下 bash 的足迹：
半数的网站都是运行在 Apache 上的（Linux 上一般都会装有），这是一块非常非常大的蛋糕。Netcraft 的同一篇文章中也指出了，在我们刚逛过的 10 亿个 WEB 站点中有一大半是用的同一款主机，这就已经有许多 bash 的装机量了。好吧——这还只是 WEB 服务器而已，别忘了还有许多别的服务器也运行在 Linux 上，很快我们会讲到还有哪些设备也会使用到 bash。
许多常见的管理功能都会用到 bash，比如配置网站，或者控制设备上的嵌入式软件，比如说网络摄像头。本质上来说这些并不是要开放给外部使用的，理论上来讲，我们说的是通过认证的用户在运行一些被授权可以执行的命令。当然了，这只是理论上。
这个 BUG 是什么？
我们来看下 NIST 的漏洞数据库中的 CVE，因为它很好地阐释了它的严重性：
4. 3 版本之前的 GNU bash 会对环境变量值中函数定义后的字符串进行处理，这使得远程攻击者可以精心布局从而执行任意的代码，已知的途径包括 OpenSSH sshd 中的 ForceCommand 特性，Apache HTTP 服务器中的 modcgi 以及 modcgid 模块，未知 DHCP 客户端所执行的脚本，以及其它在 bash 中设置环境变量的场景中都会出现跨越权限边界的问题。
在严重性方面，他们给出的评级是 10 分（一共是 10 分），也就是说，非常严重。由于攻击很容易发起，情况就更复杂了（访问的难度很低），最明显的就是，通过 CGI 脚本来调用 bash 无需任何认证。上面的描述有点复杂，我们还是来分析下这个 BUG 的原理吧。
风险主要在于你可以在指定了函数定义的 BASH 中随意定义环境变量。当 BASH 在处理函数定义后面的 SHELL 命令时，问题就来了，就会出现我们所说的”代码注入攻击“。我们来看下 Robert 的那个例子，只看这行就好了：
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74 脚本的机制，不一定非要是在请求头里。读一下seclists.or 中的建议还是很有必要的，里面介绍得详细一些，还提到了路径及查询串也是攻击的潜在目标。
当然了，修复这个攻击途径的一个方法就是禁用会调用 SHELL 的 CGI 功能，的确有人也是这么建议的。尽管在许多情况下，它会导致非常严重的破坏，至少来说，需要进行更广泛的测试以确保它不直接导致网站出现问题，而很多时候，这的确会发生的。
上面的 HTTP 的证子虽然很简单，却很有说服力，它只是一个常见协议上的一个实现而已。一旦你使用了 Telnet 或者 SSH，尤其是 DHCP，风险就会直线上升，因此这里我们不仅仅是在讲如何利用 WEB 服务器进行攻击。
需要注意的是潜在在破坏远不止 Robert 那个例子中只是随意 ping 了个地址而已，他只是演示了可以操作一台机器来执行一个 shell 命令。问题来了：攻击者可以在他们的选择的肉鸡上执行 shell 命令会选成什么破坏？
潜在的后果是什么？
潜在的影响是巨大的——对攻击者而言，夺取了 shell 一般来说就已经很成功了，因为控制了它，就相当于控制了目标环境。你可以访问内部数据，重新配置环境，将他们的恶意代码发布上去，等等。它无所不能，而且 是自动化的。有许多许多利用这个的例子，很多机器都会轻易中招。
不幸的是，由于它可以在互联网上几乎半数的网站的 SHELL 中执行任意代码，后果实在难以预料。最明显的一个就是将内部文件允许公开访问。密码文件以及配置文件首当其冲，可以想像到还有系统上的其它文件。
类似的，同样的方法还可以用于往系统中写文件。这是我们能看到的最简单的攻击网站的途径之一了，更别说它可以很容易发布一些恶意代码。
那这个呢：我见到的一个最多的词就是：“蠕虫“：
我正在 2014 年的病毒公报的会议中，我们在打赌什么时候会看到有蠕虫利用 Shellshock 在进行传播。
当提起计算机中恶意的蠕虫病毒的时候，我们指的是自我复制型的攻击，恶意的攻击者会编写可以在不同机器间传播的恶意代码。比如说，Samy 这个 Myspace 上的 XSS 蠕虫就是一个令人印象非常深刻的一个例子，这段精心编写的 JavaScript 会在不到一天时间内感染许多受害者的网页。
Shellshock 存在的担心就是类似的攻击能够迅速地复制，尤其是早期许多机器仍然存在风险的时候。理论上来讲，它会利用受感染的机器去扫描其它可以传播并进行攻击的目标。这绝不仅仅只限于可以公开访问的机器，企业防火墙背后的机器也无法幸免。
有许多人正在利用这一 BUG 进行攻击。这也是最早的这几天之所以有意思的地方，这是那些在抓紧时间修复补丁的人和那些正在抓紧时间进行攻击的人之间的装备竞赛。
哪些版本的 Bash 会被影响？
标题里说了，4.3 之前的版本都会受到影响，也就是说，这 25 年来的 Bash 版本。既然大家都喜欢拿它和 Heartbleed 比，考虑到 OpenSSL 受影响的版本只发布了仅仅两年，这和 Shellshock 相比简直是小巫见大巫。是的，大家会升级自己的版本，但他们不会一直更新，Shellshock 中潜在风险的机器的数量都要远远多于 Heartbleed 的。
不过这个风险可能还不止 4.3 版本。因为我们看到报告称这个补丁并不能完全修复所有的问题,不过考虑到这个补丁推出的速度，这也并不奇怪。那些受它影响的人应该时刻关注下这个，而不只是“修复一下就忘了这茬了”。
我们首次发现它是什么时候，这个风险已经存在了多久了？
从公共媒体上能找到的首次报道是 seclists.org 上的这段简短的摘要，它是 GMT 时间周三 18：00 左右（对于澳大利亚西部的人来说大概是今天早上 2 点）。详细的介绍在我前面提到的那份报告中有指出，大概是一个小时之后，大概是欧洲时间的周三下午或者美国时间的中午。这还是个很新的消息，现在充斥着大量的媒体的推测，就如一窝小鸡在叽叽喳喳，要想看到大规模的攻击现在还为时过早，不过如果这一漏洞的潜力充分发挥之后那也很快了。
再看下之前已经发布出来的消息，这个 BUG 似乎上周就被英国的一个”Unix/Linux，网络通信专家“Stéphane Chazelas 指出了。在 Akamai 关于这个 BUG 的文章上提到，他们认为它已经”存在了相当长的时间“，当然这个易受攻击的 Bash 版本已经存在了一二十年了。正如 Heartbleed 那样，问题在于是否有恶意的攻击者已经获知这个 BUG 并且已经在利用它了。
我的东西有被影响到吗？
这正是有意思的地方——我们有很多东西都在运行 Bash。当然我这么说指的是越来越流行的”物联网（IoT)“，它将一个 IP 地址以及一个无线适配器植入到了我们许多的东西里面，从餐具到门锁再到我们的电灯。
许多物联网的设备都运行着带有 Bash 的 Linux 发行版。我们已经看到，其它领域的这些设备是存在非常严重的安全问题的，比如数月前 LIFX 的电灯就被发现会泄露 WIFI 证书。虽然并不是像 Shellshock 这样的 Bash 漏洞，它也让我们看到了，将我们的物品连接到网络将我们原本安全的地方带入了一个充满风险的新世界。
它还带来了许多新的挑战：比如说，谁会总想着说给自家的电灯打个补丁的？再想想这个设备它的使用寿命又很长，你是否会管理它上面的软件。像数年前 Trendnet 摄像头那样的漏洞， 毫无疑问，现在仍有许多这样的摄像头还暴露在网络上，因为打补丁这个事，很容易左耳进右耳出。事实上在这个例子中，有一个 T witter 帐号仍在不停地广播它所抓到的被攻击版本的用户的图片。这是个不太容易修复的大问题，在相当长的一段时间内，它还会一直伴随着我们。
同样，Bash 在许多常见的设备上都会装有，比如我们家里的路由器，它们一般都是面向网络的。还记得你上次给固件打补丁是什么时候了么？好吧，如果你会读到这篇文章说明 你还是个技术人员，还是会去给自己的路由器打补丁的，但是假设你自己是那些普通的消费者，你再想想看。就是这样。
我用的全是微软系的，会有风险吗？
简单来说，”没有“，确切来说，”有的“。我先说下简单的这个吧——原生的 Windows 是没有 Bash 的，但是有 Windows 版本的 Bash，当然这并不常见，在一般消费者的 PC 上不太可能会有。现在还不清楚，像 win-bash 这样的产品是否也会受到 Shellshock 漏洞的影响。
确切来说的话，虽然你使用的是占主导地位的 Windows 平台，但这并不意味着你的机器不会由于别的原因在运行着 Bash。当我在写 Heartbleed 的文章的时候，我引用了 Nick Craver 的一篇文章，将 Stack Overflow 迁移到 SSL，下图能够说明他们的架构：
在微软应用栈前面还有许多非微软的组件，流量得先经过它们才能传递到 WEB 服务器中。还有一些组件是在防火墙后面的，拥有较高的权限——如果 Shellshock 攻击了这些组件的话怎么办？这个影响会很大，这正是这里我要说的：Shellshock 有可能会影响到除了带有风险的 Bash 实现以外的东西，因为它存在于一个更广泛的生态系统当中。
我是系统管理员——我该怎么做？
首先，看下自己是否也存在这个风险，这个很简单因为它很容易复现。the register 上面推荐了一个简单的测试方法，只用在你的 shell 里运行一下这个命令就可以了：
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff”
如果你的系统中存在这个漏洞，则会输出“busted"。
当然了，现在该做的就是给这个存在风险的系统打补丁了，这个补丁本质上用一句话来说就是确保在 Bash 函数后边不会再执行代码。Red Hat 等 Linux 版本都发布了修复这个风险的指南, 因此优先试一下那个。
我们肯定也会看到有一些入侵检测系统，当然这里也有一些常见的可检测的模式。对大多数机构而言这可能是一个简单有效的方法，尤其是有些公司在打补丁之前还得进行大量的检测工作。Qualys 希望能快速实现攻击检测的定位，当然其它的 IDS 提供商也在马不停蹄地忙着这个。
更激进的方法就是用一个别的 shell 实现来替换掉 bash，或者在存在风险的系统上进行隔离，这两者的影响都会比较大，因此，要下这个决心可不太容易。不过可能对很多人来说这个 BUG 就是这么处理的——能切实地改进业务的艰难决定是为了避免潜在的更严重的后果。
还有一个大家很关心的问题就是自己的机器上 Shellshock 这个漏洞是否已经被人利用了。如果没有攻击的日志的话这个很难确认（如果是通过 HTTP 请求的头或者请求体传入进来的话一般都没有日志），不过这个比 Heartbleed 要容易发现一些，后者的网络包几乎不太可能会输出到日志里。不过对于“我是否已经被 Shellshock 攻击了”的最常见回答就是：
不幸的是，并没有“没有，我们已经证实这决无影响”这样的回答，相反的，“从这个漏洞出现的这段时间来看，并没有确切证据表明你被攻击了”。我相信许多人都是这么回答的——这会让系统负责人感到很不快，因为他并不知道自己的系统发生了什么，如果真的发生过什么的话。
我们来猜测下国家安全局是否会介入此事吧。。
我是个普通用户——我能做些什么？
这就得看情况了。Shellshock 会影响到 Mac 系统，因此如果你使用的是 OS X 的话，眼下看起来很危险，一方面因为 Mac 很流行所以情况不太妙，但另一方面，由于它的更新机制这个也很容易修复。（苹果可以远程推送更新到这台机器上）。
如果你使用的是 Mac, 照 Stack Exchange 上的那个回复所说的那样做可以很容易检测下自己是否中招了：
这个很容易测试，不过我怀疑一般的 Mac 用户看到这个要重新编译 bash 的修复建议时会不会感到不爽(注：我是觉得很不爽)。
更麻烦的是有些设备可能不太容易修复，比如说你的路由器。除了到厂商的网站上看看有没有固件更新外，真是没啥容易的办法了。一般来说 ISP 提供的路由器是上锁的，因此用户无法修改配置或者固件，一般也说也没有什么可以触发的远程更新。考虑到有许多设备都已经在外边了，想修复它们的话还是有点 难度的。当然了，要你这样的普通消费者来修复这个，你肯定会感到很不满的。
简而言之，对消费者而言我建议这样：关注安全更新，尤其是 OS X 上的用户。同时关注你从 ISP 那拿到的设备，或者别的运行嵌入式软件的设备。尤其小心那些请求你的信息或者引导你运行软件的那些邮件——像这类的事件总是会伴随着许多网络钓鱼，它们利 用了消费者恐惧的心理。最近的恶作刷病毒让用户将他们的 iPHone 放到微波炉里,因此千万别以为他们不会运行那些发送给他们的”修复"Shellshock 的邮件。
总结
我们对这个漏洞的了解只是皮毛而已。当然了，会有很多人将它和 Heartbleed 进行比较，从这之中我们也会汲取到许多的经验。一个就是我们花了点时间来了解到我们有多依赖 OpenSSL。另外一个就是它还远没有结束——几个月过后，还有数不清的知名站点还是没有修复。
不过从某个意义上来讲，拿它和 Heartbleed 来比不太公平——shellshock 可能要更糟糕。Heartbleed 允许你远程访问到被影响机器的内存中的一小部分数据。而 Shellshock 可以远程注入代码来执行任意的命令而无需认证，这估计会更为杯具。因此，我很同意 Robert 说的那句话：
顺便提一句，'bash'这个 BUG 可比 Heartbleed 要严重多了。
现在时间还很短，从它首次被披露受到攻击到现在写这篇文章才只有半天时间——结果会怎样，我觉得我们只是看到了一点表面现象而已。