转载

白帽笔记:我的“一日一洞”高效漏洞挖掘之旅

白帽笔记:我的“一日一洞”高效漏洞挖掘之旅

作者:Shubham Shah,澳大利亚安全研究人员,专注于程序开发、渗透测试和黑客技术。2016年初被安全媒体评为10大著名“漏洞赏金猎人”之一。本文原名《高效漏洞挖掘:120天120个漏洞》

2016年初,我就给自己设定了一个目标:在这一年中,平均每天挖掘出一个漏洞。这个决定完全是一种自我挑战。我想回到过去 在 Atlassian 公司时候的 状态,当时,我曾经在一个月内每天都发现了一个漏洞,这些漏洞涉及Atlassian公司所有外部程序。

1   挖洞计划介绍&动机

1月初,我就积极准备进行我的高效漏洞挖掘计划,刚开始,我曾在一天之内发现了多个漏洞,然而,随着时间的推进,我觉得在一天之内找到多个漏洞是件非常耗费脑细胞的事,而且在挖洞过程中,我经常感到身心疲惫。

最终,经过120天之后,我结束了这种“日均一洞”的计划。但是,我对自己在漏洞挖掘方面多少有了些体会:

(1)寻找一些新的意想不到的技术方式去拿下目标

(2)把关注重点放在那些自己感兴趣的漏洞上面

(3)通过漏洞奖励平台结交从事安全研究的朋友或同龄群体

2   我发现的漏洞

以下就是我在120天之内挖掘的121个漏洞列表一览:(全部漏洞请参看博客 Table1 )

白帽笔记:我的“一日一洞”高效漏洞挖掘之旅

3   分析

以下统计表是对我发现的121个漏洞的大致分类,另外,还有一些杂项漏洞没有包含在内

白帽笔记:我的“一日一洞”高效漏洞挖掘之旅

出于漏洞奖励平台的工作机制,很多提交漏洞可能还处于缓解开发或保密阶段。待所有漏洞被修复公开之后,我会继续更新这些信息。

4   方法论

围绕信息系统实体进行漏洞挖掘

“资产”实体可以定义为信息系统的所有组成项,包括:应用程序、目录、文件、文件夹、可执行程序或服务器。当然,也包含大多数云平台服务,如VoIP、文件共享、网络会议等。

对“资产”实体的信息收集,是一个非常有趣的过程。例如,当我正对一家公司使用的软件开发组件进行信息收集时,碰巧,该公司的某位开发人员在1 小时之前就不小心把这些组件都上传到网上了,哎呀,对我来说,这是多么美妙的事情啊!

编写自己的漏洞挖掘工具

为了保持每天挖掘一个漏洞的节奏,我需要更好的信息系统识别工具,毕竟,想要在一些漏洞奖励项目中发现漏洞已经变得越来越难了,想要获得高额奖励更是难上加难。

为此,我和朋友 Nathan Wakelam 就信息系统的识别方法进行了一些讨论。最终,我们一起编写了三个相关工具:

Altdns : 通过域名前缀序列变化和排列发现子域名的工具

Assetnote : 通过监视跟踪被动API数据发现子域名

Bugbounty Dash : 显示漏洞奖励项目当前的状态信息

目前,Altdns已经获得了同行的一些认可。

值得信任的安全研究人员一起工作

我觉得有效的漏洞挖掘还需要一些外部氛围,如果条件允许,可以与那些 值得信任的安全研究人员或漏洞挖掘者一起工作。 毕竟,拥有一个同路的伙伴会让你觉得有动力。我非常有幸加入了一群出色的漏洞挖掘者当中,他们有我的同事和好朋友。当我处于挖洞瓶颈期的时候,我身边参与漏洞项目的朋友会和我分享他们的新方法和新思路,这能让我继续充满信心。当其它人发现了一些我所不能发现的漏洞,我都把这当成是一种激发自己学习的动力。还有就是,不要把共同参与漏洞奖励项目的同事和朋友当做竞争对手,否则,你永远都得不到进步。

提高漏洞发现视角

有时候,应该学着把漏洞发现视角提高到更高、更广的水平。我知道有一些研究人员就是这样做的,如 @phwd ,他甚至通过参加FACEBOOK的产品发布会,以了解更多关于FACEBOOK的信息。@phwd在参与FACEBOOK漏洞奖励项目中的成功,是我所不能及的,这也决非偶然。

找到在漏洞挖掘之外可以释放压力的方法或爱好

我觉得,应该在信息安全或漏洞挖掘之外,找到一个可以释放压力的方法或爱好。对我自己来说,漏洞挖掘是一个极度深入内心的爱好,每当我忽略了生活中的一些重要部分之后,我就发现自己并不开心。因为热爱过度,陷入太深,有时候我 觉得 自己已经走火入魔了,如果能有一些东西能让我暂时脱离漏洞挖掘工作,即便是一种简单的爱好或者曾经的美好时光,我也愿意。

5   建议

计划一个切实可行的目标

我是从2016年1月开始我的“高效挖洞计划”的,在坚持了两个月左右的“一天一洞”节奏后,我遇到了第一个倦怠期。我犯的最大错误是没有完全理解漏洞发现过程的波动性,从黑盒测试的角度来看, 未被发现的漏洞 是不可量化的,而我自己也不能很好的判断发现漏洞的可能性。在120天的时间里,我曾三次到达了瓶颈期。我每天如果不能按计划发现一个漏洞,情况就会变得更糟;如果在10天之内,我还没有发现一个漏洞,就意味着我必须在一天之内找到10个漏洞。这个计划让我放弃的主要原因在于不断累积的压力。

我支持你 尝试这样的高效漏洞挖掘计划,只是不要和我犯同样的错误–“每天发现一个漏洞”。请你放轻松,制订一个切实可行的目标,而不是陷入恶性循环。

保持心态平和

当你在提交了漏洞之后,你就没有了真正的漏洞处置权。因为,对于漏洞奖励平台来说,这就是一个买方市场。如果一个项目没有达到你所期望的漏洞奖励,就不要参与这个项目。另外,请记住,没有什么神人愿意出高价来收买你的漏洞,或者让你成为黑客新闻头条,也没有什么所谓的“漏洞赏金猎人”联盟或黑市愿意为你的漏洞买单。基本原则是,我们只是付出有效脑力劳动去获取该得报酬的合同工而已,我们的委托公司客户可能是伟大牛逼的,也可能是极不友好的,这就是漏洞奖励平台和商业市场的本质。

如果在参与漏洞奖励项目中,你认为没有得到你该得的报酬,并且和你提交漏洞的公司有一些内部分歧。我建议你看看这两篇关于漏洞奖励的博文 《我是如何成为一个成功的漏洞赏金猎手》 、 《5年漏洞奖励平台记录和感想》 ,或许你可以从中得到一些新的观点和想法。

加入那些友好而热情的漏洞奖励项目

找到并加入那些对待漏洞研究者非常友好的项目,这些项目把漏洞研究人员当成他们自己安全团队的一部份。他们给你的回复很及时,报酬很慷慨,并且互相之间很尊重。

以上就是我对自己“高效漏洞挖掘”计划的一些观点, 很乐意和大家分享,也希望大家提出一些意见或建议。

6   值得关注的漏洞1:二级域名/网页劫持

根据漏洞奖励平台上的一部分漏洞为样本,我发现子域名接管或劫持漏洞的奖励范围比较大,可以从 $100 到 $7,500不等。这虽然不可思议,但可能是一些公司在漏洞严重程度上有着很大的不同对比。幸运的是,我曾在一个邀请的漏洞众测项目发现过子域名劫持漏洞,并且获得了高达$7,500的奖励。这个项目为大多数有效漏洞支付了高额的奖金,他们努力修复漏洞并给予子域名漏洞提交者慷慨的奖励。因此,在六个月之后,想找出其子域名劫持漏洞已经变得很难。这就是漏洞奖励平台的作用。

然而,作为一名安全研究者,当你不能找到一种方式来对 子域名进行 劫持时,你会怎么做?这就是二级子域名劫持该发挥作用的时候了。Web应用程序非常复杂,它可以加载10多个主机发起的应用和不计其数的请求内容。例如,我们可以在wufoo.com类型中嵌入框架或者在Amazon S3 中嵌入JavaScript。有更多关于动态内容通过网页嵌入第三方源的例子,我的大多数子域名劫持漏洞的成功发现都是与wufoo和S3形式相关。

Wufoo 是一个网站应用程序。Wufoo主要帮助人们创建独特的在线表格。 在使用这个Wufoo应用程序设计表格的时候,它会自动生成数据库,后端和脚本,以便用户收集和轻松地理解数据。)

假想一下导致二级域名被劫持的情况:假如你在X公司工作,这家公司已经成立了10多年,并且最近开始了一项漏洞奖励项目。随着X公司各方面不断的发展壮大,在过去的10多年间,其相关网站的CMS系统也创建了大量网页。如果这家公司的网站曾经通过第三方URL的<script>, <iframe>, <svg> 或<object> 等元素嵌入过动态内容,这些动态内容还是存活状态吗?

这里有一个快速判断方法:

(1)创建你的目标网站URL列表(保证尽可能的全覆盖,可以用爬虫方法遍历所有子域名);

(2) 对每个URL发起请求,并寻找<script>, <iframe>, <svg>, <object>等元素,并从中提取link/hostname/URL信息。

(3) 确保在上面元素标签中找到的所有链接仍然有效。如果存在任何无效或过期的资源,请尝试注册并运用它们。

在另外一个漏洞奖励项目中,我发现了很多内嵌框架类似<companyname>.wufoo.com/<formid>的页面,由于这些页面是3-4年前创建的,而其中的wufoo账户好像已经过期。但是,我通过wufoo.com网站注册声称要求重新获得有效的子域名,通过这个方法,最终我成功劫持了目标网站的子域名。利用这种简单的方法却获得了高额的漏洞奖励。

6   值得关注的漏洞2:DOM Based XSS via subtitle tracks

在另外一个邀请的漏洞众测项目中,其中的一个宣传功能是允许用户为一个预先设置好的视频自行制作字幕。它位于以下链接 当中

http://subdomain.privatebounty.com/en/event/community.html

当访问这个链接,会显示很多输入框。在这些输入框中,用户可以插入他们自己的字幕信息。一旦用户输入完字幕,点击执行按钮,字幕文件就被发送至位于远端云平台上的 API中。

由客户端发起的发送字幕文件到API接口的请求如下:

白帽笔记:我的“一日一洞”高效漏洞挖掘之旅

远端云平台 API对以上请求的回应如下:

白帽笔记:我的“一日一洞”高效漏洞挖掘之旅

通过流量观察,我尝试去发现“”user-generated”视频请求信息:

白帽笔记:我的“一日一洞”高效漏洞挖掘之旅

后经发现,API对字幕文件的回应是明文信息。虽然不能通过终端获得持久XSS漏洞,但可以在输入的字幕文件中插入任意代码文件。例如,对于下面的URL请求,在返回字幕信息中可以包含任意JavaScript执行代码:

http://apisubdomain.privatebounty.com/api/v1/usersubs/60d499118de429510449.srt

一旦这个SRT字幕文件已经由API生成,我们可以访问下面这个链接观看由用户自定义字幕的视频:

http://subdomain.privatebounty.com/event/community.html?slug=60d499118de429510449

上面链接中存在一个 JavaScript脚本

http://subdomain.privatebounty.com/events/scripts/shared-app.js

它在网页运行中通过slug ID标识为网页多媒体播放器获取并设置字幕文件。负责设置字幕的代码可以在下面找到:

白帽笔记:我的“一日一洞”高效漏洞挖掘之旅

所以,一旦在字幕文件中插入恶意代码,通过上面 JavaScript脚本的运行,恶意字幕文件就可以从以下链接 加载并注入到受害者的DOM模型中。

http://apisubdomain.privatebounty.com/api/v1/usersubs/60d499118de429510449.srt

由于字幕文件通过SRT文件格式工作,在将它们添加到DOM之前,多媒体播放器默认情况下不会对它们进行审查。这意味着,每一行字幕文件都可以被添加到DOM中(包括攻击者脚本)。虽然HTML在此表现出了重要的可用性,但也带来了安全问题。

当视频播放时,SRT文件中的JavaScript代码就会执行:

白帽笔记:我的“一日一洞”高效漏洞挖掘之旅

我认为有两种方式可以修复这个漏洞:

(1) 审查所有的用户的字幕文件输入,不只是API的响应数据;

(2) 确保多媒体播放器不被插入HTML DOM的恶意字幕文件。 参照

该漏洞在每个支持HTML5<track>标签的浏览器中都验证有效(包括过去2-3年中的所有浏览器)。

最终,我的高效挖洞计划算是成功的吗?我想应该是的,至少我赚了钱,得到了乐趣,提高了技术能力,还加入了优秀的技术团队。虽然最终我输给了身心疲惫,但我总算了解了自己的极限。

*本文译者:clouds,参考来源: shubs.io  ,转载须注明来自FreeBuf.COM

原文  http://www.freebuf.com/articles/web/111139.html
正文到此结束
Loading...