191

ASP.NET で新たに発見されたセキュリティの脆弱性についてネットで読みました。詳細はこちらからご覧いただけます。

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

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

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

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

では、すべての ASP.NET 開発者は、ASP.NET Web サイトを数秒で所有できるこの手法を恐れるべきでしょうか?

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

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

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

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

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

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

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

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

ソリューション

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

その他の考え

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

4

10 に答える 10

58

身を守るために何をすればいいですか？

[更新2010-09-29]

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

修正に関するKB記事

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

[更新2010-09-25]

修正を待っている間、昨日、ScottGuは、カスタムURLScanルールを使用してサイトを保護するための追加の手順を追加する方法に関する最新情報を投稿しました。

基本的に、攻撃者が内部の.Netエラーにさらされないように、カスタムエラーページを提供するようにしてください。これは、リリース/本番モードでは常に行う必要があります。

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

web.configで

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

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

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

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

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

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

参考文献へのリンク

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

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

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

記事へのコメント：

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

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

攻撃が機能するためには、次のことが当てはまる必要があります。

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

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

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

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

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

于 2010-09-15T19:31:34.843 に答える
40

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

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

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

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

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

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

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

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

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

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

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

PS Padding Oracle Attacks の適切な説明は、このブログ投稿にあります。免責事項: 私のブログではありません。

于 2010-09-15T20:19:14.810 に答える
13

私が読んだものから今まで...

この攻撃により、誰かが盗聴されたCookieを復号化できます。この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。

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

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

アップデート2

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

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

したがって、上記のすべては、より多くの保護のためのより多くの手段ですが、この特定の問題に100％必要というわけではありません。たとえば、ssl cookieを使用すると、snifの問題が解決されます。役割をクッキーにキャッシュしないことは、大きなCookieを送信して返送しないこと、およびコードを解読する準備ができているものを回避するために、管理者の役割を配置することをお勧めします。彼のクッキー。

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

于 2010-09-15T19:29:03.290 に答える
12

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/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspxの2番目のブログ投稿で利用可能な追加のFAQ

于 2010-09-19T19:37:32.253 に答える
12

Here is the MS response. It all boils down to "use a custom error page" and you won't be giving away any clues.

EDIT
Here is some more detailed info from scottgu.

于 2010-09-18T05:23:15.240 に答える
4

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

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

于 2010-09-21T13:52:44.583 に答える
3

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

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

攻撃対象のキーは、ビュー ステート 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 年 9 月 21 日編集: トップへのリンクを追加]

于 2010-09-19T07:35:29.563 に答える
2

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

いくつかの事実をまっすぐにしたいだけです：

  1. 攻撃では、マシン キーを直接取得することはできません。とは言っても、メッセージを復号化し、新しいメッセージを再/暗号化して変更できるため、以前とほとんど同じです。
  2. 実際のキーを取得する方法は、1 のように再暗号化を変更して 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% 恣意的ではありません。

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

詳細:

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

認証 Cookie は署名されており、紙の情報から、実際のキーに到達しない場合 (認証 Cookie を偽造する前にビデオで行ったように)、署名付き Cookie を生成できないはずです。

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

于 2010-09-22T06:36:47.903 に答える
2

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

于 2010-10-27T19:06:22.080 に答える
1

Asp.Net MVC もこの問題の影響を受けます (Sharepoint などと同様)。

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

于 2010-09-21T10:42:35.540 に答える