Public interest in Log4Shell fades but attack surface remains
2022/04/25 BleepingComputer — Apache Log4j ライブラリに存在する、深刻なゼロデイ脆弱性 Log4Shell が発見されてから４ヶ月が経過したが、利用可能なはずの修正プログラムの適用が、依然として大幅に遅れていることを、脅威アナリストたちは警告している。世間の関心と情報セキュリティ・コミュニティの焦点は、より新しい脆弱性の悪用などに移っているが、Log4Shell は引き続き大規模な問題であり、重大なセキュリティ・リスクであることに変わりはない。
前回に Log4Shell の悪用について触れたのは、およそ２ヶ月前の Barracuda レポートが、DDoS や暗号通貨マイニングで活用されるボットネットの存在を強調したときだった。しかし、今日になって Rezilion が発表した最新レポートでは、広範囲にまたがるソフトウェア製品で、大規模な攻撃対象が明らかにされ、悲惨な状況が描かれている。それらは、リモートコード実行という潜在的な影響力と、PoC を利用できる悪用の容易さにより、深刻な問題となっている。
依然として存在し続ける問題とは
Rezilion のレポートによると、Log4Shell の脆弱性 CVE-2021-44228 は、きわめて多様なソフトウェア製品内に存在しており、論理的な説明を行うことは困難であるという。たとえば、Sonatype の Log4j Download Dashboard を見ると、4 月末でも 40%近い割合で、脆弱性のある Log4j バージョンがダウンロードされている状況が分かる (注記：一番上の茶色の部分が vulnerable versions Log4j 2.0-beta9〜2.14.1) 。
以前は、脅威アクターたちだけではなく、セキュリティ研究者やアナリストが調査のためにアクセスしていたが、このように高い割合でダウンロードが続いていることから、これらのシナリオは、いまでは除外されている。
Google の Open Source Insights サービスのデータを調べたところ、Log4j に対して依存関係に持つ 17,840件のオープンソース・パッケージのうち、安定バージョンにアップグレードしたものは 7,140件に過ぎないことが判明した。したがって、そのうちの 60% は Log4Shell に対して脆弱なままである。
Rezilion が Shodan を用いて、オープンソース・コンテナという特定のカテゴリを検索したところ、古いバージョンの Log4j を含む 90,000 以上の、潜在的な脆弱性を持つインターネット向けアプリを発見した。注目すべきは Apache Solr であり、1,657件の公開デプロイメントにおいて、依然として Log4j-core-2.16.0-jar が使用されている。
2022年4月というタイミングで、大幅に遅れてパッチ適用された人気コンテナには、Apache Storm と Apache skywalking-oap があり、また、2022年3月にパッチ適用されたものには WSO2 API Manager がある。最新のコンテナ・バージョンは、すべてのユーザーに採用されていないため、脆弱なインターネット向けのデプロイが、依然として数万件も残っているのは明らかだ。
また、Atlassian Crucible／Apache zeppelin／Bitnami Kafka／Bitnami Spark といった、時代遅れでサポートが終了しているプロダクトにも、Log4j 1.2.17 が使用されているものもある。Log4Shell は、古いバージョンのブランチには影響を与えないという誤解があるが、それは真実ではない。
最後になるが、初めて Log4Shell が発見された Minecraft サーバーを Rezilion が調査したところ、潜在的な脆弱性のあるサーバーが 68,000 件も発見されたとことだ。
さまざまな理由があるはずだ
今日のパッチ適用状況について Rezilion は、適切な脆弱性管理プロセスの欠如や、可視性の低さなどの、いくつかの要因に起因するものだと指摘している。Log4j というソフトウェアの特性により、プロダクション環境での検出は困難であり、また、サードパーティのソフトウェアを通じて使用していることに、必ずしも気づいていない組織も多いはずだ。
要約すると、それを使っているかどうかわからない、どのバージョンを使っているかわからない、どのバージョンを使えば安全かわからないということだ。さらに言えば、運用の安定性を優先するために、利用可能な最新のソフトウェア・アップデートを取得しないような粒度で、ソフトウェアのアップデート・ポリシーをコンテナ型環境に使用するなどの、さまざまな特殊なケースも存在するのだ。
古い欠陥が残っている
脆弱性の積極的な悪用について、CISA の速報で繰り返し強調されているように、ハッカーたちにとって、標的となるデバイスに侵入できるのであれば、脆弱性の古さは問題にならない。10年以上前のバグが、いまだに悪用されているケースもよくあることで、このような行為を継続させるための候補として、Log4Shell は格好の存在に見える。
Log4Shell が発見され、パッチが適用されてから４ヶ月が経過しが、いまでも、それは存在している。したがって、環境のスキャンや、使用しているバージョンの確認、そして、緊急アップグレード計画の策定を進める必要がある。
脆弱なバージョンを使用していたことが判明した場合には、侵害されていると想定すべきである。そして、継続的に悪意の活動をスキャンし、仕掛けられたバックドアを根絶するというアクションを継続してほしい。
Log4j を使っているのは確かだけど、それが何処で動いているのか分からないところに、この問題の本質があるのでしょう。また、Log4j を取り込んでいるコンポーネントなどとの依存関係も、はっきりとは把握できていないケースが多いようです。文中で参照されている、Sonatype のレポートを参照する記事には、「対応を開始する以前の問題として、ソフトウェア・インベントリーを構築しようとしている」と記されています。ただし、それがレガシー・システムの出るような場合に、費用対効果の問題も生じてきます。いろいろと考えなければならないことを、指摘してくれるのが、この Log4j 問題です。 → Log4j まとめページ
IoT OT Security News 