今週は、Log4j2の脆弱性の進化と、その脆弱性から守るために使える便利な緩和策についてご紹介します。
脆弱性の進化
"Log4Shell "の脆弱性は、影響を受けるシステムでイベントをログに記録する際のLog4j2のルックアップの処理方法に致命的なリモートコード実行の脆弱性が発見されたことに始まります。この致命的な脆弱性（CVE-2021-44228）は、CVSSで10点満点中10点を獲得しています。Apache は、Log4j のバージョン 1.x は、JNDIを意図的に有効にする必要があるため、この脆弱性の可能性は低いと述べています。Apache は、この脆弱性に対応した 2.15.0 をリリースしました。
Apache が Log4j2 をバージョン 2.15.0 にアップグレードできなかったユーザーのために緩和策を公開した後、このオープンソースプロジェクトが世間の注目を集めたおかげで、別の脆弱性が発見されました。この脆弱性（CVE-2021-45046）は、当初は10点満点中3.7点のDOS脆弱性でしたが、その後、重要なコード実行の脆弱性であるとも宣言され、CVSS上のスコアは10点満点中9点にまで引き上げられました。Apache は、1.xバージョンには脆弱性がないとし、この2つ目の問題に対処するため、Log4j2ユーザーにバージョン2.16.0へのアップデートを推奨しています。アップグレードできないユーザーには、JNDI Lookupクラスの削除方法を推奨していました。
そして、3つ目の脆弱性が登場しました。12月22日現在、Log4j2バージョン2.16.0のセキュリティページには、リモートコードの実行に関する記述はありませんが、この脆弱性（CVE-2021-45105）は、CVSSで10点満点中7.5点を獲得しており、脆弱なシステムにサービス拒否攻撃を引き起こす可能性があります。Apache は、バージョン2.17.0をリリースし、ユーザーにこの問題に対処するためのアップグレードを推奨しています。また、アップグレードできないユーザーのために、新しい緩和策を公開しています。
注意すべき点は、これらの脆弱性は、発見および緩和の段階で悪用されていたか、悪用されようとしていたということです。360 Netlab Blogによると、複数のマルウェアファミリーがこれらの脆弱性を利用して増殖を試みていたとのことです。脆弱性の悪用に成功した悪意のあるアクターは、コインマイナーを埋め込んだり、ランサムウェアをインストールしたりしていました。これらの報告は、これらの脆弱性を早急に緩和することの重要性を強調しています。
公式の緩和策
Log4j2のセキュリティページによると、コンポーネントを2.17にアップグレードすることで、3つの既知のセキュリティ問題が緩和されるとのことです。また、Log4j2をアップグレードできない方には、Apache 、脆弱なlog4j2-core-*.jarファイルからJNDI Lookupクラスを削除することをお勧めします。しかし、これだけでは、最近発見されたサービス妨害（DOS）の脆弱性（CVE-2021-45105）を緩和するには不十分です。ログ設定のPatternLayoutを変更することで、このDOS脆弱性を緩和することができます。これらの緩和方法の詳細については、この段落の最初にリンクされているApache's Log4j2 security page をお読みください。
脆弱なコンポーネントの発見
脆弱なコンポーネントをスキャンする場合は、jfrog製のLog4j-Toolsを使うことができます。このリポジトリのツールは、コードの一部がLog4jを呼び出して機能するかどうかわからないコードベースで、脆弱なLog4j JNDI Lookupの呼び出しを探すときに便利です。また、ローカルファイルの脆弱性の状態を判断するのにも役立ちます。また、Cisco CX Security LabsによるLog4j usage and exploitation rulesをチェックすることもできます。 、YARAルールでローカルファイルをスキャンし、ファイルに脆弱なJavaクラスが含まれているかどうかを判断します。この方法は、より速い結果を得ることができますが、誤検出が多くなる可能性があります。しかし、これらのルールは、Log4jに依存するコンポーネントを見つけるのにも役立ちます。
mubixのLog4Shell Hashesリポジトリには、 初期のクリティカルなRCE脆弱性(CVE-2021-44228)に対して脆弱なlog4j2-coreファイルのMD5、SHA1、SHA256ハッシュが含まれています。最後に、CISAの脆弱性データベース（CVE-2021-44228にのみ適用）をチェックすると、ベンダー別の脆弱性のあるソフトウェアの包括的なリストを見ることができます。
攻撃からの保護
Log4j2のインストールをアップグレードできない場合や、サーバーでFail2Banを使用している場合は、Jay Gooby の「Fail2Ban regexagainst Log4Shell」がLog4Shellの試みをブロックするのに役立つでしょう。CloudFlareを使用している場合は、そのWAFルールを使用してこれらの攻撃から保護することができます。しかし、CISAのアドバイスによると、Log4j 2.17.0にアップグレードするか、推奨される緩和策を直ちに適用することが推奨されます。また、Log4j2を使用している他のソフトウェアについても、ベンダーの声明を参照することが重要です。ソフトウェアによっては、注意が必要な脆弱なバージョンのLog4jがバンドルされている可能性があるからです。
IOCの発見とスキャン
ログから侵害の兆候を探している場合、この脆弱性を悪用しようとする試みがあったかどうかを判断するのは難しいかもしれません。主な理由は、既知のJNDI攻撃ベクトルを悪用するために送信できるペイロードには様々なものがあるからです。攻撃者は、ペイロード内の文字列を暗号化したり、難読化したり、単純なペイロードを探す際にキャッチしにくくしたりすることができます。そこで役に立つのが、back2root社の「Log4Shell-Rex」です。Log4Shell-Rex は、さまざまな方法でエンコードされた悪意のあるペイロードの可能性にマッチするよう作成された正規表現です。ローカルのログファイルに使用したり、SIEMで使用して結果を照合することができます。ただし、この正規表現で検索すると（他の正規表現でも）、偽陽性や偽陰性が発生する可能性があるので注意が必要です。
また、FullHunt社のLog4j-scanツールは、RCE脆弱性（CVE-2021-44228）の発見とファジングに役立ちます。このツールを使ってWAFのバイパスをテストし、より包括的なスキャン結果を得ることもできます。
このセキュリティダイジェストで有益な情報をお伝えすることで、お客様のお役に立てれば幸いです。皆様のご意見、ご感想をお待ちしております。
コメント