Cloudflare では、新しいセキュリティの脆弱性を確認した場合、すぐにチームを集めて次の2つの異なる質問に答えます。(1) お客様のインフラを確実に保護するために何ができるか、(2) 自社の環境を確実に保護するために何ができるか。昨日（2021年12月9日）、人気の高い Java ベースのロギングパッケージである Log4j に深刻な脆弱性があることが公表された際、当社のセキュリティチームは、1つ目の質問への対応と2つ目の質問への回答を支援するために行動を開始しました。この記事では、2つ目の質問について説明します。
この脆弱性の仕組みの詳細については、別のブログ記事で紹介しています。Log4j2 の脆弱性（CVE-2021-44228）の内部 ですが、要約すると、この脆弱性によって、攻撃者はリモートサーバー上でコードを実行することができます。Java と Log4j が広く使用されているため、 Heartbleed と ShellShock の両方が存在するため、これはインターネット上で最も深刻な脆弱性の一つであると考えられます。この脆弱性は、 CVE-2021-44228 と記載されています。CVE の説明によると、この脆弱性は Log4j2<=2.14.1 に影響し、2.15ではパッチが当てられています。この脆弱性は、追加で log4j 1.x のすべてのバージョンに影響します。しかし、これはサポート終了であり、修正されない他のセキュリティの脆弱性があります。2.15にアップグレードすることが推奨されます。また、お客様を保護するために WAF のルールをどのように更新したかは、こちらの記事でご紹介しています。 CVE-2021-44228 - Log4j RCE 0-day mitigation
タイムライン
事故が発生した場合、当社はまず最初に、その状況下で確認・理解すべき事象を時系列に整理しています。このタイムラインには、以下のような例があります。
2021年12月09日 16:57 UTC - developers.cloudflare.com の Log4j RCE に関する Hackerone レポートを受信
2021年12月10日 09:56 UTC - 最初の WAF ルールが Cloudflare Specials ルールセットに出荷された
2021年12月10日 10:00 UTC - 正式なエンジニアリング INCIDENT がオープンされ、Log4j にパッチを当てる必要があるエリアを特定する作業が開始
2021年12月10日 10:33 UTC - 脆弱性を軽減するパッチを適用した Logstash がデプロイされた
2021年12月10日 10:44 UTC - 2つ目の WAF ルールが Cloudflare のマネージドルールの一部として公開された
2021年12月10日 10:50 UTC - 脆弱性を軽減するパッチで ElasticSearch の再起動が開始
2021年12月10日 11:05 UTC - ElasticSearch の再起動が完了し、脆弱性が解消された
2021年12月10日 11:45 UTC - Bitbucket にパッチが適用され、脆弱性が解消
2021年12月10日 21:22 UTC - Hackerone のレポートは、再現できなかったため Informative としてクローズされた
内部影響への対応
あらゆるソフトウェアの脆弱性に対処する際の重要な質問であり、この特定のケースにおいてすべての企業が答えなければならない最も難しい質問かもしれません。脆弱性のあるソフトウェアが実際に稼働している場所はどこなのか？
ある企業が世界に向けてライセンスしているプロプライエタリなソフトウェアに脆弱性がある場合は、そのソフトウェアを見つければいいので、答えは簡単です。しかし、今回のケースではそれがはるかに困難でした。Log4j は広く使われているソフトウェアですが、Java 開発者ではないユーザーにとっては馴染みのないものです。私たちの最初の行動は、どのソフトウェアコンポーネントがこの問題に対して脆弱である可能性があるかを判断するために、JVM 上でソフトウェアを実行しているインフラストラクチャのすべての場所を再確認することでした。
私たちは、集中管理されたコードリポジトリを使用して、JVM上で実行されているすべてのソフトウェアのインベントリを作成することができました。この情報を使って、個々の Java アプリケーションを調査し、それに Log4j が含まれているかどうか、そしてどのバージョンの Log4j がコンパイルされているかを調査しました。
当社の ElasticSearch、LogStash、Bitbucket に、バージョン2.0から2.14.1の間の脆弱な Log4j パッケージのインスタンスが含まれていることが判明しました。公式の Log4j セキュリティドキュメントに記載されている緩和策を用いて、この問題を修正することができました。次のように、Log4j の各インスタンスに対して、クラスパスから JndiLookup クラスを削除しました。
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
または、log4j の設定で軽減システムのプロパティを設定します。
log4j2.formatMsgNoLookups
これらのパッケージでは、新しいバージョンのパッケージがリリースされるのを待つ間に、これらの戦略を用いてこの問題を迅速に軽減することができました。
外部レポートの見直し
脆弱性のあるソフトウェアが実行されている社内の場所をリストアップする前に、HackerOne やバグバウンティプログラム、GitHub への公開投稿など、外部からの報告を確認することから始めました。
当社は、Cloudflare が脆弱で安全性が損なわれる状態にあることを示していると思われるレポートを少なくとも2つ確認しました。そのうちの1つのレポートには、以下のようなスクリーンショットがありました。
この例は、https://developer.cloudflare.com にホストされている当社の開発者向けドキュメントを対象としています。右側では、攻撃者が当社のサーバーに送信したペイロードに対してDNSクエリーを受信したことを示しています。しかし、ここでフラグが立てられている IP アドレスは、 173.194.95.134 であり、Google が所有する IPv4 サブネット（ 173.194.94.0/23 ）のメンバーです。
Cloudflare の開発者向けドキュメントは、Cloudflare Worker としてホストされており、静的資産のみを提供しています。リポジトリは public です。この Workers は、ここに見られるように、Google のアナリティクスライブラリに依存しています。従って、攻撃者は Cloudflare からではなく、Google のサーバーを経由してリクエストを受信していたと考えられます。
バックエンドサーバーは Worker からのログを受信していますが、インターネットへの呼び出しを防止する堅牢な Kubernetes のエグレスポリシーを活用しているため、この例では悪用もできませんでした。唯一許可されているのは、厳選された内部サービスへの通信のみです。
脆弱性の開示プログラムで同様の報告を受け、さらに情報を収集したところ、リサーチャーはこの問題を再現できませんでした。このことから、原因はサードパーティ製のサーバーであり、そのサーバーがパッチを当てているのではないかという仮説がさらに強くなりました。
Cloudflare は安全性が損なわれたのか？
当社は上記のソフトウェアのバージョンを実行していましたが、当社の迅速な対応と深層部への防御アプローチのおかげで、Cloudflare の安全性が損なわれたとは考えていません。当社ではこの検証に多大な労力を費やしており、この脆弱性についてすべてが明らかになるまで、この取り組みを続けます。ここでは、その部分の取り組みについて少し紹介します。
脆弱性のあるソフトウェアが実行されている可能性のあるすべての状況を評価して隔離し、それらを修正する作業を行っている間に、それらのインスタンスが悪用されていないかどうかを分析する別のワークストリームを開始しました。当社の検出および対応方法は、業界標準のインシデントレスポンス手法に準拠しており、当社の資産が実際に侵害されているかどうかを検証するために徹底的に展開されました。当社は、次のような多面的なアプローチをとりました。
内部データの見直し
当社の資産目録とコードスキャンツールにより、Apache Log4j に依存するすべてのアプリケーションとサービスを特定することができました。これらのアプリケーションを確認し、必要に応じてアップグレードする一方で、これらのサービスやホストの徹底的なスキャンを行っています。具体的には、CVE-2021-44228 の悪用は、ログメッセージやパラメータの特定のパターンに依存しています。例えば、 \$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+です。影響を受ける可能性のある各サービスについて、ログ分析を行い、悪用の試みを明らかにしました。
ネットワーク分析の見直し
当社のネットワーク分析により、当社のインフラストラクチャを悪用しようとした、または実際に悪用したことを示す可能性のある疑わしいネットワーク行動を特定できます。当社のネットワークデータを精査した結果、以下のことが判明しました。
不審なインバウンドとアウトバウンドの活動 不審なインバウンドとアウトバウンドの接続を分析することで、環境を一掃し、システムのいずれかがアクティブな侵害の兆候を示しているかどうかを特定することができました。
ターゲットとなったシステム＆サービスネットワークデータに対するパターン分析を活用することで、脅威アクターに狙われているシステムやサービスを発見しました。これにより、当社の資産インベントリに対して相関検索を行い、各ホストを掘り下げて、それらのマシンが脆弱性にさらされているか、あるいは積極的に悪用されているかを判断することができました。
ネットワークインジケーター前述の分析から、様々な脅威主体のインフラストラクチャを把握し、この脆弱性の悪用を試みる際に利用されるネットワークインジケーターを特定しました。これらの指標へのアウトバウンド活動は、Cloudflare Gateway でブロックされました。
エンドポイントの見直し
また、ログ分析とネットワーク分析のワークフローを関連付けることで、エンドポイント分析を補完することができました。これらの分析結果から、エンドポイントのスキャン基準を作成して、影響を受ける可能性のあるシステムを特定し、個々のエンドポイントを分析して、積極的な侵害の兆候を確認しました。その際、以下の手法を用いました。
署名ベースのスキャン
現在、脆弱性が悪用された場合に警告を発するための Yara のカスタム検出ルールを導入しているところです。これらのルールは、当社のすべてのインフラストラクチャで稼働しているエンドポイント検出応答エージェントと、集中管理型のセキュリティ情報およびイベント管理（SIEM）ツールに導入される予定です。
異常なプロセスの実行と持続性の分析
Cloudflare は、当社のインフラストラクチャからエンドポイントプロセスイベントを継続的に収集・分析しています。これらのイベントを利用して、第二段階のエクスプロイトのダウンロードや異常な子プロセスなど、エクスプロイト後の手法を検索しました。
これらすべてのアプローチにおいて、安全性が損なわれた形跡は見当たりません。
サードパーティのリスク
上記の分析では、自社で作成したコードとデータの見直しに焦点を当てました。しかし、多くの企業と同様に、当社もサードパーティからライセンスを受けたソフトウェアに依存しています。この問題の調査を開始するにあたり、当社の情報技術チームと協力して、主要なサードパーティ・プロバイダーとサブプロセッサーのリストを作成し、影響を受けているかどうかを問い合わせました。現在、プロバイダーからの回答を受け取り、検討しているところです。この脆弱性の影響を受けた重要なプロバイダーは、完全に修復されるまで無効化され、ブロックされます。
ディフェンス・イン・デプスの手法が有効であることの検証
今回の事件に対応する中で、当社のディフェンス・イン・デプスのアプローチが機能した箇所がいくつかありました。
アウトバウンドトラフィックの制限
call home 機能を制限することは、脆弱性を悪用することを難しくするために、_キルチェーン_に不可欠な要素です。前述のように、当社は Kubernetes のネットワークポリシーを活用して、デプロイメント上のインターネットへのエグレスを制限しています。この文脈では、攻撃の次の段階を防止し、攻撃者がコントロールするリソースへのネットワーク接続を遮断します。
当社の外部向けサービスはすべて Cloudflare によって保護されています。これらのサービスのオリジンサーバーは、認証されたオリジンプルを介して設定されています。つまり、どのサーバーもインターネットに直接さらされることはありません。
2. Cloudflare を利用して、Cloudflare のセキュリティを確保する
当社の内部サービスはすべて、当社のZero Trust製品である Cloudflare Access によって保護されています。そのため、特定された限られた攻撃範囲にパッチを適用した後は、Cloudflare Access を利用して Cloudflare のシステムや顧客を攻撃しようとすると、攻撃者は認証が必要になります。
また、Cloudflare を使って Cloudflare を安全にする取り組みの一環として Cloudflare WAF 製品を導入しているため、お客様を守るために行われているすべての作業の恩恵を受けることができました。この脆弱性から保護するために書かれた新しい WAF ルールはすべて、デフォルトのアクションをブロックに更新しました。WAF を導入している他のすべてのお客様と同様に、当社も何もしなくても保護を受けられるようになりました。
まとめ
この困難な状況への対応は続いていますが、当社の取り組みの概要が他の方々のお役に立てることを願っています。Cloudflare の社内外から多くのご支援をいただき、誠にありがとうございました。
このブログに協力してくれた Evan Johnson 氏、Anjum Ahuja 氏、Sourov Zaman 氏、David Haynes 氏、Jackie Keith 氏にも感謝申し上げます。