背景

ハッカーの時代の初めには、Aleph Oneが1996年にPhrack Issue 49で論文Smashing The Stack For Fun And Profitを発表して以来、記憶の中の「CORE」の支配のための長期的な戦いが繰り広げられてきました。攻撃者はその後の10年間、主にユーザー空間を標的にしていましたが、ユーザーランドの緩和策の人気が高まるにつれて、より多くの攻撃者が“CORE"をカーネルに移行し始めました。私たちはLinuxカーネルセキュリティの暗黒時代を経験してきましたが、「1つのヌルポインタの逆参照がそれらをすべて台無しにする可能性があります」。 PaX/Grsecurity の著者の一人である Brad Spengler disclosed The situation of linux kernel security が Washington Post によって一般に公開され、世界のメガコーパーからいくつかの反応がもたらされた:Google、Red Hat、ARM、Intel は KSPP (Kernel Self-Protection project) と呼ばれるプロジェクトを立ち上げ、この問題を解決する傾向がある。残念なことに、KSPPは現在、サーバー上の理由によりかなり崩壊していますが、Linuxは電力、エネルギー、車両のインターネット、ICS(産業用制御システム)などのより重要なインフラストラクチャに移行しました。しかし、Linuxカーネルのセキュリティの問題は未解決のままです。

問題を解決するのが難しい

• Linuxカーネルの脆弱性に対する修正の連鎖は、アップストリームからLinuxディストリビューションカーネル(プロダクションシステム)まで、現実には誰も本当に「アップストリーム」カーネルをその意味で使用していないため、長すぎます。

*安定したブランチメイターとディストリビューションコミュニティは、脆弱性分析、回帰テスト、および各脆弱性の防御策の把握に苦労しています。一方、セキュリティバックポートの中には、安定版ブランチやディストリビューションカーネルによって見逃されるものもあります。

• Linux カーネルコミュニティは “あいまいさによるセキュリティ” という哲学を掲げており、これは CVE を決して提出しないことを意味します。それでも、2021 年 1 月から 8 月の間に 110 件以上の CVE 番号付きカーネルの脆弱性があります。

• 0日間のビジネスには独自のエコシステムがあり、CVEがあるかどうかは気にしません

当社のソリューション:VED(ボールトエクスプロイトディフェンス)

お客様がこれらの問題を解決できるように、HardenedVaultはVEDと呼ばれるLinuxカーネル0day保護ソリューションを開発しました。脅威モデルは基本的に次のようになります。

• LKM(Linuxカーネルモジュール)として動作し、基本的な実装フレームワークはフックベースであり、AKOやLKRGなどの既存のセキュリティソリューションのフックシステムと互換性があります。

*早い段階でエクスプロイトパスをブロックしてみてください。さもなければ、検出は搾取後の段階でいくつかのオッズを試みるでしょう。

*「ウォッチャーを見る」ことは、サイバーセキュリティにおける哲学的な問題です。VEDは、顧客の本番システムを保護するための最後の防衛線であるため(カーネルが侵害された場合、仮想化、ファームウェア、ハードウェア層が攻撃者の前に存在するため、VEDは最後の意味のある防御線であると言えます)、VEDには自己防衛特性が必要です。

VEDのいくつかの重要な機能:

• wCFIは、VED & syscallsのテキストセクションのバイナリコールサイトをスキャンして、実行時に重要な関数を慎重に調べ、schedule()中にカーネルスタック(呼び出しとretの間)をチェックします。これは、2つのオーバーレイ可能な防御モードをサポートしています。

** 有効範囲は、戻りアドレスの前の命令が呼び出し命令であるかどうか (アドレスかレジスタかポインタか) によってのみ決定されます。この機能により、ROPチェーンを構築するためのコードブロックの任意の借用を防ぐことができます。ROP で使用できる唯一のブロックは、コールと ret の間のブロックで、wCFI をバイパスする可能性があります。

**一部の関数はVEDによってマークされます:1)エクスプロイトライターによって好まれるかもしれません2)直接呼び出すことができます(レジスタやポインタではなくアドレスを介して呼び出す)。たとえば、関数B()がマークされている重要な関数であり、関数A()によってのみ呼び出すことができる場合、VEDはA()''のテキストセクション内の命令を "call *"のように検索してB()''のアドレスを計算し、オフセットで計算します。VEDがA()''のテキストセクションにそのような命令がないと判断した場合、実行はブロックされます。

*重要なデータ構造の保護

• VSPP(VED自己保護プロジェクト)、これは特にあなたの脅威モデルの下で複数の脅威アクターの場合に必要です:

• KERNEXEC (SMEP/PXN)、UDEREF (SMAP/PAN)、信条、MODHELPER などの悪用後のチェック

状況依存型硬化:自動車産業

UPSTREAM SECURITY’‘S GLOBAL AUTOMOTIVE CYBERSECURITY REPORT 2020によると、クラウド、インフォテインメント、ECU/TCU/GWからの攻撃は27.22%、7.69%、5.03%です。

これらのシステムで実行されているLinuxシステムの割合は非常に高いです。Requirements on Security Management for Adaptive Platform (AUTOSAR AP R20-11)には Linux セキュリティ保護の要件があるが、ベンダーにとっての最小要件に近い。一方、車両は野生でより深刻な状況に直面しています。

技術的な詳細は時代と歩調を合わせておらず、最近HardenedVaultによっていくつかの修正/提案が提案されています。

クラウドネイティブセキュリティアーキテクチャ

Kubernetesアーキテクチャは、オンプレミスや仮想マシンを主要なビジネスサポートインフラストラクチャとして使用した場合と比較して、ビジネスの開発と運用を標準化する難しさを大幅に軽減します。これはセキュリティ上の利点であり、主にクラウドネイティブセキュリティアーキテクチャに基づいて3つのコンポーネントに減らすことができます。

*監視と監査のためのファルコベースのコンテナセキュリティ検出システム。Falco’‘‘のドライバを介したデータ収集には、主に2つのモードがあります(ユーザー空間ベースのインストルメンテーションについてはここでは説明しません): 1)約88のシステムコールを監視するトレースポイントベースのLKM(Linuxカーネルモジュール)をデフォルトで使用できます。2) eBPF ベースの実装は、約 81 の syscall を監視できますが、この実装はトレースポイントにも基づいていることに注意してください。エンタープライズユーザーは、Falco フレームワークに基づいてコードとルールを作成してカスタマイズし、ニーズに合わせることができます。

• カーネルコンポーネントを保護するために、新しい Falcon のデプロイメントでは eBPF の使用が増えているため、eBPF も保護する必要があります。カーネル保護の主な目的は、EoP(特権のエスクレーション)とコンテナのエスケープを防ぐことです。このようなアーキテクチャでは、コンテナのエスケープが成功すると、データセキュリティにとって重要な他のPods /コンテナが侵害される可能性があります。

*強化されたELKまたはSIEMログサーバー。

クラウドネイティブのセキュリティアーキテクチャでは、VEDはFalcoとうまく連携するか、ブロック攻撃のログをSIEM/ELKプラットフォームに送信して分析することができます。

実生活のデモ

さて、私たちは最近、公共の脆弱な人々のカップルについて多くの問い合わせを受けたように。VEDがkCTF(CTFコンペティションのためのKubernetesベースのインフラストラクチャ)に見られる人気のあるものをどのように打ち負かすことができるかを実証しました。