昨天，翹首期待的iPhone12終於面世，不管是迴歸經典方框設計，還是首次推出小屏mini版，都讓蘋果玩家大呼過癮。不過，在今年這場別開生面的釋出會之前，以安全著稱的蘋果卻忽然被曝出55個漏洞。想要剁手的朋友們儘管放寬心，因為這些漏洞已經被5名駭客報給了蘋果，還因此小賺一筆，獲得了5萬美金的獎勵。事情是這樣的，蘋果一直有對漏洞報告者進行資金獎勵的傳統，並且給這個專案取了個酷炫的名字——Apple Bug賞金計劃。今年7月，一位資深技術從業者Brett Buerhaus在twitter上看到一位同行因為發現了蘋果的身份驗證繞行bug而獲得蘋果公司10萬美元的獎勵，於是非常心動，並召集了4位駭客朋友一起，研究蘋果的整個基礎程式。經過了長達3個月對蘋果線上服務的研究和分析，找出了55個漏洞，其中一些還非常危險。比如，居心叵測的人可以利用這些漏洞製造一種蠕蟲，進而自動竊取某人的iCloud帳戶中的所有照片、影片和文件，甚至能對受害者的聯絡人進行同樣的攻擊。聽上去也太可怕了吧，文摘菌攥緊了早已碎屏的iPhone…不過還好，在發現這些漏洞之後，這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伺服器後，我們開始在更有趣的伺服器上執行目錄暴力破解。
https://samcurry.net/hacking-apple/在國外媒體vice對這件事進行報導後不久，其中一名駭客Sam Curry就在個人推特上表示，蘋果告訴他們，他們還有機會獲得總計28.85萬美元的獎勵，因為之前蘋果只為部分漏洞付了錢，現在，他們準備再追加28個漏洞的獎金。
說到這次的專案，Sam Curry在他的部落格文章中表示，“沒想到會花掉我們3個多月的時間”。
“這原本是一個附屬專案，我們每隔一段時間會進行一次工作。但是在新冠疫情的影響下，我們有了很多額外的空閒時間，最終累積下來，每個人平均投入了數百小時。”不過，在這次的事件上，比起駭客們發現的漏洞，人們對於蘋果給予的獎金數額更感興趣。我們來簡單做一下數學。5名駭客用“數百小時”來研究蘋果的線上服務，他們在三個月內發現了55個漏洞，蘋果獎勵他們5萬美元，這麼算下來的話，每個人每個漏洞大約值250美元，或者每個人每月的“薪水”是17171美元。安全公司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個漏洞，這裡文摘菌也節選了其中兩個，先給大家過過眼癮。https://samcurry.net/hacking-apple/我們花時間入侵的第一個伺服器之一是"蘋果傑出教育家"網站。這是一個僅限邀請的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">...
觀察到這個隱藏的預設密碼欄位後，我們立即想到一種方法來手動認證應用程式，並訪問論壇的核準賬戶，而不是嘗試使用 "用蘋果登入 "系統登入。我們採取這個方法是因為我們每個人分別註冊時的密碼都是一樣的。如果有人使用這個系統進行申請，並且存在手動認證的功能的話，你可以簡單地使用預設密碼登入到他們的賬戶，完全繞過“用蘋果登入”登入。從表面上看，你似乎並不能手動認證，但在谷歌搜尋了後，我們發現了一個“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網站伺服器上執行任意命令；
儲存跨站點指令碼漏洞：允許攻擊者透過修改電子郵件竊取iCloud資料
蘋果基礎設施的核心部分之一是他們的iCloud平臺。該網站作為蘋果產品的照片、影片、文件以及app相關資料的自動儲存機制。此外，該平臺還提供了郵件和查詢我的iPhone等服務。郵件服務是一個完整的電子郵件平臺，使用者可以傳送和接收電子郵件，類似於Gmail和雅虎。此外，iOS和Mac上都有一個預設安裝的郵件應用程式。郵件服務與檔案和文件儲存等其他服務一起託管在“”上。這意味著，從攻擊者的角度來看，任何跨站點指令碼漏洞都將允許攻擊者從iCloud服務中檢索他們想要的任何資訊。在這一點上我們開始尋找任何跨站點指令碼問題。郵件應用程式的工作方式非常簡單直接。當服務收到一封電子郵件，使用者開啟它時，資料被處理成一個JSON blob，透過JavaScript進行過濾清理和分解，然後顯示給使用者。這意味著就內容過濾而言，沒有伺服器端對電子郵件進行處理，而呈現和處理郵件體的所有實際功能都在客戶端完成的JavaScript中。這並不一定是件壞事，透過理解我們需要在原始碼中具體破壞什麼，可以簡化標識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>
該電子郵件在我的收件箱中彈出。我點選了它。有警報提示！它奏效了！<style></style><script>alert(1)</script></style>
由於郵件應用程式託管在“”上，這意味著我們具有瀏覽器許可權，可以檢索iCloud服務的相應API的HTTP響應（如果我們可以潛入JavaScript以與他們聯絡）。在這一點上，我們認為最酷的概念證據會是竊取受害人的所有個人資訊（照片，日曆資訊和檔案），然後將相同的漏洞利用轉發給其所有聯絡人。我們構建了一個簡潔的PoC，它將從iCloud API返回照片URL，將其貼上到影像標籤中，然後在其下方附加使用者帳戶的聯絡人列表。這表明可以檢索這些值，但是要滲入它們，我們必須繞過CSP，這意味著除了“.apple.com”和其他幾個域外，沒有其他任何簡單的出站HTTP請求。對我們來說幸運的是，該服務是一個郵件客戶端。我們可以簡單地使用JavaScript來給自己傳送電子郵件，附加iCloud照片URL和聯絡人，然後傳送受害者簽名的iCloud照片和檔案url。以下影片展示了一個概念的證據，一個受害者的照片被盜。在由惡意方執行的充分利用場景中，攻擊者可以悄悄地竊取受害者的所有照片、影片和文件，然後將修改後的電子郵件轉發給受害者的聯絡人列表，並對iCloud郵件服務實施跨站點指令碼有效載荷蠕蟲攻擊。後來，我發現了第二個以類似方式影響郵件的跨站點指令碼漏洞。對於這類semi-HTML應用程式，我總是要檢查的一件事是它們如何處理超連結。自動將未標記的URL轉換為超連結似乎很直觀，但如果它沒有被正確地清理或與其他功能結合在一起，就會變得很混亂。這是查詢XSS的常見位置，因為依賴於regex、innerHTML和所有可在URL旁邊新增的可接受元素。此XSS的第二個有趣功能是完全刪除某些標籤，例如“ <script>”和“ <iframe>”。這很整潔，因為某些東西將依賴於字元，例如空格，製表符和換行符，而remove標記留下的void可以提供這些字元而無需告知JavaScript解析器。這些差異使攻擊者可以混淆應用程式，並潛入可以呼叫XSS的惡意字元中。我花了一段時間來研究這兩種功能（自動超連結和某些標籤的完全刪除），直到決定將兩者結合起來並嘗試觀察它們的表現方式。令我驚訝的是，以下字串破壞了超連結功能並混淆了DOM：在透過電子郵件本身傳送以上內容之後，內容解析如下：這在一開始是非常有趣的，但利用它會有點困難。在標籤中定義屬性很容易(例如src, onmouseover, onclick等)，但是提供值就很困難了，因為我們仍然需要匹配URL regex，這樣它就不會逃脫自動超連結的功能。最終在不傳送單引號、雙引號、括號、空格或反引號的情況下工作的有效負載如下： https:///mail/#<script></script>https:///onmouseover=location=/javascript:alert%28document.domain%29/.source;//
<a href="https:///mail#<a href=" https:="" ="" onmouseover="location=/javascript:alert%28document.domain%29/.source;//"">https:///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萬美元給少了嗎？歡迎在評論區留言討論~
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562039/viewspace-2727309/，如需轉載，請註明出處，否則將追究法律責任。
