Apache Log4j アプリの 30％以上が脆弱なライブラリを使用している – Veracode 調査

Over 30% of Log4J apps use a vulnerable version of the library

2023/12/10 BleepingComputer — Apache Log4j ライブラリの一連の脆弱性に対しては、２年以上も前からパッチがリリースされているが、それらを使用するアプリケーションの約 38% では、依然として脆弱なバージョンが用いられていることが判明した。それらの脆弱性の中には、深刻度が評価最大である、Log4Shell 脆弱性 CVE-2021-44228 も含まれている。

Log4Shell は、認証前のリモート・コード実行 (RCE：Remote Code Execution) の脆弱性であり、Log4j 2.0-beta9／2.15.0 までのシステムにおいて、悪用に成功した攻撃者に不正な制御を許すものだ。

この脆弱性は、2021年12月10日にアクティブに悪用されるゼロデイとして発見され、その広範な影響力／悪用の容易さ／甚大な影響などにより、多くの脅威アクターたちの格好の標的となった。

この状況を受けて、プロジェクトの保守担当者やシステム管理者に警告を通知する、大規模なキャンペーンが実施された。しかし、大量の警告にもかかわらず、パッチが利用可能になった後も、かなりの数の組織が脆弱なバージョンを使い続けた。

この脆弱性が公表され、修正パッチがリリースされてから２年が経過したが、いまだに 多数の脆弱性 Log4Shell が残存している。

アプリケーション・セキュリティ企業である Veracode は、8月15日〜11月15日の間に収集したデータに基づくレポートを発表した。

強固になった攻撃対象

90日間にわたって Veracode が収集したデータは、Log4j 1.1〜3.0.0-alpha1 に依存する、38,278 のアプリケーションを利用している、3,866 の組織からのものだ。

これらのアプリケーションのうち、2.8% は Log4J の亜種である 2.0-beta9〜2.15.0 を使用しているが、それらは Log4Shell に対して直接的に脆弱であることが判明している。

また、別の 3.8% は Log4j 2.17.0 を使用しており、脆弱性 Log4Shell は存在しないが、バージョン 2.17.1 で修正されたリモート・コード実行の脆弱性である、CVE-2021-44832 の影響を受けやすいことが判明した。

さらに、32％ のアプリケーションは、2015年8月以降にサポートが終了している、Log4j 1.2.x を使用していた。これらのバージョンは、CVE-2022-23307／CVE-2022-23305／CVE-2022-23302 を含む、2022年までに公表された複数の深刻な脆弱性に対して脆弱である。

合計すると、この期間で可視化されたアプリの約 38％が、安全ではない Log4j バージョンを使用していることになる。

この値は、Sonatype の専門家が、 Log4j ダッシュボードで報告している値と近似している。Sonatype の報告では、過去１週間にダウンロードされたライブラリのうち、25％ が脆弱なバージョンなものと示されている。

不十分なセキュリティ対策

こうした旧バージョンのライブラリの継続的な使用は、継続的な問題を示している。それについて Veracode は、開発者たちが不必要な複雑化を避けたがるためだと述べている。

Veracode の調査結果によると、開発者の 79％ は機能の破壊を避けるために、コードベースに最初に組み込まれたサードパーティのライブラリを、その後に更新しないという。

オープンソース・ライブラリ更新の 65％が、機能的な問題を引き起こす可能性の低い、マイナーな変更や修正だとされるが、それであっても状況は変わらないようだ。

さらに、この調査では、深刻度の高い脆弱性に対処するために、65日以上かかるプロジェクトが 50％ もあることが示された。人員不足の場合には、バックログにある半分を修正するのに、通常の 13.7倍の時間がかかり、情報不足の場合には、50％を処理するのに７ヶ月以上かかるという。

Veracode のデータによると、残念なことに Log4Shell は、セキュリティ業界の多くの人々が期待したような警鐘にはならなかったようだ。

それどころか、Log4j は 30% 以上の確率で、継続的なリスクであり続けている。そして攻撃者たちは、特定のターゲットを侵害する際の手段の１つとして、この脆弱性を悪用し続けている可能性も高い。

ユーザー企業に対して推奨されるのは、自社の環境をスキャンして、使用中のオープンソース・ライブラリのバージョンを確認し、それら全てに対して緊急アップグレード計画を策定することである。

Log4j の脆弱性から、もう２年も経ったのですね。懐かしがるべきものではありませんが、時間の流れの速さを感じます。しかし、各種の調査によると、いまの時点で利用されている Log4j の 30％ 近くが、依然として脆弱なままであるとのことです。なんというか、厳しい現実が突きつけられますね。 よろしければ、Log4j で検索も、ご利用ください。