本稿では、パロアルトネットワークスのお客様が、自動化された防止策とベストプラクティスを用いて、深刻度が「緊急」とされるApache Log4jの脆弱性から弊社のNGFWでどのように保護を行うかについて解説します。

本脆弱性によるエクスプロイトの仕組みについてのおさらい

Apache Log4jライブラリは、開発者が自分のアプリケーション内で様々なデータを記録することを可能にします。特定の状況下では、ログに記録されるデータがユーザーの入力に由来することがあります。図のステップ1で示したように、このユーザー入力に特殊文字が含まれている場合、ステップ2のようにJavaメソッドのlookupを呼び出すことができます。このメソッドは、ステップ3のように、攻撃者の外部サーバーにホストされているJavaクラスをダウンロードして実行するようにリダイレクトすることができます。そして悪意のあるJavaクラスが脆弱なlog4jインスタンスを使用している被害サーバー上で実行されます。本脆弱性についての細かな説明や最新情報については、弊社Unit 42チームによる詳細レポートをご覧ください。

Log4jの脆弱性の検出・予防に役立つ自動化された防止策とベストプラクティス

この図が示すように、パロアルトネットワークスは、脅威防御サービスと自動化されたコンテンツの更新を通じ、経時的に進化する同脆弱性に対するシグネチャを積極的にリリースしています。

以下に示す製品・サービスが提供する保護により、弊社のお客様は本脆弱性から保護されています。

• 企業のネットワークセキュリティのためのPA-Seriesハードウェアプラットフォーム
• マルチクラウドのネットワークセキュリティを実現するVM-Series仮想プラットフォーム
• コンテナセキュリティを実現するCN-Seriesコンテナ型プラットフォーム

弊社製品群が提供する数々の相補的なセキュリティ対策とベストプラクティスを組み合わせることで、同脆弱性から組織を保護できます。その方法は以下の通りです。

• 脅威防御セキュリティサブスクリプションは、Threat ID 91991、91994、91995、92001、92007 (Application and Threat content update 8505 以上) を使用し、この攻撃のステップ 1に関連するセッションを自動的にブロックできます。
  注意：この脆弱性に関する状況は急速に変化しており、保護機能を向上させるためのシグネチャの追加を継続して行っているため、お客様には弊社のベストプラクティスに沿って最新のコンテンツアップデートをインストールしていただくことをお勧めします。

自組織がすでに弊社のセキュリティベストプラクティスに従っている場合、この攻撃の複数のステップについて、手動による介入なしに、自動的に保護を受けられます。

なお、この攻撃に対する防御手段は複数用意されていますが、log4jが自社環境内にあるお客様は、各ベンダが指示にしたがい、アップグレードまたは緩和策の適用を行うようにし、脅威防御シグネチャだけにたよらないようにしてください。

脅威対策のベストプラクティス

セキュリティベストプラクティスとともに、以下の例で示すようなセキュリティプロファイルをポリシーに活用することを推奨します。

Log4Shellに関連する脅威IDはすべて「Critical (緊急)」に分類されているため、参照されるVulnerability Protection Profile (脆弱性保護プロファイル) もこの例と同様のものにすべきでしょう。

また、CVE-2021-44228およびCVE-2021-45046を防御するために開発されたすべてのシグネチャが存在することを、[Exceptions (例外)]タブでCVE-IDを照会して確認することができます。

• HTTPS を介した既知の攻撃をブロックするには NGFW でSSL 復号化を有効にする必要があります。
• 攻撃ステップ2をブロックするには出口方向 (Egress) のアプリケーションフィルタリングを使用する必要があります。ldap、rmi-iiopのApp-IDを利用すると、信頼されていないネットワークや予期せぬ接続元との間のすべてのRMI、LDAPをブロックできます。

• 攻撃のステップ3では、外部にホストされている悪意のあるJavaコードにアクセスする必要があります。弊社のAdvanced URL FilteringとDNSセキュリティサービス は、常に新しい、未知/既知の悪意のあるドメイン (Webサイト) を監視し、ブロックして、安全でない外部接続を遮断します。

Security Profiles (セキュリティプロファイル) を以下の例のようにセキュリティポリシーに適用します。またSecurity Profiles Groups (セキュリティプロファイルグループ) を活用することで、設定ミスを最小限に抑えることができます。

Advanced URL Filteringのベストプラクティス

Advanced URL Filteringのプロファイルは、このベストプラクティスの例の内容にあわせる必要があります。

以下のカテゴリをブロックします。

• Malware (マルウェア)
• Command-and-Control (コマンド&コントロール)
• Phishing (フィッシング)
• Grayware (グレイウェア)

上記カテゴリのほかに Newly-Registered-Domain (新たに登録されたドメイン)や High-Risk (高リスク) のカテゴリについてもセキュリティの強化を検討してください。

DNSセキュリティのベストプラクティス

DNSセキュリティはAnti-Spyware Profiles (スパイウェア対策プロファイル) の一部として設定されており、この例に示したベストプラクティスに沿ったものにする必要があります。

IoTセキュリティで脆弱なデバイスを特定する

パロアルトネットワークスのIoT Securityは、ネットワークトラフィックで観測された特定のIoC (侵害指標) や振る舞いに基づき、CVE-2021-44228またはCVE-2021-45046が悪用されているIoTデバイスやIoTデバイス管理サーバーを特定するのに役立ちます。

IoT SecurityがIoTデバイスのアイデンティティと使用しているライブラリを特定したときに、影響を受けるApache Log4jライブラリを実行しているかどうかのアラートを発報させることができます。その場合、IoT Securityポータルに脆弱性の警告が表示されるので、脆弱性のあるライブラリを使用しないソフトウェア修正プログラムを適用してデバイスを更新するなどのさらなる対応が可能になります。

これらのCVEに脆弱なデバイスや、異常な振る舞いを示すデバイスを発見した場合、またはセキュリティアラートを受け取った場合は、以下の対応を検討してください。

• Apache Log4jの最新バージョン (2021-12-21 08:50 本稿翻訳時点では2.17.0以降) を使用するようにパッチを適用します。
• Log4j 2のバージョンを更新できない場合は、以下の緩和策があります。
  • JndiLookup.classをクラスパスから削除してサービスを再起動
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• JNDIの無効化
  • spring.propertiesファイル内で spring.jndi.ignore=true に設定する

デバイスにパッチを当てることができない場合やJNDIを無効にすることができない場合は、以下の手順でリスクを最小限に抑え、ネットワークを安全に保つようにしてください。

• 脆弱性のあるデバイスをインターネットからアクセスできないように設定する。インターネット接続が必要な場合はバックドアを制限するためオープンなポートの数を制限する
• ネットワークセグメントを設定し、脆弱なデバイスがファイアウォールの内側にあり、ゲストや企業のネットワークから隔離されていることを確認する
• あらゆる重要資産を保護するためゼロトラストネットワークポリシーを導入する
• 異常のあるIoTデバイスのトラフィックをブロックする
• 侵害されたデバイスを隔離し、同一ネットワークセグメント内にあるほかの脆弱なデバイスへの攻撃の波及を阻止する

詳細は弊社のIoTセキュリティサイトをご覧ください。

Log4jの脆弱性について

2021年12月9日、ApacheのjavaロギングパッケージであるLog4jに「Critical(緊急)」レベルのリモートコード実行 (RCE) の脆弱性があることが公開されました。このオープンソースのライブラリは企業向けソフトウェアでも広く利用されていることから、業界的に警戒が強まっています。同脆弱性は、CVE番号CVE-2021-44228およびCVE-2021-45046で追跡されています。これはまた「Log4Shell」とも呼ばれています。

認証されていない攻撃者がLog4Shellを悪用すると、脆弱なシステムに悪意のあるソフトウェアをダウンロードさせ、企業ネットワーク内にあるサーバーを自身の制御下に置くことが可能になります。影響を受けるソフトウェアが多数のアプリケーションで利用されていること、この脆弱性が発見されたのがごく最近であること、これらの理由から、オンプレミス・クラウド両環境について、多数のシステムにまだパッチが適用されていません。多くの深刻度の高いRCEエクスプロイトと同様に、パッチが適用されていないシステムを探し出して悪用する目的で、インターネット上でLog4Shellの大規模なスキャン活動が始まっています。そのため、この脆弱性を利用してデバイスをボットネットに参加させ、Cobalt Strikeや暗号通貨のマイニングプログラムなどの追加ペイロードをドロップしようとする試みが確認されたるなど、活発な悪用が継続的に報告されています。

最新のLog4jの分析結果と緩和策、最新の脆弱性更新情報にアクセスするには、引き続き Unit 42ブログやUnit 42によるApache Log4jの脅威に関する最新情報のブリーフィングのオンデマンドリプレイをご確認ください。

Learn how our Palo Alto Networks customers can help protect against the critical Apache Log4j vulnerability with our Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) by using automated preventions and best practices.

Recap: How the Exploit Works

The Apache Log4j library allows for developers to log various data within their applications. In certain circumstances, data being logged can originate from user input. Should this user input contain special characters, as shown in Step 1 of the above example, a Java method lookup can be called, as shown in Step 2. This method can be redirected to download and execute a Java class hosted on an attacker's external server in Step 3. The malicious Java class is then executed on the victim server that uses the vulnerable log4j instance. For a complete breakdown, description and most up-to-date information on the vulnerability, check out the detailed report from our Unit 42 team.

Automated Preventions and Best Practices to Help Detect and Prevent Against the Log4j Vulnerability

As you can see, Palo Alto Networks, through the Threat Prevention service and automated content updates, has been actively releasing signatures throughout the evolving timeline of this vulnerability.

The following Palo Alto Networks protections can help keep customers secure from this vulnerability:

• PA-Series hardware platforms for enterprise network security
• VM-Series virtual platforms for multi-cloud network security
• CN-Series containerized platforms for container security

Multiple complementary security controls across our portfolio, combined with best practices, can help protect organizations against the vulnerability. Here’s how:

• Threat Prevention security subscription can automatically block sessions related to Step 1 of this attack using Threat IDs 91991, 91994, 91995, 92001, 92007 and 92012 (minimum Application and Threat content update 8506). Please note: the situation with this vulnerability is evolving quickly and we recommend that customers install the latest content updates in alignment with our best practices as we continue to add signatures to improve protections.

If your organization is already aligned with our security best practices, you gain automated protection against the multiple steps of this attack with no manual intervention.

Please note, while we provide multiple avenues of protection against this attack, customers with Log4j in their environments should patch or apply workarounds suggested by respective vendors, and not rely only on the Threat Prevention signatures.

Threat Prevention Best Practices

Also in line with our security best practices, we recommend security profiles be leveraged in policies, similar to this example:

The Threat IDs relating to Log4Shell are all classified as Critical, so the referenced Vulnerability Protection Profile should be similar to this example:

You can also confirm all the signatures developed to protect against CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105 are present by querying the CVE-ID in the Exceptions tab.

• SSL decryption should be enabled on the NGFW to block known attacks over HTTPS
• Egress application filtering should be used to block Step 2 of the attack. Use the App-ID for ldap and rmi-iiop to block all RMI and LDAP to or from untrusted networks and unexpected sources.

• Step 3 of the attack requires access to malicious Java code hosted externally. Our Advanced URL Filtering and DNS Security service are constantly monitoring and blocking new, unknown and known malicious domains (websites) to block those unsafe external connections.

Security Profiles should be applied to Security Policies in a fashion similar to the below example. You can also leverage Security Profiles Groups to minimize configuration errors:

Advanced URL Filtering Best Practices

Advanced URL Filtering profiles should align with this best practice example:

In addition to blocking the categories:

• Malware
• Command-and-Control
• Phishing
• Grayware

Consider heightened security for the newly-registered-domain and high-risk categories.

DNS Security Best Practices

DNS Security is configured as part of the Anti-Spyware Profiles and should align with best practices similar to this example:

Identifying Vulnerable Devices with IoT Security

Palo Alto Networks IoT Security helps identify IoT devices and IoT device management servers where CVE-2021-44228, CVE-2021-45046 or CVE-2021-45105 is being exploited based on specific indicators of compromise or behavior observed in network traffic.

When IoT Security determines the identity of an IoT device and specifically the libraries it uses, it can alert you if it's running an affected Apache Log4j library. If so, it displays a vulnerability alert in the IoT Security portal so you can take further action, such as updating the device to a software patch that doesn't use the vulnerable library.

If you find any device that is vulnerable to these CVEs or exhibiting anomalous behavior, or if you receive a security alert, consider taking the following actions:

• Patch the device to use the latest version (2.17.0 or newer) of Apache Log4j.
• If you are unable to update Log4j 2 version, the following mitigations are available:
  • Remove JndiLookup.class from the classpath and restart the service
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Disable JNDI
  • Set spring.jndi.ignore=true in the spring.properties file

If you cannot patch your device or disable JNDI, take the following steps to minimize risk and keep your network safe:

• • Configure the vulnerable device to ensure it's not accessible from the Internet. If Internet connectivity is necessary, limit the number of open ports to limit any backdoors.
  • Configure your network segments to ensure the vulnerable device is behind a firewall and isolated from guest and business networks.
  • Implement zero-trust network policies to protect any critical assets.
  • Block any anomalous IoT device traffic.
  • Quarantine any compromised device to stop attacks from spreading to other vulnerable devices in the same network segment.

Visit this website for more information on Palo Alto Networks IoT Security.

About the Log4j Vulnerability

On Dec. 9, 2021, a critical remote code execution (RCE) vulnerability in the Apache java logging package Log4j was disclosed. Given how frequently this open source library is used in enterprise software, teams are on high alert throughout the industry. The vulnerability is tracked as CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105. It is also known as "Log4Shell."

Unauthenticated attackers can exploit Log4Shell and force a vulnerable system to download malicious software, enabling them to take control of servers located within enterprise networks. The affected software is prevalent in many applications and due to the recent discovery of this vulnerability, many systems, both on-premises and within cloud environments, have yet to be patched. Like with many high severity RCE exploits, massive scanning activity for Log4Shell has begun on the internet with the intent of seeking out and exploiting unpatched systems. As such, there have been ongoing reports of active exploitation in the wild, with recorded attempts to leverage the flaw to connect devices into a botnet and drop additional payloads such as Cobalt Strike and cryptocurrency miners.

To stay on top of the latest Log4j analysis and mitigation, as well as the latest vulnerability updates, please continue checking the Unit 42 blog or view the on-demand replay of the Unit 42 Briefing: Apache Log4j Threat Update.