Google生物兵器 - 會咬人的貴賓狗

 

 

 

 

 

 

先介紹 貴賓狗

一般貴賓狗 超療癒啊

超凶狠貴賓狗 再看小心老子咬你

狗壞頂多咬人嘛

Google 家的貴賓狗呢?

它還會咬 SSL 3.0 

所以有了個代號

CVE-2014-3566
poodle-attacks-on-sslv3 

為什麼這漏洞叫 貴賓狗 ?

利用降級的方式來使用 SSL 3.0 漏洞

既然要講 SSL 安全問題

那就要先來講講 SSL&TLS

先來講講 SSL

Secure Sockets Layer (SSL)

  • 1995 年出 2.0 的公開版
  • 1996 年出 3.0 版 (因為 2.0 安全性問題)
  • 1999 年被 TLS 1.0 取代

Transport Layer Security (TLS)

  • 將 SSL 3.0 標準化與修改後成為 TLS 1.0 
  • 2006 年 TLS 1.1
  • 2008 年 TLS 1.2

SSL 3.0 是已被廢棄與不安全的老古董

但是...

原理解析:

SSL & TLS 身分認證

  • 非對稱式加密系統
  • X.509 規範

加密連線前 未加密

  1. Client > “client hello” > Server

  2. Server > “server hello” > Client

client hello

  • 支援的協定版本
  • 加密演算法
  • 隨機亂數RNC

server hello

  • 採用的協定版本
  • 加密演算法
  • 隨機亂數RNS
  1. Server > “公鑰 & 數位憑證” > Client

  2. Client  > “數位憑證/公鑰 > Server

身分認證 未加密

產生密鑰

  1. Client > "pre-master secret" > Server

  2. 利用 PMS & RNC & RNS 產生 

    master secret

  3. 改用 master secret 通訊

假.資安導論(真.密碼學)

RSA 為例計算

P=61、Q=53

N=61 x 53=3233

φ(3233)=(61-1)(53-1)3120

E需符合1<E<3120且與3120互質

選擇E=17

計算模反元素得D=2753

這時候就可以開始進行加、解密動作,假設明文M=65

加密C=MEmodN=6517mod3233=2790

解密M=CDmodN=27902753mod3233=65

安全風險

  • SSL 2.0 超不安全
  • 1024bits 的 key 容易被暴力猜解 (建議採用 2048 bits)
  • 中間人攻擊
  • 憑證沒通過認證

感覺其實安全問題不多啊

問題是...

駭客就像...

很愛挖洞鑽。

很會鑽的還會變成...

SSL 3.0 分析 :

先來討論 handshake

Handshake 內容

  • 明文/密文長度 :通常是 16 bytes 

  • 初始化向量IV:根據協議的演算法產生,長度和明文/密文長度一樣

  • 對稱 private Key:前面提到的 Master Secret

  • 加密模式:加密模似有多種,這次出問題的是 CBC

數據填充與分組

數據分組方式

  • MAC (Message Authentication Code,消息驗證碼)長度 : 20 bytes
  • 將 MAC 放在要加密的明文後面組成Plaintext
  • 將 Plaintext 長度填充到 16 bytes 整數倍的長度
  • 將 Plaintest 每 16 bytes 分為一組  > Plaintext Block (P1,P2,P3...)

數據填充方式

  • If Plaintext 長度 != 16的倍數:
    Plaintext + ( >=0 個 ) Padding byte + 1 byte (Padding byte 長度)
     
  • If Plaintext 長度 = 16的倍數  :
    Plaintext + 15 個 Padding byte + 1 byte (Padding byte 長度 = 15)

初始化向量IV

  • 初始化向量 IV 用於首次加密 (P0)
     

  • 要解密的密文一定是 16 的整數倍,所以可以直接每 16 bytes 長度分成 Cipher Block (C1,C2…Cn)
     

  • 初始化向量IV用於首次解密 (C0)

這邊還很好懂對吧?

變態的來了......

CBC模式原理

Text

每一個Plaintext Block可以解出Cipher Block
Pi -> Ci

每一個Cipher Block可以解出Plaintext Block
Ci -> Pi

SSLv3.0 驗證方式 :

  • 根據 Plaintext 最後一個 byte 取得 Padding 長度,刪掉這個 byte 還有 padding bytes 後,Plaintext 最後 20 bytes 是 Client 的 MAC 字串

     
  • 移除 MAC 字串後取得的就是明文資料, Server 重新計算該資料的 MAC 字串並且和 Client 的 MAC 比對來確定資料是否有效

POODLE 漏洞分析

  • 如果Plaintext + 20 bytes MAC 剛好是 16 的整數倍
  • Plaintext 的 Padding 填充會在 Plaintext後填充 15 bytes 的 Padding 和 1 bytes 的 Padding 長度(值為15)
  • 等於說最後 16 bytes 根本就是附加上去的拖油瓶(!?
  • 在這種天時地利人和的狀況下,有可能可以拿 Ci 替換 Cn,而且 Server 驗證還會通過的!

     
  • 也就是說...只要解密後的明文最後一 byte 是 15,就不會影響明文內容與 MAC 的排序!所以就通過驗證了!

POODLE 漏洞利用

漏洞使用成功率有高有低,使用前請先查閱漏洞使用說明書

劇情設定 :

  • 假設黑客使用中間人攻擊控制 Client 流量與發送AJAX請求
     
  • 假設攻擊者目標是取得 Client 的 cookies
     
  • 假設攻擊者知道 cookies 長度

先假設 post 是:

POST /path Cookie:…\r\n\r\nbody ‖ 20­bytes-MAC ‖ 15-bytes-padding || 15

  • 控制最後一 bytes 為 15 (P5[15] = ‘e’)
  • 加密前的 Plaintext 如下 :
  • 讓 C5 替代 C11 測試能不能通過驗證
  • 約莫 16^2 = 256 次內可以驗證成功
  • 然後控制 path 和 body 長度
  • 比如 path +1 或是 body -1
  • 持續摸出整個 cookies 

如果真的不知道 cookies 長度呢?

最多推個16次可以出來啦

第一次 Plaintext 請求內容 :
GET /\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

第二次 Plaintext 請求內容 :
GET /A\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

第三次 Plaintext 請求內容 :
GET /AA\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

第四次 Plaintext 請求內容 :
GET /AAA\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

第五次 Plaintext 請求內容 :
GET /AAAA\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

 POODLE 漏洞防範方式

  • Client - 關閉 SSL 3.0 或是 CBC 支援
  • Server - 開啓 TLS_FALLBACK_SCSV
  • 使用新版的瀏覽器 (Chrome / Firefox 新版將會不支援SSL3.0)

講了這麼多...

你有沒有發現...

Q & A

參考資料與圖表來源

POODLE -SSL3.0

By hrjk

POODLE -SSL3.0

  • 2,739