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