「Log4Shell」や「Logjam」と呼ばれるこの脆弱性が世界中で問題になっています。
これまでのところ、CVE-2021-44228として追跡されているlog4jの脆弱性は、国家の支援を受けたハッカーやランサムウェアグループなど、あらゆる種類の脅威グループによって悪用され、脆弱なシステムにMoneroのマイナーを注入されています。
多くのソフトウェア製品でLog4jの使用が乱用されており、複数のベンダーのアドバイザリーがリリースされています。また、「logback」も無関係ではないようです。
これまでに確認された複数の関連するCVEを要約し、log4jバージョン2.15.0を捨てて2.16.0を選択する十分な理由を示しています。
どのようなCVEを気にする必要がありますか？
2021年12月9日に重要なLog4jのゼロデイに対するPoCエクスプロイトがGitHubに公開されたことから始まりました。
その後、脆弱性が公開され、脆弱なサーバーを狙う攻撃者による大量のスキャンが行われました。
大半のJavaアプリケーションでLog4jが広く使われていることを考えると、Log4Shellはすぐに世界中の企業や政府への攻撃ポイントとなりました。
以下に、知っておくべきCVEを、発生した順に示します。
CVE-2021-44228 [Critical]
「Log4Shell」または「logjam」のオリジナルの脆弱性は、信頼されていないシリアル化のバグです。認証されていない攻撃者にリモートコード実行（RCE）能力を与え、システムの完全な乗っ取りを可能にします。
CVE-2021-44228は、Alibaba Cloud Security TeamのChen Zhaojunが2021年11月24日にApacheに報告したもので、Apache Struts2、Apache Solr、Apache Druid、Apache Flinkなど、複数のApacheフレームワークのデフォルト設定に影響を与えます。
この脆弱性は、log4j-coreコンポーネントに潜んでおり、2.0-beta9から2.14.1までの2.xバージョンに限定されています。Log4Shellの修正はバージョン2.15.0で行われましたが、不完全であると判断されました
脅威情報アナリストのFlorian Roth氏は、防御策の1つとして採用可能なSigmaルールを紹介しています。
CVE-2021-45046 [Low]
深刻度が低いと評価されたこの製品は、サービス拒否（DoS）の欠陥で、スコアはわずか3.7です。この欠陥は、CVE-2021-44228の2.15.0での修正が不完全だったために発生しました。2.15.0に適用された修正により、この欠陥はほぼ解決されましたが、特定の非デフォルト設定ではそうはなりませんでした。
Log4j 2.15.0は、デフォルトでJNDI LDAP検索をlocalhostに制限を行っています。しかし、スレッド・コンテキスト・マップ（MDC）の入力データを制御できる攻撃者は、JNDI Lookupパターンを介して悪意のあるペイロードを作成し、DoS攻撃を引き起こすことができます。これは、$${ctx:loginId} などの Context Lookup、または Thread Context Map パターン (%X、%mdc、または %MDC) を使用して既定外のパターンをレイアウトする既定外の構成に適用されます。
Log4j 2.16.0 では、メッセージ・ルックアップ・パターンのサポートを削除し、JNDI 機能をデフォルトで無効にすることで、この問題を修正しています
CVE-2021-4104 [High]
以前は安全だと思われていましたが、Log4Shellは古いLog4jにも潜んでいることがわかりました。。基本的に、JMSAppenderクラスを使用するLog4j 1.xインスタンスのデフォルト以外の設定も、信頼されていないデシリアライゼーションの脆弱性の影響を受けます。
CVE-2021-44228よりも深刻度は低いですが、それでもこのCVEは、1.xリリースしか存在しないlog4j:log4jおよびorg.apache.log4j:log4jコンポーネントのすべてのバージョンに影響を与えます。これらは使用済みのバージョンであるため、 1.xブランチに対する修正プログラムはどこにも存在せず、 log4j-core 2.16.0にアップグレードする必要があります。
CVE-2021-42550 [Moderate]
Logback ロギングフレームワークに脆弱性があります。
Logbackは「log4j 2.xとは無関係であり、（logbackは）その脆弱性を共有していない」と言われていましたが、CVE-2021-4104がLog4j 1.xにも影響を与えることが発見され、Logbackにも影響を与える可能性があると評価されました。
この脆弱性に対応したLogbackの新しいバージョン、1.3.0-alpha11と1.2.9がリリースされました。
Log4j 2.15は攻撃の余地あり：DNSの流出とRCEの可能性
Log4j 2.15.0には、これまでに発見されたものよりもさらに深刻な脆弱性が含まれている可能性があるため、2.16.0の方がはるかに安全となります。
前述のCVE-2021-45046のため、当初この欠陥による最大の影響はDoSであると思われていましたが、その想定は変化していることがわかりました。
クラウドセキュリティ企業のPraetorian社は、Log4j 2.15.0のバージョンが外部ホストからのDNSベースのデータ流出に悪用される可能性があることを実証し、Apache社と連携して情報公開に向けて取り組んでいます。
Praetorian社のブログ記事で
Log4jのバージョン2.15に適用されるCVE-2021-45046に対応するものです。CVEの説明によると、特定のタイプのパターンレイアウトを使用した場合、この脆弱性によりサービス拒否が発生する可能性があるとのことです。DoSのみであるとしているのは、localhostの許可リストに起因しています。
我々は、この “localhost “allowlistのバイパスを開発し、その詳細をApacheに送りました。少なくとも、CVE-2021-45046に脆弱なシステムは、DoSだけでなく、潜在的に重要な環境変数のDNS流出にも脆弱であることを意味しています。
いずれの場合も、防御者が取るべき行動は明確です。jndiがデフォルトで無効になっている2.16.0に移行することが最も安全な行動であり、我々が顧客に推奨している方法です
Log4J 2.15.0のallowedLdapHostとallowedClassesのチェックをバイパスしてRCEを実現する方法のPoCを紹介します。デシリアライズは通常通り行われます
同様に、GitHub Security LabのAlvaro Muñoz氏も、2.15.0で行われた修正をバイパスしてリモートコード実行に成功したことを報告しています。
余談ですが、デフォルトの設定では影響を受けません。Lookupは、%m{lookups}を指定して有効にするか、CVE-2021-45046のような方法で有効にする必要があります
Log4j 2.15.0に起因する最悪のシナリオはまだ完全には判明していませんが、十分に言えることは、DoSだけに限定されるものではなさそうだということです。
状況が変化し続けているため、組織や開発者は2.16.0にアップグレードすることが推奨されます。また、ApacheのLog4jアドバイザリー・ページを引き続き監視し、最新情報を入手するようにしてください。
Comments