Apache Axis2 におけるXML署名検証不備

Size: px

Start display at page:

Download "Apache Axis2 におけるXML署名検証不備"

きみかずたけすえ
5 years ago
Views:

1 Japan Computer Emergency Response Team Coordination Center 電子署名者 : Japan Computer Emergency Response Team Coordination Center DN : c=jp, st=tokyo, l=chiyoda-ku, =office@jpcert.or.jp, o=japan Computer Emergency Response Team Coordination Center, cn=japan Computer Emergency Response Team Coordination Center 日付 : :19:35 +09'00' Javaアプリケーション脆弱性事例調査資料についてこの資料は Javaプログラマである皆様に脆弱性を身近な問題として感じてもらいセキュアコーディングの重要性を認識していただくことを目指して作成しています Javaセキュアコーディングスタンダード CERT/Oracle版と合わせてセキュアコーディングに関する理解を深めるためにご利用ください JPCERTコーディネーションセンターセキュアコーディングプロジェクト secure-coding@jpcert.or.jp 1

2 Apache Axis2 における XML 署名検証不備 CVE JVNDB

3 Apache Axis2 とは XML をベースとしたメッセージ交換プロトコル SOAP を実装した Web アプリケーションフレームワーク SOAP にセキュリティ機能を追加する WS-Security は Axis2 では Rampart モジュールで実装されているトークン Axis2 フレームワーク暗号化デジタル署名 Rampart WS-Security Axis2 SOAP SOAP XML Secure Servlet (tomcat) 等 Java VM 3

4 SOAP(XML)とは SOAP(Simple Object Access Protocol) ネットワーク経由で情報を交換するためのプロトコル XML形式によるシンプルな構造 Header部とBody部から構成される WS-Security を用いて安全な交換が可能 SOAPメッセージ <soap:envelope > < soap:header> </soap:header> < soap:body> </soap:body> 4 Header 部メッセージの処理方法等の付加情報を定義する Body 部メッセージ本文

5 WS-Security とは WS-Security(Web Services Security) SOAP メッセージ交換に対してセキュリティを提供するための仕様 OASIS *1 の Web Service Security TC によって仕様策定された WS-Security のセキュリティ機能 1. セキュリティトークン ( 認証および認可に利用 ) 2. デジタル署名 3. 暗号化 *1 OASIS オープン規格標準を策定推進する非営利団体 5

6 デジタル署名とはデジタル署名ネットワーク上での印鑑やサインに相当するもの以下のような効果があるなり済ましを検出改ざんを検出否認防止送信事実の否定を防止すること 6

デジタル署名の仕組み公開鍵暗号系の性質を利用秘密鍵とそれに対応する公開鍵が存在秘密鍵で暗号化したものは対応する公開鍵でしか復号できない公開鍵で暗号化したものは対応する秘密鍵でしか復号できない秘密鍵は本人だけが持つ公開鍵は相手に持ってもらう送信者の秘密鍵

7 デジタル署名の仕組み公開鍵暗号系の性質を利用秘密鍵とそれに対応する公開鍵が存在秘密鍵で暗号化したものは対応する公開鍵でしか復号できない公開鍵で暗号化したものは対応する秘密鍵でしか復号できない秘密鍵は本人だけが持つ公開鍵は相手に持ってもらう送信者の秘密鍵予め取得しておいた送信者の公開鍵で復号送信者送信者は自分の秘密鍵で署名する受信者秘密鍵は本人しか持たないため送信者の公開鍵で復号できることが本人が暗号化したことの証明になる送信者本人が送信したものである (= 改ざんされていない ) ことを検証する場合 7

8 XML 署名とは : XML 署名の構文 XML 署名とは XML に対しデジタル署名を付与すること XML の文書全体だけでなく XML の部分的な要素に対して署名が可能 XML 署名として SOAP に埋め込まれる構文 XML のどの部分に署名が付与されているのかを示す <Signature > <SignedInfo> : <Reference URI= > : <DigestValue> </Reference> </SignedInfo> < SignatureValue> : </SignatureValue> </Signature> XML 署名要素署名情報要素 : 参照要素 (URI は署名対象の識別子 ) : 署名対象のダイジェスト値要素署名値要素署名データを付与する 8

9 XML 署名とは : Reference 値による署名対象の指定 <soap:envelope > < soap:header> <Signature> Body 部の id=123 を指している < Reference URI= #123 > < DigestValue > <SignatureValue> 署名値 < soap:body id= 123 > 署名対象署名対象 (Body) の数だけ参照要素 (Reference) も存在する署名署名対象そのものではなく署名対象のメッセージダイジェストに対して署名しその署名値を SignatureValue に設定するメッセージダイジェスト ( ハッシュ値 ) 9

メッセージダイジェストとはメッセージの指紋のようなもの固定長のバイト数で構成されるメッセージが１ビットでも異なればメッセージダイジェスト値も異なるメッセージダイジェスト値が同一となる異なるメッセージの作成は困難同一メッセージからは常に同じ値が生成される Hello world

10 メッセージダイジェストとはメッセージの指紋のようなもの固定長のバイト数で構成されるメッセージが１ビットでも異なればメッセージダイジェスト値も異なるメッセージダイジェスト値が同一となる異なるメッセージの作成は困難同一メッセージからは常に同じ値が生成される Hello world 7b502c3a1f48c8609ae212cdfb639dee39673f5e メッセージダイジェスト (ハッシュ値) attack world 不一致 d b7da546c8ba030b01cefcd85a1a0dfc0 SOAPメッセージ全体の暗号化は時間的なコストが高いことから全体ではなくメッセージのダイジェスト値に対して処理をおこなう 10

11 脆弱性の概要デジタル署名された XML メッセージの署名検証処理に不備 XML 署名を偽装したメッセージに対し署名が不正であることを検出できず正しく署名されたものとして扱ってしまうなりすまし行為などの脅威 11

12 脆弱性が悪用された場合のリスク偽装したメッセージによるサービスの不正利用送信メッセージが認証や認可に利用されている場合は認証回避につながる改ざんに気付かない通常の送信サービス利用者送信ユーザのメッセージを横取り攻撃者横取りしたメッセージを改ざんして送信サービス提供者 12

13 SOAP メッセージの処理フロークライアント側 2ポリシーファイル読み込み 3SOAPメッセージを組み立てポリシーに従い署名し送信する署名送信サーバ側 1ポリシーファイル読み込み 4メッセージを受信解析し署名を検証する受信署名検証 5ポリシーに違反していないか検証ポリシーに従い検証 6 メッセージからデータを取得する 13

12 ポリシーファイル読み込み (1/2) SOAP メッセージに適用するセキュリティポリシーが定義されている

14 12 ポリシーファイル読み込み (1/2) SOAP メッセージに適用するセキュリティポリシーが定義されているクライアント側とサーバ側の両方に署名される要素のパスが同じ内容のポリシーファイルを持つ policy.xml client.jks 付加情報ポリシーファイルクライアント / サーバに署名される要素のパスが同じ内容で記載されている署名用データ client.jks : 送信者の秘密鍵 service.jks : 送信者の公開鍵 Axis サービスファイル WEB-INF service.xml service.jks 付加情報事前に deploy SOAP XML Secure Axis2 Rampart ポリシーに従い署名ポリシーに従い検証 14

15 12 ポリシーファイル読み込み (2/2) 署名方法や署名個所が記載されているファイル policy.xml <sp:body /> = Body 要素配下への署名 <wsp:policy xmlns:wsu=" xmlns:wsp=" wsu:id="sigonly" > <wsp:exactlyone> <wsp:all> : <sp:signedparts xmlns:sp=" > <sp:body /> </sp:signedparts> <ramp:rampartconfig xmlns:ramp=" > <ramp:user>client</ramp:user> <ramp:encryptionuser>service</ramp:encryptionuser> SigOnly = 署名のみ <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> 15

16 3SOAP メッセージを組み立て署名し送信する Envelope Header Signature SignatureInfo メッセージのハッシュ値が秘密鍵で暗号化され署名に埋め込まれる Reference URI="#123" SignatureValue RA4Ydrc0h/KfvnKWVIFJZsUqs6aXjx2i4OkLufbOgv1 MvFrqDnMIHsAl1KLqrb+G4QPCLWiQDPt4 Body Id="123" 署名 echo param Hello world ポリシーファイルに従って署名される 16

17 ④メッセージを受信し署名を検証する Envelope Header 署名を公開鍵で復号化しメッセージのハッシュ値を取り出す Signature ハッシュ値が異なれば改ざんされている SignatureInfo Reference URI="#123" RA4Ydrc0h/KfvnKWVIFJZsUqs6aXjx2i4OkLufbOgv1 MvFrqDnMIHsAl1KLqrb+G4QPCLWiQDPt4 SignatureValue Body Id="123" 検証参照個所はここ echo attack world param メッセージが改ざんされているメッセージを改ざんした場合メッセージ部分は異なるハッシュ値となるため改ざんを検知することができる 17 署名の検証結果を保持しておき PolicyBasedResultsValidatorにてポリシーに違反してないか検証する

18 5 ポリシーに違反していないか検証するポリシーファイルのデフォルトの検証処理は PolicyBasedResultsValidator クラスで行われている 4 メッセージを受信し署名を検証するの検証結果を元にポリシーに違反していないか検証するメッセージに対する署名検証時の処理フロー (PolicyBasedResultsValidator) 1. セキュリティトークン ( ユーザ認証等 ) でエラーが発生している場合は Exception 生成 2. 暗号化要素でエラーが発生している場合は Exception 生成 3. 署名要素でエラーが発生している場合は Exception 生成 4. 要求されている要素がいずれか存在しない場合は Exception 生成 5. 信頼されていない署名エラーがある場合は Exception 生成 6. soapヘッダのタイムスタンプが期限切れ等の場合は Exception 生成 18

19 6 メッセージからデータを取得する Axis サーバ上で稼働するアプリケーションがデータを取得 Envelope 取得対象のデータ位置 : /Envelope/Body/echo/param Header Signature SignatureInfo Reference URI="#123" SignatureValue Body Id="123" echo Param エレメントのコンテンツ Hello world が取得される param Hello world 署名の検証が OK となったデータ部 19

20 Axis の処理の問題点署名 / 署名検証機能は SOAP メッセージを扱う Axis 本体に対する付加機能 (rampart モジュール ) 署名要素の位置とアプリケーションが処理するデータの格納位置は独立に設定される検証すべき署名データが本来想定している位置にあるかどうかを検証していない 20

21 攻撃リクエストフローユーザとサーバの間に攻撃者が入り SOAP メッセージを改ざんされた場合に検出できない問題がある操作改ざんが検出できない中継中継送信者攻撃者サーバ ( 本来の送信先 ) 改ざん操作 SOAP メッセージを改ざんレスポンスを偽装 21

22 SOAPメッセージの改ざん Envelope Header Signature SignatureInfo Reference URI="#123" SignatureValue 改ざん挿入された Body 部 Body Id= 999" 改ざん前の位置には存在しないID 999 を挿入して改ざん対象のメッセージを追加する echo param attack world wrapper 正規の Body 部 Body Id="123" echo param 22 Hello world オリジナルのXML要素を<wrapper>タグ配下に移動

23 ③改ざんされたSOAPメッセージを送信する Envelope URIの値と一致する個所を参照するため <wrapper>でラッピングされた部分を参照する Header Signature SignatureInfo Reference URI="#123" SignatureValue 改ざん挿入された Body 部 Body Id= 999" echo param attack world wrapper 正規の Body 部 Body Id="123" echo param 23 Hello world <wrapper>以下のxml要素は元のままなのでメッセージのハッシュ値が一致し検証処理に成功する

24 ⑥メッセージからデータを取得する Envelope 署名検証参照要素(Reference URI)の先を検証メッセージ取得 Body直下のメッセージを取得 Header Signature SignatureInfo Reference URI="#123" SignatureValue メッセージの取得処理では /Envelope/Body/echo/param の値が使用されため改ざんされているメッセージが取得されてしまう改ざん挿入された Body 部 Body Id= 999" echo param attack world wrapper 正規の Body 部 Body Id="123" echo param 24 Hello world 検証処理を行ったのはこちらのXML要素のみ

25 正常なリクエストと改ざんされたリクエストの比較正常なリクエスト <soap:envelope > <soap:header> <Signature> < Reference URI= #123 > 正常時の署名はあくまで正規のメッセージ部分に対してのもの改ざんされたリクエスト <soap:envelope > <soap:header> <Signature> < Reference URI= #123 > <soap:body Id= 123 > 正規のメッセージ追加されたメッセージは検証されない同一署名部分は改ざんされていないのでハッシュ値は同一 <soap:body Id= 999 > 追加されたメッセージ <soap:wrapper> <soap:body Id= 123 > 正規のメッセージ 25

26 Axis2 の XML 署名検証処理の問題点署名時の XML 要素位置と検証時の XML 要素位置が異なっていても検知しない署名検証時に XML 要素位置の検証をしていない W3C の Best Practices ドキュメントに違反している!! W3C XML Signature Best Practices Best Practice 14: 検証者は XML 署名検証の過程で名前と位置の両方をチェックする必要があります 26

27 XML 署名検証処理の修正 : 対策前署名された要素の位置の比較なし正常なリクエストのパス /Envelope/ Body 一致改ざん後のリクエストのパス /Envelope/wrapper/ Body 27

28 XML 署名検証処理の修正 : 対策後署名された要素の名前と位置を比較正常なリクエストのパス署名要素位置はポリシーファイルに記載されている /Envelope/Body 改ざん後のリクエストのパス不一致パスが異なっていた場合エラー処理をする /Envelope/wrapper/Body 名前と要素位置の比較は署名検証が完了した後のタイミングで行う 28

29 XML 署名検証処理の修正 : 対策コード作成ポリシーファイルの記載内容に基づく検証処理に要素のパスの検証処理を追加するポリシーファイルのデフォルトの検証処理をおこなっている PolicyBasedResultsValidator クラスを修正する XML 形式の妥当性検証や XML 署名の検証結果についてはすでに完了しているタイミング検証結果を元にポリシー違反をしていないかを検証する工程となっている 29

30 XML 署名検証処理の修正 : 対策コード作成正常リクエストの 6ポリシーファイルに従いポリシーに違反していないかを検証するの処理を修正する要素の位置チェックを追加する必要があるメッセージに対する署名検証時の処理フロー (PolicyBasedResultsValidator) 1. セキュリティトークン ( ユーザ認証等 ) でエラーが発生している場合は Exception 生成 2. 暗号化要素でエラーが発生している場合は Exception 生成 3. 署名要素でエラーが発生している場合は Exception 生成署名要素に対するチェック方法を修正 4. 要求されている要素がいずれか存在しない場合は Exception 生成 5. 信頼されていない署名エラーがある場合は Exception 生成 6. soapヘッダのタイムスタンプが期限切れ等の場合は Exception 生成 30

31 XML 署名検証処理の修正 : 対策コード ( 参考 ) PolicyBasedResultsValidator protected void validatesignedpartsheaders(validatordata data, List<WSEncryptionPart> signatureparts, List<WSSecurityEngineResult> results) throws RampartException { : 署名された参照 URIを取得 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; } } 署名位置が一致しなければ例外生成本脆弱性は現時点で未修正 (Apache Axis2/Java 1.6.2) ここでは独自に作成した修正コードを示すポリシーファイル記載の署名すべき要素実際の XML 署名とポリシーファイル記載の Xpath 比較 31

参考情報 XML Signature Wrapping Attack ここで紹介した攻撃手法は XML Signature Wrapping Attack という名称で呼ばれている Apache Axis2 の実装の問題は USENIX Security 2012 で発表された論文において指摘されている On

32 参考情報 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

33 まとめ XML 署名検証処理における注意点 XML 署名の検証では署名データの検証だけではなく XML 特有の要素位置に関する検証も必要上記への対策署名データの検証と署名データの要素位置の検証を行う 33

34 著作権引用や二次利用について本資料の著作権は JPCERT/CC に帰属します本資料あるいはその一部を引用転載再配布する際は引用元名資料名および URL の明示をお願いします記載例引用元 : 一般社団法人 JPCERT コーディネーションセンター Java アプリケーション脆弱性事例解説資料 Apache Axis2 における XML 署名検証不備本資料を引用転載再配布をする際は引用先文書時期内容等の情報を JPCERT コーディネーションセンター広報 (office@jpcert.or.jp) までメールにてお知らせくださいなおこの連絡により取得した個人情報は別途定める JPCERT コーディネーションセンターのプライバシーポリシーに則って取り扱います本資料の利用方法等に関するお問い合わせ JPCERT コーディネーションセンター広報担当 office@jpcert.or.jp 本資料の技術的な内容に関するお問い合わせ JPCERT コーディネーションセンターセキュアコーディング担当 secure-coding@jpcert.or.jp 34

Apache ActiveMQ における認証処理不備の脆弱性

Apache ActiveMQ における認証処理不備の脆弱性 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