Log4j 問題は収束していない:セキュリティというよりインベントリの問題?

Log4j Attack Surface Remains Massive

2022/04/27 DarkReading — Apache Log4j logging toolの、リモートコード実行の脆弱性が公開されて4ヶ月以上が経ったが、そを悪用しようとする攻撃者は、依然として膨大な数のターゲットを手にしている。検索エンジン Shodan を用いて行った、Rezilion による最新のスキャンでは、このソフトウェアの脆弱なバージョンをインターネット上に公開している、9万台以上ものサーバーが発見されている。ただし、この数字は、オープンソース・ソフトウェアを実行して、一般に公開されているサーバーのみを対象としているため、攻撃者のターゲットの一部に過ぎないと、Rezilion は考えている。

組織の内部に配置されたネットワーク・サーバーや、プロプライエタリなアプリを実行しているサーバーを足していくと、この脆弱性を持つターゲットの総数は増大する可能性があるとされる。今週に発表された Rezilion の調査結果レポートでは、同社の結論を後押しするような、その他のデータポイントも指摘されている。

そのうちの1つは、Google Open Source Insights という、オープンソース・スキャン・サービスのデータであり、この欠陥の影響を受けた合計で 17,840 パッケージのうち、Log4Shell パッチが適用された Java パッケージは、僅か 7,140 であることが示されている。また、Sonatype によるデータでは、2022年4月20日の時点において、Maven Central Java アプリ・リポジトリからダウンロードされている、Log4j バージョンの 36% が依然として脆弱なバージョンであり、この数字が2月から変化していないことも分かっている。

Rezilion の Director of Vulnerability Research である Yotam Perkal は、「他の有名な脆弱性と同様に、4ヶ月が経過した今でも、Log4Shell を対象とする攻撃の可能性は随所に存在している。一般にアクセスが可能な9万台の脆弱なサーバーは、実際の攻撃対象面と比較すれば氷山の一角に過ぎないだろう」と述べている。

2021年12月9日に Apache Foundation は、Log4Shell の脆弱性 CVE-2021-44228 を修正/更新した。この欠陥は、事実上、すべての Java アプリケーション環境に存在し、悪用は容易だと考えられており、脆弱なシステムを完全に制御される可能性が高いとされている。数多くのセキュリティ専門家は、この脆弱性について、近年で最も危険なもの1つであると考えており、更新/修正されたバージョンを、可能な限り早急にインストールするよう組織に促している。

しかし、この欠陥が悪用され、大規模な情報漏えいが発生したという事例は、これまでのところ殆ど報告されていない。しかし、多くのケースにおいて、この欠陥を悪用する攻撃者は企業ネットワークへのアクセスを済ませており、攻撃の好機を待っている状況にあるとも危惧されている。

この欠陥についてセキュリティ専門家たちは、その遍在性と検出の難しさ (欠陥を含む Java ファイルがアプリの奥深くに埋もれている) を、改善が進まない原因として指摘している。

Rezilion によると、ソフトウェア・コンポーネントか可視化できていない状況と、脆弱なサードパーティ製ソフトウェアに含まれる脆弱な Log4j を、知らずしらずに使っている状況が問題だとされる。また、Log4j の欠陥は、実稼働環境での検出が困難であることも判明している。

氷山の一角?

Rezilion の Yotam Perkal によると、Shodan 検索で見つけた9万台の脆弱なサーバーには、Log4j の旧バージョンであるため潜在的に脆弱もの、および、以前に脆弱なバージョンを使用していた Log4j コンポーネント (侵害済みの可能性)、脆弱な Log4j バージョンを公開している Minecraft があるという。

また Perkal は、「おそらく内部ネットワーク上で Log4j を実行しているサーバーもあるが、それらは Shodan を介して検索できない。また、Log4j を取り込んだ、プロプライエタリなアプリケーションや、商用アプリケーションも存在すると想定する必要がある」と述べている。

すべてのオープンソース・コンポーネントにおいて、Log4j 以外の脆弱性が相当数含まれていることも重要である。それらの脆弱性の半分は、2020年以前に公開されたものだが最新のバージョンに存在しているものもある。Rezilion の分析によると、オープンソース・コンポーネントにパッチが適用された後に、Docker Hub などのプラットフォームを介して、パッチ適用バージョンが利用可能になるまで、100日以上を必要とするケースが多かったという。

Logpoint の Head of Professional Services である Nicolai Thorndahl は、数多くのアプリケーションのロギングで Log4j は使用されているが、その存在をソフトウェア・プロバイダーが必ずしも公開していないため、この欠陥の検出は継続する課題になると述べている。

彼は、「数多くのアプリケーションにおいて、サポートが終了した古いバージョンの Log4j が使用されているため、脆弱性は存在し続ける。Log4j を使用している場所がわかるほどの、詳細な構成管理データベースを持っている企業は、あったとしてもごく僅かだ。現時点において、この不具合を悪用する攻撃はほとんど見られないが、今後は増えると予想している。以前にも他の脆弱性が引き起こしたように、たとえば1年後に企業が侵入され、Log4j の脆弱性が悪用されたことを検知し、長期間にわたって不正アクセスされていたというインシデントが公表されるだろう」と述べている。

4月25日に「Log4Shell の現状調査:いまだに山積する問題と解決できない理由とは?」という記事をポストしましたが、今回と同様に Rezilion’s Log4j Blindspots Research Analysis がベースになっているようです。先ほどダウンロードして、さっと眺めてみましたが、多用されていると思われる Java パッケージを、各種のツールでチェック/スキャンした結果などが提供されています。ただし、それがシステム内の何処にあるのかが分からないというのが、いまの問題なのでしょう。Log4j がキッカケとなり、もっとソフトウェア・インベントリが注目を集めるようになると良いですね。

%d bloggers like this: