この新しいASP.NETのセキュリティの脆弱性はどのくらい深刻ですか、どうすれば回避できますか？

ASP.NETで新しく発見されたセキュリティの脆弱性についてネットで読んだところです。詳細はこちら。

問題は、ASP.NETがAES暗号化アルゴリズムを実装して、ユーザーセッション中に情報を保存するためにこれらのアプリケーションが生成するCookieの整合性を保護する方法にあります。

これは少し曖昧ですが、ここにはもっと恐ろしい部分があります：

攻撃の最初の段階では数千の要求がかかりますが、成功して攻撃者が秘密鍵を取得すると、それは完全に隠蔽されます。必要な暗号化の知識は非常に基本的です。

全体として、私はこれが本当にそれほど深刻であるかどうかを知るのに十分なセキュリティ/暗号の主題に精通していません。

したがって、すべてのASP.NET開発者が、ASP.NET Webサイトを数秒で所有できるこの手法を恐れる必要があります。でしょうか。

この問題は平均的なASP.NET開発者にどのように影響しますか？影響はありますか？実際には、この脆弱性の影響は何ですか？そして最後に、この脆弱性を防ぐいくつかの回避策はありますか？

ご回答ありがとうございます！

編集：私が得た応答を要約しましょう

したがって、これは基本的に「パディングオラクル」タイプの攻撃です。@Sriは、このタイプの攻撃が何を意味するのかについての素晴らしい説明を提供しました。問題についての衝撃的なビデオはここにあります！

この脆弱性の深刻度について：はい、確かに深刻です。これにより、攻撃者はアプリケーションのマシンキーを知ることができます。したがって、彼はいくつかの非常に望ましくないことを行うことができます。

• アプリのマシンキーを所持している場合、攻撃者は認証Cookieを復号化できます。
• それよりもさらに悪いことに、彼は任意のユーザーの名前で認証Cookieを生成できます。したがって、彼はサイト上の誰としても登場することができます。アプリケーションは、あなた自身またはあなたの名前で認証Cookieを生成したハッカーを区別できません。
• また、これにより、セッションCookieを復号化（および生成）することもできますが、これは前のものほど危険ではありません。
• それほど深刻ではありません：彼はページの暗号化されたViewStateを復号化できます。（ViewStateを使用して信頼できるデータを保存する場合は、とにかくこれを行うべきではありません！）
• かなり予想外：マシンキーの知識を使用すると、攻撃者がダウンロードできるものも正常にダウンロードできないことを、Webアプリケーションから任意のファイルを！（Web.Configなどを含む）

これは、問題を解決せずに Webアプリケーションの一般的なセキュリティの向上に役立つ、私が得た一連の優れた実践例です。

• 保護された構成で機密データを暗号化できます
• HTTPのみのCookieを使用する
• DoS攻撃を防ぐ

さて、この問題に焦点を当てましょう。

• スコット・ガスリーは彼のブログにそれについてのエントリーを公開しました
• 脆弱性に関するScottGuのFAQブログ投稿
• 脆弱性に関するScottGuの更新
• マイクロソフトはそれについてのセキュリティ勧告を持っています
• 脆弱性を理解する
• 脆弱性に関する追加情報

ソリューション

• customErrorsを有効にして、すべてのエラーがリダイレクトされる単一のエラーページを作成します。はい、404ですら。（ScottGuは、この攻撃には404と500を区別することが不可欠であると述べています。）また、ランダムな遅延を発生させるコードをに入れApplication_Errorたり、Error.aspx入れたりします。（乱数を生成し、Thread.Sleepを使用してその間スリープします。）これにより、攻撃者はサーバーで何が起こったかを正確に判断できなくなります。
• 3DESに戻すことを推奨する人もいます。理論的には、AESを使用しない場合、AES実装のセキュリティの弱点に遭遇することはありません。結局のところ、これはまったくお勧めできません。

他のいくつかの考え

• 思われていない 、誰もがこの問題を回避するには十分に良いと考えています。

私の質問に答えてくれたみんなに感謝します。この問題だけでなく、Webセキュリティ全般について多くのことを学びました。@Mikaelの回答を承認済みとしてマークしましたが、他の回答も非常に役に立ちます。

身を守るにはどうすればいいですか？

[更新2010-09-29]

マイクロソフトセキュリティ情報

修正に関するKB記事

ScottGuにはダウンロード用のリンクがあります

[更新2010-09-25]

修正を待っている間に、昨日ScottGu が更新を投稿しましたはカスタムURLScanルールでサイトを保護するために追加の手順を追加する方法の発表しました。

さらに、エラーページにランダムな時間のスリープを追加して、攻撃者が応答のタイミングをとらないようにしますが追加の攻撃情報ます。

web.config

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

これにより、エラーが200ステータスコードで返されるカスタムページにリダイレクトされます。このようにして、攻撃者はエラーコードやエラー情報を調べて、さらなる攻撃に必要な情報を得ることができません。

設定も安全です customErrors mode="RemoteOnly"「実際の」クライアントをリダイレクト、です。localhostからの参照のみが内部.Netエラーを表示します。

重要な部分は、すべてのエラーが同じエラーページを返すように構成されていることを確認することです。これにはdefaultRedirect、<customErrors>セクションの属性を明示的に設定し、ステータスごとのコードが設定されていないことを確認する必要があります。

何が問題になっていますか？

攻撃者が上記のエクスプロイトを使用した場合、攻撃者はWebアプリケーション内から内部ファイルをダウンロードできます。通常、web.configがターゲットであり、データベース接続文字列のログイン情報などの機密情報が含まれている可能性があります。また、自動化されたsql-expressデータベースへのリンクであり、他人に知られたくない場合もあります。ただし、ベストプラクティスに従っている場合は、保護された構成を使用します。をして、web.config内のすべての機密データを暗号化します。

参考文献へのリンク

脆弱性に関するMicrosoftの公式コメントをhttp://www.microsoft.com/technet/security/advisory/2416728.mspxで読んでください。具体的には、この問題の実装の詳細に関する「回避策」の部分。

また、ScottGuのブログに関する情報（Webサーバー上の脆弱なASP.Netアプリを見つけるためのスクリプトを含む）。

「Oracle攻撃のパディングについて」の説明については、@ sriの回答をご覧ください。

記事へのコメント：

RizzoとDuongがASP.NETアプリに対して実装した攻撃では、Webサイトの暗号化実装に、暗号文を送信すると、テキストを復号化するだけでなく、暗号文のパディングかどうかに関するメッセージを送信者に送信するオラクルが必要です。有効です。

パディングが無効である場合、送信者が受け取るエラーメッセージは、サイトの復号化プロセスが機能する方法に関する情報を彼に提供します。

攻撃が機能するには、次の条件が満たされている必要があります。

• アプリケーションは、パディングが無効であることを示すエラーメッセージを表示する必要があります。
• 誰かが暗号化されたCookieまたはビューステートを改ざんする必要があります

したがって、「何か問題が発生しました。もう一度やり直してください」など、人間が読める形式のエラーメッセージをアプリに返す場合は、かなり安全です。記事のコメントを少し読んでも、貴重な情報が得られます。

• 暗号化されたCookieにセッションIDを保存する
• 実際のデータをセッション状態で保存します（データベースに永続化）
• エラーを返す前に、ユーザー情報が間違っている場合にランダムな待機を追加して、時間を計ることができないようにします

このようにして、ハイジャックされたCookieは、存在しないか無効になった可能性が最も高いセッションを取得するためにのみ使用できます。

Ekopartyカンファレンスで実際に何が発表されるかを見るのは興味深いでしょうが、今のところ、この脆弱性についてあまり心配していません。

オラクル攻撃のパディングについて

アプリケーションが暗号化された文字列をパラメータとして受け入れると仮定しましょう-パラメータがcookieであるか、urlパラメータであるか、その他は重要ではありません。アプリケーションがそれをデコードしようとすると、3つの可能な結果があります-

1. 結果1：暗号化された文字列は適切に復号化され、アプリケーションはそれを理解できました。つまり、暗号化された文字列が10桁のアカウント番号だった場合、復号化後に、アプリケーションは「abcd1213ef」ではなく「1234567890」のようなものを見つけました。

2. 結果2：パディングは正しかったが、解読後、取得した文字列は意味不明で、アプリが理解できなかった。たとえば、文字列は「abcd1213ef」に復号化されましたが、アプリは数値のみを予期していました。ほとんどのアプリには、「無効なアカウント番号」のようなメッセージが表示されます。

3. 結果3：パディングが正しくなかったため、アプリケーションがなんらかのエラーメッセージをスローしました。ほとんどのアプリでは、「エラーが発生しました」などの一般的なメッセージが表示されます。

成功するためのパディングオラクル攻撃のためには、攻撃者がリクエストの数千を作ることができなければならない、とエラーなしで上記の3つのバケットのいずれかに応答を分類することができなければなりません。

これら2つの条件が満たされている場合、攻撃者は最終的にメッセージを復号化し、その後、彼が望むものでそれを再暗号化することができます。それは時間の問題です。

それを防ぐために何ができますか？

1. 最も単純なこと-機密情報は、暗号化されているか暗号化されていないかを問わず、クライアントに送信しないでください。サーバーに保管してください。

2. 上記のリストの結果2と結果3が攻撃者にまったく同じに見えることを確認してください。どちらか一方を把握する方法はないはずです。ただし、これはそれほど簡単なことではありません。攻撃者は、ある種のタイミング攻撃を使用して判別することができます。

3. 防御の最後の行として、Webアプリケーションファイアウォールを用意します。パディングオラクル攻撃は、ほとんど同じように見える（一度に1ビットを変更する）いくつかの要求を行う必要があるため、WAFがそのような要求をキャッチしてブロックできるようにする必要があります。

PSオラクル攻撃のパディングについての良い説明は、このブログ投稿にあります。免責事項：それは私のブログではありません。

読んでから今まで...

この攻撃により、誰かがスニッフィングしたcookieを解読できるようになり、銀行の残高などの貴重なデータが含まれる可能性があります

どのアカウントでも、すでにログインしているユーザーの暗号化されたCookieが必要です。また、Cookie内のデータを見つける必要もあります。開発者がCookieに重要なデータを保存しないことを願っています:)。そして、asp.netにログインCookieにデータを保存させない方法があります。

ブラウザーのデータを手に入れられない場合、オンラインのユーザーのCookieを取得するにはどうすればよいですか？またはIPパケットをスニッフィングしますか？

これを防ぐ1つの方法は、SSL暗号化なしでCookieを転送できないようにすることです。

<httpCookies httpOnlyCookies="true" requireSSL="true" />

また、もう1つの対策は、ロールをCookieに保存しないようにすることです。

<roleManager enabled="true" cacheRolesInCookie="false">

通常のページに対して安全ではないCookieについて、これはあなたがユーザーに残したこととできないこと、ユーザーを信頼する方法、実行できる追加のチェック（たとえば、IPに変更があった場合） 、セキュリティページから再ログインするまで、彼を信頼しないでください。

参照：
ハッカーがユーザーからCookieを盗み、その名前でWebサイトにログインすることはできますか？

攻撃がどこから来て、情報を返さないかを確認する方法。パディングが無効になるのを防ぎ、同時に攻撃者を追跡する簡単な方法をここに書きました：CryptographicException：パディングが無効であり、削除できないため、ビューステートMACの検証に失敗しました

攻撃者を追跡する方法は、パディングが無効であることを確認することです。簡単な手順でそれらを追跡し、ブロックすることができます-キーを見つけるためにページで数千回の呼び出しが必要です！

アップデート1。

KEYを見つけてデータを復号化することを想定したツールをダウンロードし、上記のコードのトラップとして、viewstateをチェックしています。私のテストから、このツールには修正する必要があります。たとえば、圧縮されたビューステートをそのままスキャンできず、テストでクラッシュします。

誰かがこのツールまたはこの方法を使用しようとすると、上記のコードがそれらを追跡でき、このような"Prevent Denial Of Service（DOS）"のような単純なコード、またはこのコードがDenialを防ぐためのこのようなコードでページからそれらをブロックできます。サービスの。

アップデート2

その私がいることを今まで読んだからと思われるだけでは、それはエラーに関する情報の裏を与えないようにする必要があります本当にだと思う、とだけカスタムエラーページを配置した場合、あなたはちょうど作成できるようにしてこのページへのランダム遅延。

この問題に関する非常に興味深いビデオ。

したがって、上記のすべてはより多くの保護のためのより多くの対策ですが、この特定の問題に100％必要ではありません。たとえば、ssl cookieを使用すると、snifの問題が解決され、ロールをcookieにキャッシュしないため、大きなcookieを送信して戻さないようにし、すべての準備ができているコードをクラックするのを避けて、adminロールを彼のクッキー。

ビューステートは、攻撃を見つけるためのもう1つの手段を追跡します。

ここでは MSの応答です。結局のところ、「カスタムエラーページを使用する」ことになるので、手掛かりを与えることはありません。

EDIT
ここでは scottguからいくつかのより詳細な情報です。

http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspxでの議論から得たScottGuの応答を追加する

customErrorsの代わりにカスタムIHttpModuleが影響を受けますか？

Q：web.configで要素が宣言されていません。代わりに、セクション内にIHttpModuleがあります。このモジュールはエラーをログに記録し、検索ページ（404の場合）またはエラーページ（500の場合）にリダイレクトします。脆弱ですか？

A：常に検索ページにリダイレクトするようにモジュールを一時的に更新することをお勧めします。この攻撃が機能する方法の1つは、404エラーと500エラーの違いを探すことです。常に同じHTTPコードを返し、それらを同じ場所に送信することは、それをブロックする1つの方法です。

これを修正するパッチが出た場合、これを行う必要はありません（以前の動作に戻すことができます）。ただし、現時点では、クライアントに対して404と500を区別しないことをお勧めします。

404エラーと500エラーで異なるエラーを引き続き使用できますか？

Q：上記の原則に違反することなく、エラー時のデフォルトのリダイレクトに加えてカスタム404ページを定義することができると思いますか？

A：いいえ。実際の修正のためのパッチをリリースするまで、すべてのエラーを均質化する上記の回避策をお勧めします。この攻撃が機能する方法の1つは、404エラーと500エラーの違いを探すことです。常に同じHTTPコードを返し、それらを同じ場所に送信することは、それをブロックする1つの方法です。

これを修正するパッチが出た場合、これを行う必要はありません（以前の動作に戻すことができます）。しかし、現時点では、クライアントに対して404と500を区別すべきではありません。

これはどのようにweb.configの公開を許可しますか？

Q：これはどのようにweb.configの公開を可能にしますか？これはViewStateの復号化のみを有効にするようですが、情報の開示を可能にする別の関連する脆弱性はありますか？何が起こっているのかをよりよく説明するために攻撃を詳しく説明したホワイトペーパーはありますか？

A：公開された攻撃は、ファイル（通常はJavaScriptとCSS）のダウンロードを許可し、リクエストの一部として送信されるキーで保護されるASP.NETの機能に依存しています。残念ながら、キーを偽造できる場合は、この機能を使用してアプリケーションのweb.configファイルをダウンロードできます（ただし、アプリケーションの外部のファイルはダウンロードできません）。私たちは明らかにこれに対するパッチをリリースします-それまでは、上記の回避策は攻撃ベクトルを閉じます。

編集：http: //weblogs.asp.net/scottgu/archive/2010/09/20/frequencyly-asked-questions-about-the-asp-net-security-vulnerability.aspxの2番目のブログ投稿で利用可能な追加のFAQ

IMO、これに対する全面的な防止策はありません。ケースバイケースで処理する必要があります。

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

いくつかの重要なリンク：

• MSのセキュリティ勧告2416728（これは公式情報です）
• MSのセキュリティ調査および防衛チームからの追加情報
  • 「ASP.NETの脆弱性について」（2010-09-17）
  • 「ASP.NETの脆弱性に関する追加情報」（2010-09-20）
• Scott Gu： "重要：ASP.NETのセキュリティの脆弱性"（2010-09-18）

[これの深刻さの側面に答えるため（公開されているものと回避策は他の答えでカバーされています）]

攻撃されるキーは、ビューステートCookieとセッションCookieの両方を保護するために使用されます。通常、このキーは、Webアプリの新しいインスタンスごとにASP.NETによって内部的に生成されます。これは、損傷の範囲をワーカープロセスの存続期間に制限します。もちろん、ビジーなアプリケーションの場合、これは数日になる可能性があります（つまり、制限はあまりありません）。この間、攻撃者は値をViewStateに変更（または挿入）して、セッションを変更できます。

さらに重要なことは、セッションでワーカープロセスの有効期間を広げたり、Webファームを許可したりする場合（つまり、ファーム内のすべてのインスタンスがユーザーセッションを処理できるようにする場合）、キーをハードコーディングする必要があります。これは次のように行われweb.configます。

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

もちろん、これらは新しく作成されたキーです。次のPowerShellを使用して、Windows暗号化乱数ジェネレーターにアクセスします。

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

（検証には配列の長さ20を使用し、復号化キーには16を使用します。）

特定のエラーを漏らさないようにパブリックエラーページを変更するだけでなく、上記のキーを変更する（または、ワーカープロセスがしばらく実行されている場合はサイクルする）のがよいでしょう。

[編集2010-09-21：トップへのリンクを追加]

この問題についてさらに調査した後、私のブログに私の完全な見解を投稿しました。彼らが認証Cookieを偽造している理由を明らかにすることが重要だと思います。

真実を理解したいだけです。

1. 攻撃では、マシンキーを直接取得することはできません。とはいえ、メッセージを復号化し、新しいメッセージを再暗号化/変更することを可能にするので、それはほとんど同じでした。
2. 実際のキーを取得する方法は、1のようにre / encryptを変更する機能を使用して、web.configを取得することです。残念ながら、一部のユーザーがこれらのキーをサイトレベルでweb.configに配置する理由があり（別のディスカッション）、サンプルビデオでは、DotnetNukeのデフォルトであることからメリットを得ています。
3. すべてのweb.configを取得するには、webresources.axdまたはscriptresources.axd、あるいはその両方を使用していることを指します。これらは埋め込みリソースでのみ機能すると思いましたが、そうではないようです。
4. アプリがasp.net MVCの場合、webresources.axdやscriptresources.axdは実際には必要ないため、これらをオフにできます。また、viewstateも使用しません。そうは言っても、他のasp.net機能のいずれかが適切な回避策で異なる情報を提供するかどうかは不明です。つまり、パディングがエラーで無効な結果をもたらすかどうかはわかりませんが、有効なパディングは無視された認証チケットになります（わからない）その場合かどうか）...同じ分析をセッションCookieに適用する必要があります。
5. asp.netメンバーシッププロバイダーはCookieにロールを「キャッシュ」し、それをオフにします。

約1、暗号化されたメッセージは100％任意ではありません。制御できない値を復号化するブロックがメッセージ内に1つあるため、メッセージ内のどこかに小さなゴミを許容する必要はありません。

最後に、この問題は、msがこの場合の独自のガイダンスに従わない結果であると言いたい。機能は、クライアントに送信された何かが改ざんされないことに依存している。

詳細：

有効なパディングが無視された認証チケットをもたらす一方で、パディングがエラーで無効な結果をもたらすかどうかはわかりません（そうであるかどうかはわかりません）...同じ分析がセッションCookieに適用されるはずです。

認証Cookieは署名されています。紙の情報から、実際のキーに到達しない場合、署名されたCookieを生成することはできません（認証Cookieを偽造する前にビデオで行ったように）。

Aristosが述べたように、CookieのセッションIDはユーザーセッションにとってランダムであるため、そのセッションがアクティブな間は、ターゲットセキュリティレベルのユーザーから盗聴してクラックする必要があります。それでも、ユーザー操作の割り当て/承認を認証に依存している場合でも、影響は最小限です/そのアプリでのセッションの使用方法に大きく依存します。

このバグのパッチがWindows Updateでリリースされました：http : //weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Asp.Net MVCもこの問題の影響を受けます（Sharepointなど）。

ここでMVCの修正について説明しました。ASP.NETMVC はOracleパディング攻撃に対して脆弱ですか？