脆弱性

あれから1年、Log4Shellの現状

発見から1年、Log4Shellの脆弱性はいまだ悪用されています。

Leonid Grustniy
2023年2月22日

2021年12月、Apache Log4jライブラリにLog4Shellの脆弱性（CVE-2021-44228）が発見され大騒ぎになりました。2022年春にはITメディアのトップページに掲載されなくなりましたが、2022年11月にこの脆弱性をサイバー犯罪者が悪用して米国の連邦機関を攻撃し、暗号通貨マイナーをシステムにインストールしたと報じられたことで、再びスポットライトが当たりました。これを受けて、今回はLog4Shellについて、そして脆弱性を過去のものとするには時期尚早である理由と企業のインフラストラクチャを守る方法を解説していきます。

Apache Log4jライブラリとは？

Java SDKでは当初ログ出力をサポートしていなかったため、開発者が独自のソリューションを作成しなければなりませんでした。そのため、正式なJava Logging APIが登場するまでに、多数のバリエーションが存在していました。そのうちの1つが、2001年から開発環境で人気だったオープンソースのJavaライブラリ、Apache Log4jです。これがJavaで唯一のログ出力ソリューションというわけではありませんが、多くの企業で使われていることは確かです。多くの代替ソリューションは、本質的にはライブラリ開発のさまざまな段階で出現した、Log4jの派生物です。

Log4Shellの脆弱性とは？

Log4jライブラリを利用すると、すべてのシステムイベントを自動的にログに出力させることができます。このライブラリでは、Java Naming and Directory Interface（JNDI）データへのアクセスにインターフェイスの標準セットが使用されます。2021年11月、ログ出力中に、たとえばリクエストのヘッダーフィールドやチャットメッセージ、またはWebページの404エラーの記述内などで、イベントによってライブラリにJNDIコマンドを渡して実行できることが判明しました。

この脆弱性により、（追加のセキュリティ対策が有効になっていなければ）少なくとも理論上はサイバー犯罪者が被害者のシステムで何でも好きなことを実行できることになります。実際に多くの事例で、攻撃者は不正なマイナーのインストールやランサムウェア攻撃にLog4Shellを使用しました。もっと変わった使い方としては、標的型攻撃やMiraiボットネットの拡散に加えて、80年代の低音ボイスのシンガー、リック・アストリーのヒット曲『ギヴ・ユー・アップ』（うっとおしいほど頭から離れなくなる曲）を再生するリックロールがあります。

非常に危険でいまだに脅威である理由

Javaは、主要なプログラミング言語の1つであり、小規模企業のサーバーから産業オートメーションシステムやIoTデバイスまで、数多くのバックエンドシステムで使用されています。これらのシステムのほとんどは、さまざまな方法でログ出力を実装しています。長い間、その最も簡単な方法がLog4jライブラリの使用でした。2021年12月にその脆弱性が報告されると、専門家は、今後何年にもわたる大問題になるだろうと確信しました。以下にその理由を挙げます。

Log4jは、幅広い多数のJavaアプリケーションで使用されています。発見されたとき、最大規模のJavaパッケージリポジトリであるMaven Central内の35,000を超えるパッケージ（アーティファクト）にこの脆弱性が存在していました。これは、全パッケージの8%超です。専門家によると、世界中のネットワークの約40%がLog4Shellによって危険にさらされました。
Javaは、一般的なパソコンやサーバー以外に、産業用や医療用を含め、専門的な機器でも使用されています。このような機器でも、Log4jライブラリを使用していることが知られています。
内部でLog4jを使用しているソリューションのエンドユーザーがソフトウェアに脆弱性があることにまったく気づいていない場合は、アップデートを先延ばしにする可能性があります。
Log4jライブラリを使用するソリューションの開発元がずっと前に倒産していたり、市場から撤退していたり、そうでなくてもプログラムのサポートを終了していたりすることも十分あり得ます。エンドユーザーがアップデートしたくても、そのオプションはもはや存在しない可能性があるのです。その上、他のソフトウェアへの切り替えがそれほど簡単ではない場合もあります。
Log4jはオープンソースライブラリです。つまり、プログラマーは自分のプロジェクトでそれをコピー、修正、使用できます。残念ながら、すべての開発者が厳密に使用許諾ルールに従っているわけではなく、また、コードの作成者が常に示されているわけでもありません。したがって、理論的には、公式にはLog4jは存在しないとしているサードパーティのプロジェクトから同じ脆弱性が見つかる可能性があります。
Log4Shellはゼロデイ脆弱性です。つまり、この脆弱性に関する情報が公開される前にはすでにサイバー犯罪者によって悪用されていました。攻撃者が最初に攻撃を仕掛けたのは情報が公開される少なくとも9日前だったことを示す証拠があります。
影響を受けたプログラムには、VMware製品があり、特に人気の仮想デスクトップインフラストラクチャソリューションのVMware Horizonも含まれていました。発見されている攻撃の多くは、まさにこのソフトウェアを通じてシステムに侵入していました。
既にシステム内に侵入者が入り込んでいる事例では、プログラムをアップデートしてもほとんど効果はありません。また、すべての攻撃が侵入直後に開始されるとは限りません。今日までに多くのシステムにバックドアが仕込まれている可能性は十分にあります。

実際の被害

今のところはLog4Shellの悪用による深刻な被害は報告されていません。少なくとも、広く一般に知れ渡る規模の被害はありません。とはいえ、この脆弱性は、世界中の多くのIT担当者がクリスマス休暇を台無しにされたことも含めて、開発者やセキュリティの専門家にとって大きな悩みの種になり、（自社と顧客の両方の）セキュリティに真剣に取り組んでいる企業は、自社システムとソフトウェア内の脆弱性を見つけて除去するためにかなりのコストを費やす結果となりました。

世界で報告されたLog4Shellインシデントは下記のとおりです。

2021年12月20日、ベルギー国防省は同省のインフラストラクチャが脆弱性を利用した攻撃を受けたことを認めました。詳細は開示されませんでした。
2021年12月29日、米国内のある科学機関がLog4Shell経由の攻撃を受けたと報道されました。CrowdStrikeによりますと、APTグループのAquatic Pandaが、パッチを当てていないVMware Horizonを悪用しました。不審なアクティビティは止まりましたが、このインシデントは、本格的なハッカーグループがLog4Shellの脆弱性を利用しようと試みているを示しています。
2021年12月にはまた、ゲームパブリッシャーであるMicrosoftがホストしていないMinecraft: Java Editionのサーバーで、Log4Shellが悪用されたこともニュースになりました。Microsoftは、報道内容を認め、攻撃を実装するのが容易である点について注意を促しました。サイバー犯罪者が、悪意のあるコードを通常のゲーム内チャットで転送するだけで、サーバー側と脆弱性のあるクライアントの両方でコードを実行できてしまったのです。この事例は、犠牲者の視点で見た場合よりも、技術の実装という点で大きな関心を集めています。特定の状況下であれば、内部チャットによって簡単に攻撃を実行できるからです。チャットがゲームの世界だけにとどまらずさまざまな場面で利用されている現状を考えると、これは懸念すべき問題です。多くの企業は顧客とのコミュニケーション方法としてチャットを好んで利用し、多数のフィンテックやその他の分野のアプリケーションでも、チャットで顧客サポートが行われています。
2022年6月、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）と米国沿岸警備隊サイバー部隊（CGCYBER）は、脆弱性が今も盛んに悪用されているという警告を発しました。この警告には、具体的な名前は不明ですが2つの政府機関の内部ネットワークに、サイバー犯罪者が同じVMware Horizonの抜け穴を使用して侵入したことが記載されています。その上、攻撃者は法執行機関に関わる機密データにアクセスしていたことが報告されており、そのデータの規模は130GBにものぼります。
2022年11月、CISAはFBIと共同で、3つめの政府機関に対するLog4Shell攻撃に関する新たな警告を発行しました。攻撃者は、2月にシステムに侵入し、4月に検知されたものの、6月から7月にも活動していました。この期間に攻撃者は、管理者特権を持つアカウントを作成して、正規の管理者のパスワードを変更し、マイニングソフトウェアをサーバーにアップロードしていました。この攻撃はイラン政府が支援するハッカー集団によるものと見られているので、一部の専門家はマイニングは真の動機を隠すための単なる偽装だと考えています。

インフラストラクチャを守る方法

どの企業もLog4Shellの犠牲になる可能性がありますが、多くの場合、それは単に自社のシステムやソフトウェアに脆弱性があることに気づかないことが原因です。自社のシステム、ツール、製品、またはサービスでLog4jライブラリが使用されているかどうかがわからない場合は、徹底したセキュリティ監査を実施した方がよいでしょう。それ以外にできることとしては、攻撃を防ぐためにカスペルスキーの専門家によるヒントに従うことです。

作成したソフトウェアでLog4jを使用している場合は、プロジェクトページで入手可能な最新版のライブラリを使用するようにします。
Apache Logging Servicesのオフィシャルガイドを読み、必要に応じて指示に従います。
Log4jがサードパーティ製品で使用されている場合は、脆弱性を持つソフトウェアをすべてアップデートします。
サーバーおよびワークステーションの脆弱性を悪用する攻撃を検知できる堅牢なセキュリティーソリューションを使用します。
EDRクラスのソリューション、または検知と対応のマネージドサービスのような外部サービスを使用して、企業の境界内の不審な活動を監視します。これによって、初期の段階で攻撃を検知して撲滅できます。