原文鏈接：https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat

原文發(fā)表時間：2013.9.10

本博文僅僅是上述原文的翻譯，僅供研究參考，本人不對準(zhǔn)確性作任何保證，侵立刪，如有轉(zhuǎn)載，需自行承擔(dān)所有責(zé)任。如有翻譯不準(zhǔn)確的地方，歡迎指教。

?

昨天，我改變了?SSL Labs 的打分規(guī)則（譯者注：SSL Labs是一個在線檢測SSL站點安全性的網(wǎng)站），停止檢測站點是否啟用了服務(wù)端的BEAST緩解措施。這表示我們現(xiàn)在認(rèn)為這種可以從客戶端進(jìn)行緩解，但是有一些事情你還是要了解的。

什么是BEAST？

TLS 1.0和更早版本的協(xié)議中有一個嚴(yán)重的漏洞：分組密碼中在加密前用于混淆明文的初始化向量（IV）可以通過中間人攻擊（MITM）預(yù)測到。IV是用來避免加密陷入定式，沒有它們，你每次使用相同的密鑰加密相同的分組時，你將得到相同的加密結(jié)果。這可不太好。一個聰明的攻擊者可以通過如下三個步驟來猜測加密的原文是什么：1）猜測IV；2）看看加密結(jié)果是什么；3）改變加密原文（譯者注：也就是“選擇明文攻擊”）。從技術(shù)的角度來看，攻擊者并未解密任何數(shù)據(jù)，但是可以驗證自己的猜測是否正確，但是如果沒有足夠多次的猜測，并不能發(fā)現(xiàn)任何明文信息。

這只是該問題的一個超級濃縮版本，如果你對詳細(xì)情況感興趣，建議您參看我之前寫的一篇文章，并且參考那篇文章中推薦的鏈接。

因為猜測并不是非常有效的，因此在實踐中BEAST攻擊只能獲取一小段數(shù)據(jù)。這聽起來好像沒什么卵用，但是我們使用的很多高價值的信息都是不大的數(shù)據(jù)段，例如：HTTP session cookie，認(rèn)證憑證集（許多協(xié)議中都在用，而不僅僅是HTTP），基于URL的session token等等。因此，BEAST是一個很嚴(yán)重的問題。

緩解措施現(xiàn)狀

BEAST是純粹的客戶端脆弱性。因為這種攻擊已經(jīng)被公開，許多主流的瀏覽器廠商都通過一種稱為1/n-1 split的技術(shù)解決了這個問題。這種技術(shù)通過阻止攻擊者猜測IV從而有效的從根本上解決了這個問題。

但是有一個平臺拖了后腿 -- 蘋果家的。我們對他們是怎么想的一無所知，因為他們沒有就此問題進(jìn)行過官方的說明。我的理解是Mountain Lion的發(fā)布版中會包含1/n-1 split，但是默認(rèn)是禁用的。另外，據(jù)我所知，IOS中并未使用該防范技術(shù)。

因為蘋果沒有解決BEAST攻擊，因此用戶仍然潛在的面臨著威脅。考慮到這個原因，今年年初，SSL Labs開始檢測站點是否使用了服務(wù)端的緩解措施以對抗這種攻擊。

?不幸的是，TLS1.0和更早期協(xié)議（當(dāng)前使用協(xié)議的大多數(shù)）對抗BEAST唯一有效的方法是使用RC4算法。之所以說“不幸”，是因為我們剛開始服務(wù)端緩解措施檢測后不久，一項關(guān)于RC4的研究發(fā)現(xiàn)這種算法比我們之前認(rèn)為的更弱。這種脆弱性雖然不會立即帶來危害，但很顯然RC4算法正在走向不歸路。

情況變得有些不妙，因為我們無法同時解決兩個問題。但是因為兩個問題大致可認(rèn)為同樣是低風(fēng)險，最終的策略也是很明顯的：RC4影響所有人，并且無法緩解；BEAST僅僅影響一部分人，并且不再有可利用的方法（希望吧）。另外，我們知道針對RC4的攻擊正變得更為有效，針對BESAT的攻擊似乎變得更少了。

BEAST還是一個威脅嗎？

從目前的情況看，剩下的唯一工作就是證明利用BEAST的路徑都被切斷了。但是我們并沒有有關(guān)這點的可信信息，因此我打算測試一些運行在脆弱性平臺的瀏覽器，如果可能的話閱讀它的源代碼，并且嘗試?yán)肂EAST。

這項研究需要大量的精力和時間，主要是因為我不想只是運行現(xiàn)有的利用工具，我想完全理解這種攻擊，并且發(fā)掘其他可能的攻擊方法。Juliano和Thai（BEAST作者）對我的問題給了很多有用的回答。我曾走了一些彎路，一部分是因為現(xiàn)實的問題，一部分是因為我的錯誤。我認(rèn)為BEAST在很長一段時間里仍舊是可利用的，因為我發(fā)現(xiàn)在BEAST里使用的同源策略繞過仍舊存在，這點令我很是驚訝。很顯然，針對那個問題（譯者注：應(yīng)是指針對同源策略繞過的修復(fù)）的修復(fù)搞砸了。使用該漏洞，MITM仍能使用Java applet控制受害者的瀏覽器加密任意明文并發(fā)送到任意主機(jī)。

幸運的是，自從BEAST被公開之后，applet的運行機(jī)制已經(jīng)發(fā)生了很多改變。例如：現(xiàn)在在運行applet前總會有一個警告。在我的測試中，Java插件無法獲取HttpOnly的cookie，也無法在任何請求中發(fā)送或接收它。更為重要的是，由applet發(fā)出的HTTPS請求使用了Java的TLS協(xié)議棧，而不是宿主瀏覽器的。因為Java實現(xiàn)了1/n-1 split，因此BEAST無法發(fā)威。

結(jié)語

雖然SSL Labs對未實現(xiàn)服務(wù)端BEAST緩解措施的站點進(jìn)行懲罰（打低分），但這個問題還會長期存在，因為還有大量的瀏覽器尚未進(jìn)行修復(fù)。雖然我不認(rèn)為現(xiàn)在這個問題已經(jīng)被利用了，但是或許有我們不知道的一些攻擊方式。Safari新添加的一項特性會使得該項漏洞再次可被利用，或者有時間進(jìn)行測試的人可能會證明我是錯的。由于這個原因，我們需要一個良好的安全保證，我們需要Safari默認(rèn)的實現(xiàn)1/n-1 split。

另外，支持TLS1.1和1.2在現(xiàn)在及不遠(yuǎn)的未來并不能真正的解決BEAST，即使這些協(xié)議并不包含這種攻擊所利用的IV預(yù)測漏洞。第一個問題當(dāng)前網(wǎng)絡(luò)還主要是依賴TLS1.0，在SSL Pulse檢測的服務(wù)器中只有大約18%支持TLS1.2。因此，即使下一代的web瀏覽器都支持TLS1.2，服務(wù)完成升級仍舊需要一段時間。

還有第二個問題，所有主流瀏覽器都容易遭受協(xié)議降級攻擊，主動的MITM可以模擬失敗場景，迫使瀏覽器從TLS1.2回退至SSL3.0，從而利用IV預(yù)測漏洞。除非協(xié)議降級漏洞被修復(fù)，更新的協(xié)議僅僅對被動攻擊者有效，對主動的攻擊者則無效。

轉(zhuǎn)載于:https://www.cnblogs.com/likefrank/p/is-beast-still-a-threat.html

總結(jié)

以上是生活随笔為你收集整理的[译]BEAST还是一个威胁吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。