Over 40% of Log4j Downloads Are Vulnerable Versions of the Software
2022/03/11 DarkReading — Apache Foundation が、問題となっている Lo4j の脆弱性 CVE-2021-44228 を公表し、その修正プログラムを発行してから３カ月が経過したが、Java パッケージ・リポジトリ Maven Central からダウンロードされる、このロギング・ツールの 10件中4件以上が、依然として既知の脆弱なバージョンのままとなっている。Maven Central の administrator である Sonatype が、いわゆる Log4Shell の欠陥が表面化した直後に立ち上げたダッシュボードによると、2022年2月4日〜3月10日にダウンロードされた Log4j パッケージの 41％ が、Log4j 2.15.0 以前のバージョンであることが判明している。つまり、Log4Shell の欠陥が公開された 2021年12月10日に、Apache Foundation がリリースしたパッチ適用バージョンである。
Log4Shell の公開から僅か数日後には、このロギングツールで新たに発覚した２つの後続の (比較的深刻度の低い) 脆弱性に対処するため、Apache は別の２つのアップデートをリリースしている。
Sonatype のダッシュボードによると、2021年12月10日以降ぶおいて、Log4j のダウンロード数は合計で 3140万件以上となっている。そのうち何件が脆弱性バージョンなのかは不明だが、最新のダウンロード統計からすると、その数は 1000万件に近いか、それを超えている可能性も十分にあるようだ。
Log4j と Layers
なぜ、ユーザー組織や開発者は、既知の脆弱なバージョンの Log4j パッケージをダウンロードするのだろうか？そもそも、それらのバージョンがダウンロード可能なのだろうか？ 特に、この欠陥の広がりと、その悪用が比較的容易であることを考慮すると、そのようなことはあり得ないはずだ。
Qualys の VP of Malware Threat Research である Travis Smith は、「主な原因は、自動化されたビルド・システムにあると思われる。そのような、ビルド・システムは、依存関係のある特定のバージョンのビルドをダウンロードするように設定されている。特にメンテナンスの行き届いていないプロジェクトでは、更新されたソフトウェアとの競合を避けるために、自動的に特定のバージョンをダウンロードすることがある。そのソフトウェアのメンテナが、Log4j を取り巻くニュースに注意を払っていない場合に、彼が管理するアプリケーションに悪用の可能性が取り込まれる」と、こうしたダウンロードが続いている理由を挙げている。
Smith は、「Log4j は、多くの Java アプリケーションにとって不可欠な部分であり、また、深いレイヤーに埋もれているという事実が、多くの組織にとって、この問題の検出と修復を極めて困難にさせている。現時点で、ダウンロードされている脆弱なバージョンの多くは、アップグレードにかかる時間を正当化できない、プロジェクト向けであるという推論が成り立つ」と言う。
Smith によると、脆弱な Log4j のダウンロードの割合が高いことのもう一つの理由は、研究者が防御をテストするためにダウンロードし、敵がエクスプロイトをテストするためにダウンロードするためだという。
Sonatype の Field CTO である Ilkka Turunen は、「もう一つの問題は、多くの組織において、基本的なソフトウェア・サプライチェーン管理が行われていない点にある。適切なソフトウェア・コンフィグレーション分析ツールとソフトウェア部品表がなければ、どのコンポーネントが、どのリリースに流出したのかを把握することが困難だ。Log4j インシデントに関して、多くの組織が困惑した点は、対象となるプロダクション・システムで、どのサードパーティ・コンポーネントがに使用されているのかという認識と、可視性が完全に欠如していることだった」と述べている。
多くのケースにおいて、ユーザー企業は自社のアプリケーションに何が入っているのかを理解していないため、影響を受けるアプリケーションを素早く特定し、アップグレードすることが不可能だ。要するに、多くの企業は、対応を開始する以前の問題として、ソフトウェア・インベントリーを構築しようとしているのだ。
Qualys が、同社のクラウド・セキュリティ・プラットフォームから引き出した最新のデータによると、インターネット上の Log4j インスタンスの約 30%が、依然として悪用されやすい状態にあるという現実が示されている。
Vulcan Cyber の Senior Technical Engineer である Mike Parkin は、「Apache Foundation の Log4J は、無数の場所で使用されており、何百ものパッケージにバンドルされている。その幅広い利用が、そもそも、このような大きな脆弱性を生んだ一因である。また、すべての開発者が同じ方法で、Log4J をパッケージに実装していないことも、このパッチ適用が大きな問題となった理由だ」と述べている。
なぜ脆弱な Log4J が存在するのか？
その一方で、脆弱な Log4j パッケージが、いまだに Maven Central 経由でダウンロード可能なのは、ソフトウェアの依存関係に原因があると、Smith たちは指摘する。多くのソフトウェアが、脆弱なバージョンの Log4j に依存しており、それらを削除するとシステムが壊れる可能性がある。Log4Shell の欠陥が公開された１週間後に Google の研究者たちが行った分析では、Maven Central 上の約 1万7000 の Java パッケージが、この脆弱性を含んでいたことが判明している。このとき Google は、影響を受けたパッケージの 25% について、修正バージョンが利用可能であることを発見した。その後には、さらに多くのパッケージでパッチが適用されていると思われる。
Ilkka Turunen は、「しかし、Maven のリポジトリから脆弱なバージョンを削除することは、高いリスクを伴うことになる。私たちが Maven Central の管理者になったとき、重要な戒律の１つに [ビルドを壊してはならない] というものがあった。自分たちの判断で、脆弱性を取り除こうと主張したくなるときもあるが、コミュニティにとって一番良い判断は、全員が自分たちで判断することなのだ」と述べている。
Sonatype の CTO である Brian Fox は、「Maven Central は、ユーザーがオクタン価を選べるガソリンスタンドというよりは、天然ガスのパイプラインのようなものだ。もし、これらのダウンロードを削除したら、それを探しに来る世界中の全てのビルドは、突然に失敗するだろう」と述べている。
Fox は、「あるプログラマーが、2016年に開発した left-pad というパッケージが揉め事の原因となり、npm JavaScript のレジストリから削除さるという事件があった。このパッケージは、わずか 11行のコードで構成されていたが、その削除により何千もの依存プロジェクトが壊れ、インターネット全体に大きな混乱が引き起こされた。Log4j で同じことをすれば、正当化されない混乱が引き起こされ、利益よりも害が大きくなる可能性がある」と指摘している。
このところ、ロシアとウクライナに関する記事が多くて、忘れられがちという感じがしますが、Log4j に関する興味深い調査結果が出てきました。いまだに、これ程の数の、脆弱なバージョンがダウンロードされていることに驚きました。最近のトピックとしては、2022年3月2日の、「Log4j の問題は続いている：日本での悪用率は世界の 10% に達している」と、「Log4j 調査：回答した組織の 61％ が攻撃を受けている」が興味深い内容となっています。また、2021年12月30日の、「Log4j 問題の 5W1H：現状の正確な認識と将来へ向けたステップ」と、2022年1月4日の、「Log4j が明らかにしたもの：ソフトウェアの依存関係と SBoM のすすめ」は、この問題の本質を整理してくれています。
IoT OT Security News 