著者：MIKE MCLELLAN
COUNTER THREAT UNITリサーチチーム　DIRECTOR OF INTELLIGENCE

この一週間、多くの組織がLog4jの脆弱性 (CVE-2021-44228、別名Log4Shell) による影響範囲の解明作業に追われました。どの組織でも、以下のような点を確認したことでしょう。

  • 自組織でLog4jが稼働しているか？
  • 稼働している場合、自組織のJavaアプリケーションは影響を受けるのか？
  • 攻撃を受けたアプリケーションはあるのか？

一社だけでなく、あらゆる組織に影響が

Log4jは、膨大な数のJavaアプリケーションの中核要素として、ほぼすべての組織のシステム環境で稼働しています。Secureworks® Counter Threat Unit™ (CTU) リサーチャーの調べでは、当社のお客様全体で、2021年12月9日頃から広範囲にわたるスキャンが実行されていることが判明しています。一部はセキュリティベンダーによるものですが、大半は第三者によって実行されたスキャンでした。動きの速い攻撃者が、脆弱なシステムを物色し始めたためです。12月1日までさかのぼると、脆弱性スキャンの件数はあまり多くなかったことがCloudFlare社の調べで確認されています。

この記事の公表時点では、侵害されたシステムの数は、スキャンされたシステムより少ないことにご注目ください。脆弱性が広範囲に広がっているにもかかわらず、当社のインシデント対応チームの支援件数もごく小数です。攻撃者が今回の脆弱性をプレイブックに反映し始めると、この割合が変わってくる可能性があります。

今からでもパッチ適用を

侵害件数が想定よりも少ないと思われる背景には、いくつかの理由があります。

  • 多くの攻撃者は、この脆弱性の悪用開始に至っていない可能性がある。その場合、状況の急変が見込まれる。すでに当社のCTU™リサーチャーが、国家を後ろ盾とする既知の攻撃グループと見られる侵入後の活動を確認している。　
  • 侵入後の活動は、検知が困難なことがある。可視化できないタイミングや場所では、常に攻撃が発生していると考えて良い。当社リサーチャーの調べで、スキャン行為による大量のトラフィックが検知されている。また、当社の対策プログラムおよびTaegis™ VDRチームは、社内のSwAGチームから最新状況を確認し、日々新たな対策プログラムを考案している。重要な点として、侵入後の活動 (仮想通貨マイニングマルウェア、Webシェル、Cobalt Strikeなど) を検知するために実装済みの対策プログラムが有効であることに変わりはない。確認された侵害件数は少ないながら、当社のインシデント対応チームによって後続的な活動(follow-on activity)も検知されている。やや目新しい (とはいっても、2016年時点で話題になった) 配信方法が使われているものの、投下されたマルウェア自体はごく普通のものだった。
  • リモートコード実行のハードルは、攻撃者が当初想定していたよりも高い可能性がある。システムが脆弱であるか否かを確認できたからといって、追加のコードを当該システム上で実行できるとは限らない。攻撃の成功には、複数の変動要素が関係する。たとえば、稼働中のJavaのバージョン、ログの冗長性、ログ対象となるInputエレメント、さらには、脆弱なサーバからの外向きのトラフィックが許可されているか、などの要素がある。テスト環境やハニーポット上では比較的簡単に攻撃ができても、構成やシステムの依存関係が異なる複雑なエンタープライズ環境では攻撃の成功確率が下がる、という事例はこれが初めてではないだろう。

攻撃対象領域を把握する

社内環境で脆弱なコードを実行している場合は (ほとんどの組織が該当しますが)、まず、該当するコードの実行場所を特定しましょう。そうすると、すぐに「自社のシステムであるにもかかわらず、依存関係が非常に把握しづらい」という不都合な真実が見えてきます。ネットワークに侵入した攻撃者は、脆弱性の隙をついて横展開する可能性があるため、インターネット接続していないシステムも保護すべきです。保護対象となるインフラを「知ること」は常に重要ですが、今週ほどその重要性が浮き彫りになったことはありません。実際の影響レベルにかかわらず、脆弱なアプリケーションのリスク緩和を試みるという作業だけでも、ITやセキュリティ部門にとって膨大な時間がかかるでしょう。

結論

一連の対応に苦戦されている場合は、以下の３つを中心に対策を講じましょう。

  • 脆弱なバージョンのLog4jを使用しているシステムを特定し、インターネット接続システムを「優先度：高」に分類する。認証済みスキャナーを利用できる場合は、当該スキャンを実行してチェックするのが一番簡単。
  • 脆弱なシステムにパッチを適用する。できない場合は、Apacheが推奨する緩和策を講じる。
  • 影響を受けた可能性があるシステムに、侵害の証拠がないか調査する。サーバログの検証、ネットワークおよびホストのデータ分析のほか、新規ファイル/不審なファイル作成の痕跡がないかチェックする。さらに、検知アラートの発生を監視し、後続的な活動が行われていないか注視する。

Log4jの脆弱性に関する詳細は、当社のFAQをご覧ください。脆弱性の特定・対応に関するサポートのご依頼は、こちらまでお問い合わせください。

[PR]提供：セキュアワークス