Amazon Web Services ブログ

Log4j 脆弱性に対する AWS セキュリティサービスを利用した保護、検知、対応

*本投稿は原文 (2021年12月23日更新版) の日本語訳です

概要

この投稿では、最近公開された Log4j の脆弱性に対応しているお客様を支援するためのガイダンスを提供します。ここでは、脆弱性のリスクを制限するためにできること、問題の影響を受けやすいかどうかを特定する方法、適切なパッチでインフラストラクチャを更新するためにできることについて説明します。

Log4j の脆弱性（CVE-2021-44228、CVE-2021-45046）は、ユビキタスロギングプラットフォームの Apache Log4j における重大な脆弱性（CVSS 3.1 基本値 10.0）です。この脆弱性により、攻撃者は脆弱なプラットフォームでリモートでコードを実行する可能性があります。バージョン 2.0-beta-9 と 2.15.0 の間の Log4j のバージョン 2 が影響を受けます。

この脆弱性は、Java プログラムによって使用される Java Naming and Directory Interface (JNDI) を使用します。JNDI は、通常、ディレクトリ (この脆弱性の場合は LDAP ディレクトリ) を介してデータを検索します。

下の図 1 は、Log4j JNDI 攻撃フローを示しています。

Figure 1. Log4j attack progression

図 1. Log4j 攻撃の進行. 出典:スイス政府のコンピューター緊急対応チーム (GovCert) GovCert.ch

即時対応が必要な場合は、このブログに従い、Log4j 2.0以降を使用して実行している JVM にホットパッチを適用するように設計されたツールを使用してください。AWS の最高情報セキュリティ責任者である Steve Schmidt も、このホットパッチについて自身のブログ記事にて述べています。

保護

お客様は複数の AWS サービスを使用して、Log4j の脆弱性によるリスク/露出を抑えることができます。お客様は、階層化された管理策アプローチを構築したり、露出を制限するために以下に示す管理策を選択できます。

AWS WAF

お客様は AWS WAF の AWS マネージドルールに従って AWS Web Application Firewall を使用し、Amazon CloudFront ディストリビューション、Amazon API Gateway REST API、Application Load Balancer、または AWS AppSync GraphQL API リソースを保護することができます。

  • AWSManagedRulesknownBadInputsRuleSet 特に、Log4j の脆弱性の存在についてリクエストを検査するのに役立つ Log4JRCE ルールを設定します。パターンの例としては、${jndi:ldap://example.com/} などがあります。
  • AWSManagedRulesAnonymousIpList 特に、AnonymouousIPList は、クライアント情報を匿名化することで知られるアクセス元の IP アドレスを検査するのに役立つ ルールです。
  • AWSManagedRulesCommonRuleSet 特に、 sizeRestrictions_BODY ルールは、リクエスト本文のサイズが最大 8 KB (8,192 バイト) であることを検証します。

AWS WAF Classic を使用しているお客様は、AWS WAFに移行するか、カスタム正規表現パターンを作成する必要があります。

複数のAWSアカウントを持つお客様は、これらの手順に従って AWS Firewall Manager を使用して AWS WAF ルールを AWS 組織全体に一元的に展開できます。

Amazon Route 53 Resolver DNS Firewall

AWS マネージドドメインリストに従って Route 53 Resolver DNS Firewall を使用すれば、アウトバウンドのパブリック DNS 名前解決時にリソースを保護するのに役立ちます。AWSManagedDomainsMalwareDomainList でドメインをブロックするように設定されたルールに Route 53 Resolver DNS Firewall を関連付けることをお勧めします。このリストは、Log4j の脆弱性と関連して使用されるマルウェアをホストしていると特定されたドメインのリストで、サポートされているすべての AWS リージョンで更新されています。AWS は、このリストを通じて Route 53 Resolver DNS Firewall のドメイン更新を引き続き配信します。

また、DNS クエリロギングを有効にすることをお勧めします。これにより、Log4j の脆弱性やその他の既知の悪意のある送信先が原因でブロックされた送信クエリが DNS ログに存在していないか調べることで、VPC 内の影響を受ける可能性のあるリソースを特定して監査できます。DNS クエリロギングは、アクティブな Log4j スキャンに応答している脆弱な EC2 インスタンスの特定に役立ちます。そのスキャンは、悪意のあるアクター、または、正当なセキュリティ研究者が行っている可能性があります。いずれの場合も、これらのスキャンに応答するインスタンスには Log4j の脆弱性がある可能性があるため、対処する必要があります。GreyNoise は Log4j スキャンを監視し、ここでコールバックドメインを共有しています。お客様がログアクティビティの調査はしたいかもしれないが、必ずしもブロックする必要はない、一部の注目すべきドメインは、interact.sh、leakix.net、canarytokens.com、dnslog.cn、*cyberwar.nl などです。これらのドメインを解決しようとするインスタンスは、Log4j に対して脆弱である可能性が非常に高いです。

AWS Network Firewall

AWS Network Firewall で Suricata 互換の IDS/IPS ルールを使用して、ネットワークベースの検知と保護を展開できます。Log4j に対処するオープンソースの Suricata ルールは、 NCC Group からはこちら、ET Labs からはこちら、CrowdStrike からはこちら、から入手できます。これらのルールは Log4j の脆弱性を利用した侵入後の攻撃だけでなく、脆弱性のスキャン行為の特定に対しても役立ちます。現在、無害なスキャンも大量に行われているため、お客様はVPCから信頼できない宛先に対するLDAPのアウトバウンドトラフィックのような潜在的にリスクのあるトラフィックに注目し、まずはそこに時間をかけることを推奨します。

また、ポート53、80、123、443など非標準のLDAPポートを使用しているインスタンスを監視/防御するためにアウトバウンドのポート/プロトコルを強制するルールの実装の検討をお勧めします。ポート 1389 のアウトバウンド通信を監視または防御することは、インターネット経由でのスキャン行為によって引き起こされるコマンドアンドコントロールサーバ（攻撃者のサーバ）への通信を行うシステムを識別するのに特に役立ちます。また、インターネットへのネットワーク通信を開始する正当な業務上の必要がないシステムには、デフォルトでこの機能が付与されないようにすることをお勧めします。アウトバウンドネットワークトラフィックのフィルタリングと監視は、Log4j だけでなく、他の種類の脆弱性にも非常に役立ちます。

IMDSv2 の使用

Log4j 脆弱性の初期の頃から、ホストが初期の JDNI 脆弱性で侵害されると、攻撃者はホストから認証情報を収集し、LDAP、HTTP、DNS ルックアップなどのメカニズムを介して送信しようとすることがあることに研究者は気付いていました。アクセスキーを長期間使用するのではなく IAM ロールを使用し、認証情報などの機密情報を環境変数に保存しないことをお勧めします。また、データベース認証情報をホストの環境変数に長期間保存する代わりに、AWS Secrets Manager にデータベース認証情報を保存して、自動的にローテーションを実施することもできます。

EC2 ロールが使用されている AWS 環境でこのような攻撃を防ぐために、また、すべての IMDS データを非公開にするために、お客様は Instance Metadata Service バージョン 2 (IMDSv2) の使用を求めることを検討する必要があります。IMDSv2 はデフォルトで有効になっているため、IMDSv1（これもデフォルトで有効）を無効にすることで、IMDSv2 の使用を必須にすることができます。IMDSv2 では、呼び出し元のプロセスが最初に HTTP PUT を持つセッショントークンを取得し、それ以降のリクエストで HTTP ヘッダーにトークンを含める必要があるるので、通信の最初からリクエストが保護されます。これにより、攻撃者はIMDSから認証情報やその他のデータを収集することがはるかに困難になります。IMDSv2 の使用方法の詳細については、このブログと文書を参照してください。最近の AWS SDK とツールはすべて IMDSv2 をサポートしていますが、下位互換性がない可能性のある変更と同様に、この変更を広く展開する前に、代表的なシステムでテストしてください。

検知

この投稿では、この脆弱性が悪用される可能性を潜在的に制限する方法について説明してきました。次に、この脆弱性がお客様の環境に存在するかどうかの検出に役立つ AWS サービスに焦点を移します。

Figure 2. Log4j finding in the Inspector console

図2. Amazon Inspector 管理画面での Log4j 検出結果

Amazon Inspector

図 2 に示すように、Amazon Inspector チームは、お客様の Amazon EC2 インスタンスと Amazon Elastic Container Registry Images (Amazon ECR) にこの脆弱性が存在することを特定する機能を追加しました。新しい Amazon Inspector では、スキャンが自動化され、継続的に実行されます。継続的なスキャンは、新しいソフトウェアパッケージ、新しいインスタンス、新しい共通脆弱性識別子 (CVE) が公開されるなどのイベントによって開始されます。

たとえば、Inspector チームが Log4j 脆弱性 (CVE-2021-44228 & CVE-2021-45046) のサポートを追加し、Inspector は AWS Systems Manager によって管理された全てのサポート対象インスタンスで、OSパッケージマネージャーによってインストールされた Log4j や、Maven 互換の Amazon ECR コンテナイメージに存在するパッケージに対して、この脆弱性の検索を直ちに開始しました。この脆弱性が存在する場合、手動作業必要なしに検出結果が表示されます。もし、Inspector Classicを使用している場合は、全てのAmazon EC2 インスタンスに対して評価を実行する必要があります。全てのAmazon EC2 インスタンスを評価対象にするにはこの文書に従ってください。

Amazon GuardDuty

Inspector を通じてこの脆弱性の存在を発見することに加えて、Amazon GuardDuty チームは、Log4j の脆弱性の悪用に関連するIoC（侵害指標）を追加し始めており、今後も継続していきます。GuardDuty は、既知の悪い IP アドレスまたは DNS エントリに到達しようとする試みを監視し、異常検知による振る舞いの検出結果を通じて脆弱性を突いた攻撃後の挙動を検出することもできます。たとえば、Amazon EC2 インスタンスが通常使用しないポートで通信を開始した場合、GuardDuty はこの挙動を検知し、Behavior:EC2/NetworkPortUnusual の結果を生成します。そして、今回の挙動はNetworkPortUnusualの検出に限定されません。GuardDuty には、AWS リソースの侵害に対応して見られる可能性がある、脆弱性を突いた攻撃後の挙動に関連するさまざまな検出結果があります。GuardDuty の検出結果の一覧については、この GuardDuty の文書を参照してください。

CVE-2021-44228 および CVE-2021-45046 に関連する問題の特定と優先順位付けをさらに支援するために、GuardDuty チームは次の検出タイプの結果の詳細に脅威ラベルを追加しました。

Backdoor:EC2/C&CActivity.B

照会された IP が Log4j 関連の場合、関連する結果のフィールドには次の値が含まれます。

  • service.additionalInfo.threatListName = Amazon
  • service.additionalInfo.threatName = Log4j Related

Backdoor:EC2/C&CActivity.B!DNS

照会されたドメイン名が Log4j 関連の場合、関連する結果のフィールドには次の値が含まれます。

  • service.additionalInfo.threatListName = Amazon
  • service.additionalInfo.threatName = Log4j Related

Behavior:EC2/NetworkPortUnusual

EC2 インスタンスがポート 389 またはポート 1389 で通信した場合、関連する検出結果の重要度は高いに変更され、結果フィールドには次の値が含まれます。

  • service.additionalInfo.context = Possible Log4j callback

Figure 3. GuardDuty finding with Log4j threat labels

図3. Log4j 脅威ラベルのある GuardDuty 検出結果

AWS Security Hub

現在、多くのお客様が AWS Security Hub を使用してInspector と GuardDuty のアラートを集約し、自動修復と対応を可能にしています。短期的には、Security Hubを使用して AWS Chatbot、Amazon Simple Notification Service、またはチケット発行システムを通じてアラートを設定し、Inspector がお客様の環境でこの脆弱性を検出したときに可視化できるようにすることをお勧めします。長期的には、Security Hub を使用して、必要に応じてセキュリティアラートの自動修復と対応を有効にすることをお勧めします。こちらでは、Security Hub で自動修復と対応を設定する方法についてのアイデアを示しています。

VPC Flow Logs

お客様は VPC Flow Logs に対して Athena または CloudWatch Logs Insights クエリを使用して、Log4j の脆弱性を悪用したアウトバウンドネットワークアクティビティに関連付けられた VPC リソースを特定するのに役立ちます。VPC Flow Logs Version 5 には “flow-direction” フィールドが含まれているため、特に便利です。宛先ポート 1389 を使用したアウトバウンドネットワーク通信には特に注意することをお勧めします。これは、宛先ポート 1389 のアウトバウンド使用は正規のアプリケーションではあまり一般的ではないためです。また、信頼できないインターネット宛先 IP アドレスに対して、宛先ポート 389 を使用するネットワーク通信についても調査する必要があります。VirusTotal、GreyNoise、NOC.org、ipinfo.io などの無料 IP レピュテーションサービスは、ログに記録されたアクティビティで見つかったパブリック IP アドレスに関連する有益なインサイトを提供します。

注: キャプチャされた VPC Flow Logs にクエリ対象の Microsoft Active Directory 環境がある場合、ポート 389 を使用しているために誤検知が表示されることがあります。

対応

最初の 2 つのセクションでは、潜在的な脆弱性を突いた攻撃の試みを阻止する方法と、脆弱性の存在や潜在的な脆弱性を突いた攻撃の試みを検知する方法について説明しました。このセクションでは、この脆弱性を緩和するために実行できる手順に焦点を当てます。概要で述べたように、このブログに従い、Log4j 2.0 以降を使用して実行している JVM にホットパッチを適用するように設計されたツールを使用することをお勧めします。AWS の最高情報セキュリティ責任者である Steve Schmidt も、このホットパッチについて自身のブログ記事にて述べています。

Figure 3. Systems Manager Patch Manager patch baseline approving critical patches immediately

図4. Systems Manager Patch Manager 重要パッチを即座に承認するパッチベースライン

AWS Patch Manager

AWS Systems Manager Patch Manager を使用していて、重要なパッチがパッチベースラインにすぐに導入されるように設定されている場合、EC2 インスタンスには既にパッチが適用されているでしょう。ただし、この時点ではやることが残っていることに注意することが重要です。次に、アプリケーションコード内でライブラリが使用されている場所のクラスパスを更新して、最新バージョンを使用していることを確認する必要があります。

IMDSv2 の使用

Log4j 脆弱性の初期の頃から、ホストが初期の JDNI 脆弱性で侵害されると、攻撃者はホストから認証情報を収集し、LDAP、HTTP、DNS ルックアップなどのメカニズムを介して送信しようとすることがあることに研究者は気付いていました。アクセスキーを長期間使用するのではなく IAM ロールを使用し、認証情報などの機密情報を環境変数に保存しないことをお勧めします。また、データベース認証情報をホストの環境変数に長期間保存する代わりに、AWS Secrets Manager にデータベース認証情報を保存して、自動的にローテーションを実施することもできます。

EC2 ロールが使用されている AWS 環境でこのような攻撃を防ぐために、また、すべての IMDS データを非公開にするために、お客様は Instance Metadata Service バージョン 2 (IMDSv2) の使用を求めることを検討する必要があります。IMDSv2 はデフォルトで有効になっているため、IMDSv1（これもデフォルトで有効）を無効にすることで、IMDSv2 の使用を必須にすることができます。IMDSv2 では、呼び出し元のプロセスが最初に HTTP PUT を持つセッショントークンを取得し、それ以降のリクエストで HTTP ヘッダーにトークンを含める必要があるるので、通信の最初からリクエストが保護されます。これにより、攻撃者はIMDSから認証情報やその他のデータを収集することがはるかに困難になります。IMDSv2 の使用方法の詳細については、このブログと文書を参照してください。最近の AWS SDK とツールはすべて IMDSv2 をサポートしていますが、下位互換性がない可能性のある変更と同様に、この変更を広く展開する前に、代表的なシステムでテストしてください。

コンテナの緩和

概要に記載されているホットパッチを EKS クラスターワーカーノードにインストールするために、AWS は Log4j2 ライブラリからの JNDI ルックアップを無効にする JVM レベルのホットパッチを実行する RPM を開発しました。Apache Log4j2 ノードエージェントは、AWS の Kubernetes チームによって構築されたオープンソースプロジェクトです。このノードエージェントのインストール方法の詳細については、この Github ページを参照してください。

ECR コンテナイメージがある場合、Log4j バージョン 2.16.0 を使用するよう更新する必要があります。そして、脆弱な ECR コンテナイメージで構築されたあらゆるコンテナについて、できるだけ早く新しいイメージを使用するように更新する必要があるでしょう。これは、それらイメージの展開に使用しているサービスによります。たとえば、Amazon Elastic Container Service (Amazon ECS) を使用している場合、サービスを更新して新しいデプロイを強制的に実行し、新しい Log4j バージョンを使用してイメージをプルダウンできます。コンテナのデプロイ方法をサポートしている文書を確認してください。

アップグレードできない場合の緩和戦略

デフォルトで JDNI へのアクセスを無効にするバージョン 2.16.0 にアップグレードできない場合、または環境へのパッチ適用方法に関する戦略を決めている最中の場合は、Log4j の設定を変更することでこの脆弱性を軽減できます。2.10 以降のリリースでこの緩和策を実装するには、クラスパスからJndiLookupクラスを削除する必要があるでしょう:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

特定のバージョンの緩和手順に関するより包括的なリストについては、Apache Web サイトを参照してください。

結論

このブログ投稿では、お客様が Log4j 脆弱性によるリスクに対する保護、検知、および対応に役立つ階層型アプローチを採用できるよう主要な AWS セキュリティサービスについて概説しました。お客様には、引き続き当社のセキュリティ速報を注視していただくようお願いします。責任共有モデルの当社側の取り組みにより、引き続きセキュリティ速報を更新していきます。

この脆弱性の重大性を踏まえ、この脆弱性に細心の注意を払い、このブログで取り上げられている統制の実装に適切な優先順位を付けることをお客様に強くお勧めします。

AWS セキュリティに関するニュースをもっと知りたいですか？ツイッターをフォローしてください。

（原文はこちらです）