Apache Axis2におけるXML署名検証不備
- 1. Copyright©2013 JPCERT/CC All rights reserved. 「Javaアプリケーション脆弱性事例調査資料」について この資料は、Javaプログラマである皆様に、脆弱性を身 近な問題として感じてもらい、セキュアコーディングの 重要性を認識していただくことを目指して作成していま す。 「Javaセキュアコーディングスタンダード CERT/Oracle版」と合わせて、セキュアコーディングに 関する理解を深めるためにご利用ください。 JPCERTコーディネーションセンター セキュアコーディングプロジェクト secure-coding@jpcert.or.jp 1 Japan Computer Emergency Response Team Coordination Center 電子署名者 : Japan Computer Emergency Response Team Coordination Center DN : c=JP, st=Tokyo, l=Chiyoda-ku, email=office@jpcert.or.jp, o=Japan Computer Emergency Response Team Coordination Center, cn=Japan Computer Emergency Response Team Coordination Center 日付 : 2013.09.30 16:19:35 +09'00'
- 3. Copyright©2013 JPCERT/CC All rights reserved. Apache Axis2とは XMLをベースとしたメッセージ交換プロトコル SOAP を 実装した Webアプリケーションフレームワーク SOAP にセキュリティ機能を追加する WS-Security は、 Axis2ではRampartモジュールで実装されている 3 Java VM Servlet (tomcat)等 Axis2 Rampart SOAP WS-Security Secure SOAP XML デジタル 署名 暗号化 トークン Axis2 フレームワーク
- 4. Copyright©2013 JPCERT/CC All rights reserved. SOAP(XML)とは SOAP(Simple Object Access Protocol) • ネットワーク経由で情報を交換するためのプロトコル • XML形式によるシンプルな構造 • Header部とBody部から構成される • WS-Security を用いて安全な交換が可能 4 <soap:Envelope > < soap:Header> … </soap:Header> < soap:Body> … </soap:Body> Header 部 メッセージの処理方法等 の付加情報を定義する Body 部 メッセージ本文 SOAPメッセージ
- 5. Copyright©2013 JPCERT/CC All rights reserved. WS-Security とは WS-Security(Web Services Security) • SOAPメッセージ交換に対してセキュリティを提供するための 仕様 • OASIS *1 のWeb Service Security TC によって仕様策定された • WS-Securityのセキュリティ機能 1. セキュリティ トークン(認証および認可に利用) 2. デジタル署名 3. 暗号化 5 *1 OASIS … オープン規格標準を策定・推進する非営利団体。 https://www.oasis-open.org/
- 6. Copyright©2013 JPCERT/CC All rights reserved. デジタル署名とは ■デジタル署名 • ネットワーク上での印鑑やサインに相当するもの 以下のような効果がある —なり済ましを検出 —改ざんを検出 —否認防止 ※送信事実の否定を防止すること 6
- 7. Copyright©2013 JPCERT/CC All rights reserved. デジタル署名の仕組み 公開鍵暗号系の性質を利用 —秘密鍵とそれに対応する公開鍵が存在 —秘密鍵で暗号化したものは対応する公開鍵でしか復号できない —公開鍵で暗号化したものは対応する秘密鍵でしか復号できない —秘密鍵は本人だけが持つ、公開鍵は相手に持ってもらう 7 秘密鍵は本人しか 持たないため、送 信者の公開鍵で復 号できることが本 人が暗号化したこ との証明になる。 送信者 受信者 送信者本人が送信したものである(＝改ざんされていない)ことを検証する場合 送信者の 秘密鍵 予め取得しておいた 送信者の公開鍵で復号 送信者は自分の 秘密鍵で署名する
- 8. Copyright©2013 JPCERT/CC All rights reserved. XML署名とは: XML署名の構文 • XML署名とは、XMLに対しデジタル署名を付与すること • XMLの文書全体だけでなく、XMLの部分的な要素に対し て署名が可能 8 XML署名要素 署名情報要素 ： 参照要素（URIは署名対象の識別子） ： 署名対象のダイジェスト値要素 署名値要素 <Signature > <SignedInfo> ： <Reference URI=… > ： <DigestValue> </Reference> </SignedInfo> < SignatureValue> ： </SignatureValue> </Signature> XML署名としてSOAPに埋め込まれる構文 XMLのどの部分に 署名が付与されて いるのかを示す 署名データを付与する
- 9. Copyright©2013 JPCERT/CC All rights reserved. XML署名とは: Reference値による署名対象の指定 9 <Signature> 署名値 <SignatureValue> < Reference URI=“#123” > 署名対象 メッセージダイジェスト （ハッシュ値） < DigestValue > < soap:Header> < soap:Body id=“123”> <soap:Envelope > 署名対象(Body)の数だけ参照 要素(Reference)も存在する Body 部の id=123 を指している 署名 署名対象そのものではなく、 署名対象のメッセージダイ ジェストに対して署名し、 その署名値を SignatureValue に設定する
- 10. Copyright©2013 JPCERT/CC All rights reserved. メッセージダイジェストとは —メッセージの指紋のようなもの —固定長のバイト数で構成される —メッセージが１ビットでも異なればメッセージダイジェスト値も異 なる —メッセージダイジェスト値が同一となる異なるメッセージの作成は 困難 —同一メッセージからは常に同じ値が生成される 10 SOAPメッセージ全体の暗号化は時間的なコストが高いことから、 全体ではなくメッセージのダイジェスト値に対して処理をおこなう。 attack world Hello world 7b502c3a1f48c8609ae212cdfb639dee39673f5e d4018309b7da546c8ba030b01cefcd85a1a0dfc0 不一致 メッセージダイジェスト (ハッシュ値)
- 11. Copyright©2013 JPCERT/CC All rights reserved. 脆弱性の概要 デジタル署名されたXMLメッセージの署名検証 処理に不備 XML署名を偽装したメッセージに対し、署名が 不正であることを検出できず、正しく署名され たものとして扱ってしまう なりすまし行為などの脅威 11
- 12. Copyright©2013 JPCERT/CC All rights reserved. 改ざんに 気付かない 脆弱性が悪用された場合のリスク 偽装したメッセージによる、サービスの不正利用 送信メッセージが認証や認可に利用されている場 合は、認証回避につながる 12 サービス提供者 サービス利用者 攻撃者 送信ユーザの メッセージを 横取り 横取りした メッセージを 改ざんして送信 通常の送信
- 13. Copyright©2013 JPCERT/CC All rights reserved. SOAPメッセージの処理フロー 13 ②ポリシーファイル読み込み ③SOAPメッセージを組み立て、 ポリシーに従い署名し送信する クライアント側 サーバ側 ①ポリシーファイル読み込み ④メッセージを受信・解析し、署名 を検証する ⑤ポリシーに違反していないか検証 ⑥メッセージからデータを取得する 署名、送信 ポリシーに従い検証 受信、署名検証
- 14. Copyright©2013 JPCERT/CC All rights reserved. ①②ポリシーファイル読み込み(1/2) 14 Axis2 Rampart service.xmlWEB-INF service.jks 付加情報 Axisサービスファイル 事前にdeploy policy.xml client.jks 付加情報 ポリシーファイル クライアント/サーバに 署名される要素のパスが同じ内 容で記載されている 署名用データ client.jks : 送信者の秘密鍵 service.jks : 送信者の公開鍵 SOAP メッセージに適用するセキュリティポリシーが定義されている クライアント側とサーバ側の両方に署名される要素のパスが同じ内容 のポリシーファイルを持つ ポリシーに従い署名 ポリシーに従い検証 Secure SOAP XML
- 15. Copyright©2013 JPCERT/CC All rights reserved. ①②ポリシーファイル読み込み(2/2) 15 <wsp:Policy xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy” wsu:Id="SigOnly" > <wsp:ExactlyOne> <wsp:All> ： <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" > <sp:Body /> </sp:SignedParts> <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy" > <ramp:user>client</ramp:user> <ramp:encryptionUser>service</ramp:encryptionUser> <ramp:passwordCallbackClass>org.apache.rampart.samples.policy.sample02.PWCBHandler</ramp:passwordCallbackClass> <ramp:signatureCrypto> <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin" > <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type" >JKS</ramp:property> <ramp:property name="org.apache.ws.security.crypto.merlin.file" >client.jks</ramp:property> <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password" >apache</ramp:property> </ramp:crypto> </ramp:signatureCrypto> </ramp:RampartConfig> </wsp:All> </wsp:ExactlyOne> policy.xml SigOnly = 署名のみ <sp:Body /> = Body 要素配下への署名 署名方法や署名個所が記載されているファイル
- 16. Copyright©2013 JPCERT/CC All rights reserved. ③SOAPメッセージを組み立て署名し送信する 16 Envelope Header Body Id="123" Signature SignatureInfo Reference URI="#123" SignatureValue echo param Hello world 署名 RA4Ydrc0h/KfvnKWVIFJZsUqs6aXjx2i4OkLufbOgv1 MvFrqDnMIHsAl1KLqrb+G4QPCLWiQDPt4 ・・・ メッセージのハッシュ値が秘密鍵 で暗号化され署名に埋め込まれる ポリシーファイルに従って署名される
- 17. Copyright©2013 JPCERT/CC All rights reserved. ④メッセージを受信し署名を検証する 17 Envelope Header Body Id="123" Signature SignatureInfo Reference URI="#123" SignatureValue echo param attack world 検証 署名を公開鍵で復号化しメッセー ジのハッシュ値を取り出す メッセージを改ざんした場合、メッセージ部分は異なる ハッシュ値となるため改ざんを検知することができる。 メッセージが改ざんされている 参照個所はここ RA4Ydrc0h/KfvnKWVIFJZsUqs6aXjx2i4OkLufbOgv1 MvFrqDnMIHsAl1KLqrb+G4QPCLWiQDPt4 ・・・ 署名の検証結果を保持しておき、 PolicyBasedResultsValidatorにてポ リシーに違反してないか検証する ハッシュ値 が異なれば 改ざんされ ている
- 18. Copyright©2013 JPCERT/CC All rights reserved. ポリシーファイルのデフォルトの検証処理は、 PolicyBasedResultsValidatorクラスで行われている。 「④メッセージを受信し署名を検証する」の検証結果を元にポリシー に違反していないか検証する。 18 メッセージに対する署名検証時の処理フロー(PolicyBasedResultsValidator) 1. セキュリティトークン（ユーザ認証等）でエラーが発生している場合 は Exception生成 2. 暗号化要素でエラーが発生している場合は Exception生成 3. 署名要素でエラーが発生している場合は Exception生成 4. 要求されている要素がいずれか存在しない場合は Exception生成 5. 信頼されていない署名エラーがある場合は Exception生成 6. soapヘッダのタイムスタンプが期限切れ等の場合は Exception生成 ⑤ ポリシーに違反していないか検証する
- 19. Copyright©2013 JPCERT/CC All rights reserved. ⑥メッセージからデータを取得する Axisサーバ上で稼働するアプリケーションがデータを取得 19 署名の検証が OK となったデータ部 Envelope Header Body Id="123" Signature SignatureInfo Reference URI="#123" SignatureValue echo param Hello world Param エレメントのコン テンツ “Hello world” が取 得される。 /Envelope/Body/echo/param取得対象のデータ位置:
- 20. Copyright©2013 JPCERT/CC All rights reserved. Axis の処理の問題点 20 • 署名/署名検証機能は SOAP メッセージを扱う Axis 本体 に対する付加機能 (rampart モジュール) • 署名要素の位置とアプリケーションが処理するデータの 格納位置は独立に設定される 検証すべき署名データが本来想定している位置にあるかど うかを検証していない
- 21. Copyright©2013 JPCERT/CC All rights reserved. 操作 改ざんが 検出できない 攻撃リクエストフロー ユーザとサーバの間に攻撃者が入り、SOAPメッセージ を改ざんされた場合に、検出できない問題がある。 21 中継 中継 送信者 攻撃者 サーバ (本来の送信先) 【改ざん操作】 ・SOAP メッセージを改ざん ・レスポンスを偽装
- 22. Copyright©2013 JPCERT/CC All rights reserved. SOAPメッセージの改ざん 22 改ざん（挿入）された Body 部 正規の Body 部 Envelope Header Body Id="123" Signature SignatureInfo Reference URI="#123" SignatureValue echo param Hello world Body Id=“999" echo param attack world wrapper オリジナルのXML要素 を<wrapper>タグ配下 に移動 改ざん前の位置には、存在し ないID（”999”）を挿入して、 改ざん対象のメッセージを追 加する
- 23. Copyright©2013 JPCERT/CC All rights reserved.23 改ざん（挿入）された Body 部 正規の Body 部 Envelope Header Body Id="123" Signature SignatureInfo Reference URI="#123" SignatureValue echo param Hello world Body Id=“999" echo param attack world wrapper ③改ざんされたSOAPメッセージを送信する <wrapper>以下のXML要素は 元のままなので、メッセー ジのハッシュ値が一致し、 検証処理に成功する。 URIの値と一致する 個所を参照するた め、<wrapper>で ラッピングされた 部分を参照する。
- 24. Copyright©2013 JPCERT/CC All rights reserved.24 改ざん（挿入）された Body 部 正規の Body 部 Envelope Header Body Id="123" Signature SignatureInfo Reference URI="#123" SignatureValue echo param Hello world Body Id=“999" echo param attack world wrapper ⑥メッセージからデータを取得する 検証処理を行ったのは こちらのXML要素のみ メッセージの取得処理では 「/Envelope/Body/echo/param」 の値が使用されため、改ざんされ ているメッセージが取得されてし まう。 ■署名検証 参照要素(Reference URI)の先を検証 ■メッセージ取得 Body直下のメッセージを取得
- 25. Copyright©2013 JPCERT/CC All rights reserved. 正常なリクエストと改ざんされたリクエストの比較 25 <Signature> < Reference URI=“#123”> 追加された メッセージ <soap:Header> <soap:Body Id=“999”> <soap:Envelope > 正規のメッセージ <soap:wrapper> <soap:Body Id=“123”> <Signature> < Reference URI=“#123”> 正規のメッセージ <soap:Header> <soap:Body Id=“123”> <soap:Envelope > 正常なリクエスト 改ざんされたリクエスト 同一 正常時の署名はあ くまで「正規の メッセージ」部分 に対してのもの 追加されたメッ セージは検証さ れない 署名部分は改ざんさ れていないのでハッ シュ値は同一
- 26. Copyright©2013 JPCERT/CC All rights reserved. Axis2のXML署名検証処理の問題点 署名時のXML要素位置と検証時のXML要素位置が異なっ ていても検知しない 署名検証時にXML要素位置の検証をしていない 26 W3CのBest Practices ドキュメントに違反している!! W3C XML Signature Best Practices http://www.w3.org/TR/xmldsig-bestpractices/ Best Practice 14：検証者は、XML署名検証の過程で 名前と位置の両方をチェックする必要があります。
- 27. Copyright©2013 JPCERT/CC All rights reserved. XML署名検証処理の修正: 対策前 署名された要素の位置の比較なし 27 正常なリクエストのパス 改ざん後のリクエストのパス Body Body /Envelope/ /Envelope/wrapper/ 一致
- 28. Copyright©2013 JPCERT/CC All rights reserved. XML署名検証処理の修正: 対策後 署名された要素の名前と位置を比較 28 正常なリクエストのパス 改ざん後のリクエストのパス パスが異なっていた場合 エラー処理をする /Envelope/Body /Envelope/wrapper/Body 名前と要素位置の比較は署名検証が完了した後のタイミングで行う 署名要素位置はポリシー ファイルに記載されている 不一致
- 29. Copyright©2013 JPCERT/CC All rights reserved. XML署名検証処理の修正: 対策コード作成 ポリシーファイルの記載内容に基づく検証処理に要素の パスの検証処理を追加する ポリシーファイルのデフォルトの検証処理をおこなって いる PolicyBasedResultsValidator クラスを修正する XML形式の妥当性検証やXML署名の検証結果については すでに完了しているタイミング 検証結果を元にポリシー違反をしていないかを検証する 工程となっている 29
- 30. Copyright©2013 JPCERT/CC All rights reserved.30 メッセージに対する署名検証時の処理フロー(PolicyBasedResultsValidator) 1. セキュリティトークン（ユーザ認証等）でエラーが発生している場合 は Exception生成 2. 暗号化要素でエラーが発生している場合は Exception生成 3. 署名要素でエラーが発生している場合は Exception生成 ※ 署名要素に対するチェック方法を修正 4. 要求されている要素がいずれか存在しない場合は Exception生成 5. 信頼されていない署名エラーがある場合は Exception生成 6. soapヘッダのタイムスタンプが期限切れ等の場合は Exception生成 正常リクエストの「⑥ポリシーファイルに従いポリシーに 違反していないかを検証する」の処理を修正する。 XML署名検証処理の修正: 対策コード作成 「要素の位置チェック」を追加する必要がある
- 31. Copyright©2013 JPCERT/CC All rights reserved. XML署名検証処理の修正: 対策コード(参考) 31 protected void validateSignedPartsHeaders(ValidatorData data, List<WSEncryptionPart> signatureParts, List<WSSecurityEngineResult> results) throws RampartException { ： for (final WSSecurityEngineResult actionResult : actionResults) { List wsDataRefs = (List) actionResult.get(WSSecurityEngineResult.TAG_DATA_REF_URIS); ： for (final Object objectDataReference : wsDataRefs) { WSDataRef wsDataRef = (WSDataRef) objectDataReference; ： List<WSEncryptionPart> signedParts = rpd.getSignedParts(); boolean find = false; for (final WSEncryptionPart encParts : signedParts) { if (encParts.getXpath().equals(wsDataRef.getXpath())) { find = true; break; } } } PolicyBasedResultsValidator 署名された参照URIを取得 実際のXML署名とポリシー ファイル記載のXpath比較 ポリシーファイル記載の 署名すべき要素 署名位置が一致しなければ例外生成 ※本脆弱性は現時点で未修正(Apache Axis2/Java 1.6.2) ここでは独自に作成した修正コードを示す。
- 32. Copyright©2013 JPCERT/CC All rights reserved. 参考情報 XML Signature Wrapping Attack ここで紹介した攻撃手法は “XML Signature Wrapping Attack” と いう名称で呼ばれている。 Apache Axis2 の実装の問題は、USENIX Security 2012 で発表 された論文において指摘されている。 “On Breaking SAML: Be Whoever You Want to Be”, USENIX Security Symposium 2012 https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf 32
- 33. Copyright©2013 JPCERT/CC All rights reserved. まとめ XML署名検証処理における注意点 XML署名の検証では、署名データの検証だけではな く、XML特有の要素位置に関する検証も必要 上記への対策 署名データの検証と署名データの要素位置の検証を 行う。 33
- 34. Copyright©2013 JPCERT/CC All rights reserved. 著作権・引用や二次利用について 本資料の著作権はJPCERT/CCに帰属します。 本資料あるいはその一部を引用・転載・再配布する際は、引用元名、資料名および URL の明示を お願いします。 記載例 引用元：一般社団法人JPCERTコーディネーションセンター Java アプリケーション脆弱性事例解説資料 Apache Axis2 における XML 署名検証不備 https://www.jpcert.or.jp/securecoding/2012/No.10_Apache_Axis.pdf 本資料を引用・転載・再配布をする際は、引用先文書、時期、内容等の情報を、JPCERT コーディ ネーションセンター広報(office@jpcert.or.jp)までメールにてお知らせください。なお、この連絡 により取得した個人情報は、別途定めるJPCERT コーディネーションセンターの「プライバシーポ リシー」に則って取り扱います。 本資料の利用方法等に関するお問い合わせ JPCERTコーディネーションセンター 広報担当 E-mail：office@jpcert.or.jp 本資料の技術的な内容に関するお問い合わせ JPCERTコーディネーションセンター セキュアコーディング担当 E-mail：secure-coding@jpcert.or.jp 34