[解決済み] ASP.NETの新しいセキュリティ脆弱性の深刻度と回避方法について教えてください。

質問

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

<ブロッククオート

この問題は ASP.NETはAES暗号を実装しています。 の完全性を保護するためのアルゴリズムです。 これらのアプリケーションのクッキー の情報を保存するために生成されます。 ユーザーセッション

ちょっと漠然としていますが、ここからがもっと怖いところです。

攻撃の第一段階は 数千回のリクエストですが、一旦 成功し、攻撃者は 秘密鍵は完全にステルス化されます。 必要な暗号の知識は 非常に基本的なことです。

私はセキュリティや暗号技術に詳しくないので、これが本当に深刻な問題なのかどうかはわかりません。

では、すべてのASP.NET開発者はこのテクニックを恐れるべきなのでしょうか？ ASP.NETのウェブサイトを数秒で乗っ取ることができる。 それとも何？

この問題は、平均的なASP.NET開発者にどのような影響を与えるのでしょうか？全く影響がないのでしょうか？ 実際のところ、この脆弱性はどのような結果をもたらすのでしょうか？そして最後に、この脆弱性を防ぐ回避策はあるのでしょうか？

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

---

編集部：いただいた回答をまとめてみます。

つまり、これは基本的に "padding oracle" タイプの攻撃なのです。 スリ は、このタイプの攻撃が何を意味するのかについて、素晴らしい解説を提供してくれました。 この問題についての衝撃的な動画があります!

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

• アプリのマシンキーを所持している場合、攻撃者は認証クッキーを復号化することができます。
• さらに悪いことに、彼は以下のことができます。 認証クッキーの生成 を任意のユーザー名で使用することができます。したがって、彼はサイト上の誰にでも見えることができます。アプリケーションは、あなたと、あなたの名前で認証クッキーを自分用に生成したハッカーを区別することができません。
• また、復号化（および生成）することも可能です。 セッションクッキー とはいえ、これは前者ほど危険ではありません。
• それほど深刻ではありません。彼は、ページの暗号化されたViewStateを解読することができます。(ViewStateを使用して機密データを保存している場合は、とにかくこれを行うべきではありません!)
• かなり意外 : マシンキーを知ることで、攻撃者は をダウンロードすることができます。 ウェブアプリケーションから任意のファイルをダウンロードすることができます。(これには Web.Config など)

ここで、私が得たグッドプラクティスの数々を紹介します。 しない 問題を解決することはできませんが、Webアプリケーションの一般的なセキュリティを向上させるのに役立ちます。

• 保護された構成で機密データを暗号化することができます。
• HTTP専用クッキーを使用する
• DoS攻撃の防止

では、この問題に焦点をあててみましょう。

• スコット・ガスリー氏が自身のブログでこの件に関するエントリーを発表しています。
• ScottGuの脆弱性に関するFAQブログ記事
• ScottGuによる脆弱性に関する最新情報
• マイクロソフトがセキュリティアドバイザリを出しています
• 脆弱性を理解する
• 脆弱性に関する追加情報

解決方法

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

その他の感想

• と思われる。 ではなく みんな は、その回避策で十分だと考えています。

私の質問に答えてくれた皆さん、ありがとうございました。この問題だけでなく、ウェブセキュリティ全般について多くを学びました。私は@Mikaelの回答を受理済みとしましたが、他の回答も非常に有用です。

解決方法は？

自分を守るにはどうしたらいい？

[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" これは、本当のクライアントをリダイレクトするためです。localhostからのブラウジングのみ、内部.Netエラーが表示されます。

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

何が問題なのか？

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

参考文献へのリンク

この脆弱性についてのマイクロソフトの公式コメントは、以下をご参照ください。 http://www.microsoft.com/technet/security/advisory/2416728.mspx . この問題の実装の詳細については、特に「ワークアラウンド」の部分を参照してください。

に関する情報もあります。 ScottGuの を含むブログ。 スクリプト を使用して、Web サーバー上の脆弱な ASP.Net アプリケーションを検出することができます。

パディングオラクル攻撃を理解する」についての解説は SRIの回答 .

---

記事へのコメント

<ブロッククオート

RizzoとDuongがASP.NETアプリケーションに対して実装した攻撃では、暗号 ウェブサイト上の実装は、暗号文が送られてきたときに、その文を解読するだけでなく しかし 暗号文のパディングが有効であるかどうかのメッセージを送信者に送る。 .

パディングが無効な場合、送信者が受け取るエラーメッセージは、サイトの復号化処理の仕組みに関する情報を提供します。

この攻撃を成功させるためには、次のことが必要です。

• アプリケーションは、パディングが無効であるというエラーメッセージを出さなければなりません。
• 暗号化されたクッキーやビューステートが改ざんされること。

そのため、アプリで人間が読めるエラーメッセージを以下のように返すと "何か問題が発生しました。 であれば、かなり安全なはずです。また、この記事のコメントを少し読むと、貴重な情報を得ることができます。

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

そうすれば、乗っ取られたクッキーは、おそらくもう存在しないか無効になっているセッションを取得するためにのみ使用することができます。

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