2021年12月17日（金）
著者：COUNTER THREAT UNITリサーチチーム
※本記事は、 https://www.secureworks.com/ で公開されている Log4Shell: Easy to Launch the Attack but Hard to Stick the Landing? を翻訳したもので、 2021 年 12 月 17 日執筆時点の見解となります。
2021年12月9日以降、多くの組織がLog4jの脆弱性（リモートコード実行：CVE-2021-44228、別名Log4Shell）による影響の解明および、パッチまたは代替策を使ったリスク緩和作業に追われています。Secureworks® Counter Threat Unit™ (CTU)のリサーチャーが脅威の状況をまとめた最新ブログが12月15日に公表されましたが、その後も状況は刻々と変わっています。
各組織がビジネス保護に奔走する中、攻撃者はここぞとばかりに攻撃を仕掛けています。最初のパッチ（2.15.0）がリリースされて間もなく、大量のスキャン行為が発生しました。攻撃自体は広範囲にわたり活発に試行されていますが、これらがリモートコード実行に発展したケースは限定的です。対照的な例として、2021年はじめにプロキシとログオンに関する脆弱性（ProxyLogon）が公表された際は、その直後に（一部は公表に先立ち）約50件の侵入行為が当社CTU™リサーチャーによって確認されています。
攻撃の流れ
Log4Shellは簡単に悪用できますが、コードを持続的に実行すること（すなわち「攻撃の達成」）は困難です。この攻撃は基本的に「ブラインド」型のため、画面上に結果が表示されません。そのため攻撃者は、攻撃の成功状況を確認するために、外部へのリクエスト送信を行うペイロードを使用します。一例として、多くのDNS名前解決を試す攻撃コードでinteractsh.com、interact.sh、service.exfil.site、dnslog.cn、burpcollaborator.netなどのサービスが使われています。
攻撃が成功すると、攻撃者の制御下にあるサブドメインにリクエストが送信されるため、「この脆弱性は、少なくとも表面上は攻撃可能だ」と認識できます。海戦ゲームのように、標的に「ヒット」したら、さらに高度な攻撃が繰り広げられる仕組みです。
前述のサービスは、Log4j脆弱性の攻撃可否を判断するためだけでなく、データ持ち出しの手段としても使われます。攻撃者は、機密性の高いローカルシステムやクラウドリソースの認証情報（AWSキーなど）を窃取する目的でコマンドを送信します。こうして得られた認証情報を使用しリモート接続することで、標的環境へのアクセスを得るのです。
リモートコード実行に至る経路
「リモートコードの実行」はもう一歩進んだものです。これには、他のシステムコンポーネントや構成設定などの条件も必要になります。
攻撃を達成するには少なくとも3つの要素を連動させる必要があります。すべて揃っていなければリモートコードは実行できません。
- Log4jの脆弱なバージョン（攻撃者のURIの名前解決を行うため）
- バージョンまたは構成が脆弱なJava-core（悪意のあるコードをチェックせずに実行するためだが、これがなくても実行可能）
- 外向きトラフィックのフィルタ不備（強制的な不正リクエストをネットワーク外に送信するため）
1つ目の要素はきわめて重大です。この脆弱性は8年以上にわたって悪用可能な状態であり、Log4jのバージョン2.0-beta9（リリース日：2013年9月9日）からバージョン2.15.0（リリース日：2021年12月6日）までに影響が及びます。このブログ公表時点での最新修正版（12月13日にリリースされたバージョン2.16.0）によって、悪用リスクはひとまず回避できたと見られます。
2つ目の要素は、Log4Shell攻撃後に攻撃者のサーバからダウンロードされた悪意あるJavaコードを実行するための要素です。2018年10月16日より後にリリースされたJava Virtual Machine （JVM 6u211、7u201、8u191、11.0.1など）ではデフォルト設定が「com.sun.jndi.ldap.object.trustURLCodebase = false」となっているため、信頼できないリモートコードへの名前解決やその実行が許可されていません。自組織にインストール済みのJVMが最新の状態に保たれていれば、攻撃リスクはかなり抑えられるでしょう。
しかし、この制限を回避する新たな攻撃方法の出現が、当社CTUリサーチャーの調べで判明しました。Log4Shellの攻撃後にApache Tomcatのサーバークラス「org.apache.naming.factory.BeanFactory」を使えばリモートコードを実行できるのです。アカウントの権限の種類によっても影響度は異なります。権限の低いアカウント配下のプロセスが侵害された場合は、被害範囲が限定的になる可能性があります。
3つ目の要素は外向きトラフィックのフィルタリングです。従来の3層アーキテクチャでWebアプリケーションをデプロイしている組織やプロダクトでは、ログ管理のコンポーネントは適切にセグメント化し、外部へのリクエストを「許可しない」設定にしてください。セグメント単位に分割することで、攻撃の試みに対する応答がネットワーク外に送信されることを防ぎ、攻撃を効果的に阻止できます。
攻撃者の動きを予想する
このブログ公表日現在、数々の大規模攻撃が試みられていますが、標的組織の環境に合わせた内容ではないため、その多くが失敗に終わっています。標的組織をより慎重に見極め、対象環境を入念に模倣しなければ、攻撃の成功確率は上がりません。標的環境で使われているJavaのバージョンや構成、Java以外のシステム設定、現行のセキュリティコントロール製品に合わせて攻撃チェーンをカスタマイズする必要もあります。
Log4Shellに対応した攻撃ツールが出れば、脆弱性の悪用やリモートコード実行がさらに容易になります。攻撃ツールが改良を繰り返せば、高い技術力がない攻撃者であっても攻撃を成功させる可能性が高まります。
結論
今回の脆弱性に対処するためには、修正パッチを適用する、または緩和策を実施することがきわめて重要です。セキュリティ担当者の任務は、攻撃者に先手を打たれる前に自組織のシステムを今すぐ保護することです。ただし、思ったほど心配せずに済むかもしれません。脆弱性が大々的に悪用されたものの、スキルの低い攻撃者による試みは軒並み失敗しています。高いスキルをもつサイバー犯罪集団や国家ぐるみの攻撃グループなどは、成功確率を高めるために攻撃チェーンをさらに巧妙化する可能性があります。パッチ適用の際は、インターネット境界だけでなくローカルネットワーク内であっても実施してください。社内アプリケーションからLog4jの脆弱なバージョンにアクセスできる状態にしておくと、初期アクセスを確立した攻撃者に悪用されてしまいます。
セキュリティ担当者は、現行のセキュリティ製品から発信されるアラートの監視も怠らないようにしましょう。今回の脆弱性は新しい侵入手段となりましたが、侵入後の活動は、現行のセキュリティ製品が対処可能な攻撃手法とあまり変わらないでしょう。
12月15日付のブログで紹介したアドバイスは引き続き有効です。ご参照ください。
- 脆弱なバージョンのLog4jを使用しているシステムを特定し、インターネット接続システムを「優先度：高」に分類する。認証済みスキャナーを利用できる場合は、当該スキャンを実行してチェックするのが一番簡単。
- 脆弱なシステムにパッチを適用する。できない場合は、Apacheが推奨する緩和策を講じる。なお、Apacheは「推奨した緩和策の一部が不十分だった」と表明している。
- 影響を受けた可能性があるシステムに、侵害の証拠がないか調査する。サーバログの検証、ネットワークおよびホストのデータ分析のほか、新規ファイル/不審なファイル作成の痕跡がないかチェックする。さらに、検知アラートの発生を監視し、後続的な活動が行われていないか注視する。
当社のCTUリサーチチーム、インシデント対応チームおよびSecureworks Adversary Group（SwAG)をはじめとする各部門は引き続き連携し、問題の調査および、お客様への直接支援にあたっています。このほか、Taegis™ XDR の対策プログラムを拡充し、数十種類の項目を追加しました。また、脅威ハンティングの情報を取りまとめたノートブックもご利用いただけます。Taegisをご利用の皆様は、Log4jの脆弱性に対するスキャン行為および攻撃発生の履歴をTaegis経由で検知していただけます。 .
Log4jの脆弱性に関する詳細は、当社のFAQをご覧ください。インシデントの緊急対応サポートが必要な場合は、インシデント対応チームまでお問い合わせください。サポート全般については、こちらのお問い合わせフォームにご記入のうえ、送信をお願いします。
