Akamai が推奨する Log4j 脆弱性の緩和策
エグゼクティブサマリー
リモートでコードが実行される深刻な脆弱性（CVE-2021-44228）が Log4jで公開されています。Log4j は、アプリケーション（大手エンタープライズの多くのアプリケーションなど）で広く使用されている、オープンソースのロギングユーティリティです。
この脆弱性により、攻撃者はログメッセージを操作することで、ライブラリを利用するアプリケーションを実行しているシステムから情報を盗み出し、悪性コードを実行することが可能になります。脆弱なサーバーを特定するために インターネット全体をスキャンするサーバー がすでに報告されており、当社の脅威インテリジェンスチームも、この脆弱性を悪用しようとする試みが驚くほど大量に発生していることを確認しています。Log4j は多くの一般的なフレームワークと多くの Java アプリケーションに組み込まれており、その影響は広範囲に及びます。
アプリケーションおよび API セキュリティソリューション、Secure Internet Access Enterprise、Guardicore Segmentation など、Akamai の幅広いセキュリティスイートは、さまざまな方法でこの脆弱性に対処することができます。Log4j を最新バージョン 2.16.0 に更新することを強く推奨します。この脆弱性は急速に拡大しているため、Akamai のチームは、顧客をサポートするための緩和策を引き続き開発し、展開していく予定です。
Log4j の脆弱性とは
2021 年 12 月 9 日、Log4j には認証されていないリモートコードの実行とデータ流出を伴う重大な脆弱性（CVE-2021-44228）があることが報告されました。オープンソースのロギング機能は一般的に使用されているため、これは非常に懸念されている脆弱性です。広く使用されていることに加えて悪用が容易であるため、その影響が非常に大きくなっています。この脆弱性は活発に悪用されており、世界中のセキュリティチームが調査と緩和に取り組んでいます。
攻撃者はマシンを侵害することにより、データを盗み出し、Log4j を実行するソフトウェアをリモートから提供できるようになる可能性があります。これにより、攻撃者はサーバーの内部で任意のコマンドを実行できるようになり、情報や機密データが漏えいするだけでなく、そのサーバーを踏み台として別の攻撃を行う可能性があります。したがって、ネットワークの深い場所にあり、インターネットに直接アクセスすることのないマシンも攻撃対象になり得ます。
Java の開発者は、エラーとデバッグ情報のロギングを容易にするために、Log4j を幅広く使用しています。その結果、Java をベースにしたソフトウェアを提供する製品ベンダーは脆弱になる可能性があります。アプリケーションが直接 Log4j を使用していなくても、多くの一般的なツールやフレームワークは内部的に Log4j を使用しているため、この脆弱性がアプリケーションスタックに潜んでいる可能性があります。
Log4j の脆弱性の深刻度
Akamai は 12 月 9 日に Log4j の脆弱性を悪用しようとする試みを初めて発見しましたが、この脆弱性が何か月も前から悪用されていたことを示す証拠が徐々に見つかっています。この脆弱性が公表されて以来、1 時間あたり約 200 万回の攻撃トラフィックが持続的なペースで発生しており、さまざまな変種があることがわかっています。前代未聞のスピードで変種は進化しています。
これまでに見られた攻撃の半数以上（約 57%）は、Akamai の脅威インテリジェンスデータベースで以前に攻撃者として分類された攻撃者からのものです。パッチが適用されていないシステムの数が非常に多いため、今後数か月にわたって悪用しようとする試みが続くと予想されます。Akamai のセキュリティ調査およびインシデント対応チームは、当社独自の可視性とインテリジェンスを活用して、引き続きインフラと顧客を監視し、保護していきます。
どのような脆弱性であっても、最も重要な対抗策は、感染したシステムにパッチを適用することですが、セキュリティ研究者はそれには時間がかかることを理解しています。多くの場合、組織はどのシステムが脆弱かをまだ可視化できていないと考えられます。そのため、攻撃を受ける領域をできるだけ狭めるために、追加の緩和策を導入する必要があります。
これを支援するための推奨事項がいくつかあります。現時点で Log4j に関連すると見られている攻撃トラフィックの大部分は、Web アプリケーションベースであるため、パッチ適用後に組織が講じることのできる最も効果的な方法は、Akamai の Web アプリケーションおよび API 保護を活用することです。以下をお読みになり、攻撃ベクトルが進化する中でエンタープライズ内においてどのように対処すべきかをご確認ください。
Akamai のアプリおよび API 保護スイートを使用した、Log4j の不正使用の緩和
Akamai は、今回の悪用パターンとその多くの変種から保護できるようにするために、Web Application Firewall（WAF）ルールの更新を続けています。これには、Akamai の Kona Rule Set および Adaptive Security Engine 内のルール 3000014 の更新が含まれます。また Automated Attack Groups を使用している顧客のために、コマンド・インジェクション・グループを更新しました。現在、これらのルールまたは攻撃グループを DENY モードでアクティベートしている顧客のうち、次の保護エンジンとバージョンに該当する場合は、自動インライン保護を受けることができます。
Kona Rule Set — 2019 年 10 月 29 日以降の任意のバージョン
Automated Attack Groups — 任意のバージョン
Adaptive Security Engine — 任意のバージョン
特にインターネットに直接アクセスできるようなリスクの高い環境に置かれているサーバーの多くは、すでに侵害されている可能性があります。侵害されているかどうかを調べる場合は、次のコマンドを使用して悪用が試みられているかどうかを確認できます。
sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns)://'/var/log
Akamai の Web アプリケーションおよび API 保護の詳細については、 こちらをお読みになる か、または こちらからお問い合わせください。
現段階では、WAF 保護は Web サーバーに対して高い効果を持っていますが、侵害につながる可能性のある別の攻撃方法も考慮する必要があります。そのためには、どこから侵入される可能性があるかを可視化し、リスクと拡散を低減するために、マイクロセグメンテーションを採用するのがお勧めです。
Secure Internet Access Enterprise を使用した Log4j 不正使用の検知
Akamai の脅威研究者は、顧客の DNS、プロキシ、シンクホールのデータを調べ、野放しになっている Log4j の脆弱性を利用しようとする攻撃者の異常な挙動を探ってきました。DNS データを見たところ、「jndi:ldap」という文字列を含むドメインに対する DNS クエリがあることを知り驚きました。これらは、ドメイン名に無効な文字が含まれているため、解決されない無効な DNS クエリです。また、既知の悪性ドメインへのトラフィックがシンクホールサーバーにリダイレクトされていることを確認しました。これらのドメインは、脆弱性が存在するサーバーを悪用するために使用される悪性の Java コードをホストしていました。これらはすべて、顧客のネットワーク内で不正使用が行われた可能性を示しています。
Akamai Guardicore Segmentation を使用した、Log4j の不正使用の緩和
Akamai Guardicore Segmentation を使用している顧客は、そのプロセスレベルの可視性を活用して、環境内の脆弱なアプリケーションとセキュリティリスクを特定できます。これにより、ネットワークトラフィックを精密に制御できるため、通常の業務を中断することなく、脆弱なシステムへの攻撃を阻止できます。
脅威の対象は何か：脆弱な Java プロセスと Log4j の不正使用を特定
Log4j が不正使用される可能性をなくすためには、まず悪用される可能性のあるプロセスを特定する必要があります。これには、Akamai Guardicore Segmentation が提供する、プロセスレベルでのネットワークトラフィックの詳細な可視化が必要です。インターネット接続とトラフィックをきめ細かく可視化することで、業務を中断することなく、どのような緩和手順を実行する必要があるかを明確に把握できます。
攻撃の阻止：悪性の IoC と攻撃ベクトルをブロック
脆弱なアプリケーションが特定されたら、必ず対策を講じるようにしてください。パッチを適用している間に、Akamai Guardicore Segmentation は、攻撃のアラート、停止、防止のためのさまざまなオプションを提供します。重要なのは、通常のビジネス機能の中断を最小限からゼロに抑えながら、ネットワーク通信とトラフィックを詳細かつ正確に制御し、攻撃ベクトルをきわめて正確にブロックまたは隔離するソリューションが必要だということです。これには次のようなものが含まれます。
Threat Intelligence Firewall（TIFW）と DNS セキュリティによる自動 IoC ブロック
侵害されたサーバーの完全な隔離
脆弱なアセットへのインバウンドトラフィックとアウトバウンドトラフィックのブロック
Java アプリケーションからインターネットへの発信トラフィックのブロック
さらに、 Guardicore Hunt の顧客は、セキュリティ研究者の専任チームによる環境の監視と調査を継続的に受けることができます。セキュリティリスクに関するアラートと緩和手順の推奨事項は、すぐに送信されます。
Akamai Guardicore Segmentation の詳細については、 こちらをお読みになる か、または こちらからお問い合わせください。
結論
Akamai は引き続き、Log4j が悪用されていないか厳重に監視、調査し、当社の保護と機能をタイムリーに更新しながら、その知見を共有していきます。
