背景內容
在分析iOS平臺上與沙盒逃逸有關的攻擊面時，我們在iCloud鑰匙串同步功能的OTR實現中發現了一個嚴重的安全漏洞。
iCloud鑰匙串同步功能允許用戶以一種安全的方式跨設備共享自己的密碼。該協議與其他跨設備密碼共享機制（例如谷歌Chrome的密碼同步功能）相比，安全性有顯著的提升，因為它所采用的端到端加密使用了設備綁定型（device-specific）密鑰，而這種加密方式能夠顯著提升iCloud鑰匙串同步機制的安全性，即使用戶的密碼被盜或者iCloud后臺服務器受到攻擊，用戶的安全也能夠得到有效的保障。
但是，我們此次所發現的這個漏洞破壞了這種端到端加密的安全性，并有可能允許潛在的攻擊者竊取用戶的鑰匙串信息。在這篇文章中，我們將給大家詳細描述這個漏洞。
iCloud鑰匙串同步技術概覽
iCloud鑰匙串最早與iOS7被引入，該功能允許用戶跨設備共享自己的密碼和信用卡數據。除此之外，iCloud鑰匙串同步功能還可以讓用戶輕松地在設備間安全同步隱私信息，而且iCloud鑰匙串恢復機制還可以在用戶遺失了設備后，幫助他們恢復iCloud鑰匙串數據。
為了提升安全性，iCloud鑰匙串同步功能在交換鑰匙串對象時采用了端到端加密，這樣就可以保證只有參與鑰匙串交換的雙方設備才可以解密這些信息。加密過程依賴于一個同步識別密鑰（每臺設備只有一個），共享信息的明文數據以及加密密鑰都不會暴露給iCloud。這也就意味著，即使你可以無限制地訪問iCloud后臺服務器或iCloud通信數據，你也無法解密出鑰匙串數據。
數據的傳輸是通過iCloud鍵值存儲（與每一個iCloud賬戶單獨綁定）實現的，蘋果應用和第三方應用都可以使用鍵值存儲來為注冊了iCLoud服務的用戶同步數據。應用程序只能訪問當前用戶標識所允許的鍵值存儲數據，而iCloud系統服務控制著應用與鍵值存儲服務器之間的通信連接。與iCloud鍵值存儲的直接通信要求用戶提供密碼憑證或iCLoud認證令牌。
注：鑰匙串同步存儲數據所使用的識別符為com.apple.security.cloudkeychainproxy3。
交換信息
iCloud鑰匙串同步功能使用了一個自定義的開源OTR實現，這種OTR（Off-The-Record）信息協議具有不可否認性和前向安全性等特征。
為了接收或發送OTR數據，一臺設備必須是“signed-syncing-circle”中的一部分，并存儲在iCloud KVS之中。除了與每一臺設備相關的元數據之外，其中還包含有每臺設備所對應的公共同步身份密鑰。
系統采用了CTR模式的AES-128對數據進行加密，并且使用了ECDH認證密鑰交換算法。認證過程需要用到每個節點的身份密鑰，并且使用了ECDSA簽名算法（SHA-256）。
由于兩臺設備間的加密是成對的，因此一臺設備在向另一臺設備（必須是“signed-syncing-circle”中的一部分）傳輸新的OTR信息或交換鑰匙串數據時，必須要發起OTR會話協商。iCloud KVS中的信息屬性必須指定OTR信息的發送方和接收方，這樣才能保證正確的信息接收設備可以正常處理消息的內容。
這里需要注意的是，默認情況下并非每一個鑰匙串對象都會被同步，此時只有iCloud鑰匙串同步功能的kSecAttrSynchronizable屬性中所設置的那些鑰匙串對象才會進行同步，其中包括系統WiFI密碼和Safari憑證（例如信用卡卡號）。
加入“signed-syncing-circle”（簽名同步環）
iOS安全指南對其的描述如下：
“signed-syncing-circle”可以用來構建一個由多臺受信任設備所組成的一個組（Group）。其中，每一臺設備都要生成其自己的同步身份密鑰對（橢圓曲線密鑰），私鑰存儲在鑰匙串的‘kSecAttrAccessibleAlwaysThisDeviceOnlyPrivate’屬性之中，所以只有當設備解鎖后才可以訪問。注：“signed-syncing-circle”的簽名需要每臺設備的同步身份私鑰和用戶的iCloud密鑰。
為了讓一臺新設備加入到“signed-syncing-circle”之中，circle中現存的設備成員必須接受應用發出的ticket并將請求成員的公鑰添加到circle之中。這個ticket必須通過用戶的iCloud密鑰進行簽名，而請求過程同樣需要用戶輸入自己的iCloud密碼。這就意味著，用戶需要在請求設備以及circle中已存在的設備上進行交互操作，并通過用戶當前的iCloud密碼來驗證這些設備的真實性和有效性。
鑰匙串同步漏洞
我們所發現的這個漏洞存在于OTR的簽名認證程序中。由于系統沒有對錯誤進行適當的處理，攻擊者將有可能繞過這種簽名驗證機制。
源代碼：Security-57740.31.2/OSX/sec/Security/SecOTRSessionAKE.c
static OSStatus SecVerifySignatureAndMac(SecOTRSessionRefsession,
bool usePrimes,
const uint8_t **signatureAndMacBytes,
size_t *signatureAndMacSize)
{
OSStatus result = errSecDecode;
…
result = ReadLong(signatureAndMacBytes, signatureAndMacSize,&xbSize); [1]
require_noerr(result, exit);
require_action(xbSize > 4, exit, result = errSecDecode);
require_action(xbSize exit,result = errSecDecode);
uint8_t signatureMac[CCSHA256_OUTPUT_SIZE];
cchmac(ccsha256_di(), sizeof(m2), m2, xbSize + 4,encSigDataBlobStart, signatureMac);
require(xbSize + kSHA256HMAC160Bytes exit); [2]
…
exit:
bzero(m1, sizeof(m1));
bzero(m2, sizeof(m2));
bzero(c, sizeof(c));
return result;
}
我們可以看到代碼中標注了【1】的那一行，當程序成功從進來的握手信息中提取出了4個字節的數據時，返回代碼被設置為了‘errSecSuccess’。然后看【2】的那一行，如果傳入的信息長度太短以至于無法保存HMAC數據，那么函數將會退出運行。然而，返回代碼會錯誤地認為簽名認證已經成功了。這將允許攻擊者偽造一個能夠成功協商密鑰的OTR信息，然后繞過現有的簽名驗證機制。
影響
考慮到OTR在實現加密時采用的是臨時密鑰，所以這個漏洞也就意味著攻擊者在接收秘密信息時不用再去進行OTR會話協商了。雖然攻擊者無法利用這個漏洞加入到“signedsyncing circle”之中，但他們可以冒充circle內的任何一個節點，并且在鑰匙串對象同步的過程中攔截鑰匙串數據。
篇尾語
我個人認為，我們應該重新審視一下密碼的安全性問題了。在過去的幾年里，很多在事件應急響應團隊或政府執法部門工作的技術人員已經見過了很多由密碼重用所帶來的密碼安全問題，但攻擊者現在的技術已經不僅僅是通過釣魚網站來竊取密碼這么簡單了，因此保障密碼的安全才會變得如此的重要。但是我們應該注意一點，由于未來可能出現的安全風險是我們無法預料到的，而根據目前的情況來看，密碼也許已經不是我們保護敏感數據時的首選方案了。
更新：就在不久之前我們被告知，我們已經得到了在2017年BlackHat黑客大會上討論“iCloud鑰匙串竊取”這一主題的機會，希望感興趣的同學能夠及時關注。
| 
