Bash漏洞那些事儿

还记得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，因为它很好地阐释了它的严重性：

<quote>
4.3版本之前的GNU bash会对环境变量值中函数定义后的字符串进行处理，这使得远程攻击者可以精心布局从而执行任意的代码，已知的途径包括OpenSSH sshd中的ForceCommand特性，Apache HTTP服务器中的mod_cgi以及mod_cgid模块，未知DHCP客户端所执行的脚本，以及其它在bash中设置环境变量的场景中都会出现跨越权限边界的问题。
</quote>


在严重性方面，他们给出的评级是10分（一共是10分），也就是说，非常严重。由于攻击很容易发起，情况就更复杂了（访问的难度很低），最明显的就是，通过CGI脚本来调用bash无需任何认证。上面的描述有点复杂，我们还是来分析下这个BUG的原理吧。

风险主要在于你可以在指定了函数定义的BASH中随意定义环境变量。当BASH在处理函数定义后面的SHELL命令时，问题就来了，就会出现我们所说的”代码注入攻击“。我们来看下Robert的那个例子，只看这行就好了：

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

这个函数定义是 () { :; }; 而SHELL命令是ping语句以及它的参数。当它在一个bash SHELL的环境中执行的时候，它可以执行任意的命令。在WEB中，可以通过一个类似CGI脚本的机制，不一定非要是在请求头里。读一下seclists.or中的建议还是很有必要的，里面介绍得详细一些，还提到了路径及查询串也是攻击的潜在目标。

当然了，修复这个攻击途径的一个方法就是禁用会调用SHELL的CGI功能，的确有人也是这么建议的。尽管在许多情况下，它会导致非常严重的破坏，至少来说，需要进行更广泛的测试以确保它不直接导致网站出现问题，而很多时候，这的确会发生的。

上面的HTTP的证子虽然很简单，却很有说服力，它只是一个常见协议上的一个实现而已。一旦你使用了Telnet或者SSH，尤其是DHCP，风险就会直线上升，因此这里我们不仅仅是在讲如何利用WEB服务器进行攻击。

需要注意的是潜在在破坏远不止Robert那个例子中只是随意ping了个地址而已，他只是演示了可以操作一台机器来执行一个shell命令。问题来了：攻击者可以在他们的选择的肉鸡上执行shell命令会选成什么破坏？


潜在的后果是什么？

潜在的影响是巨大的——对攻击者而言，夺取了shell一般来说就已经很成功了，因为控制了它，就相当于控制了目标环境。你可以访问内部数据，重新配置环境，将他们的恶意代码发布上去，等等。它无所不能，而且是自动化的。有许多许多利用这个的例子，很多机器都会轻易中招。

不幸的是，由于它可以在互联网上几乎半数的网站的SHELL中执行任意代码，后果实在难以预料。最明显的一个就是将内部文件允许公开访问。密码文件以及配置文件首当其冲，可以想像到还有系统上的其它文件。

类似的，同样的方法还可以用于往系统中写文件。这是我们能看到的最简单的攻击网站的途径之一了，更别说它可以很容易发布一些恶意代码。

那这个呢：我见到的一个最多的词就是：“蠕虫“：

<quote>
我正在2014年的病毒公报的会议中，我们在打赌什么时候会看到有蠕虫利用Shellshock在进行传播。
</quote>

当提起计算机中恶意的蠕虫病毒的时候，我们指的是自我复制型的攻击，恶意的攻击者会编写可以在不同机器间传播的恶意代码。比如说，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攻击了”的最常见回答就是：


<quote>

不幸的是，并没有“没有，我们已经证实这决无影响”这样的回答，相反的，“从这个漏洞出现的这段时间来看，并没有确切证据表明你被攻击了”。我相信许多人都是这么回答的——这会让系统负责人感到很不快，因为他并不知道自己的系统发生了什么，如果真的发生过什么的话。

</quote>

我们来猜测下国家安全局是否会介入此事吧。。


我是个普通用户——我能做些什么？

这就得看情况了。Shellshock会影响到Mac系统，因此如果你使用的是OS X的话，眼下看起来很危险，一方面因为Mac很流行所以情况不太妙，但另一方面，由于它的更新机制这个也很容易修复。（苹果可以远程推送更新到这台机器上）。

如果你使用的是Mac, 照Stack Exchange上的那个回复所说的那样做可以很容易检测下自己是否中招了：



这个很容易测试，不过我怀疑一般的Mac用户看到这个要重新编译bash的修复建议时会不会感到不爽(注：我是觉得很不爽)。

更麻烦的是有些设备可能不太容易修复，比如说你的路由器。除了到厂商的网站上看看有没有固件更新外，真是没啥容易的办法了。一般来说ISP提供的路由器是上锁的，因此用户无法修改配置或者固件，一般也说也没有什么可以触发的远程更新。考虑到有许多设备都已经在外边了，想修复它们的话还是有点难度的。当然了，要你这样的普通消费者来修复这个，你肯定会感到很不满的。

简而言之，对消费者而言我建议这样：关注安全更新，尤其是OS X上的用户。同时关注你从ISP那拿到的设备，或者别的运行嵌入式软件的设备。尤其小心那些请求你的信息或者引导你运行软件的那些邮件——像这类的事件总是会伴随着许多网络钓鱼，它们利用了消费者恐惧的心理。最近的恶作刷病毒让用户将他们的iPHone放到微波炉里,因此千万别以为他们不会运行那些发送给他们的”修复"Shellshock的邮件。

总结

我们对这个漏洞的了解只是皮毛而已。当然了，会有很多人将它和Heartbleed进行比较，从这之中我们也会汲取到许多的经验。一个就是我们花了点时间来了解到我们有多依赖OpenSSL。另外一个就是它还远没有结束——几个月过后，还有数不清的知名站点还是没有修复。

不过从某个意义上来讲，拿它和Heartbleed来比不太公平——shellshock可能要更糟糕。Heartbleed允许你远程访问到被影响机器的内存中的一小部分数据。而Shellshock可以远程注入代码来执行任意的命令而无需认证，这估计会更为杯具。因此，我很同意Robert说的那句话：

<quote>
顺便提一句，'bash'这个BUG可比Heartbleed要严重多了。

</quote>

现在时间还很短，从它首次被披露受到攻击到现在写这篇文章才只有半天时间——结果会怎样，我觉得我们只是看到了一点表面现象而已。

更多文章请移步我的个人博客：Java译站


原创文章转载请注明出处：http://it.deepinmind.com




英文原文链接

评论

1 楼 yixiandave 2014-09-26  

是不是只有cgi编写的网站才会受到影响？如果我把这条代码写到cookie里面然后再请求一个php或者java编写的网站是否会受影响？