2021年12月9日、汎用的なJavaパッケージApache Log4j 2にリモートコード実行(RCE)の脆弱性があることが公表されました。この唐突な脆弱性公表以降、エクスプロイトが多数公開され、好機に乗じた攻撃者によるインスタンスへの攻撃も実際に確認されています。この脆弱性は「Log4Shell」という名前で呼ばれています。

Log4jは、あらゆるJavaアプリケーションで使用できるように設計されたロギングフレームワークです。その性質から、Log4jはWebサーバーからビデオゲームにいたるさまざまなJavaプログラムで使用されており、それらのプログラムはすべてこの問題による影響を受けます。分析の結果、私たちはこの脆弱性を、CVSS3.1 スコア 10 の最も高い深刻度であると判断しました。突然公開されたこと、リモートからコード実行が可能という悪用のしやすさ、非常に深刻な影響を与えること、これらの条件により、当該脆弱性は、攻撃者による大規模な悪用にうってつけの脆弱性と言えます。利用されている範囲の広さ、脆弱性の深刻さ、悪用のしやすさなどから、log4j脆弱性は、数年前インターネットセキュリティに深刻な影響を与えたShellshockとも比較されていました。

log4jパッケージをお使いの方は、最新の修正版である2.15.0(2.15.0-rc2)にアップグレードされることを強くお勧めします。脆弱性、エクスプロイト、リスクの詳細については、Unit 42が行ったCVE-2021-44228の分析結果を参照してください。

なお、Prisma Cloudユーザーであれば、この脆弱性の影響を受けたソフトウェアコンポーネントを容易に検出できます。Prisma CloudのIntelligence Stream（IS）は、ベンダ公式フィードからの脆弱性情報を自動的に更新します。Prisma Cloudは、Linuxディストリビューションやアプリケーション メンテナによる更新や分析があれば、それらをすべて反映します。これにより、Prisma Cloudは最新情報に基づいて影響を受けたイメージやホストを正確に検出できます。

また、Prisma Cloudのリサーチチームは、この脆弱性を社内で分析し、この問題に対する Pre-filled CVE (記入済みCVE)を公開しています。CVE-2021-44228は唐突に持ち上がってきたことから、一部のベンダは今現在も影響を受けるバージョンやパッケージを特定する分析を続けています。Intelligence Streamはこれらのベンダによる脆弱性情報公開のつど更新されますが、弊社社内で行った分析にもとづき、影響を受けるすべてのパッケージについて、ただちに脆弱性を検出可能となっています。

ユーザーは、DefenderエージェントがデプロイされているVulnerability Explorerで当該CVEを検索できます。

以下のスクリーンショットは、CVE 2021-44228を「Critical(緊急)」と表示しているコンテナイメージの詳細の例です。

更新 1:12月13日、弊社リサーチチームは「Log4j 1.x リリースについても同様の脆弱性による影響を受ける可能性がある」ことを発見しました。こちらの脆弱性には、CVE-2021-4104が割り当てられました。Log4j 1.xは2015年8月からEOL (end-of-life、製品ライフサイクルの終了)ステータスにあり、修正されることはありません。Intelligence Streamは、こちらのCVEに対応して更新されており、脆弱な1.xインスタンスはPrisma Cloudで検出されます。

更新 2: 12月14日、Log4j 2.15.0でリリースされた修正プログラムが不十分であることが判明しました。CVE-2021-45046が新たに発見された脆弱性に割り当てられました。 私たちの予備分析によると、この脆弱性の影響はサービス拒否（DoS）で、完全なリモートコード実行ではありません。Intelligence StreamのCVE-2021-45046のPre-Filled CVEエントリが更新されており、Prisma Cloudのお客様はこの脆弱性を検出できます。これまでに提案されたLog4Jの設定による緩和策は、この新しい脆弱性の影響緩和には役立ちません。

このリスクは、Log4J 2.16.0にアップグレードすることでのみ完全に解消されます。

更新 3: 12月15日、難読化されたエクスプロイトへのカバレッジを改善したWAASルールを公開いたしました。WAAS ユーザーは、こちらの更新されたルール（下記にも記載）をご利用いただくことをお勧めします。

このリスクを持つホストを環境に問い合わせるには

Prisma CloudのRQL（Resource Query Language）は、影響を受けるリソースについて迅速かつ簡単にクエリを実行する方法を提供します。この場合、ユーザーはPrismaプラットフォームの機能を利用し、脆弱性のあるリソースを分離して、さらにインターネットに直接公開されているリソースがトラフィックを受信しているかどうかを調べ、優先順位をつけることができます。 

特定の脆弱性CVE-2021-44228が存在するクラウドのホストを調べるには:

config from cloud.resource where finding.type = 'Host Vulnerability' AND protection.finding.name = 'CVE-2021-44228'

お使いのクラウドで、この特定の脆弱性CVE-2021-44228を持っており、インターネットに公開されていて、トラフィックを受信しているホストを調べるには:

network from vpc.flow_record where bytes > 0 AND source.resource IN ( resource where finding.type IN ( 'Host Vulnerability' ) AND finding.source IN ( 'Prisma Cloud' ) AND finding.name IN ('CVE-2021-44228') ) AND destination.publicnetwork IN ('Internet IPs', 'Suspicious IPs')

コンテナに対するランタイムプロテクション

実行中のコンテナ型アプリケーションの保護は、Log4Shellに対する多層防御における中核要件です。Prisma Cloudは、お使いのイメージのランタイムモデルを自動的に構築し、その情報を使って、異常なプロセスのデプロイと実行を防止するランタイムポリシーを作成できます。

以下に、脆弱なイメージ用のランタイムポリシーを、[Processes (プロセス)] と [File System (ファイルシステム)] のタブをハイライトして表示します。

このポリシーを適用するとランタイムポリシー違反により外部オブジェクトのダウンロードがブロックされることがわかります。

Web Application and API Security (WAAS) による保護

Prisma Cloudは、脆弱性の影響を受けるコンポーネントを検出するだけでなく、エクスプロイト試行を検出して積極的にブロックすることができます。弊社リサーチャーは、当該の脆弱性エクスプロイト試行を捕捉する特別なルールを作成済みです。このルールを、既知のエクスプロイトや実際の悪用が確認されているエクスプロイトに対してテストした結果、これらのエクスプロイト試行を防止することができました。

最新のコンソールバージョン（21.08.525, Update 2）を実行しているPrisma Cloud Web Application and API Security（WAAS）EnterpriseユーザーおよびComputeユーザーには、仮想パッチが提供されています。WAASユーザーは既存アプリケーションのPrevent上でこの仮想パッチを有効にすることをお勧めします。これを有効にするには、既存アプリケーションを開き、カスタムルールに移動して、仮想パッチを選択します。

これより古いバージョンを使用している場合は、[Defend]、[Custom rules]、[WAAS]、[Add rule] の順に移動すると、これと同じルールをカスタムルールとして作成できます。

このルールの内容には以下の構文を使ってください。

req.path contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.header_names contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.header_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.query_param_names contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.query_param_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.body_param_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.body contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.cookie_names contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.cookie_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.http_method contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.http_scheme contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

or

req.http_version contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|%7d))/

この脆弱性に対して最初に取るべき、かつ真の意味での対策といえるのは、脆弱性のあるすべてのインスタンスをアップデートすることです。ですが、問題の修正後も攻撃者はエクスプロイトペイロードを配信し続けてきますので、WAASはこのような攻撃者を検知・監視し、その接続をドロップできます。

アイデンティティに基づくマイクロセグメンテーションによるネットワークアクセス制限

悪意のあるLDAPサーバなど、未知ないし信頼できないリソースへのネットワークアクセス防止は、Log4Shellからの保護には非常に重要です。マイクロセグメンテーションにより、ワークロードに最小特権でのネットワークアクセスをエンフォースし、未許可の宛先へのアウトバウンドリクエストを拒否することができます。

Prisma Cloud Enterprise Editionの場合、ユーザーはEnforcerエージェントがデプロイされている場所でアイデンティティベースのマイクロセグメンテーションポリシーを適用することになります。

以下のスクリーンショットでは、マイクロセグメンテーションポリシーが設定されており、インターネットからフロントエンド・ポッドへのトラフィックが許可されていますが、その同じポッドが、ポートtcp/80を介したバックエンドリソースとの接続開始のみを許可されていることがわかります。その他のトラフィックは暗黙で拒否されます。

ポリシーにより、攻撃者はインターネットから脆弱なコンテナに到達することはできますが、ポッドが悪意のあるLDAPサーバーとの通信を許可されていないため、攻撃は阻止されます。

また、同じフローデータでも、より詳細に見ることで、何がなぜ起きたのかを理解することができます。

概要

Log4Shellは、近年公開されたなかでも、もっとも深刻な脆弱性の1つです。Log4j 2はさまざまなJavaアプリケーションで広く使用されており、この脆弱性は悪用が容易です。また、この問題に対して脆弱なインスタンスは今後もインターネット上に長く残りつづけるであろうことから、その影響は脆弱性発見後も長期にわたって続くものと推測されます。そこでセキュリティチームは、脆弱なインスタンスをすべて発見し、できるだけ早くこの脆弱性に対するパッチ適用の対策を講じる必要があります。

Prisma Cloudは、お客様環境に存在する脆弱なインスタンスをすべて検出するのに役立つほか、当該脆弱性を抱えているイメージやホストの実行を完全に防止するような設定をすることも可能です。

Prisma CloudによるLog4Jエクスプロイトに対する保護機能（ランタイムおよびWAAS保護機能を含む）の完全な PoC (概念実証)は、以下から確認できます。

On December 9, 2021, a remote code execution vulnerability in the popular Java package Apache Log4j 2 was publicly disclosed. Since the abrupt release of the vulnerability, numerous exploits had been publicly shared and attackers made use of the opportunity to attack instances in the wild. The vulnerability had been dubbed “Log4Shell.”

Log4j is a logging framework designed to be used by any Java application. Due to its nature, it has been used in various Java programs from web servers to video games, all affected by this issue. We analysed this vulnerability and determined that it is of the highest severity possible, with a score of 10 in CVSS 3.1. The vulnerability was abruptly released, and the ease of exploitation and such a severe impact of remote code execution makes it an “ideal” vulnerability for mass exploitation by attackers. Due to the widespread use of log4j, the severity of the vulnerability and its ease of exploitation, the vulnerability had been compared to Shellshock which made a serious impact on internet security a few years ago.

We strongly recommend that users of this package upgrade it to the latest, fixed version, 2.16.0. To read more about the full details of vulnerability, its exploitation and risks please refer to our Unit 42 analysis.

The good news is that Prisma Cloud users can easily detect software components affected by this vulnerability. The Prisma Cloud Intelligence Stream (IS) automatically updates to include the vulnerability information from official vendor feeds. Prisma Cloud reflects any update or analysis by Linux distribution and application maintainers. This allows Prisma Cloud to accurately detect any affected images and hosts based on the most up-to-date information.

In addition, the Prisma Cloud research team also analyzed this vulnerability internally and published a Pre-Filled CVE for this issue. CVE-2021-44228 has blown up quickly, and some vendors are still analyzing it to determine affected versions and packages. The Intelligence Stream will continue to update as vendors release vulnerability information, but thanks to our analysis the vulnerability will be detected in all affected packages immediately.

Users can search for the CVE in Vulnerability Explorer where Defender agents are deployed.

The below screenshot is an example of container image details where CVE 2021-44228 is shown as Critical.

Update 1: On December 13, our research team determined that Log4j 1.x releases may be affected by a similar vulnerability. This vulnerability has been assigned CVE-2021-4104. Log4j 1.x is at end of life status since August 2015, and will not be fixed. The Intelligence Stream has been updated with this CVE and vulnerable 1.x instances are detected in Prisma Cloud.

Update 2: On December 14, it was discovered that the fix released in Log4j 2.15.0 was insufficient. CVE-2021-45046 was assigned for the new vulnerability discovered. Per our preliminary analysis, the impact of this vulnerability is Denial of Service (DoS) but not full remote code execution. The Intelligence Stream has been updated with a Pre-Filled CVE entry for CVE-2021-45046, and Prisma Cloud customers can detect this vulnerability. Previous mitigations suggested by configuring Log4J are not helpful in remediating this new vulnerability.

The risk can only be fully remediated by upgrading to Log4J 2.16.0.

Update 3: On December 15, a refined WAAS rule with improved coverage of obfuscated exploits had been released. WAAS users are encouraged to use the updated rule (also provided below).

Update 4: On December 18, a new vulnerability was discovered in Log4j through 2.16.0, assigned with CVE-2021-45105. Also it is not a variant of the original CVE-2021-44228, it has a similar attack vector, abusing attacker-controlled lookups in logged data. The impact of this vulnerability is Denial of Service (DoS). The Intelligence Stream has been updated with a Pre-Filled CVE entry for CVE-2021-45105, and Prisma Cloud customers can detect this vulnerability.

The risk can only be fully remediated by upgrading to Log4J 2.17.0, 2.12.3 (for Java 7) or 2.3.1 (for Java 6).

Another mitigation strategy suggested in the Log4j security notes is to change the configuration as follows:

• In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

Update 5: On December 17, CVE-2021-45046 CVSS base score changed from 3.7 (low) to 9.10 (high). Additional exploits were found against the Log4j 2.15.0 release that could lead to information leaks, RCE (remote code execution), and LCE (local code execution) attacks. 

In addition to 2.16.0, also 2.12.2 (for Java 7) and 2.3.1 (for Java 6) remediates this issue.

Update 6: On December 28, a new vulnerability for log4j was discovered, and has been assigned with CVE-2021-44832. The impact of this vulnerability is Arbitrary Code Execution, however its severity is lower than Log4Shell, as a modification of the configuration is required.

The Intelligence Stream has been updated with a Pre-Filled CVE entry for CVE-2021-44832, and Prisma Cloud customers can detect this vulnerability. Upgrading to versions 2.17.1 (for Java 8 and later),  2.12.4 (for Java 7), or 2.3.2 (for Java 6) will mitigate this vulnerability.

Query Your Environment for Hosts With This Risk

Prisma Cloud’s RQL (Resource Query Language) provides a quick and easy way to query for resources impacted. In this case users can utilize the Prisma platform's capabilities to isolate assets with vulnerabilities and also prioritize it further by looking for internet exposed assets receiving traffic. 

Know the hosts in your cloud that has the specific vulnerability CVE-2021-44228:

config from cloud.resource where finding.type = 'Host Vulnerability' AND protection.finding.name = 'CVE-2021-44228'

Know the Internet exposed hosts that are receiving traffic in your cloud and have the specific vulnerability CVE-2021-44228:

network from vpc.flow_record where bytes > 0 AND source.resource IN ( resource where finding.type IN ( 'Host Vulnerability' ) AND finding.source IN ( 'Prisma Cloud' ) AND finding.name IN ('CVE-2021-44228') ) AND destination.publicnetwork IN ('Internet IPs', 'Suspicious IPs')

Runtime Protection for Containers

Protecting running containerized applications is a core requirement for defense-in-depth against Log4Shell. Prisma Cloud automatically builds runtime models of your images and uses this information to let you create runtime policies that prevent anomalous processes from being deployed and run.

The runtime policy for a vulnerable image is shown below with the Processes and File System tabs highlighted.

With this policy in place, we can see that the download of an external object is blocked due to a violation of the runtime policy.

Web Application and API Security Protections

Not only does Prisma Cloud detect components affected by the vulnerability, but it can also detect and actively block exploitation attempts. Our researchers crafted a special rule that can catch exploitation attempts of this vulnerability. We tested this rule against known exploits and exploits used in the wild, and it was able to prevent these exploitation attempts.

Two virtual patches are available for Prisma Cloud Web Application and API Security (WAAS) Enterprise users and Compute users running the latest console version (21.08.525, Update 2). We recommend users enable these virtual patch on Prevent in their existing applications by opening them, navigating to custom rules, and selecting the virtual patches (Log4Shell - CVE-2021-45046, Log4Shell - CVE-2021-44228).

Users running older releases can create a custom rule for this rule by navigating to Defend > Custom rules > WAAS > Add rule.

Use the following syntax in the rule content:

req.path contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.header_names contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.header_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.query_param_names contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.query_param_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.body_param_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.body contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.cookie_names contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.cookie_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.http_method contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.http_scheme contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.http_version contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

The first and only true remedy to this vulnerability is updating all vulnerable instances. However, attackers will continue to deliver exploit payloads even long after the issue is fixed, and WAAS can help detect and monitor these attackers and drop their connections.

Identity-Based Microsegmentation to Restrict Network Access

Preventing network access to unknown or untrusted resources, such as a malicious LDAP server, is critical for protecting against Log4Shell. Microsegmentation can enforce least-privileged network access on workloads to deny outbound requests to unauthorized destinations.

With Prisma Cloud Enterprise Edition, users enforce Identity-Based Microsegmentation policy where Enforcer agents are deployed.

In the screenshots below, you can see a microsegmentation policy in place that allows traffic from the Internet to the frontend pod, but it only allows this same pod to initiate connections with the backend resources over the port tcp/80. Other traffic is implicitly denied.

By policy, the attacker is able to reach the vulnerable container from the internet; however, the attack is prevented because the pod is not authorized to communicate with the malicious LDAP server.

And we can view the same flow data in more detail to understand what happened and why.

Summary

Log4Shell is one of the most severe vulnerabilities published in recent years. Log4j 2 is commonly used in Java applications and exploitation of the issue is straightforward. Therefore, we estimate its impact will continue to be seen long after its discovery, as vulnerable instances will continue to be open to the wild. Security teams need to take action to discover all vulnerable instances and patch this vulnerability as soon as possible.

Prisma Cloud can help in detecting all vulnerable instances in your deployments. Prisma Cloud may also be configured to fully prevent running any images or hosts vulnerable to this issue.

A complete proof-of-concept of Prisma Cloud protections for Log4J exploits, including runtime and WAAS protections, can be found below: