ASP.NETでフォーム認証を使用する場合のセキュリティ問題
ピーター・フォーゲルに伝える
2人のセキュリティ研究者、Thai DuongとJuliano Rizzoが、ASP.NETでフォーム認証の実装に一般的に使用されるCookieを保護するために使用されるデフォルトの暗号化メカニズムにバグを発見しました。 研究者が開発したツール（ Padding Oracle Exploit ToolまたはPOET）を使用すると、AES暗号化メカニズムを使用して暗号化されたCookieを繰り返し変更し、返されたエラーを調べて、Cookieの暗号化に使用されるマシンキーを計算できます。 研究者によると、このプロセスは100％信頼性が高く、どのサイトでも30〜50分かかります。
マシンキーが決定されると、攻撃者はダミーの認証Cookieを作成できます。 また、サイトの開発者がこのユーザーの役割に関する情報をCookieに埋め込むオプションを選択した場合、攻撃者は管理者の役割を適切に設定できます。 このセキュリティホールは、ロールメンバーシッププロバイダーの他の機能、ViewStateスプーフィングに対する保護、Cookieに保存できる暗号化されたデータ、またはクライアント側でアクセス可能な他の方法に影響を与える可能性があります。
悪いニュースは、問題が膨大であり、すぐに対処する必要があることです。 良いことは、その解決策が非常に簡単であることです。 このハックは、AESを使用した暗号化の.NET実装のバグを悪用します。 解決策は簡単です。たとえば、3DESなどの別の暗号化メカニズムを使用するように切り替える必要があります。 メンバーシップの暗号化とロールプロバイダーはASP.NETによって処理されるため、フォーム認証を使用する既存のコードを変更する必要はありません。
暗号化方式は、サイトのweb.configファイル、WebサーバーのIIS 7、または％SYSTEMROOT％\ Microsoft.NET \ Framework \ version \ CONFIG \ディレクトリのサーバー上の.NET構成ファイルで変更できます。 64ビットシステムでは、％SYSTEMROOT％\ Microsoft.NET \ Framework64 \ version \ CONFIG \ディレクトリの構成ファイルも変更する必要があります。 典型的なエントリは次のようになります。
Webファームでは、ファーム内のすべてのサーバーでこの設定を変更する必要があります。
これらのオプションは、ViewStateスプーフィングを防止するためにも使用されます（ViewStateデータはエンコードされますが、暗号化されません）。 したがって、これらの変更を行うと、3DESを使用したViewState暗号化も行われます。
AESを使用してクライアントで利用可能な情報を暗号化する開発者は、別の暗号化メカニズムを使用するようにコードを変更することを検討する必要があります。
ドンとリッツォは、9月17日金曜日にブエノスアイレスで開催されるセキュリティ会議で、この問題に関するより詳細な情報を提供する予定です。
2人のセキュリティ研究者、Thai DuongとJuliano Rizzoが、ASP.NETでフォーム認証の実装に一般的に使用されるCookieを保護するために使用されるデフォルトの暗号化メカニズムにバグを発見しました。 研究者が開発したツール（ Padding Oracle Exploit ToolまたはPOET）を使用すると、AES暗号化メカニズムを使用して暗号化されたCookieを繰り返し変更し、返されたエラーを調べて、Cookieの暗号化に使用されるマシンキーを計算できます。 研究者によると、このプロセスは100％信頼性が高く、どのサイトでも30〜50分かかります。
マシンキーが決定されると、攻撃者はダミーの認証Cookieを作成できます。 また、サイトの開発者がこのユーザーの役割に関する情報をCookieに埋め込むオプションを選択した場合、攻撃者は管理者の役割を適切に設定できます。 このセキュリティホールは、ロールメンバーシッププロバイダーの他の機能、ViewStateスプーフィングに対する保護、Cookieに保存できる暗号化されたデータ、またはクライアント側でアクセス可能な他の方法に影響を与える可能性があります。
悪いニュースは、問題が膨大であり、すぐに対処する必要があることです。 良いことは、その解決策が非常に簡単であることです。 このハックは、AESを使用した暗号化の.NET実装のバグを悪用します。 解決策は簡単です。たとえば、3DESなどの別の暗号化メカニズムを使用するように切り替える必要があります。 メンバーシップの暗号化とロールプロバイダーはASP.NETによって処理されるため、フォーム認証を使用する既存のコードを変更する必要はありません。
暗号化方式は、サイトのweb.configファイル、WebサーバーのIIS 7、または％SYSTEMROOT％\ Microsoft.NET \ Framework \ version \ CONFIG \ディレクトリのサーバー上の.NET構成ファイルで変更できます。 64ビットシステムでは、％SYSTEMROOT％\ Microsoft.NET \ Framework64 \ version \ CONFIG \ディレクトリの構成ファイルも変更する必要があります。 典型的なエントリは次のようになります。
<machineKey validationKey="AutoGenerate,IsolateApps"
validation="3DES"
decryptionKey="AutoGenerate,IsolateApps"
decryption="3DES" />
Webファームでは、ファーム内のすべてのサーバーでこの設定を変更する必要があります。
これらのオプションは、ViewStateスプーフィングを防止するためにも使用されます（ViewStateデータはエンコードされますが、暗号化されません）。 したがって、これらの変更を行うと、3DESを使用したViewState暗号化も行われます。
AESを使用してクライアントで利用可能な情報を暗号化する開発者は、別の暗号化メカニズムを使用するようにコードを変更することを検討する必要があります。
ドンとリッツォは、9月17日金曜日にブエノスアイレスで開催されるセキュリティ会議で、この問題に関するより詳細な情報を提供する予定です。
All Articles