利用ImageMagick命令执行漏洞拿下Facebook四万美元奖金

前言

我相信很多人都知道ImageMagick和它存在的漏洞，这个漏洞发现于2016年四月底，同时，由于许多插件都依赖于这个ImageMagick库，因此，这个漏洞的影响范围很大。有证据表明，关于这个漏洞的信息，发现它的研究人员是知道的，ImageMagick开发团队的人也知道，但是，糟糕的是，一些其它的人(坏人)也知道了这个漏洞，在2016年5月3日，在互联网上发现了这个漏洞的POC。许多研究人员发现了这个问题，而且应用程序还没有及时更新。但由于一些未知的原因，我不在其中，但这是在5月份。

漏洞分析

直到十月的一个星期六，我对一些大的服务(不是Facebook)进行了测试，当时一些重定向让我关注到了Facebook。这是一个《分享到Facebook》对话框：

链接是：

https://www.facebook.com/dialog/feedapp_id=APP_ID&link=link.example.tld&picture=http%3A%2F%2Fattacker.tld%2Fexploit.png&name=news_name&caption=news_caption&description=news_descriotion&redirect_uri=http%3A%2F%2Fwww.facebook.com&ext=1476569763&hash=Aebid3vZFdh4UF1H

大家可以看到，如果我们仔细看，我们可以看到在URL中有一个“picture”参数。但是在上面提到的页面内容中，这并不是图片URL，例如：

https://www.google.com/images/errors/robot.png

变成了：

https://external.fhen11.fna.fbcdn.net/safe_image.phpd=AQDaeWq2Fn1Ujs4P&w=158&h=158&url=https%3A%2F%2Fwww.google.com%2Fimages%2Ferrors%2Frobot.png&cfs=1&upscale=1&_nc_hash=AQD2uvqIgAdXgWyb

我首先考虑到了一些关于SSRF的问题。但是测试显示，这个URL中的参数请求来自于31.13.97.*网络，通过“facebookexternalhit/1.1”参数，如下：

它看起来像独立服务器的正常请求。我开始深入挖掘。在对这个参数进行一些测试后，我很失望，没有一个成功，ImageTragick是最后一点希望。如果你不熟悉这个问题或有点懒惰，这里有一POC链接。下面是一个简单的exploit.png载荷：

但是当我监听端口时，什么也没发现：

不过，如果有一些防火墙限制呢?-我问我自己。

好吧，通常一些公司会过滤正常的请求，但是不会过滤DNS，让我们再试一个载荷：

结果是：

这个IP是谁的呢?看下图：

成功了!

让我们总结一下，应用程序的工作流程是：

获得“picture”参数，并向它发出请求，这个请求是正常的，没有漏洞。

收到一个图片，这个图片经过了converter的转换，而它使用了有漏洞的ImageMagick库。

说实话，我试图找到一个通用的方法来利用这个HTTP请求，但是经过简短的测试后，我发现所有向外的端口都被关闭了，我花了很长的时间去找一个能打开的，没有成功，我需要找到另一种能让POC有效的方法。

载荷：

回应是：

下面是“id”返回的信息：

为了充分证明存在这个漏洞，我给Facebook安全团队提供了“cat/proc/version”的结果，在这里我就不公布它的结果了。

根据Facebook负责任的漏洞披露政策，我没有进行更深的研究。

我和Facebook安全团队的Neal研究员讨论了最初的报告，“cat/proc/version | base64”可能更好，同时，一些更深层次的研究表明，“base32”在包括DNS隧道的各种技术中是比较常用的(请看：https://www.sans.org/reading-room/whitepapers/dns/detecting-dns-tunneling-34152)。

我很高兴成为攻破Facebook的人之一。

时间线