4

その実行可能ファイル内から現在実行中の実行可能ファイルを検証するための正しいアプローチを探しています。現在実行中のファイルの（SHA256）ハッシュを計算する方法をすでに見つけました。

問題は、このハッシュをどこに安全に保存できるかということです。設定ファイルに保存すると、悪意のあるユーザーが自分のハッシュを計算して置き換えることができます。実行可能ファイル自体に保存すると、おそらく16進エディターでオーバーライドできます。

私が読んだ提案は、非対称の暗号化を行うことでしたが、これについてはどうすればよいでしょうか？

要件は、実行可能コードが異なるコンピューターでまったく同じようにハッシュおよび暗号化/復号化することです。そうしないと、正しく検証できません。すべてのコンピューターは、Windows XP（組み込み）である同じOSを実行します。

すでにすべてのアセンブリに署名していますが、セキュリティターゲットを正常に通過するには、セキュリティを追加する必要があります。

知っている人のために、それはFPT_TST.1.3に関係します：TSFは、許可されたユーザーに、保存されたTSF実行可能コードの整合性を検証する機能を提供するものとします。

4

2 に答える 2

4

すべてのコメント、特にマークからのコメントは有効です。

あなたの最善の策は、Authenticode署名を見ることだと思います-それは彼らが意図しているもののようなものです. ポイントは、exe または dll が証明書で署名されており (SSL 要求と同じように、組織の情報をそれにスタンプする)、変更されたバージョンは (理論的には、すべての通常のセキュリティ警告に加えて) 同じもので再署名できないことです。証明書。

要件に応じて (これは、この「セキュリティ ターゲット」が少しばかげているためです。コードの整合性を検証する機能は、Windows エクスプローラーでファイルをチェックする方法のウォークスルーと同じくらい簡単です)、これで十分です。それ自体 (Windows には、証明書から発行元情報を表示する機能が組み込まれています) または、Authenticode 証明書を検証するルーチンを作成できます。

この SO Verify whether an executable is signed or not (signtool used to sign that exe)を参照してください。一番上の回答は、認証コード証明書をプログラムで確認する方法に関する（確かに古い）記事へのリンクです。

アップデート

Marc が提案したことに従うには、自己プログラムによるチェックが必要な場合でも、これでは十分ではありません。実行可能ファイルを変更してチェックを削除し、証明書なしで展開できます。したがって、それを殺します。

正直に言うと、ホストアプリケーション/環境には独自のチェックが必要です (たとえば、有効な認証コード証明書を要求するなど)。コードが変更されないことが非常に重要な場合は、それを行うための独自の手順が必要です。あなたは実際に野生のガチョウを追いかけているのではないかと思います。

明らかに提供されている実際のセキュリティについてあまり心配することなく、あなたに代わって最小限の労力で済むチェックを入れてください-私はあなたが不可能な点から始めていると思うからです. あなたが書いたコードを誰かがハックしたいと思う純粋な理由が実際にあるとすれば、それをハッキングしようとするのはただの男子生徒だけではありません。したがって、利用可能なソリューション（コメントなどで言及されているもの）は簡単に覆されます。

私の「野生のガチョウ追跡」コメントを説明する最後の文を引用してください

最も弱いリンクの原則に従います。実行可能ファイルの整合性は、その実行可能ファイルを実行するホストのセキュリティ要件と同じくらい有効です。

したがって、UAC がオンになっており、すべてのセキュリティ機能がオンになっている最新の Windows マシンでは、たとえば、署名されていないコードをインストールまたは実行することは非常に困難です。ユーザーは本当にそれを実行したいに違いありません。これらをすべてゼロにすれば、比較的簡単です。ルート化された Android フォンでは、携帯電話を殺す可能性のあるものを簡単に実行できます。これには他にも多くの例があります。

したがって、コードが展開される XP Embedded 環境に、最初に実際に実行されるものに関するランタイム セキュリティ チェックがない場合 (たとえば、すべてのアプリケーションに Authenticode 証明書を要求するポリシー)、継承したポイントから開始することになります。実際に提供することになっているよりも低いレベルのセキュリティ。セキュリティプリミティブとルーチンの量はそれを復元できません。

于 2013-01-04T09:09:25.387 に答える
2

.NET 3.5 SP1 以降、ランタイムは厳密な名前の署名をチェックしていません。アセンブリに厳密な名前が付けられている場合は、コードで署名を確認することをお勧めします。mscoree.dllp/Invoke で ネイティブを使用します。

private static class NativeMethods
{
      [DllImport("mscoree.dll")]
      public static extern bool StrongNameSignatureVerificationEx([MarshalAs(UnmanagedType.LPWStr)] string wszFilePath, byte dwInFlags, ref byte pdwOutFlags);
}

assemblby load イベントを使用して、(現在の) アプリ ドメインに読み込まれているすべてのアセンブリを確認できます。

AppDomain.CurrentDomain.AssemblyLoad += CurrentDomain_AssemblyLoad;

private static void CurrentDomain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
{
    Assembly loadedAssembly = args.LoadedAssembly;

    if (!VerifytrongNameSignature(loadedAssembly))
        // Do whatever you want when the signature is broken.
}

private static bool VerifytrongNameSignature(Assembly assembly)
{
     byte wasVerified = 0;

     return NativeMethods.StrongNameSignatureVerificationEx(assembly.Location, 1, ref wasVerified);
}

もちろん、十分な経験を持つ人は、アセンブリから「チェック コード」を修正するか、単にアセンブリから厳密な名前を取り除くことができます。

于 2013-01-04T10:59:02.697 に答える