OpenID 2.0の一部実装に脆弱性、その詳細と対策とは：デジタル・アイデンティティ技術最新動向 臨時便

8月15日に公表されたアカウントハイジャックの脆弱性

　OpenID Foundation Japan、Evangelistの@novです。

　2013年8月15日に米OpenID Foundationからリリースがあったように、OpenID 2.0の一部OpenID Provider（OP）実装に、Relying Party（RP）上でのアカウントハイジャックにつながる可能性のある重大な脆弱性が見つかりました。

　これに伴いOpenID Foundation Japanでは、会員に向け、脆弱性の詳細情報および攻撃例を公表しています。以下はその抜粋です。

【脆弱性の詳細】

　この脆弱性は、RPからdirect requestで署名検証（11.4.2.1）を依頼された際、本来ならば「For verifying signatures an OP MUST only use private associations and MUST NOT use associations that have shared keys.」とすべきところを、保存してあるassociationのsharedとprivateの区別をせずに、shared associationをprivate associationとして署名検証を行ってしまい、署名検証成功を返してしまうところに起因します。

【攻撃例】

　アタック手順も非常に簡単です。

1. 普通にOPとassociationを作る。
2. 次に、アタックするRPに対して、そのassociationをopenid.associationとして付けてレスポンスを送り付ける。
3. RPは、見たことのないassociationなので「private association」だと解釈し、「verification request」をOPに出す。
4. OPはそのassociationをlookupしてチェックする。このとき、本来ならばprivate associationだけをチェックすべきところ、同じテーブルにpublic associationも入っているので、それをチェックしてしまう。するとチェックが成功してしまう。
5. OPはPositive responseを返すため、RPは攻撃者をログインさせてしまう。

図1　脆弱性を悪用した攻撃のプロセス

【脆弱性チェックの方法】

　この脆弱性の有無は、以下のURLのテストで検出できます。

　ここまでの情報は、ある程度OpenID 2.0の仕様に関する知識があることを前提にしたものです。本稿では、OpenID 2.0の仕様をおさらいしながら、この脆弱性の原因と対策について、もう少し掘り下げて検討していきたいと思います。

おさらい：OpenID 2.0の認証フロー

　最初に、OpenID 2.0の認証フローの概要から振り返りましょう。

　OpenID 2.0の認証フローは以下のようになっています。基本的には、OPとRPの間でAssociationというステップを介して、2者間で一定時間内のみ有効な共有秘密鍵を発行します。この共有秘密鍵は、後の認証レスポンスへの署名およびその検証に用いられます。

図2　OpenID 2.0の認証フロー

　しかしながら、RPが秘密共有鍵を保持できないケースなどを考慮して、OPがRPへの共有秘密鍵の発行を行わず、その代わりにレスポンス検証用のAPI Endpointを提供することもできます。その場合の認証フローは、以下のようになります。

図3　OpenID 2.0の認証フロー（Associationなし）

　OPからRPにリダイレクト経由で送られるメッセージには、共有秘密鍵、もしくはOPのみが知る秘密鍵によって署名がなされています。このメッセージには、署名に用いられた秘密鍵の識別子としてopenid.assoc_handleというパラメータが含まれており、RPはその値によって、メッセージが共有秘密鍵を用いて署名されたのか、それとも共有されていない秘密鍵によって署名されたのかを知ることができます。前者の場合、RPは自身の持つ共有秘密鍵を用いてメッセージの検証を行います。後者の場合は、RPはOPの署名検証用APIにアクセスし、署名の検証を行います。

　ここでポイントとなるのは、

• OPは、どの秘密鍵がどのRPと共有されているか or 一切共有されていないかを把握している
• RPは未知の秘密鍵が他のRPとOPの間で共有されているかどうか、知るすべがない

という点です。

　つまり、前節の攻撃例のように、攻撃者（アタッカー）が自らRPを作ってOPと自身のRPとの間で確立した共有秘密鍵は、他のRPからは「共有されていない秘密鍵」に見えるのです。

　よって、アタッカーが持つ秘密鍵で署名されたメッセージを受け取ったRPは、OPの署名検証用APIにアクセスして署名検証を行うことになります。

認証レスポンス改ざんを見破るには

　最初に紹介した攻撃例では、アタッカーは正規のOPから発行された有効な共有秘密鍵を持っています。よって、その秘密鍵を用いれば、任意のメッセージに対してその秘密鍵を用いた署名を付与できます。当然、署名付きの第三者のOpenID Claimed Identifier（RPがend-userの識別に用いる識別子）を含んだ認証メッセージを生成することもできます。

　そのメッセージを受け取ったRPには、受け取ったメッセージがアタッカーから送られたものであることを判断するすべはありません。受け取ったメッセージに既知の共有秘密鍵が含まれていないため、そのメッセージは、「OPが共有していない秘密鍵を用いて署名したものだ」と判断し、メッセージ検証のためにOPの署名検証用APIにアクセスします。

　ここで本来であれば、OPは検証要求に含まれるopenid.assoc_handleがアタッカーのRPに共有されているものであることを察知し、検証要求を拒否する必要があります。この攻撃に対しては、唯一OPのみがその攻撃を検知できるのです。

　しかし、今回の報告では、この時点でOPが共有済みの秘密鍵によって署名されたメッセージに対しても、署名検証用APIで「署名がvalidである」と応答してしまっていました。これでは、RPはアタッカーが送信してきたメッセージを受け入れるしかありません。

　このようにして、アタッカーは任意の被害者のOpenID Claimed Identifierを任意のRPに送り付け、その被害者のアカウントにログインできるようになってしまっていました。

OP、RP、エンドユーザーそれぞれが取るべき対策とは

　以上を踏まえた上で、関与するプレイヤーそれぞれが取るべき対策について説明しましょう。

OPが取るべき対策

　OPは、署名検証APIで共有済みの秘密鍵で署名されたメッセージを拒否するようにしましょう。これは発行済みのAssociationが、それぞれRPと共有されているものなのかどうかを管理することで、実現可能です。

　また、OpenID 2.0の仕様に忠実に従っていれば、そのようなメッセージは拒否するようになっているはずなので、その場合は特に対応は必要ありません。自社のOpenID Providerの仕様詳細が不明な場合は、上記のチェックツールを用いてチェックしてみてください。

RPが取るべき対策

　本来、OPが仕様通りに動作していれば何も問題はないので、すべてのOPが迅速な対応を行う限り、RPが取るべき対策は特にありません。しかしながら、一部のOPが脆弱性を残したまま運営を続けた場合、その被害を受けるのはRPおよびそのユーザーです。

　そこで、RPは自サービスで利用されているOPをリストアップし、それぞれについて脆弱性チェックを行うことが望ましいでしょう。もし脆弱性を持ったOPが見つかった場合は、該当OPおよびOpenID Foundation Japanへその旨を連絡するとともに、一時的にそのOPの署名検証用APIへのアクセスを遮断するといった対策が考えられます。

エンドユーザーが取るべき対策

　エンドユーザーは、自分が普段使っているOPに対して上記のチェックツールを用いて脆弱性チェックを行い、脆弱性が見つかった場合はRP、OPおよびOpenID Foundation Japanにその旨を連絡しましょう。

脆弱性の早期チェックと情報共有を

　今回の脆弱性は、OpenID 2.0の仕様に準拠しない一部のOPが原因となっています。本来であれば、これらのOPがすべて脆弱性をふさいでしまえば、何も問題はありません。しかしながら複数のOPが分散して存在する現状では、すべてのOPが迅速に脆弱性修正を行えるとは限りません。

　米OpenID FoundationおよびOpenID Foundation Japanでもできる限り多くのOPをチェックし、脆弱性公表前に脆弱性の早期発見および該当OPへの修正依頼に務めてきたため、主要なOPではすでにこの脆弱性は存在しないはずですが、もしまだ脆弱性を持っているOPを発見された方は、OpenID Foundation Japanへご一報ください。