最近，根據(jù)某國際安全小組的研究表明，金融巨頭Visa旗下部分受HTTPS保護(hù)的網(wǎng)站最近被發(fā)現(xiàn)了一種漏洞，它的存在可以讓黑客注入惡意代碼，訪客瀏覽器將會訪問到惡意內(nèi)容。

加密重用造成的Forbidden Attack

      據(jù)統(tǒng)計，受影響一共有184臺服務(wù)器，其中部分屬于德國證券交易所(Deutsche B?rse)和波蘭銀行協(xié)會(Zwizek Banków Polskich)，它們被發(fā)現(xiàn)容易受到某加密技術(shù)漏洞的攻擊，我們稱之為“Forbidden Attack”。此外，還有7萬臺web服務(wù)器被發(fā)現(xiàn)存在風(fēng)險，雖然實際執(zhí)行攻擊會比較困難。

      這些數(shù)據(jù)來自于1月份的全網(wǎng)掃描，當(dāng)時Deutsche B?rse就修補了這個漏洞。但是在上周三的時候，研究人員發(fā)現(xiàn)Visa和Zwizek Banków Polskich的漏洞似乎仍然存在，而且官方并沒有回復(fù)安全研究員私下提交的漏洞信息。

      該漏洞源于不正確的傳輸層安全協(xié)議，在數(shù)據(jù)被加密時，錯誤重用了相同的加密隨機(jī)數(shù)。TLS的規(guī)范其實已經(jīng)寫明，這些數(shù)據(jù)只能使用一次，當(dāng)多次重用時，則會導(dǎo)致Forbidden Attack。這種攻擊能讓黑客自行生成密鑰去認(rèn)證網(wǎng)站內(nèi)容。這個漏洞利用的首次提交，是 以評論的形式寫給國家標(biāo)準(zhǔn)技術(shù)研究所的。之所以叫這個名字，是因為其正確加密的基本原則，是必須臨時而獨特的。

      在TLS握手中，那184臺HTTPS服務(wù)重復(fù)使用了客戶端瀏覽器首次連接到HTTPS網(wǎng)站的那個隨機(jī)數(shù)，違背了加密的基本原則。因此，黑客只要有能力監(jiān)控連接傳輸?shù)膬?nèi)容，比如處于同一個不安全的wifi環(huán)境下，他們就可以將惡意內(nèi)容注入到傳輸數(shù)據(jù)流里，而客戶端瀏覽器并不能檢查出任何差錯。

      研究人員在一篇名為《忽視隨機(jī)數(shù)的惡果：TLS GCM實戰(zhàn)偽造內(nèi)容攻擊》的paper中寫道：“這是可靠性驗證的失敗，即使只在同一個時間段里重用一個隨機(jī)數(shù)，也能讓黑客通過HTTPS進(jìn)行偽造內(nèi)容攻擊。”這項研究的結(jié)果，也將作為8月份拉斯維加斯黑帽的大會某議題的基礎(chǔ)材料。

      黑客污染HTTPS認(rèn)證過的內(nèi)容的中間人攻擊，已經(jīng)擊破了TLS的基本保證。黑客可以繞過保護(hù)，添加惡意JS代碼或者添加能誘惑訪客輸入密碼、社會安全碼或者其他敏感數(shù)據(jù)的WEB內(nèi)容。雖然這個漏洞讓Forbidden Attack很好的文檔規(guī)范化了，新的研究結(jié)果仍值得我們注意如何利用它去對抗HTTPS保護(hù)的網(wǎng)站，網(wǎng)上也有相應(yīng)的POC代碼。

GCM隨機(jī)數(shù)重用攻擊visa.dk的POC

      這篇paper是由研究人員Hanno B?ck、Aaron Zauner、Sean Devlin、 Juraj Somorovsky、and Philipp Jovanovic共同撰寫，里面警告我們網(wǎng)上約7萬HTTPS服務(wù)器，可能會因為偽隨機(jī)數(shù)算法生成的“隨機(jī)數(shù)”而遭受這類攻擊。只要有足夠多的WEB請求，黑客就有很大可能性去重用其中一個來執(zhí)行攻擊。然而這樣所需WEB請求的數(shù)量是比較大的，約2的30次方個請求里取得重復(fù)隨機(jī)數(shù)的可能性為3%， 2的35次方個請求后能100%成功。正如paper的標(biāo)題所述，F(xiàn)orbidden Attack針對的是AES-GCM，世界上最廣泛的TLS對稱加密協(xié)議。

      在研究人員發(fā)現(xiàn)的7萬站點中，黑客需要往WEB連接里填充TB級別的數(shù)據(jù)，從而創(chuàng)建足夠多的請求。因此，這種攻擊的理論性可能會高于實際意義。但是，這仍然被大多數(shù)運用HTTPS保護(hù)的組織當(dāng)作不可接受的風(fēng)險。研究人員目前確定了幾個TLS實例中生成了偽隨機(jī)數(shù)，其中有IBM的DominoWEB服務(wù)器，已于3月打上了補丁。還有個Radware的負(fù)載均衡器的案例，也 已經(jīng)修復(fù)了。

      自研究人員發(fā)布掃描結(jié)果后，許多漏洞網(wǎng)站已經(jīng)修復(fù)了。但是只有工程師們深刻意識到這個問題，事情才能顯著改善，這也是研究人員發(fā)布這篇paper的原因。

Zauner 在郵件中寫道，“我敢肯定一年以后我再去掃描一遍，還是會有很多的漏洞案例?？赡苓€有更多方法可以利用它，誰知道呢?”

GCM工作機(jī)制淺析

      那么，像GCM或者類似CTR模式的CCM，為什么不能在發(fā)送的信息中進(jìn)行隨機(jī)數(shù)重用呢?下面我們將就GCM的工作機(jī)制進(jìn)行解釋一番：

      當(dāng)使用AES GCM時，我們并不會運行AES加密的數(shù)據(jù)。而我們會使用AES去加密標(biāo)志自增計數(shù)器創(chuàng)建的各區(qū)塊，這就造就了不可預(yù)知的比特流(密鑰數(shù)據(jù)流)。然后，我們會用需要加密的數(shù)據(jù)流與之進(jìn)行XOR運算。而最初的計數(shù)區(qū)塊，就是用來與其他加密文本一起生成身份驗證標(biāo)記的。

      如果我們單獨看AES加密算法，可以知道用相同的密鑰去加密相同的數(shù)據(jù)，是會得到相同的加密文本的，這也是我們?yōu)樯缎枰狢BC模式下的IV。那么我們在GCM里面重用相同的隨機(jī)數(shù)會發(fā)生什么呢?

假設(shè)有兩個不同的消息A和B，我們?nèi)绻谄渲惺褂昧送浑S機(jī)數(shù)N，這些消息的第一個區(qū)塊會被這樣加密：

      C?? = AES(counter(N,1)) ？ A?

      C?? = AES(counter(N,1)) ？ B?

      這基本上意味著，我們?nèi)绻褂孟嗤嫈?shù)器和相同的隨機(jī)數(shù)去XOR兩個加密的區(qū)塊，會得到XOR的文本：

      C?? ？ C?? = B? ？ A?

      如果我們知道其中一個純文本，我就可以用加密文本與之XOR，從而得到密鑰數(shù)據(jù)流。最后，我們就能解密另一段使用同樣的密鑰和隨機(jī)數(shù)加密的文本了(這點受限于已知文本長度)。