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

2014/06 セキュリティ勉強会 (エンジニア向け / 公開版) VOYAGE GROUP 情報セキュリティ委員会海老原昂輔 (@co3k)

セキュリティ勉強会 • かつて「セキュリティ塾」と題して実施していたものを復活 • 2014/06 から「全社向け」「エンジニア向け」の 2 パートに分けて毎月実施……予定 •
エンジニア向けにはたとえば「IE のゼロデイ脆弱性」は取り上げたりしないんじゃないかと思う [要出典] • ホントは 5 月にはやるつもりではあったのだ

おしながき • 4 月 - 6 月のトピック • Heartbleed •
DNS キャッシュポイズニング • mXSS • (2 月の話題だけど) 『CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある』の件 • その他 • ミドルウェア、ライブラリ類の 1月�- 6 月のセキュリティリリース

The Heartbleed Bug

The Heartbleed Bug (TLS heartbeat read overrun (CVE-2014-0160)) • OpenSSL
の Heartbeat 拡張の実装に脆弱性があったことから命名 • OpenSSL のプロセスメモリの一部 (64 KB) を覗き見ることができてしまう • 最悪ケースで致命的なリスクがありうること、TLS の Handshake フェーズの脆弱性であったこと、攻撃の痕跡を残さないことなどから大きく注目された

Heartbeat 拡張 (RFC 6520) • TLS に keep-alive 機能を提供する拡張 •
TLS のレイヤーに対するこの拡張の有効性を疑問視する声も • 拡張された Hello メッセージ (Handshake フェーズ) として実現される • ペイロードと共にペイロード長 (uint16) 等の情報を含む構造 • Heatbeat メッセージを受け取った側はペイロードをコピーして返す

サーバ側が被害者の場合 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

サーバ側が被害者の場合 + 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

サーバ側が被害者の場合 + 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

クライアント側が被害者の場合 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

クライアント側が被害者の場合 + 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

クライアント側が被害者の場合 + 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

原因 • Heartbeat 拡張フィールドのパース部分における buffer over read (CWE-119: Improper Restriction
of Operations within the Bounds of a Memory Buffer) • ペイロードと共に送られてきたペイロード長のチェックをおこなわないまま memcpy() している • そのため、大きすぎるペイロード長 (最大で約 65,353) を与え、隣接したメモリの内容を Heartbeat のレスポンスとして得ることができてしまう

原因となったコード (引用者によりインデント幅調整済み) 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;

*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 パケット

*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 パケット

*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 パケット

*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 パケット

*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 パケット隣接するプロセスメモリ

影響 • 最悪ケースで TLS 証明書の秘密鍵が盗まれる • DNS に対する攻撃によって偽のサーバに誘導されても見破れない • 過去に収集された通信内容
(暗号化済) を復号される (Perfect Forward Security 未実施の場合 / 後述) • あるいは復号した通信の中身が盗まれているかもしれない (そこにはパスワード等の秘密情報があるかもしれない) • 攻撃で盗める情報は 64 KB 程度で、攻撃者の望む情報がそのなかに含まれているとは限らないが、何度でも繰り返し試行することが可能 • 盗まれるのはプロセスメモリの中身なので、単一の通信内容を傍受されるよりも危険と言えるかも

「メモリガチャ」 http://d.hatena.ne.jp/nekoruri/20140408/heartbleed https://twitter.com/mad_p/status/453482047885938688

対策 • サーバ / クライアントの OpenSSL をバージョンアップ • OpenSSL を組み込んでいる製品に注意
• TLS 証明書の再発行と失効 • Heartbleed によって秘密鍵が盗まれている可能性 • 必要に応じてユーザーのセッションやパスワードのリセット、変更 • Heartbleed もしくは窃用した秘密鍵による MITM 攻撃によってこれらの秘密情報が盗まれている可能性

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 です。素晴らしい

ユーザーへの告知も視野に • http://www.ipa.go.jp/security/ciadr/vul/20140408- openssl.html • IPA は「ウェブサイト利用者へのアナウンス」を検討するよう推奨している • 脆弱性の影響があったサイトの場合、ユーザーはパスワード等の情報を変更する必要があるかもしれない
• しかしそれには対策済みであることを知っていなければならない • 未対策の場合、変更後のパスワードが盗まれてしまうかもしれないため

新たな DNS キャッシュポイズニング手法 (委任インジェクション攻撃) の発見

DNS キャッシュポイズニングルートサーバキャッシュサーバ権威 DNS サーバ Web サーバクライアント

攻撃者なんらかの方法 (後述) で DNS キャッシュサーバを攻略

攻撃者なんらかの方法 (後述) で DNS キャッシュサーバを攻略攻撃者の Web サーバ攻撃者のサーバに誘導

代表的な攻撃手法 • Kashpureff 型 • 攻撃者が管理する権威サーバの応答パケットに問い合わせとは関係のない (ゾーン外の) ドメインの情報を付加してキャッシュさせる •
偽装応答型 • 問い合わせに対する本来の応答が送り込まれるよりも先に偽装応答をキャッシュサーバに送り込む (攻撃対象ドメインの TTL に影響される) • Kaminsky 型 • 攻撃者が攻撃対象ドメインの存在しない名前をキャッシュサーバに検索させ、偽装応答型攻撃を実施 (攻撃対象ドメインの TTL の影響を受けない)

Kashpureff 型攻撃キャッシュサーバ good.example.jp 権威 DNS サーバクライアント evil.example.com 権威
DNS サーバ

DNS サーバ evil.example.com

DNS サーバ evil.example.com evil.example.com の応答と一緒に good.example.jp の additional セクション (攻撃者のサーバに向けた) を返す

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

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

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

Kashpureff 型攻撃への対策キャッシュサーバ good.example.jp 権威 DNS サーバ evil.example.com 権威 DNS
サーバ偽装 additional セクション *.example.com の応答に *.example.jp の応答が返ってくるのはおかしいのでキャッシュせずに破棄する

偽装応答型攻撃キャッシュサーバ DNS サーバクライアント

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

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

Kaminsky 型攻撃キャッシュサーバ攻撃者 DNS サーバ

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

(キャッシュされていないので、常に問い合わせがおこなわれる) evil1.example.jp evil2.example.jp evil3.example.jp evil1.example.jp evil2.example.jp evil3.example.jp

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

Kaminsky 型攻撃への対策キャッシュサーバ攻撃者 DNS サーバ evil1.example.jp evil2.example.jp evil3.example.jp evil1.example.jp
evil2.example.jp evil3.example.jp transaction ID を毎回異なるものにポート番号を毎回異なるものに (port randomization)

Kaminsky 型攻撃のその後 • Dan Kaminsky が 2008 年に発表した方式では攻撃できず (当時の
BIND の実装上の問題によって成功していた) • しかし、同年 Bernhard Müller によって示された node redelegation を用いた Kaminsky 型攻撃は成立する

委任 (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 ゾーン (ebi.example.co.jp, kani.example.co.jp, sasori.example.co.jp, …) • .jp ゾーン example.co.jp ゾーンから委任されている

• example.co.jp ゾーン (ebi.example.co.jp, kani.example.co.jp, sasori.example.co.jp, …) • .jp ゾーン .jp ゾーンから委任されている 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 ゾーンから委任されている

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 の算出方法は本スライドでは割愛

前野氏、鈴木氏による委任インジェクション攻撃手法 (1) • ゾーンとしては存在しない (=キャッシュされていない) ドメイン名に対して Müller 方式
(偽ネームサーバ応答) による攻撃をおこなうというもの • 存在しないゾーンに対するキャッシュは、偽応答以外に存在しないため容易に攻撃可能 (=キャッシュを上書きする必要がない) • 「ゾーンとしては存在しないドメイン名」とは、たとえば、 �co.jp がある

前野氏、鈴木氏による委任インジェクション攻撃手法 (2) https://moin.qmail.jp/DNS/%E6%AF%92%E7%9B%9B%E5%86%8D%E8%80%83/%E3%82%BE%E3%83%BC %E3%83%B3%E3%81%AA%E3%81%97%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E5%90%8D

対策 • 詳細は JPRS 公表の http://jprs.jp/tech/security/2014-04-30-poisoning- countermeasure-resolver-1.pdf を参照のこと • Port
Randomization は基本 • キャッシュサーバに対する攻撃の検知 • 攻撃可能な時間が増えれば増えるほど攻撃の成功確率が上がることは既に示したとおり • DNS キャッシュポイズニングはある種ブルートフォース的な攻撃手法であるので、アノーマリーベースでの振る舞い検知のアプローチで充分いける • 検知次第キャッシュをクリアする

Port Randomization Test • http://entropy.dns-oarc.net/test/ • $ dig +short porttest.dns-oarc.net
TXT

mXSS (Mutation-based Cross-Site-Scripting)

mXSS とは • innerHTML 等を経由して DOM ツリーを参照した際に、本来の DOM 構造とは異なる結果が得られることがあるのを利用して XSS
攻撃に繋げる手法 • XSS 界隈で最近注目されているとのこと • 2007 年にはせがわようすけ氏が発見した、 IE の innerHTML 実装がバックティックを引用符と解釈してしまう問題が再評価されて発覚 • だが、 mXSS は IE に限らず利用できうるテクニック

innerHTML • innerHTML で操作した DOM 構造は入力の HTML とは異なる • innerHTML
から取得した HTML は DOM 構造とは異なる • ということは、以下のような JavaScript の結果は……？ • element.innerHTML = element.innerHTML • element.innerHTML += ‘…’ • element. insertAdjacentHTML(‘…’, element.innerHTML) • document.write(element.innerHTML)

mXSS …<script>alert(0);</script>…

mXSS …<script>alert(0);</script>… innerHTML

mXSS …<script>alert(0);</script>… innerHTML innerHTML

mXSS …<script>alert(0);</script>… innerHTML innerHTML …<script>alert(0);</script>…

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 とかまだ存在してるの

デモ • 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/

影響 • JavaScript ライブラリ等も含め、 innerHTML 等を利用した DOM 再構築をおこなっている箇所で XSS
となりうる • innerHTML を避けるのはたぶん難しい • 幸いにも mXSS を成立させるためのテクニックはまだそれほど多くはない (が、潜在的なリスクはあるといえる) • 特に一部の HTML 要素のみを許可するようなフィルタリングはバイパスされる可能性が高い。オリジナルの論文でも Web メーラに多く脆弱性が見つかったと報告されている

対策 • インライン CSS の動的書き出しは絶対に避ける • TrueHTML と呼ばれるテクニックを使う (後述) •
そろそろ CSP (Content Security Policy) も視野に入れる必要があるかもしれない • CSP についてはまたどこかの機会で詳しく触れていきたいですね

TrueHTML • http://html5sec.org/trueHTML/ (汎用的に使えるように作ってあるようだが、ライセンスは？) • innerHTML の setter /
getter の実装を XMLSerializer を利用したものに置き換えるアプローチ • 対策が透過的に適用できる • XMLSerializer 自体はブラウザのコンポーネントなのでパフォーマンス上の影響は小さい (らしい) • たぶんすべてのモダンブラウザで動作する

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 ポリシーのみの模様……

『CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある』の件

http://co3k.org/blog/csrf-token-should-not-be-session-id

https://gist.github.com/mala/9086206

(そもそも) CSRF 脆弱性とは攻撃者攻撃者の用意した罠 (Web サーバ / メール) 攻撃者の知り得ない秘密情報
セッション ID ?

(そもそも) CSRF 脆弱性とは攻撃者攻撃者の用意した罠 (Web サーバ / メール) 攻撃者の知り得ない秘密情報
• パスワード • 都度生成したトークンセッション ID ?

何が問題か • 「セッション cookie は盗まれないが CSRF 対策用トークンは盗まれうる」という状況が存在する • 海老原は
HttpOnly を利用しているケースと BREACH attack を示した • これに加え、mala 氏はソーシャルエンジニアリング、プロキシサーバのキャッシュ、表示中の HTML ソースを外部サーバに送る種類のブラウザ拡張機能 (クリッピングやあとで読む系サービス) を経由して HTML が漏洩する可能性を示した

HttpOnly • このフラグを指定した cookie は DOM に含まれなくなる • XSS 攻撃を受けた場合にセッション
cookie が DOM 経由で漏洩するのを防ぐ目的で IE が導入 (後にほとんどのモダンブラウザが導入し、 RFC 6265 も追従) • しかし、 CSRF 対策用トークンとしてセッション ID を DOM 上に載っけてしまうと……

BREACH Attack • HTTP 圧縮によるコンテンツ長の変化を収集していき、 SSL による暗号化されたレスポンスに含まれるトークン等の秘密情報を推測するサイドチャンネル攻撃 • CSRF
トークンをはじめとした、レスポンスに繰り返し現れるトークン類を推測することができる • 一方で、レスポンスに現れないトークンは推測できない。つまり通常はセッション ID を盗むことはできない

どうすればよいか (1) • CSRF 対策の文脈のみでいえば、セッション ID を SHA2 ファミリ
のハッシュ関数あたりで生成したダイジェストをトークンとして使えばいい • しかし、攻撃者がセッション ID を入手している状況であってもなお CSRF 攻撃を実行する動機は存在する • 自らがセッションハイジャックして攻撃をしたくない場合 • セッションハイジャックを検知されてセッションが無効になる場合

どうすればよいか (2) • 以下のどちらか一方のアプローチでトークンを発行する • セッション ID と鍵を利用した HMAC •
鍵の管理の必要が生じるが、設定ファイルにでも書いておけばいい • CSPRNG (暗号論的擬似乱数生成器) によって生成した乱数をセッション等に格納しておいてそれを用いる

その他最近のセキュリティトピック

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)

Covert Redirect • http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html • OpenID と OAuth 2.0 のクライアント側に存在するオープンリダイレクタ脆弱性を利用
し、アクセストークンを窃用できてしまうという攻撃手法 • 本来クライアント側に渡されるはずのアクセストークンが、オープンリダイレクタを経由して攻撃者のサーバに渡ってしまう • つまり攻撃者はそのアクセストークンによって実行可能なすべての操作をクライアントの権限によって実行可能 • サーバ側はリダイレクト先 URL の完全一致を必須に • クライアント側はオープンリダイレクタ脆弱性を作らないように

CDNetworks の配信するコンテンツにマルウェアが混入 • http://www.cdnetworks.co.jp/pressrelease/2254/ • CDN サービスのオプションサービスである「コンテンツアップロードサービス」を利用してアップロードされたコンテンツにマルウェア (Infostealer.Bankeiya.B)
が混入 • 少なくとも JUGEM サービスで運営されたブログ、 H.I.S のウェブサイト、 Buffalo の公開するドライバファイル、 Aiming のオンラインゲームのパッチファイルが影響を受けた • 詳細な原因は調査中だが、アップロード用のサーバに何らかの方法で侵入され、ファイルを改竄された可能性があるとしている

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)

RFC 2616 is Dead • http://evertpot.com/http-11-updated/ • RFC 2616 (Hypertext
Transfer Protocol -- HTTP/ 1.1) を置き換える RFC 7230 - 7239 が公開された • 古い仕様を整理、改善し、簡潔なものとした。仕様上のいくつかのセキュリティ上の問題点についても解決を図った • プロトコルバージョンに変更はない

ソフトウェア、ライブラリ類セキュリティリリース情報 (2014/01 -) ※yum とかでパッチ当たってそうなものは除外（自前ビルドがあるかもしれないものは念のため含めた） ※他にウォッチした方がいいものがあれば @co3k まで

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)

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

Composer • Composer が意図しないパッケージのインストールを誘発しやすい問題が修正された • 解説エントリ書いております: http://co3k.org/blog/composer- replace-security-bug-has-been-fixed •
Composer を最新版に更新しましょう • インストールしたパッケージが期待通りのものかを都度確認しましょう • 人の目の介在しないシステム上では composer update ではなく、信頼できる lock ファイルを生成した上で composer install を実行しましょう

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’);)

CakePHP • SecurityComponent によるフォーム保護機構が mass assignment 脆弱性を受けやすくなっていた問題 • CakePHP 1.3.18
および CakePHP 2.4.8 にて修正済み

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 で修正済み

SwiftMailer • Swift_Transport_SendmailTransport における OS コマンドインジェクション脆弱性 • sendmail コマンドの
-f オプションにて渡される From ヘッダ値がエスケープされていなかった • SwiftMailer 5.2.1 にて修正

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!" という注意書きも追加されている

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/ など) に対するバリデーションを厳しくした

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/

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 にて修正

Redmine • オープンリダイレクタ脆弱性 • [CVE-2014-1985] Redmine 2.4.5, 2.5.1 にて修正

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 におけるディレクトリトラバーサル

WordPress • 複数のセキュリティ上の問題を修正した 3.8.2, 3.7.2 がリリースされている • CVE ID:
2014-0166, 2014-0165 • あと謎の SQLi • WordPress 3.9.0 が出た • WordPress は基本的に最新のメジャーバージョンしかサポートしないので早めのアップグレードを

参考文献  (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)

参考文献  (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)

参考文献  (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

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

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

More Decks by Kousuke Ebihara

Other Decks in Technology

Featured

Transcript