一、前言
时间回到5月20日的那天晚上，在这之前，我花了好几天的时间研究了雅虎的Messenger应用，依然无法搞清它的工作原理，同时烦人的头痛和脖子疼痛又找上了我。因此我决定出去走走，找找新的目标。然后我注意到某件非常有趣的事情，那就是名为Sean的某个研究人员在参与雅虎的Bug奖励计划时，因为测试行为超出了雅虎的允许界限而被列入黑名单。
回到屋内后，我与好友Thomas（dawgyg）做了一番交流，我们一致认为可以再研究一下Sean被列入黑名单之前测试的那个应用。
二、步骤1：侦察踩点
Sean的目标是被雅虎收购的一些子公司，在他写的那份白皮书中，这些公司所使用的域名包括：
|
1
2
3
4
5
|
*.mediagroupone.de
*.snacktv.de
*.vertical-network.de
*.vertical-n.de
*.fabalista.com
|
虽然上面有不少域名，但在Sean的报告中，主要针对的是SnackTV的内容管理系统。我和Thomas决定重复Sean使用的方法，并以SnackTV的www站点为目标，这样做的原因在于Thomas已经在这个站点上花了一定时间，同时也找到了一些XSS盲打漏洞。这个站点与其他站点有所不同，原因有两点：（1）这是个德国公司，（2）这是为视频制作者准备的开发者网站，并不是为普通的雅虎用户准备的。
上图是SnackTV的搜索页面。很明显这是一个视频网站，但用户注册必须经过管理员的人工审查，因此我们无法直接访问该网站的上传面板。
正当Thomas正在忙于自动化扫描这个网站时，我花了些时间来培养与这个应用的感觉（理解某些事物不正常反应的基础通常是能够理解它们的正常反应是什么）。
三、步骤二：扫描
在挖掘这个应用的脆弱性时，我和Thomas都在做的事情就是运行与这个特定应用有关的后台任务。我使用了“subbrute”以及“dirsearch”这两个被动识别脚本，目的在于（1）挖掘直接漏洞以及（2）探测可能存在漏洞的内容。理解如何使用这些工具可以帮助渗透测试人员挖掘漏洞。
花了很长时间运行这些工具后，我们收获了大量的输出，但对我们的帮助并不大。这些输出信息中大多数都是标准的错误信息，比如访问“.htpasswd”时出现的HTTP 403错误、“admin”页面无法直接访问被重定向到登陆页面等。然而，使用“dirsearch”脚本经过大量关键词列表匹配后，最终我们的确收获了一个脆弱点。
存在问题的文件名为“getImg.php”，该文件位于“imged”目录中（http://snacktv.de/imged/getImg.php）。经过一番查找，我们发现通过Google搜索“site:snacktv.de filetype:php”能公开访问这个文件。这个步骤很重要，因为存在漏洞的这个文件需要GET参数才能返回内容。我们可能需要花费数周时间才能暴力破解或者猜测出正确的GET参数，我猜没有人愿意这么做，因为这些参数通常还需要与另外一个参数配合才能执行正确的查询请求。
GET参数的典型逻辑处理流程如下所示：
1、访问“http://example.com/supersecretdevblog.php”：返回HTTP 500内部服务器错误，表明我们必须提供参数才能查看内容。
2、访问“http://example.com/supersecretdevblog.php?page=index&post=1”：返回HTTP 200响应，表明参数正确，有可能会返回敏感信息。
目前为止，我们知道的信息包括：
1、“getImage.php”文件需要多个HTTP GET参数，如果我们通过“imgurl”参数提供一个图像的链接地址，那么这个文件就会根据这个地址自动下载一个被修改过的图片。
2、根据Google搜索暴露的参数，我们知道这个文件与ImageMagick的裁剪函数有关。
四、步骤3：漏洞访问及逻辑逃逸限制
当挖掘出这些信息后，我们想到的第一点就是“ImageTragick”漏洞（CVE-2016-3714），我们决定发送几个测试载荷试试。
我和Thomas花了几个小时的时间，构造包含漏洞载荷的图片文件。漏洞利用的原理就是利用热点图片文件（即包含载荷的图片文件），服务器会使用 “ImageMagick”命令行工具处理这个图片文件，由于这个工具过滤不严格，导致处理过程中存在任意命令执行漏洞。然而我们的载荷没有一个成功，这让我们有点灰心丧气。我们怀疑他们是否已经针对这种载荷文件打上了补丁。
我们发往服务器的载荷样例如下所示。图片地址使用的是我们的私人域名，将载荷上传到服务器后，我们通过“imageurl”参数获取服务器上的载荷图片。我们的目标是使服务器执行一条任意命令。请注意其中“xlink:href”所指向的图片地址。
|
1
2
3
4
|
<?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" rel="external nofollow" x="0" y="0" height="640px" width="480px"/> </svg>
|
除了服务器在处理文件所属的URL地址上有点奇怪之外，一切都很正常。我们向服务器发送了一些随机的文本文件，服务器返回的数据总是与上一次调用相同。我们仔细阅读了“ImageMagick”相关资料，结合漏洞披露细节，我们发现服务器似乎不存在这个漏洞，也有可能服务器没有使用ImageMagick。我们暂缓攻击这个文件，决定看一下网站是否存在其他漏洞。
大约在凌晨3:30时，我们发现了几个存储型跨站脚本漏洞、HTTP 401响应注入漏洞以及常见的管理不当问题，但这些都不是关键问题。当你在参与bug奖励计划、特别是对某个子公司进行测试时，这些问题的奖金通常会大幅缩水，因为这些问题的影响非常低。在某些人眼里，拿到打折的奖金还是可以接受，但对其他人而言这只是在浪费时间。以被收购的子公司为目标的唯一好处在于，许多人在这些目标上会放松安全警惕性。
重新回到URL地址后，我变得有些烦躁，开始怀疑服务器在处理图片文件的具体实现。如果雅虎没有将图片作为一个整体来处理，而是采用将URL注入到XML中的“image xlink:href”的处理方式呢，这种方式与漏洞PoC中的情况类似。那么我需要尝试哪种载荷才能验证我的猜想？
我在浏览器的地址中附加了一个额外的双引号，然后看到了一些有趣的输出信息，如下所示：
请求：
|
1
2
3
4
|
GET /imged/getImg.php?imageurl=" HTTP/1.1
Host: snacktv.de
Connection: close
Upgrade-Insecure-Requests: 1
|
服务器响应：
|
1
2
3
|
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！在某种程度上，我是否打破了服务器的执行流程呢？这是否就是命令行的输出？我应该接着发送更多请求。
请求：
|
1
2
3
4
|
GET /imged/getImg.php?imageurl=";ls HTTP/1.1
Host: snacktv.de
Connection: close
Upgrade-Insecure-Requests: 1
|
服务器响应：
|
1
2
3
4
5
6
7
8
9
|
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小时以内），我就收到了漏洞响应，并且漏洞已经被顺利修复。
五、总结
你是不是还想看步骤4？不不不，我们是有职业操守的黑客，要牢记这一点 :-)
搞定SnackTV之后，我意识到不完美的逻辑实现将会带来何种严重的后果。目标服务器不会受到通用的ImageTragick漏洞影响，因为它没有遵循标准的格式，而是使用类似的自定义处理格式。如果你在测试中无法确定目标是否存在漏洞，你可以尝试换个思路，从根源上查找漏洞攻击方法，思考漏洞接受什么输入、什么情况下会触发漏洞、你能输入的数据最长可以多长、服务器返回的响应会有什么不同等等。
在雅虎的这种大型应用上花费这么多精力显然是值得的，特别感谢dawgyg在百忙中与我一起测试。
顺便说下，漏洞奖励为3,000美元，漏洞的CVSS评分为9.9分。
本文转载自 samcurry.net，作者：興趣使然的小胃