移動(dòng)瀏覽器中UI漏洞的演變

文/劉保證

大部分移動(dòng)安全研究都專(zhuān)注于惡意應(yīng)用，但對(duì)廣泛被使用的瀏覽器的安全研究卻很少，而移動(dòng)端的瀏覽器和桌面端的瀏覽器一樣容易受到攻擊。論文（Hindsight∶ Understanding the Evolution of UI Vulnerabilities in Mobile Browsers）作者表示這篇文章是首次從事移動(dòng)端瀏覽器的安全研究，專(zhuān)注于手機(jī)瀏覽器的 UI 漏洞。論文作者根據(jù)前人的工作以及自己的調(diào)查，量化了 27 個(gè) UI 相關(guān)的攻擊，針對(duì)于超過(guò) 128 個(gè)瀏覽器家族以及 2324 個(gè)獨(dú)立的瀏覽器版本（跨度超過(guò) 5 年）進(jìn)行了瀏覽器 UI 的安全性研究，基本的步驟如下：（1）從不同的源中收集了不同時(shí)期的瀏覽器樣本；（2）設(shè)計(jì)并實(shí)現(xiàn)了與瀏覽器無(wú)關(guān)的測(cè)試框架Hindsight，自動(dòng)化測(cè)試瀏覽器 UI 的漏洞。

最后，論文作者發(fā)現(xiàn)，98.6% 的瀏覽器至少受到一種攻擊的影響，而且隨著時(shí)間的變化，移動(dòng)端瀏覽器的平均安全性變得越來(lái)越差。因此，論文作者認(rèn)為目前手機(jī)瀏覽器的安全性被嚴(yán)重忽視，也表示手機(jī)瀏覽器的安全應(yīng)該受到重視。

基本攻擊塊

為了評(píng)估移動(dòng)端手機(jī)瀏覽器的 UI 安全性，論文作者首先調(diào)研了之前相關(guān)的研究，以便于找到一些已有的攻擊方法。基于這樣的發(fā)現(xiàn)，他們猜測(cè)瀏覽器和網(wǎng)站交互的方式，并指出瀏覽器嘗試為要渲染的網(wǎng)站提供最大化的空間。通過(guò)不斷地嘗試，作者發(fā)現(xiàn)了已有攻擊的一些變種。此外，為了說(shuō)明這些漏洞既可以被單獨(dú)使用也可以被聯(lián)合使用，作者將每種攻擊都命名為 ABB（Attack Building Block）。更加具體的，如表1所示，作者將收集到攻擊方法分為多種類(lèi)別。從表1中分類(lèi)可以發(fā)現(xiàn)，這里很多的攻擊都是釣魚(yú)攻擊。

數(shù)據(jù)收集

由于論文作者希望測(cè)量近些年來(lái)手機(jī)瀏覽器 UI 漏洞的演變過(guò)程，所以收集了來(lái)自于不同時(shí)期的不同家族的瀏覽器，具體步驟如下：

表1 已知攻擊方法的分類(lèi)

1.使用 Selenium 來(lái)自動(dòng)化地收集 Google Play 中包含browser 關(guān)鍵字的APK，并過(guò)濾一些不是 web 的瀏覽器，比如文件瀏覽器。

2.收集不同版本的瀏覽器。為了獲取舊版本的瀏覽器，作者從不同的網(wǎng)站（Androidapps,Apkhere, Apkmirror, Apkpure,Uptodown, 以及 Aptoide）中，爬取了盡可能多的 APKs。

3.過(guò)濾一些 APKs，比如過(guò)濾相同的瀏覽器。

表2 過(guò)濾和處理瀏覽器的APKs

表3 每年APK和瀏覽器系列的數(shù)量

最后，作者獲取的 APK 的統(tǒng)計(jì)結(jié)果見(jiàn)表2和表3。

可以發(fā)現(xiàn)，在進(jìn)行過(guò)濾之后，最后一共有 2324個(gè)APK。而且，隨著時(shí)間的增加，每年發(fā)現(xiàn)的瀏覽器的 APK 數(shù)量不斷增加。

基本測(cè)試框架

論文作者設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)自動(dòng)化的漏洞測(cè)試框架，Hindsight，基本步驟如下：

1. SDK 分配。由于每個(gè) APK 都會(huì)有 targetSdkVersion 以及min sdkVersion，所以該框架需要為對(duì)應(yīng)的 APK 分配一個(gè)合適的手機(jī)，使得其可以正常運(yùn)行。

2. 安裝以及啟動(dòng)屏幕繞過(guò)。使用 ADB 安裝對(duì)應(yīng) APK，并繞過(guò) APK 啟動(dòng)時(shí)的一些歡迎界面，以及一些提示信息。

3. ABB 測(cè)試。使用預(yù)先編寫(xiě)好的 ABB 的測(cè)試邏輯對(duì)安裝好的 APK 進(jìn)行測(cè)試，并輸出相關(guān)的信息。

4. 結(jié)果評(píng)估。對(duì)輸出的信息進(jìn)行分析，說(shuō)明這個(gè)瀏覽器是否會(huì)受到相應(yīng)的 ABB 的攻擊。

Hindsight 框架的架構(gòu)如圖1所示。

瀏覽器無(wú)關(guān)的 UI 分析的實(shí)現(xiàn)

圖1 Hindsight 框架的架構(gòu)

圖2 手機(jī)端瀏覽器的 UI 漏洞的總體發(fā)展趨勢(shì)

由于作者想要自動(dòng)化地對(duì)這個(gè)程序進(jìn)行分析，所以需要自動(dòng)化識(shí)別如地址欄一些信息，也就需要打造一個(gè)瀏覽器無(wú)關(guān)的 UI 測(cè)試框架。論文作者認(rèn)為，在 2～4 步中主要需要解決的問(wèn)題是：分析給定應(yīng)用的 UI 來(lái)決定某些元素是否存在，如果存在的話，需要確定在屏幕的具體位置。更具體一點(diǎn)，這些 UI 元素主要包括應(yīng)用級(jí)別的 UI 元素，比如地址欄、掛鎖、圖標(biāo)以及標(biāo)簽頁(yè)webpage 的內(nèi)容。作者針對(duì)于這兩種元素，分別提出了相應(yīng)的解決辦法：

1.應(yīng)用級(jí)別的 UI 元素。大部分瀏覽器都會(huì)使用標(biāo)準(zhǔn)的Android UI 庫(kù)。這使得 Hindsight 可以使用 UI Automator 來(lái)獲取應(yīng)用 UI 的 DOM 的 XML dump，包括網(wǎng)站中的文字，圖片，甚至坐標(biāo)。

2.Webpage 的元素。不能夠依賴于上述的 dump 方法，因?yàn)楹芏酁g覽器渲染的網(wǎng)站內(nèi)容并不是 DOM 中的一部分，測(cè)試者需要定位屏幕上某個(gè)按鈕的位置。最后論文作者選擇采用 OCR 識(shí)別來(lái)解決這個(gè)問(wèn)題。

在使用 OCR 時(shí)，發(fā)現(xiàn) OCR 方法存在一定的局限性，并提出相應(yīng)解決辦法：

1.不同瀏覽器渲染同一個(gè)網(wǎng)頁(yè)的方法可能是不一樣的。比如對(duì)于同樣一個(gè)網(wǎng)頁(yè)，不同的瀏覽器可能會(huì)使用不同的字體來(lái)進(jìn)行渲染。通過(guò)不斷嘗試多次，發(fā)現(xiàn)對(duì)于 ABB 中重要的文本元素，需要使用不同的字體大小和家族以及重復(fù)多次，以便于提高被OCR 識(shí)別的效率。

2.渲染的網(wǎng)頁(yè)可能并不是網(wǎng)頁(yè)中唯一出現(xiàn)的內(nèi)容，比如一些其他的信息，如提示信息、更新信息。

論文作者通過(guò)自動(dòng)化識(shí)別的方法來(lái)點(diǎn)擊這些提示信息，消除這些提示信息；同時(shí)在設(shè)計(jì) ABB 測(cè)試網(wǎng)頁(yè)的時(shí)候盡可能地使得網(wǎng)頁(yè)內(nèi)容靠近屏幕中間。

通過(guò)這樣的 UI 分析，為自動(dòng)點(diǎn)擊相關(guān)按鈕，填寫(xiě)文字內(nèi)容等需要在 2～4 步驟中操作的問(wèn)題提供了一種解決辦法。

結(jié)果驗(yàn)證及評(píng)估

論文作者指出，由于這樣的框架是首個(gè)被提出來(lái)的，所以目前沒(méi)有可以驗(yàn)證的方法，所只能使用手工驗(yàn)證。因此，在使用上述方法的時(shí)候，確保測(cè)試結(jié)果盡可能是用戶友好的，即盡可能可讀；另外，所有設(shè)備相關(guān)的截圖都會(huì)被保存。

圖3 影響手機(jī)瀏覽器的漏洞數(shù)

對(duì)于目前的數(shù)據(jù)集，論文作者指出這大概會(huì)花費(fèi)一個(gè)人 60個(gè)小時(shí)的時(shí)間來(lái)完成，而且，自動(dòng)化測(cè)試邏輯的錯(cuò)誤概率是 1.5%，其實(shí)還是很低的。

在收集到的 2324 個(gè) APK 中，作者分別都進(jìn)行了 27 種 ABB的測(cè)試，結(jié)果發(fā)現(xiàn)錯(cuò)誤的概率大約有 3.6%，其中1.5 由檢查的人發(fā)現(xiàn)，2.1% 由 Hindsight 框架發(fā)現(xiàn)。作者進(jìn)一步分別將所有的錯(cuò)誤分別分為有漏洞和安全，考慮了有漏洞的 APK 的上界和下界。近幾年手機(jī)端瀏覽器的 UI 漏洞的總體發(fā)展趨勢(shì)如圖2所示。

從圖3可以發(fā)現(xiàn)，98% 的瀏覽器至少受到 1 種 ABB 的影響，50% 的瀏覽器至少受到 12 種 ABB 的影響。針對(duì)于不同種類(lèi)的漏洞，還發(fā)現(xiàn)瀏覽器更容易受到 URL 方面的漏洞影響，如圖4所示。

而且，新版本的瀏覽器不見(jiàn)得比舊版本的瀏覽器的漏洞更少，比如 Chrome 瀏覽器（如圖5所示）。

此外，瀏覽器的安裝程度與其受歡迎的程度有時(shí)候并沒(méi)有什么必然的聯(lián)系，比如排名第 13 的 Shark 瀏覽器受到的 Event Routing 和 Address bar 相關(guān)種類(lèi)的漏洞影響的個(gè)數(shù)就比排名的 1的 Chrome 瀏覽器少很多。

圖4 至少受一個(gè)漏洞影響的瀏覽器系列的部分

圖5 最流行瀏覽器每年的平均漏洞數(shù)

圖6 手機(jī)瀏覽器處理長(zhǎng) URL 的不同現(xiàn)象

圖7 受影響的瀏覽器家族數(shù)量

更進(jìn)一步，論文作者分析了隨著時(shí)間的推進(jìn)，每種瀏覽器針對(duì)于某種漏洞的變化，首先給出了如下的定義：

總是有漏洞的標(biāo)記為 YES

從安全的變?yōu)椴话踩臉?biāo)記為 noYES

臨時(shí)有漏洞即為 noYESno

在有漏洞和沒(méi)有漏洞之間回歸記為 yesNOyes

論文作者給出了一個(gè) yesNOyes 的例子，如 Dolphin browser的如圖6所示版本，在面對(duì)長(zhǎng) URL 的時(shí)候可能會(huì)表現(xiàn)出不同的現(xiàn)象。并且，給出了整體的效果，如圖7所示。

整體來(lái)說(shuō)，有漏洞的幾乎總是漏洞，沒(méi)有漏洞的在新版本中會(huì)有一定概率出現(xiàn)漏洞，對(duì)于 noYESno 以及 YESnoYES 則出現(xiàn)的情況較少。

同時(shí)，存在一定的優(yōu)點(diǎn)，如收集了足夠多的手機(jī)端的瀏覽器；測(cè)試方法是自動(dòng)化的，而且還可以不斷集成新的漏洞種類(lèi)；從不同角度分析了近些年來(lái)瀏覽器 UI 漏洞發(fā)展的歷史。

雖然分析了這么多瀏覽器，但是其實(shí)很多用戶都不使用，并沒(méi)有反映到這些漏洞對(duì)于現(xiàn)實(shí)用戶的影響。hindsight 在繞過(guò)一些開(kāi)始安裝 APK 時(shí)，仍然存在一些不足。由于物理資源的限制，作者只是用了 4 個(gè)SDK 版本的手機(jī)。如果使用更多版本的話，獲取曾經(jīng)安裝失敗的瀏覽器可能就可以安裝成功了。在最后仍然對(duì)結(jié)果進(jìn)行了手工分析，難以做到全自動(dòng)化。