（本文經合作夥伴 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈3 個月時間，5 名黑客找出蘋果 55 個漏洞，賺了 5 萬多美元，還寫了篇博客記錄全程 〉。）
【我們為什麼挑選這篇文章】蘋果的消息這幾天充斥各新聞，大多聚焦在 iPhone 12 的設計與新功能，但在這波新機討論的聲浪中，蘋果卻被爆出 55 個網路服務漏洞，究竟是何方神聖，有辦法攻破蘋果的安全防線，而這些漏洞都被一一解決了嗎？（責任編輯：賴佩萱）
昨天，翹首期待的 iPhone 12 終於面世，不管是回歸經典方框設計，還是首次推出小螢幕 mini 版，都讓蘋果玩家大呼過癮。不過，在今年這場別開生面的發布會之前，以安全著稱的蘋果卻忽然被曝出 55 個漏洞。
想要剁手的朋友們儘管放寬心，因為這些漏洞已經被 5 名駭客報給了蘋果，還因此小賺一筆，獲得了 5 萬美金的獎勵。
想要拿獎金，五名同好一頭栽進蘋果研究漏洞
事情是這樣的，蘋果一直有對漏洞報告者進行資金獎勵的傳統，並且給這個項目取了個酷炫的名字—— Apple Bug 賞金計劃。今年 7 月，一位資深技術從業者 Brett Buerhaus 在 Twitter 上看到一位同行因為發現了蘋果的身份驗證繞行 bug 而獲得蘋果公司 10 萬美元的獎勵，於是非常心動，並召集了 4 位駭客朋友一起，研究蘋果的整個基礎程式。經過了長達 3 個月對蘋果線上服務的研究和分析，找出了 55 個漏洞，其中一些還非常危險。
比如，居心叵測的人可以利用這些漏洞製造一種蠕蟲，進而自動竊取某人的 iCloud 帳戶中的所有照片、影片和文檔，甚至能對受害者的聯繫人進行同樣的攻擊。
聽上去也太可怕了吧！
不過還好，在發現這些漏洞之後，這 5 名駭客就已經向蘋果進行了報告，蘋果隨即修復了這些錯誤。
Brett Buerhaus 接下來也以自述的方式，在自己的 部落格 上把這個過程和所有漏洞內容都記錄了下來。
入侵蘋果的第一步是弄清楚實際目標是什麼。Ben 和 Tanner 都是這裡的專家，所以他們開始弄清楚我們可以訪問的所有蘋果的內容。他們掃描的所有結果都在儀表板中建立了索引，該儀表板包括 HTTP 狀態代碼，標頭，響應正文以及 Apple 擁有的各個域下可訪問的 Web 服務器的螢幕快照，我們將在參與過程中參考這些。
簡而言之：蘋果的基礎設施規模巨大。
他們擁有整個 17.0.0.0/8 IP 範圍，其中包括 25,000 個 Web 服務器，其中 apple.com 下擁有 10,000 個 Web 服務器，另外 7,000 個唯一域，最重要的是擁有自己的 TLD（點蘋果）。我們的時間主要花費在 17.0.0.0/8 IP 範圍，.apple.com 和 .icloud.com 上，因為那是有趣的功能所在。
列出所有 Web 服務器後，我們開始在更有趣的服務器上運行目錄暴力破解。
這篇部落格文很快引起了海外媒體和不少網友的關注。
在國外媒體 vice 對這件事進行報導後不久，其中一名駭客 Sam Curry 就在個人推特上表示，蘋果告訴他們，他們還有機會獲得總計 28.85 萬美元的獎勵，因為之前蘋果只為部分漏洞付了錢，現在，他們準備再追加 28 個漏洞的獎金。
說到這次的項目，Sam Curry 在他的部落格文章中表示，「沒想到會花掉我們 3 個多月的時間」。
「這原本是一個附屬項目，我們每隔一段時間會進行一次工作。但是在新冠疫情的影響下，我們有了很多額外的空閒時間，最終累積下來，每個人平均投入了數百小時。」
5 萬的獎金，是多了還是少了？
不過，在這次的事件上，比起駭客們發現的漏洞，人們對於蘋果給予的獎金數額更感興趣。
我們來簡單做一下數學。5 名駭客用「數百小時」來研究蘋果的線上服務，他們在三個月內發現了 55 個漏洞，蘋果獎勵他們 5 萬美元，這麼算下來的話，每個人每個漏洞大約值 250 美元，或者每個人每月的「薪水」是 17171 美元（約台幣 515130 元）。
安全公司 Phobos 的創始人 Dan Tentler 感嘆道，這「非常低」。
Tentler 在一次線上會議中對 Motherboard 表示：「在我看來，兩到四周的安全評估，大約就能值到 50K 美元，尚且不論這 5 位駭客發現的問題本身其實更有價值。」
「想像一下，如果有任何威脅國家安全的不法分子發現並利用了這些漏洞，造成的損害將會有多大。但是，蘋果卻告訴他們和大眾，這一切只值 5 萬，這讓我不得其解，並且這與他們所宣揚的將嚴肅對待隱私和安全問題的說法背道而馳。」
不過在著名漏洞懸賞專家 Katie Moussouris 看來，蘋果給出的金額可能是公平的。
Moussouris 表示：「查找基於網絡的漏洞所需的技能比移動端或 iOS 的要更容易。」「從邏輯上講，蘋果會為能夠入侵其核心操作系統的人支付更高金額，這可能也是為什麼蘋果願意為 iCloud 數據洩露等系統漏洞支付金額。」
Moussouris 總結說：「真正的問題是，蘋果可以向專業的滲透測試人員提供文檔，讓他們在更少的時間內找到更多的漏洞，而不是浪費時間進行黑匣子檢查，尤其是考慮到兩者的價格並不會相差太大。」
認識蘋果的漏洞揭發獎勵機制
在駭客們向蘋果報告了發現的漏洞後，蘋果發言人表示，「我們重視與安全研究人員的合作，以幫助確保用戶的安全，感謝團隊的協助，我們將從 Apple Security Bounty 計劃中獎勵他們」。
Apple Security Bounty 是蘋果在 2016 年宣布啟動的一個計劃，時任蘋果安全工程和體系結構負責人 Ivan Krstic 在 Black Hat 上宣布，蘋果將開始向發現其產品漏洞的研究人員提供最高 200,000 美元的現金獎勵。
Apple Security Bounty 的設立，旨在消除安全架構的某些秘密，並向願意幫助改善蘋果安全性的駭客、研究人員和密碼學家開放，這其中涵蓋了 HomeKit、AutoUnlock 和 iCloud 鑰匙串的安全功能。
蘋果給的獎金太少，駭客把漏洞拿去黑市賣會更賺？
不過，這四年間，儘管蘋果也開始慢慢向部分研究人員發放獎勵，但總的來說，這項計劃並沒有達到最初的目的，因為對於大多數安全研究人員來說，參與這項計劃可能並不划算，他們需要投入大量的精力，最終的收入也無法可能證明前期的時間投入是合理的。
一位前蘋果員工就在推特上吐槽到，「獎金就是最好的勞動力」。
2017 年，Motherboard 採訪了部分安全研究員，他們都表示，iOS 漏洞非常值錢，但與之相對的是，蘋果給出的獎金太少，因為就算發現了漏洞，他們也不會報告給蘋果，這些漏洞在黑市上可以賣到更高的價錢。
Zimperium 安全研究員 Nikias Bassen 表示：「把漏洞賣給其他人可以得到更高的價格，對於那些以此謀生的人來說，肯定是不會選擇把漏洞直接報告給蘋果的。」
不過，毫無疑問，這 5 個人在未來幾個月內，會獲得更多的收入。
「我認為，蘋果可能會支付與這些發現同等價值的金錢。公平地說，我們在短時間內解決了大量問題，但處理這些問題的過程比報告 1 或 2 個問題要困難得多。」
儘管如此，這只是錯誤專家賞金行業中許多專家認為是個大問題的又一個例子。正如網絡安全諮詢公司 Trail of Bits 去年在部落格文章中所寫的那樣，「試著以工程師的身份參加漏洞獎勵活動謀生，就像說服自己在德州足夠優秀，辭掉工作也能正常生活一樣」。
駭客發現哪些漏洞？
想必到現在，大家對於這些駭客到底發現了蘋果的哪些漏洞還十分好奇。
別擔心，在 部落格 上，Brett Buerhaus 公開了他們發現的 55 個漏洞，這裡也節選了其中兩個，先給大家過過眼癮。
透過認證和授權旁路，蘋果傑出教育家計劃被攻破
我們花時間入侵的第一個服務器之一是「蘋果傑出教育家」網站。這是一個僅限邀請的 Jive 論壇，用戶可以使用他們的蘋果帳戶進行認證。這個論壇的有趣之處在於，一些註冊應用的核心 Jive 功能是透過蘋果公司建立的自定義中間頁面移植過來的，以便將他們的認證系統（IDMSA）與使用用戶名/密碼認證的底層 Jive 論壇連接起來。
這樣做的目的是為了讓用戶能夠輕鬆地使用他們已有的 Apple 帳戶來驗證身份，而不需要創建一個額外的用戶帳戶。你只需要使用「用蘋果登錄」就可以登錄到論壇。
不被允許進入論壇的用戶的登陸頁面是一個申請入口，你提供自己的訊息，然後由論壇版主進行評估審批。
當你提交使用論壇的申請時，就像你正常註冊 Jive 論壇一樣，你提供了幾乎所有的帳號訊息。這樣就可以讓 Jive 論壇根據你的 IDMSA cookie 知道你是誰，因為它把你蘋果帳號的郵件地址和論壇綁定在一起。
在申請註冊使用論壇的頁面中，有一個隱藏的信息是「密碼」字段，其值為「##INvALID#%！3」。當你提交了包括用戶名、姓名、郵件地址和雇主在內的申請時，你也在提交一個「密碼」值，這個密碼值從頁面上的一個隱藏的輸入字段被秘密地綁定到你的帳戶上。
<div class=”j-form-row”><input id=”password” type=”hidden” value=”###INvALID#%!3″><div id=”jive-pw-strength”>…
觀察到這個隱藏的默認密碼字段後，我們立即想到一種方法來手動認證應用程序，並訪問論壇的核准賬戶，而不是嘗試使用” 用蘋果登錄” 系統登錄。我們採取這個方法是因為我們每個人分別註冊時的密碼都是一樣的。
如果有人使用這個系統進行申請，並且存在手動認證的功能的話，你可以簡單地使用默認密碼登錄到他們的帳戶，完全繞過「用蘋果登錄」登錄。
從表面上看，你似乎並不能手動認證，但在 Google 搜索了後，我們發現了一個「cs_login」端點，它是用來用用戶名和密碼登錄 Jive 應用的。當我們手動提出測試 HTTP 請求來驗證蘋果傑出開發者應用時，我們發現它試圖透過顯示密碼錯誤來驗證我們。
當我們使用自己之前申請的帳戶時，由於我們還沒有被批准，所以應用程序不允許我們進行身份驗證。如果我們想進行身份驗證，就必須找到已經批准的會員的用戶名。
這時，我們將 HTTP 請求加載到 Burp Suite 的入侵器中，並嘗試通過登錄和默認密碼來強行輸入 1 到 3 個字符的用戶名。
大約兩分鐘後，我們收到了一個 302 響應，表示用默認密碼成功登錄到用戶名「erb」的帳號中。我們成功了！現在，我們的下一個目標是對具有高權限的人的身份進行認證。我們截圖了幾張訪問記錄，點擊「用戶」列表，查看哪些用戶是管理員。我們登錄到列表中看到的第一個管理員賬戶，試圖證明我們可以通過管理功能實現遠程代碼執行，但是，我們遇見了一些障礙。
當我們試圖以管理員帳戶瀏覽「/admin/」（Jive 管理員控制台）時，應用程序重定向到登錄頁面，看起來像是我們還沒有通過認證。這很奇怪，因為這只是 Jive 應用的行為，我們之前都沒有觀察到這種情況。我們的猜測是，蘋果公司根據 IP 地址限制了管理控制台，以確保應用程序永遠不會完全被攻克。
我們嘗試的第一件事是使用 X-Forwarded-For 來繞過我們猜測的限制，但很遺憾，這失敗了。接下來我們嘗試的是加載不同形式的「/admin/」，以防應用程序有訪問管理員控制台的特定路徑黑名單。
僅僅經過幾次 HTTP 請求，我們就發現「GET /admin;/」允許攻擊者訪問管理控制台。我們通過設置一個 Burp Suite 規則，自動將 HTTP 請求中的「GET/POST /admin/” 改為”GET/POST /admin;/」，從而實現了自動繞過。
當我們最終找到並加載管理控制台時，障礙又出現了。我們無法使用一般的功能來演示遠程代碼執行（沒有模板、插件上傳，也沒有標準的管理調試功能）。
這時，我們停下來想了想自己的問題，意識到我們認證的賬號可能不是應用程序的「核心」管理員。我們又繼續認證了 2-3 個帳戶，最後才認證為核心管理員，並實現了可以進行遠程代碼執行的功能。
攻擊者可以（1）通過使用隱藏的默認登錄功能手動認證繞過認證，然後（2）透過在請求中發送修改後的 HTTP 路徑訪問管理控制台，最後（3）透過使用插件上傳、模板或文件管理等眾多 RCE 的功能中的一個來徹底破壞應用程序。
總的來說，這將使攻擊者能夠做到以下事件：
- 在 ade.apple.com 網站服務器上執行任意命令
- 訪問內部的 LDAP 服務以管理用戶帳戶
- 訪問蘋果公司的大部分內部網絡
儲存跨站點腳本漏洞：允許攻擊者透過修改電子郵件竊取 iCloud 數據
蘋果基礎設施的核心部分之一是他們的 iCloud 平台。該網站作為蘋果產品的照片、視頻、文檔以及 App 相關數據的自動存儲機制。此外，該平台還提供了郵件和查找我的 iPhone 等服務。
郵件服務是一個完整的電子郵件平台，用戶可以發送和接收電子郵件，類似於 Gmail 和雅虎。此外，iOS 和 Mac 上都有一個默認安裝的郵件應用程序。郵件服務與文件和文檔存儲等其他服務一起託管在「www.icloud.com」上。
這意味著，從攻擊者的角度來看，任何跨站點腳本漏洞都將允許攻擊者從 iCloud 服務中檢索他們想要的任何信息。在這一點上我們開始尋找任何跨站點腳本問題。
郵件應用程序的工作方式非常簡單直接。當服務收到一封電子郵件，用戶打開它時，數據被處理成一個 JSON blob，通過 JavaScript 進行過濾清理和分解，然後顯示給用戶。
這意味著就內容過濾而言，沒有服務器端對電子郵件進行處理，而呈現和處理郵件體的所有實際功能都在客戶端完成的 JavaScript 中。這並不一定是件壞事，通過理解我們需要在源代碼中具體破壞什麼，可以簡化標識 XSS 的過程。
基於 Style 標籤混淆來存儲的 XSS
當測試此功能時，我最終遇到的一件事是「<style>」標籤。這個標籤很有趣，因為 DOM 只會取消帶有結尾「<style>」標籤的元素。這意味著，如果我們編寫「<style> <script> alert（1）</ script> </ style>」並且完全在 DOM 中呈現，則由於標記的內容嚴格是 CSS，因此不會出現警告提示並且腳本標籤已填充在標籤內，並且沒有超出結束標籤。
從安全清理的角度來看，Apple 唯一需要擔心的是結束 Style 標籤，或者如果頁面上有敏感信息，則是通過導入鏈接進行 CSS 注入。
我決定集中精力打破 Style 標籤，因為這將是一個非常簡單的存儲ㄒXSS，如果可以實現。蘋果不會意識到這一點。
我玩了一段時間，嘗試了各種排列，最後發現了一些有趣的現象: 當郵件中有兩個 Style 標籤時，Style 標籤的內容會被連接到一個 Style 標籤中。這意味著，如果我們可以將「</sty」放入第一個標籤，並且將「le>」放入第二個標籤，就有可能欺騙應用程序，使其認為我們的標籤仍然是開放的，而實際上它並不是。
我發送了以下有效負載以測試是否有效：
<style></sty</style><style>le><script>alert(1)</script></style>
該電子郵件在我的收件箱中彈出。我點擊了它。有警報提示！它奏效了！
頁面的 DOM 包括以下內容：
<style></style><script>alert(1)</script></style>
由於郵件應用程序託管在「www.icloud.com」上，這意味著我們具有瀏覽器許可權，可以檢索 iCloud 服務的相應 API 的 HTTP 響應（如果我們可以潛入 JavaScript 以與他們聯繫）。
上述有效負載的解釋如下： 
在這一點上，我們認為最酷的概念證據會是竊取受害人的所有個人訊息（照片，日曆信息和文件），然後將相同的漏洞利用轉發給其所有聯繫人。
我們構建了一個簡潔的 PoC，它將從 iCloud API 返回照片 URL，將其粘貼到圖像標籤中，然後在其下方附加用戶帳戶的聯繫人列表。這表明可以檢索這些值，但是要滲入它們，我們必須繞過 CSP，這意味著除了「.apple.com」和其他幾個域外，沒有其他任何簡單的出站 HTTP 請求。
對我們來說幸運的是，該服務是一個郵件客戶端。我們可以簡單地使用 JavaScript 來給自己發送電子郵件，附加 iCloud 照片 URL 和聯繫人，然後發送受害者簽名的 iCloud 照片和文件 URL。
基於超連結混淆儲存的 XSS
後來，我發現了第二個以類似方式影響郵件的跨站點腳本漏洞。
對於這類 semi-HTML 應用程序，我總是要檢查的一件事是它們如何處理超連結。自動將未標記的 URL 轉換為超連結似乎很直觀，但如果它沒有被正確地清理或與其他功能結合在一起，就會變得很混亂。這是查找 XSS 的常見位置，因為依賴於 regex、innerHTML 和所有可在 URL 旁邊添加的可接受元素。
此 XSS 的第二個有趣功能是完全刪除某些標籤，例如「<script>」和「<iframe>」。這很整潔，因為某些東西將依賴於字符，例如空格，製表符和換行符，而 remove 標記留下的 void 可以提供這些字符而無需告知 JavaScript 解析器。這些差異使攻擊者可以混淆應用程序，並潛入可以調用 XSS 的惡意字符中。
我花了一段時間來研究這兩種功能（自動超連結和某些標籤的完全刪除），直到決定將兩者結合起來並嘗試觀察它們的表現方式。令我驚訝的是，以下字符串破壞了超鏈接功能並混淆了 DOM：
https://www.domain.com/abc#<script></script>https://domain.com/abc
在通過電子郵件本身發送以上內容之後，內容解析如下：
<a href=”https://www.domain.com/abc#<a href=” https:=”” www.domain.com=”” abc=”"” rel=”noopener noreferrer”>https://www.domain.com/abc</a>
這在一開始是非常有趣的，但利用它會有點困難。在標籤中定義屬性很容易（例如 src、onmouseover、onclick 等），但是提供值就很困難了，因為我們仍然需要匹配 URL regex，這樣它就不會逃脫自動超連結的功能。最終在不發送單引號、雙引號、括號、空格或反引號的情況下工作的有效負載如下：
https://www.icloud.com/mail/#<script></script>https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//
有效負載在 DOM 中生成如下內容：
<a href=”https://www.icloud.com/mail#<a href=” https:=”” www.icloud.com=”” onmouseover=”location=/javascript:alert%28document.domain%29/.source;//"”>https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//</a>
並給我們這個美麗的警告：
這個有效負載來自@Blaklis_的一個 CTF 解決方案。我最初認為它可能是不可利用的 XSS，但似乎總有某個地方可以解決邊界情況下的 XSS。
我最好的解釋是（1）加載初始 URL 時，「<script> </ script>」中的字符在自動超鏈接過程中是可接受的，並且沒有破壞它，然後（2）刪除了腳本標籤創建了一個空白或某種類型的 void，這些在不關閉初始超鏈接功能的情況下重置了自動超鏈接功能，最後（3），第二個超鏈接添加了額外的引號，該引號用於打破 href 並創建 onmouseover 事件處理程序。
第二個 XSS 的影響與第一個 XSS 相同，不同之處在於，用戶必須通過將鼠標置於電子郵件正文中的某個位置來觸發 onmouseover 事件處理程序，但是可以通過製作整個電子郵件的超鏈接簡化此部分以使其更容易觸發。
總體而言，攻擊者可能會濫用此訊息來：
創建一種蠕蟲病毒，該蠕蟲能夠以靜默方式洩露/修改 iCloud 帳戶信息（包括照片和視頻）；在受害者的瀏覽器中靜默執行任意 HTML 和 JavaScript。
看到最後，你認為蘋果這 5 萬美元給少了嗎？
（本文經合作夥伴 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈3 個月時間，5 名黑客找出蘋果 55 個漏洞，賺了 5 萬多美元，還寫了篇博客記錄全程 〉。）
你可能會有興趣
- 【駭客收到警方通知後馬上提供解鑰】本想將勒索軟體送到大學卻誤送醫院，導致 IT 系統崩潰使一病患不幸身亡
- 【戶籍所得資料全被看光光？】MyData 爆資安漏洞！自然人憑證簽章流程成駭客攻擊目標
- 【聽聲音就能複製鑰匙！】駭客蒐集大量開鎖「喀擦」聲，用軟體分析破解門鎖