画像： ペクセル
過去数年間、情報セキュリティの分野では、新しいクラスのオペレーティングシステム保護ツール、アプリケーション制御が登場しました。 動作分析とシグネチャ分析を使用して悪意のあるソフトウェアを検出できない場合、またはシステムにウイルス対策更新プログラムをダウンロードするためのインターネットアクセスがない場合、高度に専門化されたツールが必要です。
理論的には、アプリケーション制御ツールはローカルOSセキュリティポリシーに置き換えることができますが、このクラスのソフトウェアはブラックリストおよびホワイトリストポリシーをより柔軟に管理するのに役立ちます。 今日は、ATMセキュリティの実際の例を使用して、このようなセキュリティ対策の使用方法について説明します。
アプリケーション制御ツールが正確に行うこと
アプリケーションが特定のホワイトリストに一致するかどうかを確認する方法はいくつかあります。実行可能ファイルまたはそのハッシュへのパスの確認から、デジタル署名と拡張子の分析まで。 アプリケーション制御ツールは、ほとんどの場合、クライアントコンピューターに追加の保護を提供するために使用されます（ホワイトリストからではないソフトウェアの起動の禁止）、または一定のオペレーターの介入を意味しない分離システムのセキュリティの確保（ATMなど）。
最初のケースでは、フィッシング攻撃など、攻撃者が悪意のあるアプリケーションを起動するようにユーザーを説得するようにユーザーを保護する必要があります。たとえば、特別な添付ファイルを含む手紙を使用します。 この場合、保護システムは、行動分析または署名（ハッカーがますます巧妙にバイパスする）に基づいてではなく、単にユーザーがそのようなアプリケーションから原則的に禁止されているため、ダウンロードされた添付ファイルの起動を単に禁止します。
2番目のシナリオでは、攻撃者が何らかの方法で既にシステムに入っている、つまり、システムへの物理的またはリモートアクセスを持っていると想定されます-cmd.exeコマンドコンソールまたはエクスプローラー。 ここでは、権限を増やしたり、悪意のあるアクション（mimikatz、nmapなど）を実行するために使用できるサードパーティソフトウェアを実行する機能を制限する必要があります。
ここで何が問題になる可能性があるか：制御の3つの問題
アプリケーション制御は若い分野であるため、関連するツールのほとんどすべてに、ある種の「小児疾患」があります。 その結果、そのような製品はすぐに動作することはほとんどなく、すでに使用中の構成、テスト、および適応が必要です。 これは、とりわけ、起動されたアプリケーションを制御するというまさにそのタスクを解決するのが困難なためです-主なものをリストします。
ホワイトリストの実装ははるかに困難です
ブロックする価値のある拡張機能の「ブラックリスト」が多かれ少なかれ普遍的で構成が容易な場合、実行が許可されるものの「ホワイトリスト」はデフォルトで冗長です-多くの場合、構成時にOSのすべてのアプリケーションが含まれます。
これは、チェックの条件に違反することなく、ATMでさまざまな方法で任意のコードを実行できることを意味します。 たとえば、PowerShell（ほとんどの場合、ATMはWindowsで実行されます）などの非常に正当なツールと、外部コードを呼び出すユーティリティを使用します。 過去数年にわたって、Microsoft Windowsツール（「rundll32」、「regsvr32」など）、OSの通常の操作を中断する単純なロックを使用して、アプリケーション制御をバイパスする多くの方法が説明されてきました。
これは、アプリケーション制御システムがこれらのユーティリティを起動するという事実ではなく、どのプロセスがユーティリティ（システムまたはユーザー）を使用するか、どの権限が使用されるか、必要なライブラリがどのように呼び出されるかなどの一連の条件を監視する必要があることを意味します
比較的短期間で、Positive Technologiesの専門家は、「debug.exe」、「ntsd.exe」、「rasautou.exe」など、他の方法でサードパーティコードを実行できるOSユーティリティのリストを拡張することができました。
別の攻撃の方向は、プログラミング言語（Java、.NET、PHP）のインタープリターです。 ほとんどの場合、ATMでの打ち上げの条件は可能な限り詳細である必要があります。 実際、これはそうではなく、任意のコードを実行する可能性を開きます。 考えられる結果の例は、 Microsoft Windows Applockerのセキュリティ機能をバイパスするための.NETへの最近の攻撃です 。
私たちの実践では、32ビットのファイル拡張子を任意に変更したり、通常はファイルをチェックするための条件であるPEヘッダーが含まれていないためテストされていない16ビットアプリケーションを使用して、単に拡張子制御をバイパスすることから保護するソリューションもあります起動する前に。
ご覧のとおり、正しく構成する必要がある構成パラメーターがたくさんあります。 また、拡張機能ではなくヘッダーでアプリケーションをブロックして、32ビットアプリケーションだけでなく16ビットアプリケーションも禁止することは理にかなっています。
脆弱性は保護ツールにもある可能性があります
他のソフトウェアと同様に、保護ツールには脆弱性が含まれる場合があります。 研究者は、ウイルス対策およびファイアウォールのセキュリティエラーを定期的に発見します-アプリケーション制御ツールは同じラインにあります。
その場合、ネットワーク攻撃の可能性を開く脆弱性があります。たとえば、傍受したコマンドまたはバッファオーバーフローエラーを繰り返すだけで保護メカニズムを無効にします。 別のタイプの問題は、アプリケーション制御システムの動作における論理エラーです;それらの動作により、保護メカニズムをバイパスすることができます。
すべての攻撃が同じように簡単に撃退できるわけではありません
アプリケーション制御ツールの使用には固有の特性があり、アプリケーションの範囲によって異なります。たとえば、ATMの場合、原子力発電所のインフラストラクチャを保護するよりも、異なるプロファイルの攻撃から身を守ることが重要です。 最初のケースでは、攻撃者はお金を盗むために、持ち込まれたマルウェアを実行する必要はありません。
私たちの調査が示すように、特定のファイルを読み書きするだけで十分な場合があります。 また、アプリケーション制御製品は、このような「攻撃」から保護するように設計されていませんが、攻撃者の成功率を下げるように構成できます。 たとえば、OSとMSXFSライブラリATMの周辺とのやり取りを担当するアクティビティ分析を開始する場合、同じPowerShell、Regedit、およびメモ帳とやり取りできます-メモ帳は構成ファイルの読み取りまたは書き込みに十分であるため、不正なユーザーのアクティビティは禁止されています。
結論：特効薬は存在しません
Application Controlクラスのツールは、攻撃が成功する可能性を減らし、攻撃者の生活を複雑にしますが、本質的には、ATMなどのシステムの保護にはあまり適していません。 非常に微調整する必要性から、正しく構成されたアプリケーションフィルタリングルールさえもバイパスできる独自の脆弱性を持つ可能性まで、これらのツールを最も効果的な保護方法としない多くの制限があります。
銀行は、インフラストラクチャを保護するために、現在のトレンドの影響下でツールを実装するだけでなく、包括的なセキュリティ戦略を実装する必要があります。それに応じて、特定の保護手段を選択できます。 この問題を解決するために必要な手順は次のとおりです。
- 独立した専門家の関与により、脅威モデルと侵入者モデルを作成します。
- 情報セキュリティ監査員およびアプリケーション制御ソリューションベンダーと連携してポリシーを開発します。 最小限の特権の原則を順守します（明らかに許可すべきでないものはすべて禁止します）。
- ハッカーの攻撃スペースを大幅に削減する他の手段を導入することを考えます：接続されたデバイスを制御するためのツール（デバイス制御）、処理センター側の暗号署名を使用したブラックボックス攻撃に対する保護メカニズム。
投稿： Timur Yunusov、Positive Technologies