5月20日晚上，我花了几天时间研究雅虎的Messenger应用程序。但是我依然无法搞清楚背后的工作管理。所以我走出了外面走走，决定找到一个新的目标。我发现了另我我感兴趣的事情是，那就是名为Sean的某个研究人员在参与雅虎的Bug奖励计划时，测试范围超出了雅虎的允许范围而被列入了黑名单。

回来房子之后，我跟好友Thomas讨论之后，我决定研究安全研究人员(Sean)被列入黑名单之前测试的应用。

步骤1：侦察

从Sean给出报告来看，这些公司的域名包括如下

* .mediagroupone.de 
* .snacktv.de 
* .vertical-network.de 
* .vertical-n.de 
* .fabalista.com

虽然有不少的域名出现在Sean的报告中,但是他的报告大部分的时间都是针对于SnackTV的内容管理系统，我和Thomas决定重复Sean使用的方法，针对SnackTV的www站点为目标，因为Thomas已经在这个站点上花了一些时间，同时也找到了一些XSS盲打漏洞。并且这个站点跟其他站点有所不同，原因有两点：（1）这是个德国公司，（2）这是为视频制作者准备的开发者网站。

SnackTV的搜索页面。很明显，这是一个视频网络，但注册的用户必须人工审核，因此我们无法直接访问该网站上的上传页面。

步骤2：扫描

我和Thomas在查看新范围时,都会后台运行一些工具，我使用了“subbrute”以及“dirsearch”这个工具。

后台运行这些工具一段时间后，我们收到了大量的输出，但是并没有多大帮助。大多数信息是非常标准的响应信息，如“.htpasswd”被阻止在标准的HTTP 403错误之后，“admin”页面重定向到登录页面等等。然而，最终，dirsearch发现了一个脆弱点。

有问题的文件名是“getImg.php”隐藏在“imged”目录（http://snacktv.de/imged/getImg.php）后面。经过一些环顾之后，我们意识到这个文件可以通过Google dork“sites：snacktv.de filetype：php”公开访问。

这一步非常重要，因为易受攻击的文件需要GET参数才能返回内容。如果我们要知道GET参数，可能需要几周的时间来猜测，很少有人去猜GET的参数，因为它们通常还需要另外的参数配合才可以。

所需GET参数的示例

1、访问“http://example.com/supersecretdevblog.php”：返回HTTP 500内部服务器错误

2、访问“http://example.com/supersecretdevblog.php?page=index&post=1”：返回HTTP 200响应

我们到目前为止知道信息如下

1、文件“getImg.php”采用多个HTTP GET参数，如果通过“imgurl”参数提供了图像的链接，将自动下载修改的图像文件。

2、根据Google搜索中出现的参数,我们知道裁剪函数使用ImageMagick。

步骤3：访问及获取权限

从获取的信息我们得知这个网站使用了"ImageMagick",第一时间就想到了“ImageTragick”(CVE-2016-3714)，并决定测试几个POC。

我和Thomas花了几个小时的时间，构造包含漏洞载荷的图片文件。漏洞利用的原理是把svg图片文件（即包含载荷的图片文件），交给ImageMagick”命令行工具处理，ImageMagick存在漏洞，导致处理过程中存在任意命令执行漏洞。然而我们的poc没有一个成功，我们怀疑他们已经打了ImageMagick补丁。

我们发往服务器的paylod如下所示。图片地址使用的是我们的私人域名，将载荷上传到服务器后，我们通过“imageurl”参数获取服务器上的载荷图片。我们的目标是使服务器执行一条任意命令。请注意其中“xlink:href”所指向的图片地址。

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
<svg width="640px" height="480px" version="1.1" xmlns="http://www.w3.org/2000/svg"; xmlns:xlink= "http://www.w3.org/1999/xlink";>
<image xlink:href="https://example.com/image.jpg"|ls "-la" x="0" y="0" height="640px" width="480px"/> </svg>

除了服务器在处理文件所属的URL地址上有点奇怪之外，一切都很正常。我们向服务器发送了一些随机的文本文件，服务器返回的数据总是与上一次调用相同。我们仔细阅读了“ImageMagick”相关资料，结合漏洞披露细节，我们发现服务器似乎不存在这个漏洞，也有可能服务器没有使用ImageMagick。我们暂缓攻击这个文件，决定看一下网站是否存在其他漏洞。

貌似在凌晨3:30时，我们发现了存储型跨站脚本漏洞、HTTP 401响应注入漏洞以及常见的管理不当问题，但这些都不是关键问题。当你在参与bug奖励计划、这些漏洞奖金通常会大幅缩水，因为这些问题的影响非常低。在某些人眼里，拿到打折的奖金还是可以接受，但对其他人而言这只是在浪费时间。收购的子公司为目标的唯一好处在于，许多人在这些目标上会放松安全警惕性。

重新回到URL地址后，我变得有些烦躁，开始怀疑服务器在处理图片文件的具体实现。如果雅虎没有将图片作为一个整体来处理，而是采用将URL注入到XML中的“image xlink:href”的处理方式呢，这种方式与漏洞PoC中的情况类似。那么我需要尝试哪种载荷才能验证我的猜想？

我在浏览器的地址中附加了一个额外的双引号，然后看到了一些有趣的输出信息，如下所示：

请求：

GET /imged/getImg.php?imageurl=" HTTP/1.1
Host: snacktv.de
Connection: close
Upgrade-Insecure-Requests: 1

服务器响应：

By default, the image format is determined by its magic number.
To specify a particular image format, precede the filename with an image format name and a colon (i.e. ps:image)...
... or specify the image type as the filename suffix (i.e. image.ps). Specify file as - for standard input or output.

我之所以使用这个请求，是因为在之前的PoC所使用的XML文件中，我们是在URL实体上使用了双引号（可能单引号也可以）。如果我们向服务器发送一个双引号，就可以迫使服务器跳出这个逻辑处理区域，然后获取服务器上写入命令位置的写权限（参考前文引用的PoC）。

看来服务器的确使用了ImageMagick！在某种程度上，我是否打破了服务器的执行流程呢？这是否就是命令行的输出？我应该接着发送更多请求。

请求：

GET /imged/getImg.php?imageurl=";ls HTTP/1.1
Host: snacktv.de
Connection: close

服务器响应：

By default, the image format is determined by its magic number.
 To specify a particular image format, precede the filename with an image format name and a colon (i.e. ps:image)...
 ... or specify the image type as the filename suffix (i.e. image.ps). Specify file as - for standard input or output.
 [redacted]
 [redacted]
 index.php
 getImage.php
 [redacted]
 [redacted]

我发送上面列出的字符串的原因是逃避第一个命令范围。在Linux环境中，您可以将分号附加到初始命令中，并开始编写第二个命令。这对攻击者很有用，因为它允许在初始预定义内容之外执行。

在这一点上我很兴奋。我在渗透测试生涯中首次实现命令注入。在此之前，我愚蠢的认为发送引号和分号来试图实现命令注入这是一种不现实的想法，但这一次完全改变了我的观点。不久之后，我通过HackerOne针对雅虎的bug赏金计划报告了这一点。我在24小时内收到了一个回复，并将该bug修复了六个。

结论

你以为会有四步？不，不。我们是白帽的黑客…记得吗？

 奖励：$ 3,000

 CVSS得分：9.9