提取私人信息

在介紹這個漏洞之前，讓我們先了解一下占位符。眾所周知，當我們與自動填充建議的用戶界面互動時，如果將鼠標懸停在每個建議的條目上，都會發生一些有趣的事情。一個占位符值將被放置在我們試圖填寫的任何輸入中。不過，這個占位符的值不應該允許網頁隨意訪問：只有當用戶明確選擇了他們認為合適的條目后，瀏覽器才能讀取自動填充數據。除此之外，占位符將被設置為所有具有匹配名稱的輸入。這意味著信用卡號碼、地址、用戶名、全名等都可以被提取出來。

我第一次意識到這個微妙的安全問題是因為這個漏洞（作者Mark Amery），它使用CSS/字體技巧來提取占位符數據。

現在回到這個漏洞本身。在試圖找出我之前提到的問題（關于瀏覽器用戶界面的偽造）的解決方案時，我偶然發現了一個有趣的行為。在研究問題（2）時，我在自動填充出現時切換了輸入的類型，結果導致自動填充的用戶界面一直存在。在這個例子中，我所做的不是改變輸入類型，而是在第一個自動填充建議的用戶界面出現時，讓另一個自動填充用戶界面出現：

1.用戶與一個輸入元素“A”互動

2.自動填充建議出現在輸入元素“A”上

3.讓自動填充建議出現在輸入元素“B”上

4.從文檔中刪除輸入元素“B”。

這樣一來，最后剩下的只有輸入元素“A”（包括來自自動填充建議的占位符值），而實際的建議用戶界面并不存在。這對攻擊者來說是好事，因為現在他們有充分的時間來提取數據，而以前，一旦自動填充建議消失，占位符值就會被刪除。

下面是針對這一特定行為的小型PoC：

hit down arrow < Br >< br >< form id="qsub" >< input id="qa" name=email placeholder="tester" type=text autocomplete=email >< /form >< form name="addr1.1" id="paymentForm" action="" method="post" >< input type="text" id="nameInput" name="name" autofocus >< /form >< script >nameInput.onkeydown = (e) = > {setTimeout((g) = > {qa.click();qa.focus();document.execCommand("insertText", false, "\u0000");qa.remove();}, 215);}; < /script >

我發現有兩種方法可以提取這些數據并將其暴露在網頁上，具體如下所示。

CVE-2021-21177：拖放占位符的值

一個有趣的函數是document.execCommand(‘selectAll’)，其作用就是選擇一個可編輯文檔中的所有文本（我們可以通過contenteditable=true屬性將所有元素設置為可編輯）。我注意到，當占位符停留在輸入中時，如果執行這個命令，它將被選中。不夠，由于我們無法自動復制和粘貼所選的值（沒有剪貼板使用權限），所以，我使用了另一種方法：拖放!

所以，漏洞利用過程變為：

1.讓用戶點擊頁面

2.觸發占位符持久性故障

3.誘使用戶拖放頁面的一部分

前面，我們已經介紹了完成任務(1)的方法，對于任務(2)，我的方法是放置一個冒充iframe的圖片，當用戶試圖使用不存在的滾動條向下滾動時，他們會在不知不覺中拖放他們的自動填充占位符值。

【學習視頻】

基于拖放方法的原始PoC可以從這里找到。

在這個漏洞的相關報告中，最初的討論似乎是為了防止拖放適用于占位符的值。實際上，已經有一個CSS可以做到這一點“ -webkit-user-select: none;”。但這還不夠，主要問題是自動填充數據的持久性。

實際上，拖放已經是一種經常遇到的用戶互動了，所以我想看看是否可以用一個更好的提取占位數據的方法來代替它。CSS和字體似乎根本不適用于占位符數據，所以，經過一番折騰，我最終發現了一個不同的方法。

CVE-2021-21177：使用window.find()提取占位符的值

這個函數一出現在我的腦海中，我就對它抱有很大的期望，結果確實如此。

眾所周知，window.find()是一個非常有用的API，網頁通過它對自身的內容進行搜索。假設我們有一個只有Hello World文本的文檔，那么window.find(“Hello”)==true，window.find(“World”)==true，當然window.find(“doesntexist”)==false。

現在，完整的漏洞利用過程如下所示：

1.用戶按下向下箭頭

2.觸發占位符故障

3.使用window.find提取占位符

這意味著，用戶只需要在一個惡意的頁面上按下方向鍵，我就能提取很多私人信息，其中最危險的是信用卡信息。

【學習視頻】

原始PoC可以從這里找到。

CVE-2021-21216：隱藏自動填充建議的用戶界面

我們知道，有一些UI應該始終顯示給用戶。其中，最受歡迎的是當我們進入全屏時出現的“You are now in fullscreen”的信息。由于進入全屏后，由于瀏覽器的頭部會消失，因此，攻擊者可以輕易通過偽造的信息來代替它來欺騙用戶的。

我清楚地認識到，自動填充建議的用戶界面和全屏用戶界面一樣重要。這是因為，在它從未顯示出來的情況下，攻擊者就可以讓用戶按下某些鍵盤按鈕，并神不知鬼不覺地用自動填充值來填充隱藏的輸入元素。關于這一點，我也是從一個漏洞利用代碼中領悟到的：相應的PoC是一個游戲，以獲得提取數據所需的用戶手勢。

使用一個類似于之前討論的本地瀏覽器偽造的漏洞，我注意到：可以讓自動填充建議的UI“出現”在用戶屏幕之外。因此，換句話說，攻擊者可以讓用戶看不到自動填充的用戶界面，盡管該界面確實存在。

利用這個漏洞的方法非常簡單：

1.誘騙用戶訪問惡意頁面，設法讓他們點擊向下的箭頭。

2.讓隱藏的自動填充出現在屏幕外的某個地方，并選擇第一個建議的結果，隨后用占位符的值填充多個隱藏的輸入。

3.讓惡意頁面誘導用戶點擊“Enter”鍵。

這樣的話，就能讓用戶會在不知不覺中用自動填充數據填寫一個隱藏的表單。

【學習視頻】

原始PoC可以從這里找到。

自動挖掘UI安全漏洞

我開發了一個審查UI安全問題的工具，當然，這只能算是我學習Fuzzer工作原理的副產品，因為我在加入目前團隊之前，從未真正使用過Fuzzer。這是一個非常簡陋的工具，幾乎都不能算作Fuzzer，之所以這么說，是因為Fuzzer通常能夠發現內存問題。通常來說，瀏覽器的崩潰是出現安全問題的明確信號，但檢測用戶界面問題卻沒有這樣明確的信號。所以，我為該工具設置了一個模式，以觀察的用戶可以手動選擇某個東西看起來是不是很奇怪。

結果是，我既能發現內存問題的漏洞，也能發現與UI有關的設計缺陷。在繼續之前，讓我先介紹一下這個簡單的自動測試器是如何工作的。

?使用普通Web內容可調用的UI列表及其相應的PoC，我創建了一個測試用例，以隨機的順序隨機地顯示這些用戶界面。當測試用例運行時，我就進行某種導航操作：

-在歷史中導航-導航到一個新標簽-打開一個彈出式窗口-在一個iframe中運行測試案例 + （可選）呈現兩個按鈕，看看是否出現某些奇怪的東西-如果出現：保存測試用例，并開始新的迭代-如果沒有出現：直接開始新的迭代

這個實驗確實找到了一些有趣的結果，具體如下所示。

smartscreen:FlyoutShower中的堆使用后釋放漏洞（僅限Edge瀏覽器）

這個內部漏洞是我最先發現的，該漏洞與Smartscreen有關。Smartscreen是Edge瀏覽器特有的一種功能，相當于谷歌的安全瀏覽功能：進行相應的檢查，以確保下載的文件和訪問的網站沒有被標記為惡意的。

然而，它們的區別在于Edge處理被標記為潛在網絡釣魚網站的網站的具體方式。如果我們使用Edge瀏覽器導航到這種類型的網站，就會看到：

因此，這自然成為我實現自動化的UI調用命令之一。不久后，我發現Edge崩潰了，原來是瀏覽器進程崩了。

< html >< body >< script >const blob = new Blob([`< iframe id="qss"src="https://nav.smartscreen.msft.net/other/areyousure.html"target="_blank" rel="noreferrer noopener" >< /iframe >`,], {type: "text/html"});var test = window.open(window.URL.createObjectURL(blob));var blank = window.open("about:blank");setTimeout(function() {blank.close();test.close();}, 1400);< /script >< /body >< /html >

之所以出現這種情況，是因為SmartScreen UI沒有安全地處理指向WebContents對象的指針所致。在Chromium和Edge瀏覽器中，WebContents對象是直接與標簽的壽命掛鉤的。由于標簽可以自行關閉，考慮到它們有一個開啟器，我們可以濫用調用這個用戶界面的自行關閉的標簽，并可靠地令其崩潰。

使用這種技術，我們在Edge和上游瀏覽器中還發現了其他一些與UI相關的漏洞，這些漏洞要么還沒有被完全修復，要么沒有那么有趣，因此，這里就不介紹了。

CVE-2020-26953：繞過Firefox中的全屏UI

作為BVR團隊的一員，我們被鼓勵對其他瀏覽器中進行相關的安全測試。雖然Chromium的代碼庫與Firefox不同，但兩者可能具有相同的設計缺陷。這樣做的另一個好處是：可以了解Firefox是如何處理某種行為的，并從中獲得啟示。

在一個周末，我決定修改自己的工具，看看對Firefox的效果如何，結果發現一個UI設計缺陷不斷出現，但并不穩定。這個漏洞會導致瀏覽器進入全屏時，通知用戶進入全屏的UI完全不可見。

最初報告的PoC中有一個謎團：似乎只有在建立websocket連接并失敗的情況下，它才會起作用。不僅如此，你還必須不斷地把它改變到另一個無效的位置（假設是為了繞過任何緩存）。

原始PoC可以從這里找到。

一位Mozilla員工（Gijs）指出，PoC中神秘的websocket部分可以用卸載處理程序中的console.log()調用代替。這個變化對我來說是個謎，console.log與全屏UI顯示與否有什么關系？如果您想了解其中的緣由，請參閱Bugzilla的相關報告。

按照上述報告給出的建議，我用卸載處理程序替換了websocket連接，還添加了一個blob導航，而不是導航到同一個頁面，最終得到了一個更可靠的PoC。

關于修訂版的PoC，可以從這里找到。

【學習視頻】

對我來說，這具有很重要的意義，因為這個漏洞是以半自動的方式發現的，從而讓我看到了自動挖掘邏輯/設計漏洞的潛力。

與標簽相關的安全漏洞

標簽是用戶界面的一部分，可以說是瀏覽器中比較復雜的用戶界面之一。因此，當我注意到標簽頁中的一個安全漏洞被修復時，我覺得這個代碼中一定還有更多的漏洞尚未發現。例如，通過標簽，我們可以將它們添加到組中，進行拖放，將一個窗口中的標簽轉換成另一個窗口中的標簽，反之亦然，等等。正如之前提到的，標簽是可以自行關閉（如果它們有一個開啟器的話）的，這意味著網頁內容可以控制標簽的壽命。

我所做的事情，只是創建了一個腳本來打開標簽，而這些標簽會自行關閉；然后，在這個連續的打開和關閉標簽的過程中，對標簽的不同功能進行了相應的處理。

以下安全漏洞已被上報并隨后得到了修復。

CVE-2021-21197：TabStrip的堆緩沖區溢出

這里被利用的主要標簽功能是將標簽拖放到自己的窗口中的能力。當一個標簽在拖動另一個標簽到自己的窗口時關閉，就會發生崩潰。

相關的PoC可以從這里找到。

CVE-2021-21192：標簽組中的堆緩沖區溢出漏洞

這里再次利用了拖放技術，只不過，這次拖動的不是一個普通的標簽，而是在標簽關閉時將標簽組拖出并拖入主窗口。

相關的PoC可以從這里找到。

CVE-2021-21154：頁簽列（Tab Strip）中的堆緩沖區溢出

您猜對沒錯：在一些標簽關閉時拖動一組標簽會導致這種崩潰。在這個例子中，用到了通過按住shift鍵+選擇范圍來選擇標簽的主要標簽功能。

相關的PoC可以從這里找到。

CVE-2021-21180：標簽搜索功能中UAF漏洞

該漏洞與一個相對較新的功能有關，該功能使用戶能夠搜索自己的活動標簽。我發現，這個新的標簽搜索用戶界面實際上就是一個位于chrome://tab-search.top-chrome/的WebUI。

在這個標簽搜索用戶界面中，我們可以關閉標簽，但是，當我們在自己的窗口中打開“chrome://tab-search.top-chrome/”，然后試圖使用標簽搜索用戶界面的關閉機制來關閉自己時，就會觸發UAF漏洞。

小結

我們希望本文能夠幫助讀者了解UI安全的相關知識，正如您所看到的，這并不是一個單純的邏輯/設計問題，因為有時還會摻雜內存損壞問題。另外，UI安全的審計工作，是很難實現自動化和模糊處理的，即使是圍繞著標簽的內存問題也需要進行拖放操作，但是幾乎沒有Fuzzer會模擬這些操作。由此看起來，UI安全是自動化漏洞挖掘領域中的一塊處女地，一旦獲得突破，將曝出更多的安全漏洞。

【領取網絡安全相關的學習資料】

總結

以上是生活随笔為你收集整理的进一步考察与UI相关的安全漏洞-下的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。