web-dev-qa-db-ja.com

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

ASP.NETで新たに発見されたセキュリティの脆弱性についてネットで読んだばかりです。 詳細はこちらで確認できます

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

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

攻撃の最初の段階では数千のリクエストを受け取りますが、攻撃が成功し、攻撃者が秘密鍵を取得すると、完全にステルス化されます。必要な暗号知識は非常に基本的です。

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

したがって、すべてのASP.NET開発者は、ASP.NET Webサイトを数秒で所有できるというこの手法を恐れるべきでしょうかまたは何ですか？

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

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

編集：私が得た応答をまとめましょう

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

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

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

しないは問題を解決しますが、Webアプリケーションの一般的なセキュリティの向上に役立つと私が得た多くの優れたプラクティスを次に示します。

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

ソリューション

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

他の考え

  • noteveryone は回避策で十分だと考えているようです。

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

asp.net.netsecuritypadding-oracle-attack
189
Venemo

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

[2010-09-29更新]

Microsoftセキュリティ情報

修正に関するKB記事

ScottG ダウンロード用のリンクがあります

[2010-09-25更新]

修正を待っている間、昨日ScottGu postet a update カスタムURLScanルールでサイトを保護するための追加のステップを追加する方法について。

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

Web.configで

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

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

また、customErrors mode="RemoteOnly"を設定しても安全です。これにより、「実際の」クライアントがリダイレクトされます。ローカルホストからの参照のみが内部.Netエラーを表示します。

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

何が危機にatしていますか？

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

参考文献へのリンク

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

また、Webサーバー上の脆弱なASP.Netアプリを見つけるための script を含む ScottGu's ブログに関する情報もあります。

「パディングOracle攻撃の理解」の説明については、 @ sri's answer を参照してください。

記事へのコメント：

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

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

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

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

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

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

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

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

58
Mikael Svenson

パディングOracle攻撃の理解

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

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

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

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

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

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

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

  1. 最も単純なこと-機密性の高いものは、暗号化されているか暗号化されていない状態でクライアントに送信しないでください。サーバーに保管してください。

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

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

追伸パディングOracle攻撃の適切な説明は このブログ投稿 にあります。免責事項：それは私のブログではありません。

40
Sripathi Krishnan

今まで読んだことから...

この攻撃により、誰かが銀行の残高などの貴重なデータを含む可能性のあるスニッフィング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を見つけてデータを復号化することを想定したツールをダウンロードしました。そして、 ビューステートをチェックする上記のコード でそのトラップを言うように。私のテストでは、このツールにはさらに多くの修正が必要です。たとえば、圧縮されたビューステートをそのままスキャンできず、テストでクラッシュする可能性があります。

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

更新2

私が今まで読んだことから、エラーについての情報を返さないために本当に必要なのはそれだけだと思う​​、そしてただ カスタムエラーページ。必要に応じて、このページにランダムな遅延を作成してください。

非常に興味深いビデオ この問題について。

したがって、上記のすべては、この特定の問題に対する100％の必需品ではなく、より多くの保護のためのより多くの手段です。たとえば、SSL Cookieを使用すると、snifの問題が解決されます。Cookieにロールをキャッシュしないで、大きなCookieを送信して返さないようにして、管理者ロールを配置するだけのコードをクラックする準備を整えてください彼のクッキー。

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

13
Aristos

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

[〜＃〜] edit [〜＃〜]
ここ は、スコットグからのより詳細な情報です。

12
ScottS

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ファイルをダウンロードできます（ただし、アプリケーション外のファイルはダウンロードできません）。このためのパッチを明らかにリリースします。それまでは、上記の回避策により攻撃ベクトルが閉じられます。

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

12
Martin Vobr

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

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

4
Nariman

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

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

攻撃されているキーは、ビューステート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編集：トップへのリンクを追加]

3
Richard

私はこの問題に関する追加調査の後、これについての完全な見解を投稿しました 私のブログで 。認証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を実際に必要としないため、これらをオフにできます。ビューステートも使用しません。それは、他のasp.net機能のいずれかが回避策と異なる情報を提供するかどうか、つまりパディングが無効な結果を与えるかどうかわからないが、無効な認証チケットに有効な結果をパディングするかどうかわからない（わからないその場合、そうでない場合）...同じ分析がセッションCookieに適用される必要があります。
  5. asp.netメンバーシッププロバイダーはCookieのロールを「キャッシュ」し、それをオフにします。

約1の暗号化されたメッセージは、制御できない値を解読するメッセージ内に1つのブロックがあるため、メッセージのどこかにごみの小さな破片を100％arbitrary意的に許容することはできません。

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

詳細：

無効な認証チケットで有効な結果をパディングしながら、パディングが無効な結果をエラーで与えるかどうかはわかりません（その場合かどうかわからない）...同じ分析がセッションCookieに適用される必要があります。

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

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

2
eglasius

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

2
Josh Yeager

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

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

1
Stefanvds