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

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

前言

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

漏洞分析

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

利用ImageMagick命令执行漏洞拿下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,例如:

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

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

变成了:

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

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”参数,如下:

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

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

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

但是当我监听端口时,什么也没发现:

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

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

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

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

结果是:

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

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

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

成功了!

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

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

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

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

载荷:

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

回应是:

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

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

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

为了充分证明存在这个漏洞,我给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

来源:51CTO
上一篇:SQL Server中的分页


下一篇:HAWQ技术总结