25

管理対象DLLを参照する.NETアプリケーションがあります。

このDLLには、ScoreKeeperと呼ばれるメソッドを実装するクラスが含まれていGetHighScore()ます。アプリケーションはこれを定期的に呼び出します。

.NETアプリケーションが提供しているDLLの代わりに「許可されていない」DLLを使用しないようにする方法はありますか？

4

2 に答える 2

51

あなたが言及する：

このDLLには、ScoreKeeperGetHighScore（）というメソッドを実装するクラスが含まれています。アプリケーションはこれを定期的に呼び出します。

その後：

.NETアプリケーションが提供しているDLLの代わりに「許可されていない」DLLを使用しないようにする方法はありますか？

同じ名前とタイプ（同じ名前空間にある）を持つ独自のアセンブリで提供したアセンブリを誰かがスワップアウトするのを防ぎたい場合は、クラスを含むアセンブリに厳密な名前を適用でき ます。消費者にそれを参照してもらいます。ScoreKeeper

ただし、これを100％信頼できないものにする問題があることがわかります。厳密な名前は、知らないユーザーを悪意のあるなりすましコピーでDLLを置き換えることから保護するのに役立ちます。しかし、ユーザーがなりすましに加担している場合（これは、ユーザーが不正行為を試みている場合に当てはまります）、コード署名はスピードバンプにすぎず、実際の保護は提供されません。確かに、Strong Namesは、PunkBusterなどに匹敵する保護を提供しません。

厳密な名前を使用してアセンブリ発行者のIDを確認する

アセンブリに厳密な名前を追加する場合、秘密鍵（非対称の公開鍵と秘密鍵のペアの一部、これについては後で詳しく説明します）を使用して暗号化ハッシュを生成し、公開鍵をアセンブリ名に含めます（ハッシュ）。

公開ハッシュと公開鍵を使用して、CLRは、アセンブリの署名が実際に秘密鍵からのものであることを確認できます。

もちろん、これは、キーを（内部および外部で）保護する必要があることを意味します。他の誰かがあなたの鍵を持っている場合、彼らは効果的にあなたになりすまして、人々があなたからのものであると信頼するであろうアセンブリを公開することができます。

次に、署名されたアセンブリへの参照を追加するときに、誰かが同じアセンブリ名（完全修飾されたものではなく、バージョン、ハッシュ、公開鍵を含まない名前のみ）と同じタイプ名で別のアセンブリを挿入しようとすると、タイプをロードしようとするとCLRフィルが失敗し、タイプが見つからなかったことを示します。タイプは、名前空間とタイプ名とともに、完全修飾アセンブリ名を使用して解決されます。

厳密な名前が100％安全ではない理由（何かありますか？）

1）ハッシュ衝突

まだ検証中のハッシュです。ハッシュは非常に大きいですが（デフォルトのハッシュアルゴリズムであるSHA-1の場合は160ビット）、値の数が有限であるハッシュは衝突の対象になります。非常に可能性は低いですが、可能です（不可能か不可能か）。さらに、デフォルトでは最後の8バイトのみが使用されます。SHA-1が比較的弱いことを示す調査と組み合わせると、これは、MSDNで説明されているSHA-256拡張ストロングネーミングを使用する十分な理由です。

2）ストロングネームの削除

強い名前は削除できます。ただし、この場合、アセンブリは参照されているアセンブリの厳密な名前のバージョンを参照しているため、アセンブリが侵害されたバージョンを使用しようとすると、検証が正しく再度有効になっていると仮定して、実行時に失敗します（以下を参照）。

3）アセンブリへの物理的なアクセスとは、すべてのアセンブリを意味します

誰かが物理マシンにアクセスでき、参照しているアセンブリを変更できる場合、アセンブリも同様に脆弱です。攻撃者があなたが参照したアセンブリの厳密な名前を変更する能力を持っている場合、攻撃者はあなたのアセンブリと実行に関与する他のすべてのものを同じように簡単に変更できます。この目的のために、物理的なアセンブリがハッキングされていないことを100％確実にする唯一の方法は、それを介した物理的なアクセスを拒否することです。もちろん、それは多くの異なるセキュリティ上の懸念を引き起こします。

4）管理者が厳密な名前のチェックを無効にする

コンピューター管理者は、を使用して厳密な名前のチェックをバイパスできますsn -Vr。MSDNによると：

検証スキップのためにアセンブリを登録します...悪意のあるアセンブリは、スキップ検証リストに追加されたアセンブリの完全に指定されたアセンブリ名（アセンブリ名、バージョン、カルチャ、および公開鍵トークン）を使用して、そのIDを偽造する可能性があります。これにより、悪意のあるアセンブリも検証をスキップできます。

5）厳密な名前のチェックは、.NET 3.5SP1以降で明示的に有効にする必要があります

.NET 3.5 SP 1以降では、厳密な名前を付けるだけでは保護は提供されません。

.NETFrameworkバージョン3.5ServicePack 1（SP1）以降、アセンブリがMyComputerゾーンの既定のAppDomainなどの完全信頼のAppDomainオブジェクトに読み込まれるときに、厳密な名前の署名は検証されません。

.NETでアプリケーションにロードされた各アセンブリの厳密な名前を確認するには、次のスニペット（MSDNから提供）をアプリケーション構成ファイルに挿入する必要があります。

<configuration>
  <runtime>
     <bypassTrustedAppStrongNames enabled="false" />
  </runtime>
</configuration>

ただし、これは厳密な名前の削除に対してのみ保護されることに注意してください。

バイパス機能をオーバーライドすると、厳密な名前は正確さについてのみ検証されます。のチェックは行われませんStrongNameIdentityPermission。特定の厳密な名前を確認する場合は、そのチェックを個別に実行する必要があります。

上記の懸念に照らして、アセンブリのストロングネーミングを引き続き実行したい場合は、次の方法で行います。

厳密な名前を生成し、アセンブリに署名する

厳密な名前を生成するときに使用するキーには2つのオプションがあります。Visual Studioで、プロジェクトプロパティの[署名]タブに移動し、[アセンブリに署名する]をクリックします。

そこから、公開鍵/秘密鍵を生成する、VS.NETに鍵を生成させる、または既存の鍵を指す2つのオプションがあります。

[新規]を選択すると、Visual Studioは、生成するファイルの名前と、オプションでパスワードを使用してファイルにアクセスするかどうかを確認するメッセージを表示します。

厳密な名前キーの作成ダイアログ

その時点で、キーがプロジェクトに追加されます。

プロジェクトに追加されたキー

これで、これをソリューションアイテムに移動できます（ソリューションに複数のプロジェクトがある場合）。

この場合のVisualStudioは、実際には、厳密な名前のコマンドラインツールを呼び出して公開鍵と秘密鍵のペアを生成しているだけです。自分でそれを行いたい場合は、次のようsn.exeに、-kコマンドラインオプションを使用して呼び出してキーを生成する必要があります。

sn -k keyPair.snk

次に、上の[参照]ダイアログから追加します。

これを行うと、プロジェクトにキーがプルされることに注意してください。これを実行したくない場合は（すべてのプロジェクトにキーをコピーするため）、プロジェクトからキーを削除してから、既存のファイルをプロジェクトに追加しますが、リンクします。これにより、[厳密な名前のキーファイルを選択]オプションがクリアされますが、ドロップダウンすると、リンクされたキーファイルへのフルパスが表示されます。

于 2012-11-12T15:17:55.007 に答える
3

最も簡単な答えは、ロードしているDLLの安全なハッシュを計算し、それを事前に計算したゴールデン値と比較することだと思われます。もちろん、これは十分に決定された攻撃者によって破壊される可能性がありますが、不正行為をしたい人の水準を大幅に引き上げます。

于 2012-11-12T15:17:23.767 に答える