SSL的弱點-SSL renegotiation

http://www.isecutech.com.tw/article/article_detail.aspx?tv=71&aid=6448

作者：張維君 -10/31/2011
許多網友以為只要網站有SSL加密，網址前面是https就可以安心填入個資、安心購物。但實際上這樣的想法恐怕只對了一半。安全研究人員指出，過去3年來，SSL協定的安全疑慮一直未獲得解決。德國駭客團體The Hacker”s Choice為了讓憑證廠商正視此問題，日前釋出一個攻擊工具，利用SSL renegotiation的漏洞，不需要大量頻寬，只要一台筆電就可癱瘓一個https網站。

一直以來，憑證廠商往往告訴網站、消費者，要認明SSL憑證來保護線上交易資料的安全。但實際上他們對於研究人員所提出的SSL漏洞問題，卻不夠重視。早在2009年，就有研究人員發表SSL renegotiation存有漏洞，renegotiation是用於驗證瀏覽器與網站伺服器間的連線。而今透過這個攻擊工具，只要用一台筆電持續對網站發出安全連線請求，就可以快速耗掉伺服器資源，達到讓系統癱瘓的目的。

除此之外，研究人員對SSL憑證的安全性仍有相當質疑，包括2009年SSL加密被破解，以及今年以來部分CA憑證公司遭入侵等。日前安全內容遞送網路(CDN)業者Akamai發表一份網際網路現狀報告，指出2009年以來SSL AES 128-SHA-1加密技術的使用已增加3倍，相對於RC4-MD5-128的使用減少將近2/3。因此，正當使用者、網站業者越來越重視線上交易安全，憑證廠商因盡速確保SSL加密技術如廣告行銷所言般值得信賴。

原文網址: 憑證廠商該修補漏洞了 駭客釋出SSL攻擊工具,Information Security 資安人科技網 http://www.isecutech.com.tw/article/article_detail.aspx?tv=71&aid=6448#ixzz1cVUhIprZ

http://mycck.blogspot.com/2010/01/renegotiating-tls-attack.html

作者：雲舒

摘要：sowhat大牛今天介紹了國外一 種的新的針對TLS/SSL3.0的攻擊方式，貌似關注的人不多，所以我特地看了一下那個PDF，稍微八 卦一下。

這個攻擊是非常巧妙的，主要是利用了TLS/SSL 3.0重置加密演算法機制和HTTP協定請求頭的key、value結構，實現了多次資料的組合以完成自己想要的請求，從攻擊效果來看有點類似CSRF攻擊。主要步驟如下：

1. 攻擊者連接目標網站完成SSL握手稱為session 1，並發送GET /adduser.jsp?u=yunshu&passwd=123 HTTP/1.1
FVCK: 之類的資料包。

2. 攻擊者劫持被攻擊者訪問目標網站的資料，在session 1中轉發被攻擊者與目標伺服器之間的SSL握手，被攻擊者和目標伺服器完成握手稱為session 2。

4. 目標網站和被攻擊者通過攻擊者的轉發完成握手，在session 2中被攻擊者發送自己的請求資料到目標伺服器，類似於GET / HTTP/1.1
Host: www.xxx.com
Accept: */*
Cookie: admin=1

之類的資料。

5. 目標網站在一個SSL Session 1中接收到一個新的SSL Client Hello時，會認為用戶端是在要求重新生成金鑰，因為在目標伺服器看來session 2也是攻擊者發過來的，而且是相同的TCP session中。最終導致目標伺服器認為session 2是session 1金鑰重置之後的延續，會將兩次的資料組合到一起。

6. 最終資料如下：GET /adduser.jsp?u=yunshu&passwd=123 HTTP/1.1
FVCK: GET / HTTP/1.1
Host: www.xxx.com
Accept: */*
Cookie: admin=1

。FVCK欄位伺服器不認識，真實請求GET / HTTP/1.1當成了FVCK欄位的值，一起被忽略掉，攻擊者成功的執行了添加WEB系統使用者的操作。

http://xizhizhu.blogspot.com/2009/11/ssl-renegotiation-vulnerability_16.html

The SSL renegotiation vulnerability revealed earlier this month has been demonstrated by a Turkish grad student, named Anil Kurmus, to steal user names and passwords of Twitter. The code is also available in the wild.

Yes, it’s totally true that even the attacker can inject a small amount of message at the beginning, he’s still unable to read the encrypted data. But let’s see how Kurmus’ attack works. (Of course, this hole has been patched by Twitter)

You can update your Twitter status with its API by posting your new status to http://twitter.com/statuses/update.xml, as well as your user name and password. The message is something like below:
POST /statuses/update.xml HTTP/1.1
Authorization: Basic username:password
User-Agent: curl/7.19.5
Host: twitter.com
Accept:*/*
Content-Length: 22
Content-Type: application/x-www-form-urlencoded
status=your new status

All that the attacker need to do is to inject a POST request header, and post the victim’s POST request to his own twitter account:
POST /statuses/update.xml HTTP/1.1
Authorization: Basic username:password
User-Agent: curl/7.19.5
Host: twitter.com
Accept:*/*
Content-Length: 140
Content-Type: application/x-www-form-urlencoded
status=POST /statuses/update.xml HTTP/1.1
Authorization: Basic username:password
…

The red part is injected by the attacker, and the blue part is submitted by the victim. Then the server would be fooled to post the victim’s credential, and now, the attacker gets the user name and password of the victim.

Quite simple, but really destructive!