従来のEDRがクラウドにおけるサーバーD&Rで失敗する理由

By 清水 孝郎 - NOVEMBER 16, 2023
Topics: クラウド セキュリティ, コンテナ、Kubernetes、ホストのセキュリティ

SHARE:

本文の内容は、2023年11月16日に NIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/traditional-edr-solutions-cloud/)を元に日本語に翻訳・再構成した内容となっております。

クラウドコンピューティングの時代では、Linuxディストリビューションを使用した仮想ホストやサーバーが増えており、攻撃者はクラウドシステムに侵入し、潜在的な脆弱性を悪用する革新的な方法を継続的に見つけています。実際、Elastic Security Labsの2023年の調査によると、マルウェア感染の91%はLinuxエンドポイントによるものでした。Linux VMに特に深刻な危険をもたらすもう1つのアプローチは、ホストカーネルへのBPF（Berkeley Packet Filter）バックドア・プログラムのインジェクションです。

この記事では、従来のEDR（Endpoint Detection and Response）ソリューションが、なぜカーネル攻撃の検出と適切な対応に苦戦することが多いのかを探り、この憂慮すべきリスクに対抗するためにシステムコールを深く可視化する必要性を説明していきます。最後に、プロセスの動作のようなホストの D&R アクティビティをクラウドの監査コンテキストと関連付けることで、クラウドにおけるレスポンスまでの時間を短縮し、クラウドにおける毎秒のセキュリティを確保する必要性も説明します。

BPFバックドア インジェクションのリスクを理解しましょう

オペレーティングシステムのカーネルへの BPF バックドアプログラムの挿入は脅威です。カーネルはオペレーティングシステムの中核として、システムリソースを管理し、ホスト/サーバ全体の完全性とセキュリティを保証する責任があります。敵対者が BPF プログラムをカーネルにロードすることに成功すると、彼らは昇格した特権を獲得し、検出されることなくホストの振る舞いを操作できるようになります。これは機密データの機密性と完全性を危険にさらすだけでなく、ホストシステムを不正にコントロールすることにもつながります。

カーネル攻撃検知における従来のEDRの欠点

  1. 限られた可視性： 従来のEDRソリューションは、ファイルやレジストリの変更、ネットワーク・アクティビティ、ユーザー・アクティビティ、ペイロードの実行など、より高いレベルのアクティビティやプロセスの監視に依存しており、多くの場合、カーネル・レベルの操作に対する深い可視性がありません。この制限により、カーネル内で発生する脅威の検出や対応には適していません。
  2. コンパイラ動作の非効率的な検出： EDRソリューションは、悪意のあるコードのコンパイルなど、コンパイラの動作を検出すると主張するかもしれませんが、攻撃者は検出を回避するためにこれらのプロセスを難読化することができます。コンパイラの動作をカモフラージュするために Base64 エンコーディングのようなテクニックを使用することができるため、EDR では疑わしい動作を特定することができません。
  3. ポリシー制御への過度の依存： 多くの EDR ソリューションは、主にコンパイラの動作に基づいて自動的にアクションを実行する保護ポリシーに依存しています。しかし、このようなポリシーは無効化されたり、誤った設定にされたりする可能性があるため、システムは検出されない脅威に対して脆弱なままとなります。攻撃者がこれらの制御の回避に成功した場合、EDR は侵害を防ぐ力を失います。

ディープなシステムコール可視化が必要

カーネル攻撃がもたらす脅威と効果的に戦うためには、オペレーティング・システムのディープなシステム・コール・アーキテクチャーの視点を採用することが不可欠です。コンテナ・セキュリティのリーダーであるSysdigは、このアプローチの重要性を認識しています。システムコールをきめ細かなレベルで監視することで、正常な動作からの微妙な逸脱を発見することが可能になり、リアルタイムでの侵入検知と対応が可能になります。

BPFバックドア・プログラムの検出におけるSysdigのアプローチ

Sysdigの包括的な脅威検出機能は、カーネルレベルの攻撃に対抗するために設計されています。BPFバックドア・プログラム・インジェクションの場合、Sysdigはシステムコールを注意深く監視し、カーネルに対する不正や未承認の変更を探すことで、この活動を検出することができます。攻撃者が難読化技術を使用している場合でも、Sysdigの深いシステムコールにおける可視性により、このような欺瞞的な行為を明らかにすることができます。

ルール: カーネルにロードされた eBPF プログラム
説明: このルールは、eBPFプログラムのカーネルへのロードを検出します。eBPFプログラムは非常に強力で、eBPFベリファイアが課す制約に適合する限り（カーネルパニックを引き起こさない限り）、ターゲットシステムに対してほぼ任意に近い制御を行うことができます。

ホストカーネルへの ebpf プログラムのインジェクション

上記のスクリーンショットのように、プロセスツリーを使用すると、親 Powershellプロセス（pwsh）が、eBPF（拡張Berkeley Packet Filter）プログラムをカーネルにロードしようとしている別の子プロセス（bash）をトリガーしていることがわかります。この深いレベルの可視性のおかげで、私たちは不審な動作を通知されるだけでなく、より迅速に改善策を講じることができます。私たちは、bashコマンドがどこから来ているのかを知っており、親プログラム/スクリプトに対して自然にアクションを起こし、システムを修復することができます。

しかし、これがEDR検出とどう関係があるのでしょうか？

ルール出力で提供されるsyscall引数は、eBPFプログラムをカーネルにロードして実行するための一連のシェルコマンドにデコードする、base64エンコードされたシェルコマンドを示しています。このプロセスには、eBPFプログラムの作成、コンパイル、実行が含まれます。以下は、Falco 検出ルールの “親の名と引数” に記載されているコマンドの全文です。

bash -c echo I2RlZmluZSBfR05VX1NPVVJDRQoKI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8c3lzL3N5c2NhbGwuaD4KI2luY2x1ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDxsaW51eC9icGYuaD4KCmludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKewogICAgaW50IG47CiAgICBpbnQgYmZkLCBwZmQ7CiAgICBzdHJ1Y3QgYnBmX2luc24gKmluc247CiAgICB1bmlvbiBicGZfYXR0ciBhdHRyOwogICAgY2hhciBsb2dfYnVmWzQwOTZdOwogICAgY2hhciBidWZbXSA9ICJceDk1XHgwMFx4MDBceDAwXHgwMFx4MDBceDAwXHgwMCI7CgogICAgaW5zbiA9IChzdHJ1Y3QgYnBmX2luc24qKWJ1ZjsKICAgIGF0dHIucHJvZ190eXBlID0gQlBGX1BST0dfVFlQRV9LUFJPQkU7CiAgICBhdHRyLmluc25zID0gKHVuc2lnbmVkIGxvbmcpaW5zbjsKICAgIGF0dHIuaW5zbl9jbnQgPSBzaXplb2YoYnVmKSAvIHNpemVvZihzdHJ1Y3QgYnBmX2luc24pOwogICAgYXR0ci5saWNlbnNlID0gKHVuc2lnbmVkIGxvbmcpIkdQTCI7CiAgICBhdHRyLmxvZ19zaXplID0gc2l6ZW9mKGxvZ19idWYpOwogICAgYXR0ci5sb2dfYnVmID0gKHVuc2lnbmVkIGxvbmcpbG9nX2J1ZjsKICAgIGF0dHIubG9nX2xldmVsID0gMTsKICAgIGF0dHIua2Vybl92ZXJzaW9uID0gMjY0NjU2OwoKICAgIHBmZCA9IHN5c2NhbGwoU1lTX2JwZiwgQlBGX1BST0dfTE9BRCwgJmF0dHIsIHNpemVvZihhdHRyKSk7CiAgICBjbG9zZShwZmQpOwoKICAgIHJldHVybiAwOwp9Cg== | base64 -d > /tmp/prog.c; gcc /tmp/prog.c -o /tmp/prog && /tmp/progCode language: JavaScript (javascript)

では、その手順を説明しましょう：

 bash -c ...: コマンドは新しい Bash シェルを起動し、それに続くコマンドを実行します。これだけでは、従来のセキュリティツールが検出する問題ではありません。

EDRにとっては、ここが難しくなるところです。echo … | base64 -d > /tmp/prog.c は、base64 エンコードされた文字列をデコードし、/tmp/prog.c という名前の C ソースファイルとして保存します。いったん C ソースコードがエンコードされると、正当なトークンの多くが Base64 でエンコードされているため、EDR がこの動作を不審なものとして検出するのは難しいでしょう。もちろん、以下のコマンドで手動でデコードすることもできます：

<base64-encoded-value> | base64 -d

終了すると、gcc /tmp/prog.c -o /tmp/prog コマンドはGCCコンパイラを使用してCソースコード(/tmp/prog.c) をコンパイルし、/tmp/prog という名前の実行バイナリを作成します。tmp/progプログラムは最終的に、eBPFプログラムを含むコンパイル済みバイナリを実行できるようになります。EDRが新しくコンパイルされたバイナリを隔離できる可能性はありますが、もし隔離できたとしても、そもそもそのプログラムがどのようにしてそこに到達したのか、すでにコンテキストが欠けています。そのため、悪意のあるプログラムがホストのエンドポイントでどのように作成されたかを把握することはできません。

EDRが、エンドポイントエージェントの設定の不適切なコンフィギュレーションや、検出エンジンからの誤検出/ネガティブ検出のためにコンパイルされたバイナリを検出できないと仮定すると、この種の攻撃は永遠に検出されない可能性があります。

Sysdigは、複数のデータ・ソースにまたがるイベント・エンリッチメントを通じて、この可視性の喪失という問題を解決します。多くのEDRは、CrowdstrikeのようにKubernetes Auditログをインジェストしていません。これらの従来のツールは、Cloudtrailの監査ログだけでは、ほとんどのリアルタイムの設定変更を理解することもできません。このようなクラウドにおける基本的な可視性の欠如は、セキュリティチームが迅速かつコンテキストに沿った対応をすることを妨げています。

システムコール可視化における必要性の正当化

私たちはもちろん、実際のBPFプログラムがカーネルにロードされるタイミングを検出する必要性を示しました。しかし、全体的なサイバー攻撃の準備態勢を改善するためには、このホストエンドポイント攻撃に関連する侵害の指標をすべて検出する必要があります。潜在的に悪意のあるスクリプトがBase64でエンコードされたとき、敵がプログラムを実行する機会を得る前に検出する必要があります。真のランタイム・セキュリティには、悪意のあるペイロードが実行されたときだけでなく、私たちの環境において望ましくない動作について警告することが必要です。Sysdigは、プロセス、コンテナ、ホスト、Kubernetes、クラウド間のコンテキストを相関させることで、エンコードされたスクリプトがどこから実行されたかを正確に伝え、対応までの時間を改善します。

スクリプトのエンコード方法やシステム内の場所に関係なく、Sysdigは一貫した侵入検知機能を保証します。ユーザは、ホストシステムの特定の動作に合わせて、独自の検出ルールを柔軟に変更または作成することができます。

コマンドラインにシェルスクリプトをエンコードする正当な根拠がない場合、潜在的な敵対者や内部の脅威が悪意のあるプログラムをカーネルに注入する機会を得る前に、事前に対策を講じることができます。

まとめ

BPFバックドアプログラムのインジェクションのようなホストカーネルへの攻撃は、クラウド上で動作するセキュリティマシンに重大なリスクをもたらします。従来の EDR ソリューションは、可視性が限られており、ポリシーに過度に依存しているため、このような脅威に対処するのに適していません。Sysdigのホストとサーバーのディープシステムコールアーキテクチャービューは、WindowsとLinuxシステム全体で、最も巧妙なカーネルレベルの攻撃でさえも検出し、対応することを可能にし、防御の重要なレイヤーを提供します。常に変化する今日のクラウド脅威の状況において、悪意のある侵入者による機密データへのアクセスや、金銭的利益のためにクラウドインフラを悪用することを防ぐには、このレベルの可視性を確保することが不可欠です。