要約

サイバーセキュリティ製品の目標は、既知または未知の脅威からデジタル資産を保護することです。 サイバーセキュリティ製品で「self-protection」という防御メカニズムが欠けているリスク管理は冗談になります。 この記事では、Tetragonと呼ばれる脅威の検出と防止のサイバーセキュリティ製品がリリース後2時間以内にセキュリティ研究者に突破される調査によって作成された事例研究です。 Tetragonは、大人気のネイティブセキュリティ会社によって、何年と数百万ドルがかかって、開発するサイバーセキュリティ製品ですが。 残念ながら、このサイバーセキュリティ製品には「self-protection」がまったくない典型的なケースになりました。

対象読者

• CISO、セキュリティエンジニア、セキュリティ研究者、DFIR（Digital Forensics and Incident Response）チームを含む企業級情報セキュリティ従業者。
• GNU/Linuxサーバーシステム管理者
• Linuxカーネルセキュリティに趣味がある人

物語の始まり

クラウドネイティブセキュリティ会社IsovalentのCTOは、数年開発されたeBPFベースのセキュリティ可観測性と、Runtime Enforcementのソリューションである「Tetragon」 ( WayBackMachine 20220516 )が、オープンソースになりますと2022年5月16日に発表しました。

「Tetragon」が注目された理由、それはLinuxカーネルの脆弱性に対してコンテナエスケープ攻撃が制御されますと主張しました。しかし、「Tetragon」のrule-basedの防止/検知メカニズムはただ防御メカニズムの中でpost-exploitationの段階のみを実装しているようですとセキュリティ研究者のFelix Wilhelm氏がそう質疑して、それから数日の検討でより多くのセキュリティ研究者に注目されました。PaX/GRsecurityチームのメンバーのPawel Wieczorkiewicz氏は2時間調査後、公開エクスプロイトのCVE-2021-22555に基づいて数行のソースコードを追加すると、「Tetragon」の防御メカニズムが突破されました。参照PaX/GRsecurityチーム発表のこのタイプの緩和策が何故失敗が避けられませんと技術的な詳細を明らかに。

何故「Tetragon」(および他のセキュリティ製品)は失敗の運命が避けられません

脆弱性悪用の緩和策は通常、「Pre-exploitation（悪用前）」、「Exploitation（悪用中）」、「Post-exploitation（悪用後）」と3つの段階があります。初期段階の緩和策（例：Pre-exploitation段階に対し）の設計と実装は困難ですが、攻撃者にはこの段階の緩和策を回避することはより困難です（例：PaX/GRsecurity’s KERNSEAL/AUTOSLAB）。一方、後期段階の緩和策（検知メカニズム）の開発は簡単ですが、攻撃者にも回避が簡単です。以前の記事からの緩和評価の概要をご覧りましょう：

典型的なself-protectionのセキュリティ製品（例：EDE/XDR）は通常に「L1：I can win!」という程度にしか達しません。「Tetragon」の防御メカニズムはほぼ同じレベルです、しかしもっとも保護が必要なのはアプリケーション層ではなく、Linuxカーネルへの攻撃からの保護であるため、「Tetragon」の脅威モデルは非常に間違っています。 PaX/ GRsecurityチームから公開された対kprobeのバイパス方法は、どんなhook-basedの実装にも適用できます。つまり、LKM-basedの安全性（ルートキットを含む）はほとんどがこのバイパス方法の影響を受けます。 幸い、VEDのself-protectionはこの攻撃方法の影響を受けません。セキュリティ製品には高度な脅威に対して、ある程度のself-protectionの方法が必要です。さもなければ、何度も「who’s watching the watcher」の問題を繰り返す状況に陥る可能性があります。

何故この方法はVEDに効きません

前回の記事で、複数の攻撃者から攻撃を受ける状況でVSPP（Vault self-protection project）はどれほど重要であるかと説明しました。

高度な脅威保護（ATP）の分野では、このタイプの緩和策は氷山の一角にすぎません。

eBPF/LKMベースのセキュリティ実装の問題

• Linuxカーネルにどんなのセキュリティ緩和策を導入するのはlock issuesなどの副作用があり、より厳重なケースでは悪用可能な競合状態になりという可能性があります。

• 通常の回帰テストでは、いくつかのバグを再現できません。例えば、特別な信号操作の再実装を必要とする状態。

• 性能への影響、セキュリティメカニズムには少なくとも設計の開始時にターゲットシナリオを考慮に入れる必要があります。

• Self-protection

• 脅威モデルについて、悪い脅威モデルは脅威モデルがない場合よりも危険です。この危険さは「design→implementation→testing/QA→delivery - integration→deployment→production」のプロセス全体でバタフライ効果を引き起こし、複雑性の闇に覆隠される可能性があります。敵対相手がスクリプトキッズである場合は、通常的なGNU/Linuxでbest-practicesのCIS/STIGを配置したら、これだけで対処できましょう。敵対相手がThe Hidden Playerである場合（あなたはこのタイプの敵が一生遭えないように祈ります）、Linuxカーネルセキュリティの観点からは、VED（Vault Exploit Defense）でも良い選択肢ではないかもしれません。あなたの選択肢はPaX/GRsecurityしかありません。

結論

クラウドネイティブの普及率が高まっている今、Linuxカーネルセキュリティは避けられない問題になります。成功的なコンテナエスケープの攻撃でクラスタ全体が危険にさらされます。お金、時間、人を大量投入した開発したセキュリティ製品の防御メカニズムは、「研究者」という知らない人（まあ、問題を見つけた彼らに感謝するべき）に2時間突破されましたということを望まなければ、どうやって「適切な」脅威モデルを構築できますかと最初から検討すべきです。

ちなみに、Vault Labsの観点から見ると、eBPFは予防より監視のほうに適しています。 残りはSIEM/SOCチームに任せ、 KISSの原則は、情報セキュリティ管理でも適用されます。