Empfohlen
Weitere ähnliche Inhalte
Empfohlen
Empfohlen (20)
SSLv3の脆弱性 Another
- 2. はじめまして 平木です 今年のハッキング実演を担当しています 去年から大幅に質が上がったので是非来てね その内容に関連したことを話します
- 3. SSLv3 Webの通信でかつて使われていた暗号化のプロトコル POODLE Attack (CVE-2014-3566)によって 破られたため，安全でない 実はその前にも様々な脆弱性が指摘されてきた
- 4. SSLv3 Webの通信でかつて使われていた暗号化のプロトコル POODLE Attack (CVE-2014-3566)によって 破られたため，安全でない 実はその前にも様々な脆弱性が指摘されてきた BEAST Attack (CVE-2011-3389) Lucky Thirteen Attack (CVE-2013-0169)
- 7. ブロック暗号の仕組み (概略) ブロック暗号では，平文を固定長のブロックに分割して，ブロック単位で暗号化を行う 固定長の倍数にならない場合のために，パディング(詰め物)を末尾につける パディング判定の都合上，平文長がちょうど倍数のときもブロックと同じ長さのパディングをつける 平文 ブロック ブロック ブロック ブロック 平文 ブロック ブ ロック ブロック
- 8. ブロック暗号の仕組み (概略) ブロック暗号では，平文を固定長のブロックに分割して，ブロック単位で暗号化を行う 固定長の倍数にならない場合のために，パディング(詰め物)を末尾につける パディング判定の都合上，平文長がちょうど倍数のときもブロックと同じ長さのパディングをつける 最も単純なものは次のようなもの(ECB方式という)が，安全ではない 平文 ブロック ブロック ブロック ブロック 平文 ブロック ブ ロック ブロック
- 9. ECB方式 (安全でない) 同じブロックを 暗号化すると 常に同じ結果になる 使うべきでない 暗号化 CIPHER 3 PLAIN 3 暗号化 CIPHER 2 PLAIN 2 暗号化 CIPHER 1 PLAIN 1
- 10. 1976年にIBMが開発 CBC方式 暗号化 CIPHER 3 PLAIN 3 XOR 暗号化 CIPHER 2 PLAIN 2 XOR 暗号化 CIPHER 1 PLAIN 1 XOR IV
- 11. 1976年にIBMが開発 平文ブロックに 「直前の暗号ブロック」とXORしてから 暗号化にかける 同じブロックでも違う結果になるので より安全 最初の平文ブロックでは ランダムに生成したブロック(IV)を XORのために使う CBC方式 暗号化 CIPHER 2 PLAIN 2 XOR CIPHER 1IV
- 12. 逆をするだけ CBC方式の復号 CIPHER 1 復号 CIPHER 2 PLAIN 2 XOR
- 13. 2つの整数をbitごとにみて 等しいなら0, 異なるなら1 XOR? 1 0 1 1 0 1 0 1 1 0 0 1 1 1 0 1 0 0 1 0 1 0 0 0
- 14. 2つの整数をbitごとにみて 等しいなら0, 異なるなら1 すごい性質を持つ A xor A = 0 結合法則，交換法則が成り立つ そのおかげで足し算感覚で使える XOR? 1 0 1 1 0 1 0 1 1 0 0 1 1 1 0 1 0 0 1 0 1 0 0 0
- 15. こんな感じ もっとゆっくり聞きたいなら ハッキング実演聞きに来てね SSLv3の仕組み (概略) 暗号化 CIPHER 2 PLAIN 2 XOR CIPHER 1IV
- 16. 平和に暮らしていたSSLv3ちゃん 1995年生まれ Introduction 暗号化 CIPHER 2 PLAIN 2 XOR CIPHER 1IV
- 17. 平和に暮らしていたSSLv3ちゃん 1995年生まれ でも平穏はそんなに長くは続かなかった Introduction 暗号化 CIPHER 2 PLAIN 2 XOR CIPHER 1IV
- 18. 2011年発表 SSLv3はおバカだったので， 前回の通信での最後の暗号ブロックを IVとして再利用していた BEAST attack (CVE-2011-3389) 暗号化 CIPHER 2 PLAIN 2 XOR CIPHER 1IV
- 19. 2011年発表 SSLv3はおバカだったので， 前回の通信での最後の暗号ブロックを IVとして再利用していた これを利用して，通信を傍受することで IVの値を知ることが出来る BEAST attack (CVE-2011-3389) 暗号化 CIPHER 2 PLAIN 2 XOR CIPHER 1IV
- 20. 右側が解読したい暗号文 CIPHER Dを 解読してみる BEAST attack (CVE-2011-3389) 暗号化 CIPHER D PLAIN D XOR CIPHER CIV 暗号化 CIPHER 1 ?????? XOR
- 21. BEAST attack (CVE-2011-3389) 解読したい暗号文 “CIPHER D”を 解読してみる 傍受直後にリクエストさせる IVは直前の通信から既知 PLAIN 1を操作でき， 暗号化の結果を後から 傍受できる 暗号化 CIPHER 1 PLAIN 1 XOR CIPHER C IV 暗号化 CIPHER D PLAIN D XOR ↑傍受した ←解読したい ↑傍受した ↑脆弱性より推測できた ↑後で傍受できる いじれる→
- 22. BEAST attack (CVE-2011-3389) 解読したい暗号文 “CIPHER D”を 解読してみる PLAIN 1を適当なブロックに 置き換えて送った後 CIPHER 1が左図の CIPHER Dと等しくなった時 暗号化 CIPHER D PLAIN 1 XOR CIPHER C IV 暗号化 CIPHER D PLAIN D XOR ↑傍受した ←解読したい ↑傍受した ↑脆弱性より推測できた ↑後で傍受できる いじれる→
- 23. BEAST attack (CVE-2011-3389) 解読したい暗号文 “CIPHER D”を 解読してみる PLAIN 1を適当なブロックに 置き換えて送った後 CIPHER 1が左図の CIPHER Dと等しくなった時 CIPHER C xor PLAIN D IV xor PLAIN 1 この2つは等しいと 推測できる PLAIN 1 XOR CIPHER C IV PLAIN D XOR ↑傍受した ←解読したい ↑脆弱性より推測できた いじれる→ DECRY DECRY
- 24. BEAST attack (CVE-2011-3389) 解読したい暗号文 “CIPHER D”を 解読してみる 右で分かった式で PLAIN D以外の 3ブロックは全て わかっているので PLAIN Dの値が 逆算できる PLAIN 1を適当なブロックに 置き換えて送った後 CIPHER 1が左図の CIPHER Dと等しくなった時 CIPHER C xor PLAIN D IV xor PLAIN 1 この2つは等しいと 推測できる PLAIN 1 XOR CIPHER C IV PLAIN D XOR ↑傍受した ←解読できた ↑脆弱性より推測できた いじれる→ DECRY DECRY
- 25. そのままだとブロック全体を総当たりしなければならない ブロック長が16byteとしても3.40 × 1038 通り BEASTの成功確率 暗号化 CIPHER 1 PLAIN 1 XOR IV
- 26. そのままだとブロック全体を総当たりしなければならない ブロック長が16byteとしても3.40 × 1038 通り どうにかして「1byteを除いて全てわかる」状態にしたい 実はできる BEASTの成功確率 暗号化 CIPHER 1 PLAIN 1 XOR IV
- 27. そのままだとブロック全体を総当たりしなければならない ブロック長が16byteとしても3.40 × 1038 通り どうにかして「1byteを除いて全てわかる」状態にしたい 実はできる 以下のようなリクエストを送信した時: POST /about HTTP1.1¥r¥n[HEADER]¥r¥n[BODY] パスとボディは攻撃者が任意に変えることが可能なので 上記のような状態を容易に作り出せる BEASTの成功確率 暗号化 CIPHER 1 PLAIN 1 XOR IV
- 28. めっちゃこわい SSLv3にひどいことしないで 幸いにも対策が容易だったので致命的にはならなかった BEASTの餌食と化したSSLv3 暗号化 CIPHER 1 PLAIN 1 XOR IV
- 29. 2013年に発表 SSLv3破りがアツい(？) パディングオラクル攻撃を実証 オラクル(Oracle): 神託，神の言葉 Lucky Thirteen attack (CVE-2013-0169)
- 30. 2013年に発表 SSLv3破りがアツい(？) パディングオラクル攻撃を実証 オラクル(Oracle): 神託，神の言葉 パディング様の御言葉が聞こえる… Lucky Thirteen attack (CVE-2013-0169)
- 31. TLSパケットの暗号処理では，データの改竄を検出するために， MACというハッシュ値を生成している ここで，メジャーなMAC生成法であるHMAC-SHA1においては，データ長によって 何度ハッシュ処理を行うかが異なる 55byte以下で4回，56, 57byteで5回 Lucky Thirteen attack (CVE-2013-0169) 平文ヘッダ MAC→ ↑ ヘッダは13byte固定
- 32. TLSパケットの暗号処理では，データの改竄を検出するために， MACというハッシュ値を生成している ここで，メジャーなMAC生成法であるHMAC-SHA1においては，データ長によって 何度ハッシュ処理を行うかが異なる 55byte以下で4回，56, 57byteで5回 テキトーに計80byteのシーケンスを送って復号させると， 「(57-N)byteのデータ，20byteのMAC，Nbyteのパディング」のように解釈される 復号結果のパディングは，大きく以下の4種類に分けられる おかしいパディング (MAC計算の対象は57byte) 0x00 で終わる，1byteのパディング (MAC計算の対象は56byte) 0x01 0x01 で終わる，2byteのパディング (MAC計算の対象は55byte) その他のパディングとなるレアケース Lucky Thirteen attack (CVE-2013-0169) 平文ヘッダ MAC PADDING
- 33. TLSパケットの暗号処理では，データの改竄を検出するために， MACというハッシュ値を生成している ここで，メジャーなMAC生成法であるHMAC-SHA1においては，データ長によって 何度ハッシュ処理を行うかが異なる 55byte以下で4回，56, 57byteで5回 テキトーに計80byteのシーケンスを送って復号させると， 「(57-N)byteのデータ，20byteのMAC，Nbyteのパディング」のように解釈される 復号結果のパディングは，大きく以下の4種類に分けられる おかしいパディング (MAC計算の対象は57byte) 0x00 で終わる，1byteのパディング (MAC計算の対象は56byte) 0x01 0x01 で終わる，2byteのパディング (MAC計算の対象は55byte) その他のパディングとなるレアケース Lucky Thirteen attack (CVE-2013-0169) 平文ヘッダ MAC PADDING
- 34. (レアケースを除けば)最後の2byteが”0x01 0x01”に復号されるときのみ ハッシュ処理が1回だけ減る この微妙な時間差を利用して，2byteずつ解読していく ならし成功確率は2byte毎に1/65536 (2byteの取り得る値は65536通り) 結構ヤバい SSLv3にひどいことしないで！！ Lucky Thirteen attack (CVE-2013-0169) 平文ヘッダ MAC PADDING
- 35. (レアケースを除けば)最後の2byteが”0x01 0x01”に復号されるときのみ ハッシュ処理が1回だけ減る この微妙な時間差を利用して，2byteずつ解読していく ならし成功確率は2byte毎に1/65536 (2byteの取り得る値は65536通り) 結構ヤバい SSLv3にひどいことしないで！！ 時間差を隠すことでなんとか対策した Lucky Thirteen attack (CVE-2013-0169) 平文ヘッダ MAC PADDING
- 36. 翌年(2014)，SSLv3はついにとどめを刺される それがPOODLE攻撃 名前はかわいい ハッキング実演で実際に暗号化部分を破ってみるので， 興味のある方，またSSLv3の仕組みを復習したい方は是非お越しください あっちではもう少しだけゆっくりと解説します そしてPOODLE(CVE-2014-3566)へ…