macOS小技巧：副檔名
一、前言
如果大家關注我們之前在MDSec上發表過的 ofollow,noindex" target="_blank">博文 ，可以看到我們最近在macOS方面的研究成果。
作為紅方，在攻擊Windows端點時我們可以使用各種各樣的手段，比如HTA、OLE、包含巨集的Office文件或者偽裝成合法應用的簡單二進位制程式，我們總有各種辦法在釣魚攻擊中獲得目標主機的訪問許可權。
不幸的是，對於macOS系統來說我們的運氣並沒有那麼好。如果我們在網上搜索一番，會發現很難找到在攻擊macOS時可以為我們所用的技術。
在本文中，我想給大家介紹我們在研究過程中發現的一些小發現，這些小發現很難獨立撐起一篇完整的文章；也會與大家分享一些小技巧，可能對大家在下次攻擊macOS時有所幫助，或許能借此在系統中獲得立足之地。
二、面臨的障礙
在面對macOS系統時，我們會面臨什麼樣的障礙？令人驚訝的是，第一個障礙也是最容易繞過的障礙：Gatekeeper。
Gatekeeper是macOS在防禦從網際網路下載惡意應用時的第一道防線。
普通Mac使用者肯定對如下提示視窗非常熟悉：
從這個提示視窗中，macOS告訴我們已下載的這個應用並不可信，這主要是因為缺少程式碼簽名證書。
毫無疑問，在滲透過程中我們的任務是儘可能模模擬實攻擊者已使用的一些技術。檢視惡意軟體分析報告，我們可以快速找到真實攻擊環境中攻擊者如何繞過這個限制：
如上圖所示，方法其實很簡單，那就是使用有效的開發者賬號來繞過該限制，這也是惡意軟體開發者採取的方法。
顯然，通過任何惡意方法獲得證書並不可行，也就是說我們要麼選擇購買有效的開發者賬戶，成功繞過Gatekeeper，要麼擴充套件我們的社會工程學技巧，說服使用者幫我們繞過Gatekeeper。
在下文中我們採用的是第一種方法，然而在實際攻擊場景中，這種方法有個明顯的缺點，那就是會將開發者證書與惡意軟體關聯起來。
那麼我們如何才能構造足夠迷惑人的誘餌，成功突破目標呢？
三、APP檔案
幾星期以前（實際上是幾個月以前，這篇文章已經構思了好長一段時間），我在推特上公佈了一個 截圖 ，介紹瞭如何在釣魚攻擊中隱藏一個app：
大家可能知道，在之前版本的macOS中，我們有可能將某個檔案命名為 mysecrets.docx.app 。在這種情況下，macOS會自動移除 .app 副檔名，這樣使用者一開始觀察這個檔案時可能以為看到的是 .docx 檔案。
然後Apple做了一些修改，現在如果在 .app 副檔名之前的副檔名已註冊，那麼就會顯示完整的副檔名。比如，如果我們將某個檔案命名為 mysecrets.docx.app ，那麼我們看到如下畫面：
有趣的是，無效的副檔名並不會顯示出完整的 .app 名。比如，如果我們將應用重新命名為 secrets.docy.app ，我們可以看到如下畫面：
那麼我們如何才能在滿足如上限制條件的前提下，構造出更有欺騙性的誘餌呢？好吧，其實我們可以利用“同形字”技術來繞過對合法副檔名的檢測。比如，如果我們使用IronGeek的 Homoglyph Generator 工具，可以看到許多可選項，能夠呈現近乎相似的副檔名：
簡單選擇合適的同形字元後，我們可以滿足如上限制條件，並且能夠成功隱去 .app 副檔名。然後接下來我們需要為我們的載荷構造一個圖示，如下所示：
四、投遞APP
現在我們已經構造完載荷，也具備欺騙性的檔名，現在我們需要將載荷傳送給我們的受害者。不幸的是，與Windows環境不同，在這種場景下我們不能使用檔案連結方式或者將其封裝到一片HTML資料中，這是因為 .app 實際上是一個目錄，我們需要在傳送之前進行打包。
為了投遞檔案後增加攻擊成功的概率，我們需要理解目標會通過那種方式下載我們的載荷。
假設經過踩點後，我們知道目標使用的是Safari，那麼這正合我們意，因為Safari會幫我們自動下載並解壓檔案，只給使用者呈現一個非常有誘惑力的圖示，留待使用者點選：
但我們很快發現使用者所選擇的瀏覽器並不是我們需要考慮的唯一因素，如果受害者使用的是其他解決方案，比如Google Mail呢？此時我們就會遇到問題。在這種情況下，Google通常會提供 .zip 檔案的預覽，這樣使用者很快就會發現我們的檔案不是 .docx 檔案，而是一個 .docx.app 檔案，提高警覺度。
那麼我們如何解決這個問題？我們知道macOS將Archive Utility作為解壓縮檔案的預設解決方案。啟動Archive Utility後，我們可以看到該工具支援3種檔案型別：
也就是說，支援以下3種檔案：
cpgz cpio zip
我們知道Google Mail會自動解開 .zip 檔案，但其他兩種檔案會怎麼處理呢？
對於 CPGZ 檔案，我們可以看到包含在其中的 CPIO 檔案：
如果我們使用的是 CPIO ：
非常棒，根據前面的測試結果，如果我們傳送的是 .cpio 檔案，Google Mail只會簡單提示使用者下載該檔案，但這個檔名本身有沒有問題？受害者看到一個 .cpio 檔案時會不會有所警覺？
讓我們載入Archive Utility來看看我們是否可以找到解決辦法。我們可以使用 Hopper 工具分析Archive Utility，先來看看 [BAHController doUnarchiveFile:] 這個方法：
其中包含一個函式呼叫： [BAHController dearchiveItem:withController:isIntermediateItem:]
以上程式碼呼叫了 +[BAHCodec decompressorForFile:andOptions:] ，從中我們可以看到應用使用了 +[BAHDecompressor classNameForFile:checkMagic:isPrimaryArchive:] 方法來判斷應該選擇哪種解壓器。
首先我們可以看到應用會搜尋常見的幾種副檔名：
程式碼邏輯非常直白，一旦找到支援的副檔名後，我們可以看到如下呼叫：
r13 = [BAHDecompressor reconcileClassName:r13 withMagic:[[BAHController sharedInstance] magicInfoForFile:r12] isPrimaryArchive:sign_extend_64(var_2C)];
第一個呼叫為 -[BAHController magicInfoForFile:] ，這是 /usr/bin/file 工具的簡單封裝函式，可以無視檔案的副檔名，獲取檔案的具體型別。輸出結果傳遞給 +[BAHDecompressor reconcileClassName:withMagic:isPrimaryArchive:] ，確保副檔名與 file 的輸出相匹配：
繼續跟蹤，我們可以看到 file 會識別魔術位元組（magic byte），根據這些資訊判斷檔案型別（而非副檔名），選擇匹配的解壓縮器。
這意味著我們可以建立Archive Utility支援的各種歸檔檔案（如 CPIO 、 GZIP 等），然後隨便使用支援的其他副檔名（如 .cpio 、 .tar.gz 、 .uu 、 .zip 等），這樣Archive Utility就會自己會去處理這些不匹配因素。
利用這些知識點，我們可以建立一個 CPIO 檔案，然後將其重新命名為 .zip 檔案：
非常棒，Google Mail只會顯示一個錯誤資訊，提示使用者下載。當受害者訪問該檔案時，可以看到Achive Utility會正常解壓出我們的檔案。
