リリース時と更新時の間の競合状態を回避する

Question

開発者がセキュリティ更新プログラムをリリースするときと、ユーザーがセキュリティ更新プログラムを実際に適用するときの間には、一種の競合状態があります。その間、攻撃者は脆弱性について学び、まだパッチが適用されていないシステムを攻撃することができます。この問題は完全に回避できますか？そうでない場合、それを可能な限り軽減するためのベストプラクティスは何ですか？

これは、パッチが悪用が困難な複雑な問題に対するものである場合など、特にソフトウェアがクローズドソースである場合など、場合によっては大きな問題のように聞こえないことがあります。その場合、攻撃者はエクスプロイトを開発するのに数日を要し、ユーザーはシステムを更新するのに十分な時間があります。しかし、他の場合では、この競合状態の影響は実際に悲惨です。 GitHubのオープンソースプロジェクトで次のコミットを想像してください。

- echo '<span>' . $username . '</span>'; // line removed + echo '<span>' . htmlspecialchars($username) . '</span>'; // line added

これは明らかに永続的なXSS脆弱性の修正です。セキュリティ更新プログラムがそのコミットの1時間後にのみ一般にリリースされ、ユーザーが更新プログラムをリリースしてから1時間後に更新する場合（これは完全に非現実的です）であっても、これにより2時間のウィンドウが表示されます。経験の浅い攻撃者でも1分で悪用できる脆弱性。非常に人気のあるソフトウェアの場合、自動化された攻撃がセキュリティ更新プログラムのリリース後わずか数時間で始まることも珍しくなく、場合によっては公式リリースの少し前でさえあります。

それでは、この競合状態を完全に回避または部分的に緩和するために何ができるでしょうか？システムのセキュリティに真剣に取り組んでいるベンダーや顧客が使用するベストプラクティスは何ですか？ここに私が考えたいくつかの可能な解決策があります：

コンパイルまたは難読化して、ソースコードをすぐに利用できるようにしないでください。これは、プロプライエタリソフトウェアでよく行われることです。 Microsoftは、パッチのリバースエンジニアリングに時間がかかり、その間にすべてのユーザーが更新を実行できるという事実に依存していると思います。
セキュリティ修正をアドバタイズしないでください。修正したことを誰にも知らせずに修正してリリースするか、ヒントをどこかに残します。これにより、攻撃が遅れる可能性がありますが、ユーザーが「重要ではないように思われるので、後で更新する」と考える可能性があるため、更新が遅れる可能性もあります。
セキュリティバグの自動パッチを強制します。システムはできるだけ早く自動的にパッチが適用され、公開アナウンスやセキュリティアドバイザリを発行する前に、セキュリティの問題のみを修正し、機能を壊さないようにします。これは、すべてのシステムに短時間でほぼ同時にパッチが適用されるという条件で、良い考えのように思えます。 Wordpressはデフォルトでそのコアに対してこのようなことをしますが、すべてのインストールを更新するのにどれくらい時間がかかるかわかりません（数百万あります）。
セキュリティ会社のサービスを利用して攻撃者より先を行く攻撃者が行うのと同じようにさまざまなことを監視すると主張するセキュリティ会社があります（新しい攻撃を検出して調査し、公式の勧告を確認してください）、ブラックハットコミュニティなどから情報を収集することもできます）。特別なアドバイスやWebファイアウォールなどを使用して、攻撃者の先を行く手助けをします。これは、レースの問題を実際に解決しない場合を除いて、もう1つの人気のあるソリューションのようです。より速くレースしようとしています。また、このソリューションは一般的なソフトウェアに役立つ可能性がありますが、あまり一般的でないアプリケーションに役立つサービスを見つけるのは難しいと思います。

今は他に何も考えられません。

Benoit Esnard · Accepted Answer

以下は、私が実際に目にしたリバースエンジニアリングパッチに対する防御策です。

重要なパッチが利用可能になる時期を公表します。

攻撃者と顧客の両方が同時にパッチにアクセスできるようにすることで、攻撃者がエクスプロイトを開発するのに十分な時間を確保する前に、顧客がパッチを適用する必要があるすべてにパッチを適用できるようにします。

有名な例は、 Patch Tuesday です。これは、Windowsが既知の日付にパッチをリリースするために使用する戦略です。

別の例はDrupalです：リリースの1週間前に非常に重要なパッチについて人々に知らせます。

すべてに対して単一のパッチをリリースします。

この戦略はWindowsでも使用されています。数週間ごとに1つのパッチをリリースすることで、セキュリティ修正の1行の変更と比較して、すべての変更をリバースエンジニアリングするのにより多くの労力がかかります。

JeffUK · Answer

これが、Defence in Depthの概念がそれ自体に入るところです。はい、定期的かつ適切にパッチを適用しますが、重要なシステムでは、あなたが脆弱なコンポーネントを持っているという事実を考慮に入れてください。

XSSはフィッシングを介して悪用されることがあり、フィッシング攻撃を特定して回避する方法についてエンドユーザーをトレーニングするための最初の防御ライン。

ユーザーがWebアプリケーションファイアウォールを実装した場合。その後、XSSがまだ存在している場合でも、XSSを悪用する試みを検出してブロックすることができます。

Webサーバーが標準の同じオリジンポリシーで構成されている場合、xssが成功する可能性は低くなります。 WAFがそれを検出しなくても。

ソフトウェアが適切なセッション管理を使用していて、たとえば重要なトランザクションの再認証を行うと、たとえXSS攻撃が成功したとしても、その影響を大幅に減らすことができます。

データが適切に暗号化されていることを確認すると、ユーザーは必要なデータにのみアクセスでき、機密データは絶対に必要な場合にのみ保存されます。そのxssの脆弱性を利用すると、たとえ攻撃者が脆弱なシステム。

Gaius · Answer

適切に設計されたシステムでは、攻撃者が簡単にアクセスできる脆弱性は1つだけでは不十分です。たとえば、PHPで重大なバグが発見された可能性がありますが、nginxで mod_security を実行していて、 nreferenced files をクリーンアップしており、ファイルシステム、およびデータベースユーザーストアドプロシージャのみを実行できます、および開発者は既に OWASPガイドライン ...に従っていますしかし、あなたはずっと安全衛生を守ってきたので、少し余裕があります。煩わしい場合は、メンテナンスウィンドウが機能するまで待つことができます。攻撃者は、理想的には、侵入するためだけに0日間を燃やす必要があり、横方向の動きを実行するにはさらに多くの必要があります。完全に安全にすることはできませんが、攻撃コストを高くすることができます。

2つ目は、自分の背中にターゲットをペイントしないことです。狙われた投機的な攻撃の犠牲になると仮定します-そして、現代の水飲み場/サプライチェーン攻撃により、ますます可能性が高まります-LinkedIn全体で開発者がスキルを磨き上げないようにし、簡単に追跡できるIDを使用してください会社に戻って、特定のテクノロジーの特定のバージョンなどについてフォーラムに投稿します。架空のPHPシナリオでは、攻撃者はすでにあなたを見ていて、あなたがPHPを使用していることを知っているため、「あはは！」新しい脆弱性が発表されたらすぐに、すぐに試してください。