Log4j の新たな攻撃ベクター WebSocket と3つの脆弱性に関する整理

New Log4j Attack Vector Discovered

2021/12/21 DarkReading — 12月9日に公開された Log4j のリモートコード実行 (RCE) の脆弱性だが、それを狙う攻撃への対応を進めている企業は、いくつかの新たな検討事項を念頭に置いている。Blumira のセキュリティ研究者たちは、内部およびローカルに公開された Log4j アプリケーションに対して、JavaScript による WebSocket 接続を介した、RCE の脆弱性がトリガーされる可能性があることを発見した。

これにより、当初に考えられていたよりも、はるかに大きな攻撃対象が存在することが示唆される。その一方で、Apache Foundationは、この週末に Log4j フレームワークに存在する、3つ目の脆弱性を修正するためのアップデートを公開した。

Blumira の An Analysis of The Log4Shell Alternative Local Trigger によると、攻撃者は JavaScript を実行している任意のサーバーにユーザーを誘い込み、WebSocket 接続を開始させることで、Log4j RCE の欠陥を利用することが可能となる。WebSocket は、多くのモダン・ブラウザが、サーバーとクライアントの間での、双方向通信に使用している通信プロトコルである。

たとえば、WebSocket を使って、ユーザーのシステムやローカル・ネットワークに対して、呼び出しを行うサイトもある。被害者のホストに脆弱性が存在する場合には、LDAP/RMI/DNS/HTTP などのプロトコルを介して、攻撃者が管理する別の Web サイトに呼び出し、Log4j RCE を悪用するための悪意の JavaScript をダウンロードさせられる、と Blumira の CTO であり共同設立者である Matthew Warner は述べている。

彼は、「被害者が脆弱なバージョンの Log4j を使用していて、リクエストされたパスやリクエストの発信元をログアウトしている場合には、Log4j の JNDI Lookup を悪意のホストで起動させてしまう。それ以外には、何も行うことはない。つまり、Log4j の影響は脆弱なサーバーに限らないことになる。脆弱な Log4j のバージョンを利用しているサービスを、自身のマシンやローカル・プライベート・ネットワークで利用しているケースでは、Web サイトを閲覧するだけで脆弱性を誘発する可能性がある。この新しい攻撃経路は、すでに Log4j の推奨される修正手順に従っている組織にとって、問題を複雑にするものではない。しかし、ローカルの開発環境や社内のサーバにパッチを適用することの重要性が強調されている」と述べている。

これまでに発見された3つの脆弱性

Log4j は、Java 環境では普遍的とも言えるロギング・ツールである。12月9日以降、このロギング・フレームワークでは、深刻度の異なる3種類の脆弱性が公開されている。最も深刻なものは、Apache Foundation が12月9日に公開した深刻な RCE 脆弱性 (CVE-2021-44228) である。この脆弱性は、Log4j 2.0-beta9 〜 Log4j 2.14.1 までのバージョンでデフォルトで有効となっている、Java Naming and Directory Interface (JNDI) Lookup 機能に存在するものだ。

攻撃者は、この機能を悪用して、インターネットに接続されたシステム/内部システム/ネットワーク・コンポーネント/仮想マシン/産業用制御システム/SCADA システム/クラウドに接続された資産などの、脆弱なシステムを完全にリモート操作できる。Apache Foundation は 12月10日に、この脆弱性に対処するために、Java 8 ユーザー向けのロギング・フレームワークのアップデート版である、Log4j 2.15.0 をリリースした。

その後には、12月13日に2回目のアップデートである、Log4j 2.16.0 for Java 8 およびLog4j 2.12.2 for Java 7 をリリースした。当初の修正では、特定の条件下でサービス拒否 (DoS) 攻撃 CVE 2021-45046 が生じるため、それに対応するものとなる。

12月18日に、Apache Foundation は、Log4j に存在する3つ目の無限再帰的な脆弱性 (CVE-2021-45105) に対するアップデート Log4j 2.17.0 for Java 8 をリリースし、DoS 攻撃への対応を行った。Gurucul の CEOである Saryu Nayyar は、「無限再帰とは、コードが自分自身を、何度も何度も呼び出すものだ。最終的には、割り当てられたメモリをオーバーフローさせ、定義されたメモリ空間の外に悪意のコードを注入する機能を提供する」と述べている。

CVE 2021-45046 および CVE-2021-45105 は、特定の非デフォルト状態でのみ悪用が可能なものであるため、12月9日に公開された、広範囲に影響をおよぼす脆弱性 CVE-2021-44228 と比較して、深刻度は低いと考えられている。

Google のセキュリティ研究者たちによると、このバグは、Java パッケージの最大級のレポジトリである Maven Central 上の、全パッケージの 8%以上に相当する、35,000個以上の Java パッケージに影響を与えるという。このバグが広く知られ、また、比較的容易に悪用できることから、脅威アクターのコミュニティで広く注目されている。

複数のセキュリティ・ベンダーの報告によると、イラン/中国/トルコなどの国々から、金銭目的の攻撃者や国家に支援された脅威グループが、この欠陥を積極的に利用しようとしているようだ。

こうした動きを受けて、金曜日に米国の CISA は緊急指令を発表し、すべての民間連邦機関に対して、脆弱なシステムの特定/パッチの適用/一連の緩和措置を講じるよう命じた。各省庁は、12月23日までに、この指令の要件を満たす必要がある。

今回の動きは、この脅威への対応を、それぞれの企業がある程度は進めていることを示すものだ。クラウド・セキュリティ・ベンダーの Wiz が実施した分析によると、欠陥が公開されてから10日後に、企業は平均して、脆弱なクラウド・リソースの約 45%にパッチを適用したことが分かった。しかし、その一方で、45% の脆弱なマシンが脅威に対して無防備な状態であることも分かった。これらのシステムのうち、25% が管理者権限を持ち、7% がインターネットに接続されている。

その一方で、今週に Sonatype が発表した、Log4j のダウンロード状況を追跡するダッシュボードによると、12月10日以降において、460万件以上のロギング・ツールのダウンロードが発生した。同社が「最新のダウンロード」と表現したうちの 40% は、脆弱性が存在するバージョンの Log4j だった。

12月18日に「Log4j 脆弱性:WebSocket を介した新たな攻撃ベクターと参入ランサムウェア」という記事をポストしていまして、WebSocket に関しては、そちらの方が詳しく説明しています。後半の3つの脆弱性に関する部分は、あちらこちらに散在している情報を、丁寧にマトメてくれているので、とても助かります。また、Wiz の分析に含まれる数値ですが、いまの状況を端的に表していますね。→ Log4j まとめページ

%d bloggers like this: