** 本記事は、Log4Shell: No Mass Abuse, But No Respite, What Happened? の翻訳です。最新の情報は英語記事をご覧ください。**
Log4Shell については、大規模な悪用はないものの、沈静化もしていません。Log4Shell の現状をお伝えします。
ソフトウェアの脆弱性が、懸念されていたような惨状を引き起こさないことがあります。そのようなケースでは、それは本当の危機ではなかったということがあり得ます。しかし、2021 年 12 月初旬に、広く使われている Apache Log4J ソフトウェアで Log4Shell の脆弱性が見つかったケースはその例にはあてはまりません。懸念されたような脆弱性の大規模な悪用は起きていないとはいえ、多くのデジタルアプリケーションや製品に深く埋め込まれている Log4Shell のバグは、今後何年にもわたって攻撃の標的にされる可能性が高いのです。
ソフォスは、攻撃者による Log4Shell の脆弱性を悪用した素早い大規模攻撃が回避されたのは、このバグの深刻さがデジタルコミュニティとセキュリティコミュニティを結束させ、人々の行動を喚起したためだと考えています。このようなことは、2000 年の Y2K バグのときにも見られており、今回も人々の結束が大きな成果を生んだようです。
Log4Shell バグの詳細が明らかになるや否や、世界最大かつ最も重要なクラウドサービスやソフトウェアパッケージ、各企業は、セキュリティコミュニティによる脅威情報の共有と実践的ガイダンスに支えられながら、危険を回避するための行動を開始しました。
セキュリティ業界の他の企業と同様、ソフォスも脅威の追跡と監視を続けています。2021 年 12 月 9 日以降、どのような展開があったのか、現在わかっていること、今後予想されることを整理しておきます。
スキャナーのスキャン
Log4J のインスタンスをソフォスがスキャンして収集したテレメトリから、新たに報告された脆弱性の一般的なパターンがわかります。最初の数日間は、 概念実証のためのエクスプロイトが初期段階で開発されて、本格的な攻撃の前に攻撃可能なシステムをオンラインスキャンしているだけであり、スキャンされた攻撃ボリュームは控えめでした。
1 週間のうちにスキャンの検出数が大幅に増加し、12 月 20 日から 12 月 23 日の間に数がピークに達しました。
この数字には、成功したもののまだ特定されていないエクスプロイト、日和見的なクリプトマイナー、国家の支援を受けた攻撃者、標的を見つけて侵入を試みる他の攻撃者が含まれていることは間違いないでしょう。しかし、 12 月下旬のこの時期は、多くのセキュリティ企業が休暇に入る前で、まだ営業しており、積極的に状況を監視していたことも注目すべき点です。
Iつまり、この数字は、善意であれ悪意であれ、非常に多くの人が、潜在的に Log4Shell の問題の影響を受ける可能性があるシステムの数を調べており、他のユーザーがどの程度脅威に晒されているかを測ろうとしていたことを裏付けているに過ぎません。
スキャン数を評価する際に考慮すべきもう一つの要因は、 Log4Shell タイプの欠陥は、Log4J コードが存在するアプリケーションとそのアプリケーションとの統合方法に基づいて、悪用の方法が異なる点です。このため、さまざまなアプリケーションを攻撃するために、多様な方法を試すための冗長なスキャンが大量に発生します。
しかし、12 月下旬から 2022 年 1 月にかけて、攻撃試行数の曲線は平坦になり、減少しています。とはいえ、脅威レベルが低下した訳ではありません。この時期には、実際の攻撃の検出割合が増え、最新のパッチ適用状況を監視している研究者の検出は少なくなっています。
限定的な大規模エクスプロイト
これまでのところ、全体的な攻撃成功件数は予想より少ないままです。その証拠は、最前線の現場でも確認されています。ソフォスの Managed Threat Response (MTR) は、多くのスキャンや Log4Shell エクスプロイトの試行を検出している一方で、 2022 年 1 月初旬までに、 Log4j が最初のエントリポイントと判断された侵入の試行に直面した MTR の顧客はほんの一握りだったと指摘しています。 検出された攻撃の大半はクリプトマイナーでした。
大規模な悪用が抑制されているもう一つの理由は、脆弱な Apache Log4J コードを含む各アプリケーションを攻撃するためには、カスタマイズする必要があるためと考えられます。
その一方で、インターネットに接続しており広く利用されているため、コンポーネントを一つ一つ手動で更新する必要があるアプリケーションもあります。これらは、自動化された方法で、大規模に悪用されています。このようなアプリケーションの例として、 VMware Horizon が挙げられます。Log4Shell を利用した最初の侵入は、ソフォス MTR が目撃した VMware Horizon でした。
一方、 Apache Log4J を使用するあまり一般的ではないアプリケーションも多くありますが、攻撃者によって発見され悪用されるまでに時間がかかります。これらの攻撃は手動で実行され、ゆっくりとしたペースで進行するため、攻撃数が急増することはありませんが、脆弱性が残る組織にとっては重大なリスクとなります。
攻撃手法の地理的特徴の変遷
2021 年 12 月 9 日にバグが報告された時から年末まで、そして 2022 年 1 月の最初の 2 週間のソフォスが収集している各地域のテレメトリでは、攻撃の試行とスキャンのソースに興味深い変動がありました
12 月の地図を見ると、米国、ロシア、中国などの主要国と西ヨーロッパ、ラテンアメリカの国などは概して人口が多く、サイバーセキュリティのスキルを持つ人材が多く存在することが分かります。また、多くの国がデジタルインフラを確立しており、インターネットホスティングの拠点として人気があります。たとえば、地域別の IP ソースデータで米国とドイツの比重が高いのは、Amazon、 Microsoft、 Google などが運営する大規模なデータセンターがそれらの国にあることを反映していると考えられます。
2022 年の初めには、詳細なプロービングとエクスプロイトの痕跡がスキャンで多く検出されるようになり、この図式は劇的に変化します。
2 つの図式の最も顕著な違いは、ロシアと中国がそれ以前まで持っていた支配力が、1 月までに減少しているように見えることです。ソフォスのインテリジェンスから、これは、中国とロシアを拠点とする少数の積極的なクリプトマイナーによる攻撃の試行回数が明らかに減少していることを反映していることがわかります。
脆弱性をスキャンまたは攻撃しているソース IP と、トラフィックを生成しているユーザーの実際の場所には関係がない可能性があることに注意することが重要です。攻撃者の帰属については、コールバックの送信先を確認するのがより適切になります。
コールバックの送信先の地理的特徴
ソース IP データと同様に、ソフォスは 2021 年末と 2022 年初めの Log4Shell に関連するコールバック先を収集しています。時期的な変動は少ないですが、全体的な図式は IP ソースの場所とは大きく異なっています。
このデータには、脆弱な (パッチが適用されていない) デバイスが、Java ペイロードを取得するため、または AWS セキュリティキーやその他の変数などのマシンから抽出された情報をダンプするために通信を試みている世界の上位の送信先が表示されています。
米国が依然としてトップである一方、今回の調査では、インドが 1 位となり、トルコ、ブラジル、さらにはオーストラリアが存在感を示しています。なぜこれらの地域がコールバック先の上位に位置するのか、推測することは困難です。その理由の一つとして、これらの国には脆弱性報奨金制度の参加者が多く、自分たちが感染していることをいち早く組織に知らせることで収入を得ようとする傾向があるのかもしれません。
脅威は依然として存在する
当面の危険を回避できたからと言って、リスクがなくなったわけではありません。
他で指摘されているように、最初の攻撃スキャンの結果、攻撃者が脆弱なターゲットへのアクセスを確保しても、そのアクセスを悪用してマルウェアを配信するなどの行為を実際に行わなかったために、成功した侵入が検出されないままになっている場合があります。
ソフォスは過去に、イランや北朝鮮などの国が、VPN の脆弱性を突いて標的のネットワークにアクセスし、標的がパッチを導入する前にバックドアをインストールし、数か月たってからそのアクセスを攻撃に使用した事例を観察しています。
また、ProxyLogon のパッチが適用された直後、攻撃者は脆弱な Exchange サーバーを狙い、バックドアとなる Web シェルを残して、後の攻撃に利用した例もあります。その例では、Exchange サーバーにパッチを当てるだけでは不十分で、ドロップされたバックドアを削除する必要がありました。
もう一つ例を挙げると、Log4Shell の問題が攻撃される可能性が高いインターネットに接続しているアプリケーションは、今後、パッチが適用されたり、削除されたりする可能性があります。しかし、内部的に使用されている脆弱な未知のシステムは、いつまでたっても発見されず、セキュリティリスクとして残ります。ソフォスのテレメトリによると、ソフォスが保護するエンドポイント上の脆弱な Java Archive ファイル (JAR) の数は変化していないことが分かっています。これらのファイルは、今後、悪意のあるラテラルムーブメントを可能にする格好のツールになる可能性があります。
結論
ソフォスは、Log4Shell の脆弱性を悪用する試みは何年も続き、ペネトレーションテスト担当者や国家的な支援を受ける攻撃者の格好の標的になると考えています。アプリケーションで使用されている場所を特定し、パッチを適用してソフトウェアをアップデートすることの緊急性は、これまでと同様、非常に重要です。
