Fight For Freedom

05月 09

由ImageMagick命令执行引发的思考

       ImageMagick漏洞出来好几天了,在乌云、补天上几乎引起了一波刷洞高潮。在漏洞当天公开后,我并没有意识到该漏洞会产生如此大的危害,也没有去想它会产生的一系列连锁效应,比如wordpress类似大CMS的无辜躺枪、各种大站的沦陷、php disable_functions的bypass等等。所以,在这浪潮狂欢背后,我们究竟要有什么需要值得去思考呢。

       以开发者视角

       ImageMagick是一套功能强大、稳定而且开源的工具集和开发包,可以用来读、写和处理超过89种基本格式的图片文件,包括流行的TIFF、JPEG、GIF、 PNG、PDF以及PhotoCD等格式。ImageMagic的主要精力集中在性能,减少bug以及提供稳定的API上。

       对大多数主流编程语言而言都有API可调。开发者往往对其大厂商提供的API很信任,直接应用于功能中,但这终究还是不稳定因素。这个锅当然不能由开发者来背,不过造成的危害还是得由自己来承担。引用第三方的插件或包库时,开发者并没有丰富的安全经验,也只因根据需求去使用它们,即便拥有安全经验,该调用的功能还不是得调用,对于官方的东西也一致信任。因此简单来说,运维人员唯一能做的就是跟进安全最新动态,根据官方要求打好最新的补丁。

       以攻击者视角

       主要有三方面:一是如何能挖到这种重量级别的洞;二是如何能快速做到态势感知;三是如何“榨干”漏洞价值。(以下内容纯属yy)

       一. 漏洞挖掘

       对于这样低级的漏洞竟然会出现在大厂商中,多多少少会让人感到一些意外。使用者认为不会有漏洞,开发者认为不会有漏洞.....都认为不会产生漏洞,结果漏洞就偏偏存在,并且还是这么无语低级的漏洞。那么对于攻击者来说如何在如此庞大的代码体系中找到漏洞呢?

       这种审计思路应该普遍是一样相通的。关键函数的定位、危险函数的逆向追踪、可控点的跟踪等等。那为什么这种应用的漏洞明明存在这么简单的漏洞还爆发得较少呢?依我看,它的难点不在于审计思路,而是在于知识库的储备和经验问题上。面对这种庞大不熟悉的应用,功能多样,逻辑复杂,代码风格迥异,已经可以让一大群人退却。再者,对于这种大应用,很多人都抱着“它怎么会出漏洞”的心态,无条件信任,更不会去view。应了那句话,只要有足够的能力、足够的耐心,那么没有一个系统将会是安全的。

       二. 态势感知

       当漏洞一爆发时,如何能做到正确合理推出漏洞将会造成的影响,是一个有趣的问题。像许多安全公司都有着自己的一套系统,比如zoomeye、天眼等,凭借着安全大数据与态势感知技术,能快速有效地持续监测互联网攻击、漏洞、网站安全状况和僵尸木马蠕虫等,并作出预警响应。认清漏洞的危害程度是一件很重要的事情,但有些漏洞被严重低估,那么其造成的影响和价值会不可估量,而这些经常会被有心人给利用(机会是留给有准备的人的)。在漏洞的存在周期中,我们应把它最大价值地进行利用。

       那些有能力的人通过海量数据的实时监测、实时分析、追踪分析技术、可视化的能力来提供准确可靠的信息,但对于我等屌丝如何能赶上这样的浪潮呢?

       1. 敏锐嗅探到漏洞的价值。精力毕竟有限,我们尽量地使付出和收益成正比。展开联想,找到漏洞的范围。

       2. 集中一个方向深究。通过对一个方向上的研究,由点发散到面。

       3. 拥有属于自己的弹药库,快速实现自动化。收集确定目标,打造复杂漏洞利用的自动化。

       以后有了具体例子成果后再详细补充。

       三.  漏洞利用

       利用漏洞时,我们应根据思路、发挥想象,将漏洞潜在的价值真正发挥出来。

       下面以ImageMagick 为例。

       CVE-2016-3714是由于其不完全过滤而导致的命令执行,而CVE-2016-3718、CVE-2016-3715、CVE-2016-3716和CVE-2016-3717则是根据ImageMagick本身的特性或者是它可支持的协议而产生的。相对而言,如果是黑盒测试会更容易测出来。这一连串的漏洞是否就完了?我不这么认为。ImageMagick的复杂性决定了它所带来安全隐患的大小,只要用足够的耐心去把它的文档读完,并根据该CVE连续产生的思路,举一反三,相信ImageMagick还有其它的复杂点的漏洞产生。

       拓展

       我们可以用上述思路去分析FFMpeg漏洞(CVE-2016-1897和CVE-2016-1898)

       FFmpeg是一套可以用来记录、转换数字音频、视频,并能将其转化为流的开源计算机程序。功能非常强大,是每个视频网站必不可少的多媒体文件处理程序。

       在FFMpeg2.X 由于在解析HTTP Live Streaming流媒体m3u8文件处理不当,可导致SSRF漏洞与任意文件读取漏洞。

       触发漏洞时机:当网站允许用户上传多媒体文件,并使用FFMpeg进行处理时会触发该漏洞。

       该漏洞有两个CVE编号,CVE-2016-1897和CVE-2016-1898,它们两个的区别在于读取文件的行数,CVE-2016-1897只能读取文件的第一行,而CVE-2016-1898可以读取文件任意行,原理差不多。

       但究其本质CVE-2016-1897到CVE-2016-1898是一种思路的体现。ffmpeg用concat协议可以读取文件的第一行,但终究意义不大,所以要进一步探究其它功能来扩大危害。FFMpeg可支持一个截取数据流片段的功能:subfile。用法:subfile,,start,153391104,end,268142592,,:/media/dvd/VIDEO_TS/VTS_08_1.VOB。既然可以截取数据流就可以利用subfile获取比较完整的文件了。由于测试时候一次最多只能截取32字节,所以要继续用concat合并多个数据流片段。第二个CVE就这么出现了。

       同理,在脚本语言中开发者也常使用FFMpeg来处理多媒体文件。在白盒审计中多多留意这些功能代码的调用,如果代码中用来此API的调用,那么漏洞就确立了一小半,剩下的则在于站长是否将服务器的ffmpeg升至最新版本。

       那么如何快速找到漏洞目标,定位关键呢在我看来,可以从两方面去找,一是白盒,通过github等平台上的开源代码,根据关键函数名,找到对应的cms,确立漏洞后再全网censys或撒旦进行广撒网;二是黑盒,寻找具有该功能的网站,比如具有该功能的网站一般是什么类型的,一般是不开源的CMS,视频类、商城类等等,可以更加方便地进行搜索,精准度较高。同时,也不要忽视app所带来更为严重的安全问题。另外,值得注意的是脚本语言的范围,很多人都只分析了php、java这种主流语言的漏洞exp,但对于ruby、nodejs等‘新型’语言而言,是否会有类似的漏洞呢。客观看待一事物时,还得跳出既定的圈子。

       总结

       在漏洞爆发的那一刻,我们储备的知识程度和对漏洞思想的理解程度决定了我们究竟将会成为什么样的人。看客?脚本小子?漏洞分析人员?发现者?还是像我一样默默啃shi的人?......

标签:none

还不快抢沙发

添加新评论

captcha
请输入验证码

最新文章

最近回复

  • lynahex:好的。
  • xdxd:友链已加~~~希望有机会多多交流~~
  • lynahex:恩,重测了下是可以的。可能当时一些危险函数被我禁掉了。 thx
  • 过客:虽然博主文章过了好久了,本地system测试还是可以执行的
  • 友情链接

    分类

    其它