前言
我相信很多人都知道ImageMagick和它存在的漏洞，这个漏洞发现于2016年四月底，同时，由于许多插件都依赖于这个ImageMagick库，因此，这个漏洞的影响范围很大。有证据表明，关于这个漏洞的信息，发现它的研究人员是知道的，ImageMagick开发团队的人也知道，但是，糟糕的是，一些其它的人(坏人)也知道了这个漏洞，在2016年5月3日，在互联网上发现了这个漏洞的POC。许多研究人员发现了这个问题，而且应用程序还没有及时更新。但由于一些未知的原因，我不在其中，但这是在5月份。
漏洞分析
直到十月的一个星期六，我对一些大的服务(不是Facebook)进行了测试，当时一些重定向让我关注到了Facebook。这是一个《分享到Facebook》对话框：
链接是：
大家可以看到，如果我们仔细看，我们可以看到在URL中有一个“picture”参数。但是在上面提到的页面内容中，这并不是图片URL，例如：
https://www.google.com/images/errors/robot.png
变成了：
我首先考虑到了一些关于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的人之一。
时间线
16 Oct 2016, 03:31 am: 初始报告;
18 Oct 2016, 05:35 pm: Neal向我要使用的POC；
18 Oct 2016, 08:40 pm: 我发送了一个POC并提供了额外的信息；
18 Oct 2016, 10:31 pm: Neal确认了漏洞；
19 Oct 2016, 12:26 am: Neal说正在修复漏洞；
19 Oct 2016, 02:28 am: Neal通知我说漏洞已经修复；
19 Oct 2016, 07:49 am: 我回答说，确认漏洞修补，并要求披露时间表；
22 Oct 2016, 03:34 am: 尼尔回答披露时间表；
28 Oct 2016, 03:04 pm: 4万美元的奖励发放；
16 Dec 2016: 披露批准；
本文由 安全客 翻译，作者：pwn_361
原文链接：http://4lemon.ru/2017-01-17_facebook_imagetragick_remote_code_execution.html