ゼロトラストと Log4Shell:どのように考えれば攻撃を防げるのか?

How would zero trust prevent a Log4Shell attack?

2022/01/27 HelpNetSecurity — どのようなリモートコード実行の攻撃であっても、一見すると些細に思える解決策がある。それは、インバウンド・トラフィックが、サーバーの脆弱性を引き起こすパターンと、一致しないようにすることだ。言うのは簡単だが、実行するのは困難である。致命的な深刻さを持つ Log4j の脆弱性を誘発する可能性のあるトラフィック・パターンには、ほぼ無限のバリエーションがある。

そのため、悪意のパターンのインバウンド・トラフィックを検知することは、きわめて困難になる。その一方で、Log4Shell の攻撃サイトから引き起こされるアウトバウンド・トラフィックは容易に検出できる。この種のトラフィックは、特別なプロトコルでランダムなインターネット・サイトをターゲットにしているため、常に疑わしいとみなされ、ゼロトラスト・モデルでは許可されるべきものではない。

ランダムなインターネット・サイトへのアウトバウンド・トラフィックは、他の任意コード実行攻撃が必ずしも持っていない、Log4Shell 攻撃の特徴である。この特徴は、ネットワーク境界を防御するわけではない、ZTNA (zero trust network architecture) セキュリティ・モデルに基づくケースに加えて、城壁のような境界防御のケースにおいても、悪用の防止に役立つはずだ。

Log4Shell 攻撃の結果として、悪用されるサーバーは、攻撃者が所有するインターネット・サイトから、コードをダウンロードしようとする。ダウンロードが成功すると、そのコードがサーバー上で実行され、通常は攻撃者にバックドアを与えることになる。いくつかの疑問が生じる。ランダムなインターネット・サイトへのアクセスが、なぜ成功したのか?また、成功したとしても、開かれたバックドアに、どのようにして攻撃者はアクセスできたのだろう?

ゼロトラストは Log4Shell を無害化する

マイクロ・セグメンテーションを必要とするゼロトラストとは異なり、従来のからの DMZ (Demilitarized Zone) は、組織の外部に面したサーバーを、インターネットのような信頼できない大規模なネットワークから隔離し、また、LAN からも隔離するために最良の方法である。DMZのサーバー上で実行されているサービスは、Web サービスなどのパブリック・サービスを除き、インターネットからのアクセスを禁止するか、厳密に認証する必要がある。

DMZ 内のサーバーが、インターネットにアクセスする正当な理由は限られているため、この種のトラフィックも厳密に制御する必要がある。仮に Log4Shell の脆弱性がサーバーで悪用されたとしても、DMZ からインターネットへの送信トラフィックが禁止されているため、悪意のコードをダウンロード/実行することは不可能だ。

悪用されたサーバーで上で悪意のコードをダウンロードするために、プロトコル LDAP/JNDI が使用されるため、厳密に防御された DMZ であれば Log4Shell 攻撃を防ぐことができる。何かにアクセスするために、あるいは、インターネット上のランダムなサイトにアクセスするために、これらのプロトコルの使用を許可する正当な理由を、特に DMZ において想像することは困難だ。

ゼロトラストは、すでに DMZ で適用されている方法やアプローチを特定し、一般化するものでもある。ゼロトラストでは、たとえば、最小特権主義が要求される。したがってサーバーは、インターネット上の特定のアドレス/ポート/プロトコルを使用して、アップデート・サーバーなどの必要最小限のリソースだけにアクセスできる。サーバーがインターネットにアクセスする理由は限られており、その理由のために作成されたファイアウォール・ルールが変更されることは稀有なため、この方法はセキュリティ・チームに深刻な管理コストを要求しない。

何らかの理由があり、信頼できるリソースへのアクセスが制限されない場合は、プロトコルの施行とコンテンツ・フィルタリングが優先される。最小限の特権とは、必要なプロトコルだけを用いてリソースにアクセスすることも意味する。DMZ から許可されていると想定されるポート (HTTPS) を介して、攻撃者がサーバーを実行したとしても、 Log4j が別のプロトコル (LDAP/JNDI) を使用しているケースでは、悪意の コードのダウンロードは失敗する。必要なプロトコルが使用されていても、コンテンツ・フィルタリングにより、悪意のコードを検出することが可能だ。

ゼロトラストによる RCE 攻撃の防御

リモート・コード実行の攻撃は、悪意のコードを取得するための、インターネット上の外部サーバを必ずしも必要としない。このような場合、コードは正規のリクエストに注入されるが、脆弱性を利用した不正なリクエストもある。ゼロデイ脆弱性を悪用するパターンを検出することは、ほとんどのケースで不可能である。したがって、悪用されたサーバー上で、任意のコードが実行された場合の結果に注目すべきだ。

単純に、悪用された直後のサービス停止が目的であれば、悪用されたサービスの特権レベルのみで実行する、いくとかの方法があるため、攻撃者は成功するだろう。しかし、特権昇格は RCE の後に起こることが極めて多様であり、この脅威を最小限に抑えるためには、適切なパッチ管理プロセスが不可欠となる。

次のステップとしては、横方向への移動が、つまり、組織内の他のサーバーへの感染が試みられるだろう。そのためには、侵害したサーバーを、永続的なアクセスを必要とする Command and Control (C&C) マシンに変更する必要性が生じる。ゼロトラストの原則に従えば、インターネットからアクセスできるのは、DMZ 内のサーバーのパブリック・サービスだけとなる。サーバー上の他のサービスへのアクセスは、通常は許可されていないケースが多く、また、強力な認証を経た場合だけに許可されるケースもある。このような場合、攻撃者は C&C サーバーにアクセスできない。

たとえパブリック・サービス自身が、サーバーの制御に利用できるとしても、ゼロトラスト原則に沿ったマイクロ・セグメンテーションでサーバーが隔離されているなら、盗聴や横移動はできない。データ漏洩は、攻撃が標的化され、悪用されたサービスがデータ漏洩に利用される場合には、依然として深刻な脅威だが、ゼロトラスト原則を適用することで、この問題を局所化することが可能となる。

ローカルではなくグローバルに考える。一つ一つの解決策では効果がない

Log4j 開発者は、アウトバウンド・トラフィックの LDAP/JNDI 接続を制御する組み込みを、解決策として実装した。短期的に見れば、これらの攻撃の影響を受けている人々のためのソリューションとなるが、他のソフトウェアが同様の問題を持っている可能性があるため、長期的に見た根本的な解決にはならない。

このようなセキュリティの問題は、現在のソフトウェア業界のあり方に起因している。短時間の開発サイクル/リリースのプレッシャー/欠落したセキュリティ・マインド/低いテスト・カバレッジ/セキュリティ・テストの欠如などの全てが、セキュリティ問題の原因となる。

ペネトレーション・テスターなどのセキュリティ専門家だけではなく、ハッカーやクラッカーたちも、開発者とは異なる考え方を持っている。開発者は主にハッピー・パスに注目するが、セキュリティ専門家たちはエッジ・ケースやコーナー・ケースに注目し、それを攻略する方法に注目する。ただし、ペネトレーション・テスターとクラッカーの目的は全く異なる。

一般的には、サーバーからのアウトバウンド・トラフィックを制御することは良いアイデアだが、それを全てのアプリケーションに対して、個別に実装することは、おそらく最も効果的な方式ではなく、最も短時間で完了する方式でもない。特に、包括的なソリューションを目指している場合は、このような機能ごとの実装が異なると、異なる問題が発生し、複雑さが増す可能性もある。多種多様なソフトウェア・プロジェクトの開発者が、同様の制御を実装したとしても、かなりの作業が必要になる。

その場合のメンテナーは、大量のソフトウェアを更新する必要があるが、それはリスクであり、特に大規模な組織や IT インフラの場合には、シンプルに不可能となるケースが多い。ZTNA (zero trust network architecture) に従うのであれば、PEP (policy enforcement point) が存在する必要があり、この PEP はサブジェクトとエンタープライズ・リソースとの間の接続を、有効化または終了させる役割を果たす。PEP を使用すると、DMZ からインターネットへの送信接続について、有効/無効の状態を注意深く制御することが可能となる。

リソースの管理を徹底する

少なくとも、セキュリティ・バイ・デザインの時代が到来するまでの解決策は、リソースを厳密に管理することだ。たとえインターネット上に存在するものであっても、すべてをリソースとみなすべきだ。Log4Shell のような脆弱性の影響を避けるためには、リソースにアクセスする方式、リソースから他のリソースへのアクセスの方式、そして一連のアクセス・ルールをネットワーク上で実施する方式などを、最小特権主義などのゼロトラスト原則を用いて制御する必要がある。

インバウンドとアウトバウンドのトラフィック検出の違いから始まり、そもそも DMZ で厳密に防御されていれば Log4Shell 攻撃を防げると言っています。やはり、セグメンテーションは大事です。それらを全て棚上げして、Log4j へのパッチ適用だけに注目しても、また同じことが起きるとも言っています。現実に、「H2 Database Console に Log4Shell と同じ構造の脆弱性:約 6,800 件のアーティファクトに影響」という問題も生じています。ソフトウェアのエコシステムを考えるのと同時に、ゼロトラストについて、もう一歩踏み込んで考えるべき、良い機会なのでしょう。 → Log4j まとめページ

%d bloggers like this: