メモリ内およびローカルホスト上のローカルWindowsプロセス間のセキュリティ

Question

2つのプロセスで実行され、localhostネットワークポートを介して通信するWindowsアプリケーションがあります。

このアプリケーションは、Web Cookieなどの秘密を保持できます。

セキュリティの脆弱性について考えています。

私の印象：

最新の仮想メモリでは、アプリケーションはデフォルトで実行スペース（DEP）を保護しているため、開発者は何もする必要がありませんか？
メモリACLは、他のユーザーとして実行されている悪意のあるコードからのみ保護します。ボブが私のアプリと悪意のあるアプリをインストールした場合、ボブとして実行されている悪意のあるアプリが私のアプリのメモリにアクセスする可能性があります。
ASLRはバッファオーバーフローの悪用を目的としており、読み取り防止には適用されません。
Localhost呼び出しは、コンピューター上の他のユーザーに対して保護されていません。誰でもこれを聞くことができます。別のICPメディアを使用する方が安全です。
Localhostネットワークポートが実行時に決定される場合は、修正される場合よりもMITMの方が簡単です。
Windowsは、秘密を保持するのに適したユーザーキーストアを提供します。しかし、アプリケーションが秘密をRAM=に保持している場合は、他のプロセスから読み取り可能である可能性があります。

何がいけないのか教えてください。ありがとう！

CBHacking · Accepted Answer

TL; DR：ほとんどの場合、より安全なIPCに切り替える必要があります。それを超えて、おそらく素晴らしい脅威モデルはありません。

最初に番号の付いたポイントに対応し、次に一般的な回答を以下に記入します。

最近のすべてのWindowsバージョンはDEPをサポートしており、最近のすべてのMicrosoftコンパイラ（およびほとんどまたはすべてのサードパーティコンパイラも）は、出力をDEP互換（/NXCOMPAT）。このフラグをオーバーライドするようにWindowsを構成することは可能です（どちらの方向でも-フラグなしでもDEPを使用するか、存在する場合でも使用しない）。デフォルトの構成ではフラグを使用します。 DEPは実際には仮想メモリ自体とは何の関係もないことに注意してください。理論上、仮想メモリを使用しないシステムにそれを実装することはできますが、そのようなシステムにはDEPがないと思います-そして何もありませんすべてはメモリにアクセスする他のプロセスと関係があるため、DEP（および仮想メモリ）が何であるかを確実に理解したい場合があります。
仮想メモリは、誤って誤って別のプロセスのアドレス空間を読み取ることを防ぎます。プロセスは、別のプロセスのメモリへのアクセスを要求できます（読み取り許可を使用してOpenProcessを呼び出すことにより）。これはアクセスチェックの対象になります。呼び出し元のセキュリティトークン（プロセスのIDを説明するカーネルモードのデータBLOB）と要求されたアクセス許可は、ターゲットプロセスのACLに対してチェックされます。 デフォルト、このACLは他のユーザーのほとんどの権限（メモリへのアクセスを含む）を禁止しますが、同じユーザーとして（異なる標高レベル、整合性レベル、または他のサンドボックスを使用せずに）コードを実行できます完全に制御します。ですから、ユーザーがマルウェアを実行している場合、アプリは不正解です。
ASLR（DEPのような）は、広範なクラスのメモリ破損の脆弱性（バッファオーバーフローを含む）の緩和策であり、プロセス間メモリアクセスとは何の関係もありません（「読み取り中のアドレスをハードコードできない」のようなものを除いて）、アドレス空間がランダム化されるため」）。また、なんらかの理由でネイティブコード（C/C++）を使用する必要がない限り、マネージ言語（.NETランタイムのその他の何か、またはJava、Pythonなど）ではなく、メモリ管理（またはネイティブコードの相互運用）で愚かなことをしていない限り、このクラスの攻撃を心配してください。また、（DEPと同様に）ASLRは、バイナリのオプションの（ただし、すべての最新バージョンではデフォルトで有効になっている）フラグを介して有効になります。最近のすべてのライブラリにはそれが必要です（バイナリに互換性があるとマークされていなくてもWindowsに強制的に使用させることもできます）が、ASLRを使用していない単一のライブラリでも、攻撃者がメモリ破損を任意のコード実行に変える可能性があります。また、ASLRとDEPの両方を使用しても、攻撃者はメモリ内容をstill抽出する（または単に任意のコードを実行する）ことができます。プログラムまたはプラットフォーム（ランタイム、OS、CPUなど）の脆弱性（実際には通常、複数の脆弱性）に依存します。
ループバックネットワーク接続には固有のセキュリティがなく、機密コードの最悪のIPCオプションの1つです。同じマシン上の（ユーザーとして）悪意のあるコードは、いずれかまたは両方を偽装して通信を危険にさらす可能性があります。さらに、さまざまなリモート起動攻撃（SSRFなど）により、マシンのローカルでなくても、このようなシステムが危険にさらされる可能性があります。最後に、「localhost」（ループバックIPアドレスではなく）を使用すると、「localhost」のように安全性が低下します。規則により現在のマシンに解決されるだけで、代わりに別のマシンに解決されるか（これは奇妙ですが）、ネットワーク攻撃者がDNSルックアップを引き起こす可能性がありますなりすましの可能性があります（まれにこれを実際に見かけました）絶対に別のIPCメカニズムを使用する必要があります。 Windowsには欠けていません。パイプ、ローカルドメイン（Unixスタイル）ソケット、ALPC/RPC、共有メモリ、マップされたファイル、ウィンドウメッセージなどでも、ネットワークソケットよりも安全です。 amedパイプは、Windowsの古いリリースと互換性のある最もソケットのようなオプションですが、ローカルドメインソケットはしばらくの間Win10にあり、最小限のコード変更が必要です（ソケットAPIに対して直接プログラミングしている場合）。一部のライブラリを使用している場合、ライブラリはまだそれらをサポートしていない可能性があります）。
これは、エンドポイント間でポートをどのように通信しているかに依存しますが、一般的に言えば、攻撃者がポートを理解する必要がなくても、物事が簡単になるだけです。ただし、同じマシンでも、ネットワークソケットはひどい選択ですIPC機密性の高いもの。また、固定ポートを使用するプログラムはbreak他の（完全に正当な）プロセスがたまたまそのポートを使用している場合、通常、必要な場合にのみそれらを使用します。
Windows資格情報ストアは、キー、資格情報、および長期間有効なトークンを保持するのに最適な場所です。格納された値は、それを格納したものと同じまたは厳密に高い権限を持つ他のプロセスでも読み取り可能です（同じユーザーの2つの通常のプロセス、または格納プロセスがサンドボックスアプリであったが、取得プロセスがそうでない場合）。これは、トークンを長期保存にコミットすることも意味します。資格情報ストアは、ユーザーのパスワードで保護されたキーを使用するDPAPIを使用してデータを暗号化します（同じユーザーで実行されているプロセスのデータを透過的に復号化します）。

あなたが間違っていること：

ローカルIPCにネットワークソケットを使用しないでください。真剣に、1つのエンドポイントがWebアプリでない限り、ほとんどの場合それは間違いです。それを超えて、しかし、あなたはこのシステムに対する脅威の非常に完全な見方を持っていないようです。別のプロセスからシークレットを読み取ることは、通常、それを取得するための最も簡単な方法ではありません。それを実行できる攻撃者は、おそらくさらに悪い結果をもたらす可能性があります。 脅威モデルが必要であり、許容レベルリスクを決定する必要があり、リスクを受け入れないすべての脅威を軽減する必要があります。

以下の脅威モデリングのアドバイス;質問に直接直接関連することはあまりありません。

脅威のモデリングにはいくつかの異なるアプローチがありますが、それらはすべて、誰かがあなたが望まない何かをすることができる方法を列挙しようとすることへと要約されます。 1つのオプションは、潜在的な攻撃者、攻撃を阻止しようとしているすべてのこと、および攻撃者が実行できるすべての方法をリストすることから始めることです。または、攻撃者がシステムと対話できるすべての場所を特定することから始め（「攻撃ベクトル」）、次に、各対話ポイントについて、攻撃者が何ができるかを理解します。 STRIDE（なりすまし、改ざん、[非]否認、情報開示、サービス拒否、特権の昇格）などの脅威を列挙するためのニーモニックがいくつかあります。

このシステムでは、潜在的な攻撃者は誰ですか？

同じマシン上の管理者（または管理者特権で実行されているマルウェア）：図面に戻ります。安全にすることはできません。
アプリを起動したユーザーと同じ（非管理者）ユーザーとして実行されている他のプロセス：可能かもしれませんが、インストールと更新には管理者権限が必要です。それがブロッカーの場合は、製図板に戻ります。
（非管理者）他のユーザーとして実行しているアプリ：安全なIPCに切り替える限り、おそらく問題ありません。
同じネットワークまたはインターネット上の他のマシン：（「ローカルプロセス間でシークレットを渡す」という側面に関しては）問題はないが、セキュアに切り替える必要があるIPCとにかく。
マシンがオフのときにディスクに直接アクセスできる攻撃者（ラップトップの盗難など）：可能であれば、BitLockerのようなフルボリューム暗号化を使用しますが、それを保証できない場合（または非常に安全に構成できない場合））、ページファイルに書き込まれないシークレットをメモリに保持し、永続ストレージにまったく書き込まないか、またはユーザーが何らかの方法で提供したキー（パスワード、ハードウェアトークンなど）で暗号化することを検討してください。これを行う前（DPAPIはここで機能しますが、ユーザーのWindowsパスワードのセキュリティに依存し、それらを解読することは非常に簡単です）。
プログラムの実行中または最近実行中にRAM=に直接アクセスできる攻撃者（高度な「ラップトップが盗まれた」シナリオ））：できることは何もない、物理的なセキュリティの強化や埋め込みシステム内のハードウェアセキュリティモジュール（どちらもソフトウェアの対象外です）。

さて、気をつけてください。秘密がそれ価値がない場合、緩和策が高すぎるため、おそらくそれらのいくつかのアクターからの脅威を受け入れることができます。または不便。受け入れるリスクを知ることは、セキュリティの重要な部分です。

このようなシステムの完全な脅威モデルのどこかにあるかもしれない他のいくつかのこと：

シークレットは、プロセス外の何か（Webサーバーとの通信など）に使用される可能性があります。 thatも安全であることを確認してください。
プログラムはおそらくマシンのディスクのどこかにインストールされています。インストール場所が安全であることを確認してください（IPCと、世界中のメモリセキュリティは、攻撃者が実行可能コードを編集するだけでは何の役にも立ちません）。
同様に、機密性の高いデータを保存する場合は、たとえ秘密よりも機密性が低くても、攻撃者がアクセスできない場所に保存し、場合によっては暗号化する必要があります。
シークレットがセキュリティトークンであり、攻撃者がそれを推測しようとする（たとえば、サーバーに要求を出す）可能性がある場合は、ブルートフォースに抵抗するのに十分なエントロピー（安全にランダムなデータの長さ）があることを確認して、サイドチャネル攻撃（タイミング攻撃など）をブロックします。
シークレットが暗号化に使用されている場合（または実際に暗号化コードをそこに記述している場合）、暗号化を知っている誰かにそれをレビューしてもらいます。暗号化は正しく行うのが難しく、時には小さな間違いで完全に保護を破ることは簡単です。
...および「プログラムがユーザー入力を受け取るか」、「プログラムが外部ネットワークトラフィックを送信または受信するか」、「プログラムがパスワードを処理するか」、「プログラムはどのように更新するか」などに応じて、列挙する他の数が多すぎる等々。