【第1040期】浏览器漏洞挖掘思路

前言

最近被运维吊打了，之前开发的时候点被遗漏。今日早读文章由@Masato Kinugawa分享。

正文从这开始～

在 Web 安全中，服务端一直扮演着十分重要的角色。然而浏览器的问题也不容小觑，它也会导致信息泄露等诸如此类的问题。然而许多人还没有意识到浏览器对于安全的重要性。在这篇讲座（文章）中，我们会给读者带来挖掘浏览器漏洞的思路。

挖掘漏洞的思路

确定目标

我们先来看看浏览器的大概结构：

• DOM 解析 （HTML, XML, SVG, MathML, XUL）

• 脚本处理 （JavaScript, VBScript, asm.js, WebAssembly）

• 协议支持 （HTTP, FTP, WebSocket, HTTP/2, QUIC, DNS, mDNS, WebRTC）

• 媒体流支持 （JPG, GIF, PNG, WebM, Ogg, AAC, MP3, MP4, FLAC）

• 包含的中间件（Skia, ffmpeg, ICU, NSS, OpenVR, libpng, sqlite）

• 各种 API（Fetch API, Push API, Extension API, Fullscreen API, Web Speech API）

• UI 组建（Location Bar, History, Bookmark, Context Menu）

• 安全功能（SOP, XSS Filter, CSP, SRI, TLS, Mixed Content, HSTS, HPKP, CT）

• 便利功能（Chrome Extension, Reading View, Secret Mode）

• 其它

我们应该如何从诸多功能中选取攻击目标？这时，我们可以这样入手：

检查新功能

刚刚公布的功能往往没有被太多的人研究，因此更有可能存在潜在的隐患。因此，我们可以试着在下列产品挖掘漏洞：

• Firefox Nightly

• Chrome Dev, Canary

• Safari Technology Preview

• Edge的最新版本

更新时，我们最好注意一下它们的发行日记或者开发者的 blog。这样我们可以在最短的时间内得知新加入的特性。

Firefox 在该版本中提供了 link 预加载，这看上去十分有趣!这时，白帽子们可以以此功能为基础，对其进行安全检测，或者思考能否用它扩展供给面。

这是能让我们获取一手消息的相关平台：

检查冷门的老功能

这些功能常常不被人们重视：

• 非标准化功能

• 冷门功能

• 常规插件

同样地，我们也可以通过发行记录，或者从已有的研究报告中来探索这些功能。

打个比方：

我用 dialogArguments/returnValue 时，发现数据可以传输到任意窗口，此处是否有 SOP 绕过漏洞呢？

在用 Dailog 时，用户不能操作其它窗口，这有没有可能引发 UI 相关的问题呢？

枚举法 — 延伸已经存在的漏洞

我们可以去挖掘一下常见机制的问题：

• JavaScript 的 HTTP 通信机制（sendBeacon，Fetch，Worker）

• 浏览器弹窗机制（alert，confirm，getUserMedia）

• MIME 类型（text / javascript, image / svg + xml, application / octet-stream ...）

研究已经被列为高危的功能也很奏效：

• windows 对象

• HTTP 泄露

• HTML5 Security Cheatsheet

通过枚举法，我们能更好地集中到有效目标上。比方说：

在这里，我们可以得知IE可以运行 CSS 里的脚本，这是否意味着我们可以用它来进行 XSS 或者过滤器绕过呢？

从 commit 历史中挖掘漏洞

我们可以通过 git 历史来发现有趣的特性，比如说：

• 对移动系统的支持（3d Touch, Spotlight, Universal Links)

• 正在完善中的功能（Web App Manifest, Geckoview)

那么，我们如何发现值得关注的点呢：

• 已经被开发者标明为高危的功能

• 实现复杂的第三方库(SQLite, Alamofire)

我们再来看个例子，这是一个 Chrome 的 commit 记录：Https://goo.gl/xo6MMV

在 commit 之前，chrome 并没有对国际化字符进行一个良好的处理，以下图片的 a 实际上是Cyrillic 字符集的 U+0430（并不是英语的 a0）:

而:则是 U+0589，/是 U+2215

我汇报了这个问题，不过谷歌的解决方法是简单粗暴地禁用国际化域名。

这个 commit 记录则增加了两个潜在的攻击点：

• 用 SQLite 存储数据是否意味着有 SQL 注入？

• 将变量插入到页面中时候会导致 XSS?

当浏览器的一个功能有如下特点时，就往往意味着该功能有问题：

• 将 URL 给 API，它会返回特定的标志

• CSP 运行异常

• 你能发送任意 header 给一个目标

如果你知道要攻击的具体目标，那么你可以检查：

• location 返回的值

• 函数的行为

• CSP 实现是否正确？

• 寻找字符集漏洞

通过浏览器对字符集处理的不当，我们可以挖掘许多问题。

各个浏览器对字符集的支持：

比方说 CVE-2013-5612，当你在 POST 请求中不指定字符集，那么它就会默认使用上一个被指定的字符集。我们可以利用支持上的差异性来达到绕过 XSS Auditor

寻找第三方库的漏洞

在 Pwn2Own 比赛中，来自长亭科技的研究人员成功地利用 SQLite 的内存损坏攻破了 Safari。同理，我们也可以在下面的lib中寻找漏洞：

其它攻击面

浏览器解析特殊协议（比如 about）也可能产生种种问题。当我们在 firefox 输入about:neterror?e=nssBadCert&d=Hello%20Guys!时，会有：

不忘学习前人经验

在我们找漏洞的同时，不要忘记学习前人的思路，我们应该多想想这些问题：漏洞是什么类型的？他们是怎么找到漏洞的？这个漏洞又为何出现的？

我们可以通过 Security Advisor（mozilla，chrome），以及私人 blog 来学习寻找漏洞的过程。

深入研究目标

为了深入探索一个目标，我们需要了解一下特性：

• 这个功能是用来干什么的

• 如何使用它

• 输入和输出是什么

• 有没有什么过滤

• 我们能否利用它绕过安全机制

• 我们能否用它攻击安全站点

那么，我们应该用什么手段去深度挖掘呢？

• 亲自使用一遍

• 审计代码

• 审计可执行文件（反汇编）

• 查看软件 log

就拿 Fetch API 来说：

fetch('http://api.example.jp/path',{  //我在这里能代入哪些地址？
 method:'POST',                        //我还能添加哪些方法?
 headers: {
   'Content-Type':'text/plain'           //这里是否能插入其它header或者MIME类型?
 },
 body:'Hello World!'                   //body能插入哪些文字?
 }).then(function(res){
   console.log(res.headers.get('Content-Type')); //我能读取哪些header的值?
 }).catch(function(err){
 console.error(err);                   //抛出的错误时候包含了敏感信息?
});

一个通过逆向找漏洞的例子：

edge 的一个 dll 包含了 XSS 过滤器的正则表达式，我们通过反向推导，或许可以找出 bypass payload。

探索有趣的行为

当我们发现了一些异常行为时，我们需要继续留心，因为这往往意味着更深层次的漏洞：

• 跳转后，地址栏不更新 (URL Spoof)

• 某个输入导致浏览器崩溃或者暂停响应

• HTML tag 不正常运行

• 文字乱码

比方说 CVE-2012-3695，我们输入https://aaa%http://[e-mail]/时，%2F会被解码，并返回https://aaa/@http://example.com/。本来被用做认证的 aaa%2F 被转化成了一个域名，这很有可能导致网络钓鱼。

挖掘这类漏洞有什么技巧呢？我们可以通过检查如下功能：

• URL scheme (http:, https:, ftp:, data:, resource:, about:, chrome-extension:)

• Request method (GET, POST, HEAD, OPTIONS, TRACE)

• 浏览器怎么输出相关信息 (iframe, object / embed tag, svg foreignobject, Reading View)

• 浏览器怎么获取资源(img标签, video/audio标签, Worker的importScripts)

• 打开新 URL 的方法(Location头, meta刷新, window.open, 浏览器的返回键)

• 非常规输入（过长的字符串，HPP，空值，过大的数字，负数）

• 枚举各种其他元素

• 来快速发现可能的隐患。

举几个例子：

在 CVE-2017-7789中，如果 firefox 在响应中收到多个 HSTS 头，那么 HSTS 就不会被启用。这时只要攻击者在普通的 HTTP 响应中包含几个 HSTS 头，那么他/她就可以绕过 HSTS 机制。

而在CVE-2015-4483里,我们在`feed:`后添加 URL，就可以绕过 Content Mixed Blocker

漏洞利用

当你找到一个漏洞后，你应该如何利用它呢：

想象如何在现有 Web 应用中利用

• 因为这一漏洞，我们可以攻击原本安全的网页

• 这个漏洞会导致浏览器安全机制失效

就算不能在某些场景利用，你也要考虑可以利用它的理想环境

如果这个网站是这样（设想状态）实现的，那么我们可以如何如何（攻击）

如果这个设想相对靠谱，那么该漏洞可能在特定环境有效

让我们来看看 firefox 插件的一怪异行为，虽然我们可以利用该漏洞对页面的 title（标签页的标题）进行 HTML 注入，然而由于 CSP，我们并不能触发 XSS。

当我们仔细观察%TITLE%，%CONTENT%的顺序后，就会发现一个模板注入漏洞：

这样的话，只要我们插入 form 元素到%TITLE%时，即使不能 XSS，也能外带%CONTENT%给攻击者。

在实际情境中，许多网站会将用户输入插入到页面 title，就拿 Google 来说：

然而获取别人的搜索结果似乎没什么卵用，我们是否能得到更敏感的资料呢？

Gmail 似乎是一个不错的目标，我们可以发送一封恶意邮件给目标，当他/她展开该邮件时，页面 title 会更换为邮件标题：

当用户点击 Click Me 时，邮箱信息就会被传送给攻击者

至此，我们成功地将该漏洞变废为宝。

最后，为你推荐：

关于本文

作者：@Masato Kinugawa

原文：https://zhuanlan.zhihu.com/p/28719766