Upgrade to Pro — share decks privately, control downloads, hide ads and more …

VOYAGE GROUP 2014/06 セキュリティ勉強会 (エンジニア向け / 公開版)

VOYAGE GROUP 2014/06 セキュリティ勉強会 (エンジニア向け / 公開版)

Kousuke Ebihara

June 18, 2014
Tweet

More Decks by Kousuke Ebihara

Other Decks in Technology

Transcript

  1. セキュリティ勉強会 • かつて「セキュリティ塾」と題して実施していたものを復活 • 2014/06 から「全社向け」「エンジニア向け」の 2 パートに 分けて毎月実施……予定 •

    エンジニア向けにはたとえば「IE のゼロデイ脆弱性」は取 り上げたりしないんじゃないかと思う [要出典] • ホントは 5 月にはやるつもりではあったのだ
  2. おしながき • 4 月 - 6 月のトピック • Heartbleed •

    DNS キャッシュポイズニング • mXSS • (2 月の話題だけど) 『CSRF 対策用トークンの値にセッション ID そのものを使っても いい時代は終わりつつある』の件 • その他 • ミドルウェア、ライブラリ類の 1月�- 6 月のセキュリティリリース
  3. The Heartbleed Bug (TLS heartbeat read overrun (CVE-2014-0160)) • OpenSSL

    の Heartbeat 拡張の実装に脆弱性があったこ とから命名 • OpenSSL のプロセスメモリの一部 (64 KB) を覗き見るこ とができてしまう • 最悪ケースで致命的なリスクがありうること、TLS の Handshake フェーズの脆弱性であったこと、攻撃の痕跡を 残さないことなどから大きく注目された
  4. Heartbeat 拡張 (RFC 6520) • TLS に keep-alive 機能を提供する拡張 •

    TLS のレイヤーに対するこの拡張の有効性を疑問視する声も • 拡張された Hello メッセージ (Handshake フェーズ) として実現され る • ペイロードと共にペイロード長 (uint16) 等の情報を含む構造 • Heatbeat メッセージを受け取った側はペイロードをコピーして返す
  5. サーバ側が被害者の場合 + Heartbeat Client Mobile Server Handshake:ClientHello Handshake:ServerHello Handshake:Certificate Handshake:ServerHelloDone

    Handshake:ClientKeyExchange Handshake:Finished ChangeCipherSpec ChangeCipherSpec Handshake:Finished application_data application_data Alert:warning, close_notify
  6. サーバ側が被害者の場合 + Heartbeat Client Mobile Server Handshake:ClientHello Handshake:ServerHello Handshake:Certificate Handshake:ServerHelloDone

    Handshake:ClientKeyExchange Handshake:Finished ChangeCipherSpec ChangeCipherSpec Handshake:Finished application_data application_data Alert:warning, close_notify
  7. サーバ側が被害者の場合 + Heartbeat Client Mobile Server Handshake:ClientHello Handshake:ServerHello Handshake:Certificate Handshake:ServerHelloDone

    Handshake:ClientKeyExchange Handshake:Finished ChangeCipherSpec ChangeCipherSpec Handshake:Finished application_data application_data Alert:warning, close_notify
  8. サーバ側が被害者の場合 + Heartbeat Client Mobile Server Handshake:ClientHello Handshake:ServerHello Handshake:Certificate Handshake:ServerHelloDone

    Handshake:ClientKeyExchange Handshake:Finished ChangeCipherSpec ChangeCipherSpec Handshake:Finished application_data application_data Alert:warning, close_notify 0123456789abcd ef…⋯POST /login \nusername=admin &password=passwo rd…⋯0123456789ab
  9. クライアント側が被害者の場合 + Heartbeat Client Mobile Server Handshake:ClientHello Handshake:ServerHello Handshake:Certificate Handshake:ServerHelloDone

    Handshake:ClientKeyExchange Handshake:Finished ChangeCipherSpec ChangeCipherSpec Handshake:Finished application_data application_data Alert:warning, close_notify
  10. クライアント側が被害者の場合 + Heartbeat Client Mobile Server Handshake:ClientHello Handshake:ServerHello Handshake:Certificate Handshake:ServerHelloDone

    Handshake:ClientKeyExchange Handshake:Finished ChangeCipherSpec ChangeCipherSpec Handshake:Finished application_data application_data Alert:warning, close_notify
  11. クライアント側が被害者の場合 + Heartbeat Client Mobile Server Handshake:ClientHello Handshake:ServerHello Handshake:Certificate Handshake:ServerHelloDone

    Handshake:ClientKeyExchange Handshake:Finished ChangeCipherSpec ChangeCipherSpec Handshake:Finished application_data application_data Alert:warning, close_notify
  12. クライアント側が被害者の場合 + Heartbeat Client Mobile Server Handshake:ClientHello Handshake:ServerHello Handshake:Certificate Handshake:ServerHelloDone

    Handshake:ClientKeyExchange Handshake:Finished ChangeCipherSpec ChangeCipherSpec Handshake:Finished application_data application_data Alert:warning, close_notify 0123456789abcd ef…⋯POST /login \nusername=admin &password=passwo rd…⋯0123456789ab
  13. 原因 • Heartbeat 拡張フィールドのパース部分における buffer over read (CWE-119: Improper Restriction

    of Operations within the Bounds of a Memory Buffer) • ペイロードと共に送られてきたペイロード長のチェックをおこなわ ないまま memcpy() している • そのため、大きすぎるペイロード長 (最大で約 65,353) を与え、 隣接したメモリの内容を Heartbeat のレスポンスとして得ること ができてしまう
  14. 原因となったコード (引用者によりインデント幅調整済み) tls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0],

    *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ ! /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; ************************ SNIP ************************ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; ! /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); bp += payload;
  15. 原因となったコード (引用者によりインデント幅調整済み) tls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0],

    *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ ! /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; ************************ SNIP ************************ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; ! /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); bp += payload; *p Heartbeat パケット Heartbeat パケット
  16. 原因となったコード (引用者によりインデント幅調整済み) tls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0],

    *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ ! /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; ************************ SNIP ************************ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; ! /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); bp += payload; 先頭バイトはメッセージの種類 (request /response) *p Heartbeat パケット Heartbeat パケット
  17. 原因となったコード (引用者によりインデント幅調整済み) tls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0],

    *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ ! /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; ************************ SNIP ************************ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; ! /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); bp += payload; 先頭バイトはメッセージの種類 (request /response) 次の 16 bit を payload (ペイロード長) に格納 *p Heartbeat パケット Heartbeat パケット
  18. 原因となったコード (引用者によりインデント幅調整済み) tls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0],

    *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ ! /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; ************************ SNIP ************************ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; ! /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); bp += payload; 先頭バイトはメッセージの種類 (request /response) 次の 16 bit を payload (ペイロード長) に格納 レスポンス用 buffer を allocate *p *buffer Heartbeat パケット Heartbeat パケット
  19. 原因となったコード (引用者によりインデント幅調整済み) tls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0],

    *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ ! /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; ************************ SNIP ************************ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; ! /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); bp += payload; 先頭バイトはメッセージの種類 (request /response) 次の 16 bit を payload (ペイロード長) に格納 レスポンス用 buffer を allocate リクエストから指定された長さのデー タをレスポンスのペイロードとして コピー。 Heartbeat パケットを超 えた領域もコピーしてしまう *p *buffer Heartbeat パケット Heartbeat パケット 隣接するプロセスメモリ
  20. 原因となったコード (引用者によりインデント幅調整済み) tls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0],

    *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ ! /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; ************************ SNIP ************************ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; ! /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); bp += payload; 先頭バイトはメッセージの種類 (request /response) 次の 16 bit を payload (ペイロード長) に格納 レスポンス用 buffer を allocate リクエストから指定された長さのデー タをレスポンスのペイロードとして コピー。 Heartbeat パケットを超 えた領域もコピーしてしまう *p *buffer Heartbeat パケット Heartbeat パケット 隣接するプロセスメモリ
  21. 影響 • 最悪ケースで TLS 証明書の秘密鍵が盗まれる • DNS に対する攻撃によって偽のサーバに誘導されても見破れない • 過去に収集された通信内容

    (暗号化済) を復号される (Perfect Forward Security 未実施の 場合 / 後述) • あるいは復号した通信の中身が盗まれているかもしれない (そこにはパスワード等の秘密情報があ るかもしれない) • 攻撃で盗める情報は 64 KB 程度で、攻撃者の望む情報がそのなかに含まれているとは限らない が、何度でも繰り返し試行することが可能 • 盗まれるのはプロセスメモリの中身なので、単一の通信内容を傍受されるよりも危険と言えるかも
  22. 対策 • サーバ / クライアントの OpenSSL をバージョンアップ • OpenSSL を組み込んでいる製品に注意

    • TLS 証明書の再発行と失効 • Heartbleed によって秘密鍵が盗まれている可能性 • 必要に応じてユーザーのセッションやパスワードのリセット、変更 • Heartbleed もしくは窃用した秘密鍵による MITM 攻撃によってこれら の秘密情報が盗まれている可能性
  23. Perfect Forward Security • 将来における通信内容の解読を防ぐ • 鍵交換アルゴリズムに ECDHE などを使うことによって実現 (認証の鍵と鍵交換の鍵を分け、か

    つ一時的な鍵とする) • NSA 情報漏洩事件によりその必要性が認識された • Twitter が 2013 年 11 月に導入したことでも話題に • おっと、 ELB で Perfect Forward Security が使えるようになってるらしい http:// aws.typepad.com/aws_japan/2014/02/elastic-load-balancing-perfect-forward- secrecy-and-other-security-enhancements.html • Predefined Security Policy で ELBSecurityPolicy-2014-01 を選択するだけで OK です。 素晴らしい
  24. DNS キャッシュポイズニング ルートサーバ キャッシュサーバ 権威 DNS サーバ Web サーバ クライアント

    攻撃者 なんらかの方法 (後述) で DNS キャッシュサーバを攻略 攻撃者の Web サーバ 攻撃者のサーバに誘導
  25. 代表的な攻撃手法 • Kashpureff 型 • 攻撃者が管理する権威サーバの応答パケットに問い合わせとは関係のない (ゾーン外の) ドメインの情 報を付加してキャッシュさせる •

    偽装応答型 • 問い合わせに対する本来の応答が送り込まれるよりも先に偽装応答をキャッシュサーバに送り込む (攻撃 対象ドメインの TTL に影響される) • Kaminsky 型 • 攻撃者が攻撃対象ドメインの存在しない名前をキャッシュサーバに検索させ、偽装応答型攻撃を実施 (攻 撃対象ドメインの TTL の影響を受けない)
  26. Kashpureff 型攻撃 キャッシュサーバ good.example.jp 権威 DNS サーバ クライアント evil.example.com 権威

    DNS サーバ evil.example.com evil.example.com の 応答と一緒に good.example.jp の additional セクショ ン (攻撃者のサーバに 向けた) を返す
  27. Kashpureff 型攻撃 キャッシュサーバ good.example.jp 権威 DNS サーバ クライアント evil.example.com 権威

    DNS サーバ 攻撃者の騙った good.example.jp の 情報をキャッシュ evil.example.com evil.example.com の 応答と一緒に good.example.jp の additional セクショ ン (攻撃者のサーバに 向けた) を返す
  28. Kashpureff 型攻撃 キャッシュサーバ good.example.jp 権威 DNS サーバ クライアント evil.example.com 権威

    DNS サーバ 攻撃者の騙った good.example.jp の 情報をキャッシュ evil.example.com evil.example.com の 応答と一緒に good.example.jp の additional セクショ ン (攻撃者のサーバに 向けた) を返す
  29. Kashpureff 型攻撃 キャッシュサーバ good.example.jp 権威 DNS サーバ クライアント evil.example.com 権威

    DNS サーバ 攻撃者の騙った good.example.jp の 情報をキャッシュ evil.example.com good.example.jp evil.example.com の 応答と一緒に good.example.jp の additional セクショ ン (攻撃者のサーバに 向けた) を返す
  30. Kashpureff 型攻撃 キャッシュサーバ good.example.jp 権威 DNS サーバ クライアント evil.example.com 権威

    DNS サーバ 攻撃者の騙った good.example.jp の 情報をキャッシュ evil.example.com good.example.jp キャッシュサーバが 偽装された good.example.jp の 応答を返してしまう evil.example.com の 応答と一緒に good.example.jp の additional セクショ ン (攻撃者のサーバに 向けた) を返す
  31. Kashpureff 型攻撃への対策 キャッシュサーバ good.example.jp 権威 DNS サーバ evil.example.com 権威 DNS

    サーバ 偽装 additional セクション *.example.com の応答に *.example.jp の応答が返って くるのはおかしいのでキャッシュ せずに破棄する
  32. 偽装応答型攻撃 キャッシュサーバ DNS サーバ クライアント 攻撃者 送信元 IP アドレスや正しい ポート番号、

    transaction ID を騙った偽装 DNS 応答を (正しい DNS サーバが応答を 返すまでの間に) 送り込む
  33. 偽装応答型攻撃 キャッシュサーバ DNS サーバ クライアント 攻撃者 送信元 IP アドレスや正しい ポート番号、

    transaction ID を騙った偽装 DNS 応答を (正しい DNS サーバが応答を 返すまでの間に) 送り込む ※正しい DNS サーバが応答を返してしまう とその応答がキャッシュされてしまうため、 TTL 切れまで攻撃できない
  34. Kaminsky 型攻撃 キャッシュサーバ 攻撃者 DNS サーバ 存在しない *.example.jp に対する問 い合わせを大量に送りつける

    (キャッ シュされていないので、常に問い合わ せがおこなわれる) evil1.example.jp evil2.example.jp evil3.example.jp
  35. Kaminsky 型攻撃 キャッシュサーバ 攻撃者 DNS サーバ 存在しない *.example.jp に対する問 い合わせを大量に送りつける

    (キャッ シュされていないので、常に問い合わ せがおこなわれる) evil1.example.jp evil2.example.jp evil3.example.jp evil1.example.jp evil2.example.jp evil3.example.jp
  36. Kaminsky 型攻撃 キャッシュサーバ 攻撃者 DNS サーバ 存在しない *.example.jp に対する問 い合わせを大量に送りつける

    (キャッ シュされていないので、常に問い合わ せがおこなわれる) evil1.example.jp evil2.example.jp evil3.example.jp evil1.example.jp evil2.example.jp evil3.example.jp 攻撃対象の good.example.jp の additional セクションを有した 偽装応答を大量に送りつける
  37. Kaminsky 型攻撃への対策 キャッシュサーバ 攻撃者 DNS サーバ evil1.example.jp evil2.example.jp evil3.example.jp evil1.example.jp

    evil2.example.jp evil3.example.jp transaction ID を 毎回異なるものに ポート番号を 毎回異なるものに (port randomization)
  38. Kaminsky 型攻撃のその後 • Dan Kaminsky が 2008 年に発表した方式では攻撃でき ず (当時の

    BIND の実装上の問題によって成功していた) • しかし、同年 Bernhard Müller によって示された node re- delegation を用いた Kaminsky 型攻撃は成立する
  39. 委任 (delegation) • ドメイン名を各ゾーンに階層化するための仕組み • sub.example.co.jp ゾーン (a.sub.example.co.jp, b.sub.example.co.jp, …)

    • example.co.jp ゾーン (ebi.example.co.jp, kani.example.co.jp, sasori.example.co.jp, …) • .jp ゾーン
  40. 委任 (delegation) • ドメイン名を各ゾーンに階層化するための仕組み • sub.example.co.jp ゾーン (a.sub.example.co.jp, b.sub.example.co.jp, …)

    • example.co.jp ゾーン (ebi.example.co.jp, kani.example.co.jp, sasori.example.co.jp, …) • .jp ゾーン example.co.jp ゾーンから委任さ れている
  41. 委任 (delegation) • ドメイン名を各ゾーンに階層化するための仕組み • sub.example.co.jp ゾーン (a.sub.example.co.jp, b.sub.example.co.jp, …)

    • example.co.jp ゾーン (ebi.example.co.jp, kani.example.co.jp, sasori.example.co.jp, …) • .jp ゾーン .jp ゾーンから委任されている example.co.jp ゾーンから委任さ れている
  42. 委任 (delegation) • ドメイン名を各ゾーンに階層化するための仕組み • sub.example.co.jp ゾーン (a.sub.example.co.jp, b.sub.example.co.jp, …)

    • example.co.jp ゾーン (ebi.example.co.jp, kani.example.co.jp, sasori.example.co.jp, …) • .jp ゾーン .co.jp ゾーンは存在しない (.jp ゾーンに属している) .jp ゾーンから委任されている example.co.jp ゾーンから委任さ れている
  43. Müller による攻撃手法 • 攻撃対象のドメインを直接問い合わせるのではなく、ネームサーバの偽委 任応答をキャッシュさせる (より「近い」サーバの委任応答を優先するという DNS の仕様を悪用する) ことで効率的に攻撃が成功する旨が示されている •

    直接問い合わせ時の攻撃成功確率:
 P_cs = 1 - (1 - P_s) ^ (T / TTL) • 偽委任応答利用時の攻撃成功確率:
 P_cs = 1 - (1 - P_s) ^ (T) ※この計算式は http://tools.ietf.org/html/draft-hubert-dns-anti-spoofing-00 にて示されたものを基にしている。 P_cs…偽装パケットをキャッシュさせられる確率 (=攻撃成功確率)、P_s…正しい偽装パケットを生成できる確率、T…攻撃を実施す る時間、TTL…攻撃対象ドメインのキャッシュの TTL を意味する。 P_s の算出方法は本スライドでは割愛
  44. 前野氏、鈴木氏による 委任インジェクション攻撃手法 (1) • ゾーンとしては存在しない (=キャッシュされていない) ドメイン名 に対して Müller 方式

    (偽ネームサーバ応答) による攻撃をおこな うというもの • 存在しないゾーンに対するキャッシュは、偽応答以外に存在しな いため容易に攻撃可能 (=キャッシュを上書きする必要がない) • 「ゾーンとしては存在しないドメイン名」とは、たとえば、 �co.jp がある
  45. 対策 • 詳細は JPRS 公表の http://jprs.jp/tech/security/2014-04-30-poisoning- countermeasure-resolver-1.pdf を参照のこと • Port

    Randomization は基本 • キャッシュサーバに対する攻撃の検知 • 攻撃可能な時間が増えれば増えるほど攻撃の成功確率が上がることは既に示したと おり • DNS キャッシュポイズニングはある種ブルートフォース的な攻撃手法であるので、ア ノーマリーベースでの振る舞い検知のアプローチで充分いける • 検知次第キャッシュをクリアする
  46. mXSS とは • innerHTML 等を経由して DOM ツリーを参照した際に、本来の DOM 構造とは異なる結果が得られることがあるのを利用して XSS

    攻撃に繋げる手法 • XSS 界隈で最近注目されているとのこと • 2007 年にはせがわようすけ氏が発見した、 IE の innerHTML 実装 がバックティックを引用符と解釈してしまう問題が再評価されて発覚 • だが、 mXSS は IE に限らず利用できうるテクニック
  47. innerHTML • innerHTML で操作した DOM 構造は入力の HTML とは異なる • innerHTML

    から取得した HTML は DOM 構造とは異なる • ということは、以下のような JavaScript の結果は……? • element.innerHTML = element.innerHTML • element.innerHTML += ‘…’ • element. insertAdjacentHTML(‘…’, element.innerHTML) • document.write(element.innerHTML)
  48. Attack Vector • Backtick Characters breaking Attribute Delimiter Syntax •

    XML Namespaces in Unknown Elements causing Structural Mutation • Backslashes in CSS Escapes causing String-Boundary Violation • Misfit Characters in Entity Representation breaking CSS Strings • CSS Escapes in Property Names violating entire HTML Structure • Entity-Mutation in non-HTML Documents • Entity-Mutation in non-HTML context of HTML documents 古い IE でのみ まあ普通はしない CSS を動的に構築するなってば。 しかも HTML 内に CSS を動的に (ry CSS (ry ? インライン SVG とかまだ存在してるの
  49. デモ • http://bit.ly/1hTlZ7L • WooYun.org が「QQ 空间」というサービスにて発見した IE に て影響を受ける

    mXSS 脆弱性を参考にしたもの • WooYun.org のアドバイザリ (中国語): http:// www.wooyun.org/bugs/wooyun-2014-051536 • その他 IE で影響のある例: http://www.thespanner.co.uk/ 2014/05/06/mxss/
  50. 影響 • JavaScript ライブラリ等も含め、 innerHTML 等を利用した DOM 再 構築をおこなっている箇所で XSS

    となりうる • innerHTML を避けるのはたぶん難しい • 幸いにも mXSS を成立させるためのテクニックはまだそれほど多く はない (が、潜在的なリスクはあるといえる) • 特に一部の HTML 要素のみを許可するようなフィルタリングはバイパ スされる可能性が高い。オリジナルの論文でも Web メーラに多く脆弱 性が見つかったと報告されている
  51. 対策 • インライン CSS の動的書き出しは絶対に避ける • TrueHTML と呼ばれるテクニックを使う (後述) •

    そろそろ CSP (Content Security Policy) も視野に入れ る必要があるかもしれない • CSP についてはまたどこかの機会で詳しく触れていきた いですね
  52. TrueHTML • http://html5sec.org/trueHTML/ (汎用的に使えるように作ってあるよう だが、ライセンスは?) • innerHTML の setter /

    getter の実装を XMLSerializer を利用したもの に置き換えるアプローチ • 対策が透過的に適用できる • XMLSerializer 自体はブラウザのコンポーネントなのでパフォーマンス上 の影響は小さい (らしい) • たぶんすべてのモダンブラウザで動作する
  53. Content Security Policy • https://developer.mozilla.org/ja/docs/Security/CSP • あらかじめ Web サイト作成者が用意したメタデータ内のポリシーに基 づき、ブラウザ上でのスクリプト実行を制限する

    • script / object / style / connect (XHR や WebSocket など) の 提供元ホストの制限、インラインスクリプトの制限、 eval() 等の制限 • Supported: IE 10+ (limited), Fx28+, Chrome31+, Safari5+ • IE の CSP はいまのところ sandbox ポリシーのみの模様……
  54. 何が問題か • 「セッション cookie は盗まれないが CSRF 対策用トークンは盗ま れうる」という状況が存在する • 海老原は

    HttpOnly を利用しているケースと BREACH attack を示した • これに加え、mala 氏はソーシャルエンジニアリング、プロキシサー バのキャッシュ、表示中の HTML ソースを外部サーバに送る種 類のブラウザ拡張機能 (クリッピングやあとで読む系サービス) を 経由して HTML が漏洩する可能性を示した
  55. HttpOnly • このフラグを指定した cookie は DOM に含まれなくなる • XSS 攻撃を受けた場合にセッション

    cookie が DOM 経 由で漏洩するのを防ぐ目的で IE が導入 (後にほとんど のモダンブラウザが導入し、 RFC 6265 も追従) • しかし、 CSRF 対策用トークンとしてセッション ID を DOM 上に載っけてしまうと……
  56. BREACH Attack • HTTP 圧縮によるコンテンツ長の変化を収集していき、 SSL による暗号化されたレスポンスに含まれるトークン等 の秘密情報を推測するサイドチャンネル攻撃 • CSRF

    トークンをはじめとした、レスポンスに繰り返し現れる トークン類を推測することができる • 一方で、レスポンスに現れないトークンは推測できない。 つまり通常はセッション ID を盗むことはできない
  57. どうすればよいか (1) • CSRF 対策の文脈のみでいえば、 セッション ID を SHA2 ファミリ

    のハッシュ関数あたりで生成したダイジェストをトークンとして使え ばいい • しかし、攻撃者がセッション ID を入手している状況であってもなお CSRF 攻撃を実行する動機は存在する • 自らがセッションハイジャックして攻撃をしたくない場合 • セッションハイジャックを検知されてセッションが無効になる場合
  58. どうすればよいか (2) • 以下のどちらか一方のアプローチでトークンを発行する • セッション ID と鍵を利用した HMAC •

    鍵の管理の必要が生じるが、設定ファイルにでも書い ておけばいい • CSPRNG (暗号論的擬似乱数生成器) によって生成した 乱数をセッション等に格納しておいてそれを用いる
  59. Apache Struts2 のクラスローダを 操作できてしまう脆弱性 • http://www.ipa.go.jp/security/ciadr/vul/20140417-struts.html • Web アプリケーションの権限を利用して特定ファイルの操作や任意 Java

    コードの実 行などができる • リクエストパラメータによってリフレクションを操作できる機能の悪用 • 過去にも同種の脆弱性が存在していたが、そのたびにブラックリスト的な正規表現に よるマッチングルールを増やすという方法で対処 • だが、 2014/03/05 にリリースされた 2.3.16.1 に CVE-2014-0094 への対 策漏れがあり、またその問題が修正版リリース前に公知になってしまったことによっ て問題が大きくなった (CVE-2014-0112, CVE-2014-0113)
  60. Covert Redirect • http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html • OpenID と OAuth 2.0 のクライアント側に存在するオープンリダイレクタ脆弱性を利用

    し、アクセストークンを窃用できてしまうという攻撃手法 • 本来クライアント側に渡されるはずのアクセストークンが、オープンリダイレクタを経由 して攻撃者のサーバに渡ってしまう • つまり攻撃者はそのアクセストークンによって実行可能なすべての操作をクライアント の権限によって実行可能 • サーバ側はリダイレクト先 URL の完全一致を必須に • クライアント側はオープンリダイレクタ脆弱性を作らないように
  61. CDNetworks の配信する コンテンツにマルウェアが混入 • http://www.cdnetworks.co.jp/pressrelease/2254/ • CDN サービスのオプションサービスである「コンテンツアップロードサービス」 を利用してアップロードされたコンテンツにマルウェア (Infostealer.Bankeiya.B)

    が混入 • 少なくとも JUGEM サービスで運営されたブログ、 H.I.S のウェブサイト、 Buffalo の公開するドライバファイル、 Aiming のオンラインゲームのパッ チファイルが影響を受けた • 詳細な原因は調査中だが、アップロード用のサーバに何らかの方法で侵入さ れ、ファイルを改竄された可能性があるとしている
  62. OpenSSL CCS Injection Vulnerability • http://ccsinjection.lepidum.co.jp/ja.html • クライアント/サーバの両方が脆弱な OpenSSL を利用している場合に、

    通信路上の攻撃者が本来と異なるタイミングで ChangeCipherSpec を 偽装して送信することで、その通信で使われる暗号鍵として第三者が予 測可能なものを使わせることができてしまう (つまり容易に MITM が成立 する) • 多くのウェブブラウザ (Android 版 Google Chrome を除く) では OpenSSL によって SSL 通信を処理していない (http://twitter.com/ kitagawa_takuji/status/475472325375049729)
  63. RFC 2616 is Dead • http://evertpot.com/http-11-updated/ • RFC 2616 (Hypertext

    Transfer Protocol -- HTTP/ 1.1) を置き換える RFC 7230 - 7239 が公開された • 古い仕様を整理、改善し、簡潔なものとした。仕様上のい くつかのセキュリティ上の問題点についても解決を図った • プロトコルバージョンに変更はない
  64. PHP (1) • Fileinfo 拡張における DoS • [CVE-2014-1943] PHP 5.5.10,

    PHP 5.4.26 にて修正 • [CVE-2014-2270] PHP 5.5.10 にて修正 • [CVE-2013-7345] PHP 5.5.11, PHP 5.4.27 にて修正 • [CVE-2014-0237] PHP 5.5.13, PHP 5.4.29 にて修正 • [CVE-2014-0238] PHP 5.5.13, PHP 5.4.29 にて修正 • 他、 CVE 番号のない DoS が PHP 5.5.12 と PHP 5.4.28 で修正されている • GD 拡張における Heap Buffer Overflow • [CVE-2013-7327] PHP 5.5.10 にて修正 (PoC あり: https://hackerone.com/reports/1356)
  65. PHP (2) • PHP-FPM における権限昇格 (ソケットファイルがデフォルト設定で 0666 で書き出されていた) • [CVE-2014-0185]

    PHP 5.5.12, PHP 5.4.28 にて修正 • PHP-FPM および PHP-CGI における DoS • 現時点では修正版リリースなし • PHP のビルドスクリプトが固定の /tmp/phpglibccheck に対して書き込んでいる • [CVE-2014-3981] 現時点では修正版リリースなし • dns_get_record() における Heap Buffer Overflow • [CVE-2014-4049] 現時点では修正版リリースなし (!) • 問題の修正コミットは PHP 5.4, PHP 5.5, PHP 5.6 に対しておこなわれている https://github.com/php/php-src/ commit/4f73394fdd95d3165b4391e1b0dedd57fced8c3b • けどこれ PHP 5.3 も影響受けるのでは……?�https://github.com/php/php-src/blob/PHP-5.3/ext/standard/ dns.c#L508-L513
  66. Composer • Composer が意図しないパッケージのインストールを誘発しやすい問題が 修正された • 解説エントリ書いております: http://co3k.org/blog/composer- replace-security-bug-has-been-fixed •

    Composer を最新版に更新しましょう • インストールしたパッケージが期待通りのものかを都度確認しましょう • 人の目の介在しないシステム上では composer update ではなく、信頼で きる lock ファイルを生成した上で composer install を実行しましょう
  67. ZendFramework • ZF2014-01: PHP-FPM 環境下で XXE 対策が有効にならないことがある PHP 側バ グへの対策

    (ZF1, ZF2) • http://co3k.org/blog/zf2014-01-xxe-protection に解説記事を書きました • ZF2014-02: OpenID のコンシュマー側実装に問題があり、悪意のあるプロバイダを 利用してなりすましログインされてしまう問題への対策 (ZF1, ZF2) • ZF2014-03: XSS 脆弱性があったというより、属性値として JavaScript 書いても大 丈夫なように過剰エスケープするようになった • ZF2014-04: ZF1 の Zend_Db_Select の order メソッドに任意の SQL を記述で きてしまう問題への対策 (例: ->order('MD5(1); drop table products’);)
  68. CodeIgniter • xss_clean() という XSS フィルタをバイパス可能な脆弱性に対する修正 • 大変そうですね…… https://github.com/EllisLab/CodeIgniter/issues/2667, https://github.com/

    EllisLab/CodeIgniter/issues/2771 • ハッシュ値のタイミング攻撃 (リモートから) に成功すれば PHP Object Injection 攻撃が可能となる脆弱性に対する修 正 (もしかすると任意 PHP コード実行に繋がるかもしれない) • http://seclists.org/fulldisclosure/2014/May/54 • CodeIgniter 2.2.0 で修正済み • mcrypt 拡張がインストールされていない場合のフォールバックとなる暗号化が弱く、暗号化済みセッション cookie を容 易に改竄できる問題に対する修正 (セッション変数の改竄のほか、状況によっては PHP Object Injection 攻撃が可能) • http://www.dionach.com/blog/codeigniter-session-decoding-vulnerability • CodeIgniter 2.2.0 で修正済み
  69. SwiftMailer • Swift_Transport_SendmailTransport における OS コ マンドインジェクション脆弱性 • sendmail コマンドの

    -f オプションにて渡される From ヘッ ダ値がエスケープされていなかった • SwiftMailer 5.2.1 にて修正
  70. Python • ZipExtFile.read() における DoS • [CVE-2013-7338] Python 3.3.4 にて修正

    • socket.recvfrom_into() における Buffer Overflow • [CVE-2014-1912] Python 2.7.7, Python 3.3.4 にて修正 • strop.expandtabs() における DoS • 現時点で CVE 番号なし / 修正版リリースもなし • exploit コードが公開されている • http://hg.python.org/cpython/rev/5dabc2d2f776 にて修正コミット自体はおこなわれて いるが、 NEWS に "You shouldn't be using this module!" という注意書きも追加されている
  71. Django • Django 1.4.11, 1.5.6, 1.6.3 リリース • [CVE-2014-0472] reverse()

    による任意コード実行 • [CVE-2014-0473] 未ログインページの CSRF トークンのキャッシュ経由の漏洩 • [CVE-2014-0474] いくつかの型のフィールドが MySQL の暗黙の型変換によって意図しない結 果を示す可能性 • Django 1.4.13, 1.5.8, 1.6.5 リリース • [CVE-2014-1418] IE に対して保存するべきでないブラウザキャッシュが保存されてしまってい た問題 • [CVE-2014-3730] いくつかのブラウザで許容される特殊な URL (http://\example.com/ な ど) に対するバリデーションを厳しくした
  72. Ruby • YAML パーサにおける Heap Overflow (任意コード実行の 可能性) (同梱、依存している libyaml

    の問題) • [CVE-2014-2525] Ruby 2.0.0-p481, Ruby 2.1.2 にて修正 • https://www.ruby-lang.org/ja/news/ 2014/03/29/heap-overflow-in-yaml-uri-escape- parsing-cve-2014-2525/
  73. Ruby on Rails • PostgreSQL の配列型の値に任意のデータを注入できる問題への対策 • [CVE-2014-0080] 4.0.3, 4.1.0.beta2

    にて修正 • ヘルパ関数 number_to_currency, number_to_percentage, number_to_human における XSS • [CVE-2014-0081] 3.2.17, 4.0.3, 4.1.0.beta2 にて修正 • ActionView における DoS (Rails 3.x のみ) • [CVE-2014-0082] 3.2.17 にて修正 • implicit render におけるディレクトリトラバーサル • [CVE-2014-0130] 3.2.18, 4.0.5, 4.1.1 にて修正
  74. Jenkins • 2014/2/14 に 14 件のセキュリティ脆弱性に関するアドバイザリが公開された https://wiki.jenkins-ci.org/ display/SECURITY/Jenkins+Security+Advisory+2014-02-14 • Jenkins

    自身が high と位置づけている脆弱性としてはたとえば以下がある • ログインを要求しないもの • Winstone サーブレットにおけるセッションハイジャック • クリックジャッキング • 実質的な権限昇格に繋がるもの • いくつかの API におけるシリアライゼーションの不備を悪用した任意コード実行 • XSS • CLI job におけるディレクトリトラバーサル
  75. WordPress • 複数のセキュリティ上の問題を修正した 3.8.2, 3.7.2 がリリースされ ている • CVE ID:

    2014-0166, 2014-0165 • あと謎の SQLi • WordPress 3.9.0 が出た • WordPress は基本的に最新のメジャーバージョンしかサポートし ないので早めのアップグレードを
  76. 参考文献
 (The Heartbleed Bug) • https://www.openssl.org/news/secadv_20140407.txt • Heartbleed OpenSSL -

    Information Leak Exploit http://www.exploit-db.com/exploits/32791/ • http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902 • RFC 6520 http://tools.ietf.org/html/rfc6520 • CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば http://d.hatena.ne.jp/nekoruri/ 20140408/heartbleed • 本の虫: なぜTheo de RaadtはIETFに激怒しているのか http://cpplover.blogspot.jp/2014/04/theo-de- raadtietf.html • 自堕落な技術者の日記 : ECDHE - livedoor Blog(ブログ) http://blog.livedoor.jp/k_urushima/tag/ ECDHE • Eric Rescorla 著 『マスタリング TCP/IP SSL/TLS 編』 (ISBN-978-4274065422)
  77. 参考文献
 (DNS キャッシュポイズニング) • Bernhard Müeller IMPROVED DNS SPOOFING USING

    NODE RE-DELEGATION https://www.sec-consult.com/fxdata/seccons/prod/ downloads/whitepaper-dns-node-redelegation.pdf • キャッシュポイズニングの開いたパンドラの箱 -1- http://www.e-ontap.com/dns/endofdns.html • インターノット崩壊論者の独り言 - 開いたパンドラの箱 - 長年放置されてきた DNS の恐るべき欠陥が明らかに http://www.e-ontap.com/blog/ 20140415.html • DNS/毒盛 - moin.qmail.jp https://moin.qmail.jp/DNS/%E6%AF%92%E7%9B%9B • Kaminsky Attack の全て https://www.nic.ad.jp/ja/materials/iw/2008/proceedings/H3/IW2008-H3-07.pdf • 株式会社日本レジストリサービス (JPRS) : キャッシュポイズニング攻撃対策:キャッシュ DNS サーバー運用者向け — 基本対策編 http://jprs.jp/ tech/security/2014-04-30-poisoning-countermeasure-resolver-1.pdf • JPRS トピックス&コラム 新たなるDNSキャッシュポイズニングの脅威 〜カミンスキー・アタックの出現〜 http://jprs.jp/related-info/guide/ 009.pdf • 親の心子知らず? 委任にまつわる諸問題について考える 〜ランチのおともに DNS〜 http://jprs.jp/tech/material/iw2012-lunch-L3-01.pdf • 民田 雅人 (著), 森下 泰宏 (著), 坂口 智哉 (著), 株式会社日本レジストリサービス(JPRS) (監修) 『実践DNS DNSSEC時代のDNSの設定と運用』 (ISBN-978-4048700733)
  78. 参考文献
 (mXSS) • mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記

    http:// d.hatena.ne.jp/hasegawayosuke/20140508/p1 • The innerHTML Apocalypse http://www.slideshare.net/x00mario/the- innerhtml-apocalypse • mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations https://cure53.de/fp170.pdf • mXSS http://www.thespanner.co.uk/2014/05/06/mxss/ • QQ空间某功能缺陷导致日志存储型XSS - 15 | WooYun-2014-51536 | WooYun.org http://www.wooyun.org/bugs/wooyun-2014-051536