Log4shellにprismatixがチームとしてどう立ち回ったか

先日全世界を揺るがせたLog4jの脆弱性(通称Log4Shell)に対して、開発チームとしてどのように立ち回ったのか、その記録です。

#プロジェクトマネジメント（PM）

#プリズマティクス

#Log4j

#セキュリティ

#脆弱性

髙野将

2021.12.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2021/12/9に報告され、全世界を揺るがせたApache Log4jの脆弱性 CVE-2021-44228 ですが、我々prismatix事業部もその例外ではありませんでした。

脆弱性が判明した直後から、チームとして様々な対応を行っていましたが、一旦開発チームとしては状況が落ち着いています。このエントリでは、脆弱性に対してチームがどのように立ち回ったのか、記録を残しておきます。

最初の一報

12/10の朝、チームメンバーの藤村が、下記のtwitterにてlog4j2にRCEがあることを知り、Slackでチームに共有しました。

log4j2 って使ってましたっけ？RCE が見つかってやばいという話が出てる。

RCE in #Log4j2 #security https://t.co/nPfevJTGTk

— Asif Wani (@KernelCrypt) December 9, 2021

その後すぐ、チーム内で下記のようなやり取りで終わりました。

確か使ってないはず。

このときは、まさかこんなに大事になるとはあまり思っていませんでした…… (私の認識が甘かった

顧客からの問い合わせ

翌11日、prismatixを導入いただいている顧客から、顧客が契約したホワイトハッカーによるセキュリティ検知サービスにて、「Apache Log4J におけるリモートコード実行の脆弱性」について報告があったと連絡がありました。

ここから我々の戦いが始まります。

本当に使ってないのか？を調べる

前日の時点では、prismatixではlog4jを使っていないはずという認識でしたが、本当に使っていないのかの検証からはじめました。

その結果、Springの依存によってLog4jが入ってしまっていることが判明しました ^*1。

今朝藤村さんが見つけた Log4j のやつ、Spring 使ってると依存で入ってるっぽい。全MSC確認しないとダメかも
https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-logging

SpringBootからLog4jへの依存

このあたりの技術的な内容については、下記の小室のエントリを参照ください。

Log4j2 脆弱性問題における SpringBoot アプリケーションの検証

この時点で、脆弱性への対応作業がチームにとって「緊急及び最優先」に一気に躍り上がりました。

緊急体制の構築

最優先課題であり、開発チームだけでなく運用チーム、顧客に対応するチーム、経営層まで巻き込んで体制を組むことになりました。

まず行ったのは 再優先課題である ことの表明です。そのため、開発チームのPjMである私から、PO(Product Owner: プロダクトオーナー)および経営層に「緊急対応開始します」と宣言しました。また、「開発チームのプロジェクトマネージャーになって最初にやったことn連発 - 2. タスク流れ整理」で述べたように、我々のチームではタスクをPBL(Product Backlog: プロダクトバックログ)で管理していますので、PBI(Product Backlog Item: プロダクトバックログアイテム)としてLog4jRCEの対応タスクを起票しました。 ^*2

次に、リアルタイムな情報共有ように、Slackにて「Log4jRCE脆弱性対応用のタスクフォースチャンネル」を作成し、関係者を全員入れました。 ^*3

また、情報を一元管理するための「場所」を用意する必要があります。我々のチームでは esa を利用しているので、そこに作りました。大まかに下記のような構成です。

履歴・記録系調査記録2021-12-10 CVE-2021-44228/:まとめ用ディレクトリ 
|
+- README: 概要ページ(ここを見れば全体がわかるようにするところ)
|
+- 対応履歴(時系列): 報告を受けてから何が起きたか、なにをやったか時系列でひたすらログを書くところ
|
+- フロントとのやりとり: 顧客とどのようなやり取りを行ったかをまとめるところ
|
+- (個別の調査記録): 検証や調査などの記録をそれぞれ残すところ

そして、脆弱性対応のコントロールを行うため、それぞれのチームから下記のような役割のメンバーを指名しました。

インシデント指揮官 (IC = Incident Commander): 全体を把握して対応をコントロールする役割
- 私が担当
書記官 (Scribe) : ひたすら記録を残す役割
- 私が兼任
外部通信役 (External Liaison): 顧客との窓口となる人
- 連絡をいただいた顧客へのフロントチーム担当者
主任SME (SME = Subject Matter Expert): 技術的な調査をする人
- 開発チームのプロジェクトマネージャーになって最初にやったことn連発 - 4. チーム整理で再編成された「リフォームの匠」チーム(以下匠チーム)を始めとして、開発チームメンバー

このあたりの役割については、下記の記事を参考にしています。

インシデント指揮官トレーニングの手引き | Yakst

影響範囲の特定

体制を整えたら、情報収集とともに影響範囲を特定していきます。

prismatixではJavaを使っている何かしらのモノとして、次の2つがありました。

各マイクロサービスアプリケーション
Elasticsearch(以下ES)
- Elasticsearch: 比較的新しいバージョンを使っている環境
- Amazon OpenSearch Service: 古いバージョンを使っている環境

今度はそれぞれについて「脆弱性があるか」、「あったとして問題があるか」を調べていきます。

調査担当については下記のように割り振りました。

各マイクロサービスアプリケーション
- 前述のリフォームの匠チーム、認証・認可サービスチーム ^*4
ES
- 検索・保守チーム

各マイクロサービス

次の視点で調査を進めてもらいました ^*5。

問題がないことの確認
問題がないことの裏付け

また、この内容は esaの専用ページにまとめてもらいました。

調査初日の時点では、おそらく問題がないことまではわかました。また、問題がないことの裏付け(現在の状態でも攻撃できないこと)の確認をするための確認コード作成に着手しましたが、SpringBootのログライブラリ切り替え(logback -> log4j)に手間取り、初日では終わりませんでした。

ES

ESについては、まずLog4jを使っているかどうかについて調査を行い、使っていることが判明しました。

log4j は使っています
https://github.com/elastic/elasticsearch/blob/master/server/build.gradle#L61-L62

その上で、JVMオプションにて脆弱性を緩和できる非公式な情報を入手しました。

Elasticsearch の中じゃない人が同じように JAVA_OPTS に指定すればおｋみたいな話ある
https://github.com/elastic/elasticsearch/issues/81618#issuecomment-990570546

次に、現在顧客が利用しているESバージョンを確認し、大きく3バージョン(Amazon OpenSearch Service含む)があることがわかりました。

ただ、これ以上の調査は難しく、一旦それぞれのバージョンに問題があるかどうかは、オフィシャルの情報を待つことにしました。

初日の状況まとめ

ここまでわかったところで、一旦関係者をSlackのハドルミーティングで集めて現状を共有しました。

各マイクロサービスの影響調査について
- 問題がおそらく無いこと
- 裏付けに手間取っていること
顧客への対応について
- 影響調査結果が今日中に出た場合、出なかった場合のプランA、Bの検討
ESの状況について
- オフィシャル情報待ちであること
- 翌営業日に改めて状況をまとめること
翌営業日の動きについて

顧客への一次報告

「外部通信役」から初日の現状をまとめ、顧客に報告しました。脆弱性の緊急度から、単に「問題ないです」で済ませられるものではなかったので、下記の点に気をつけて繰り返し繰り返し、丁寧に説得してもらいました。

「問題がないこと」を理解していただき、なによりも安心いただくこと
翌営業日に引き続き作業を行い、裏付け結果を報告すること

検証、調査の継続

顧客への一次報告も終わり、更に検証、調査を進めます。

脆弱性の原因となるJNDILookupインターフェースはlog4j-coreに存在し、今の各マイクロサービスの依存には存在しないこと
現象再現モジュールを作成し、攻撃が成立しないことの確認
- 攻撃できないことをスクリーンショットも使って説明するドキュメントも作成した
SpringBootの公式見解で、log4jを使うように明示的に変更していなければ問題ないことを確認
- Log4J2 Vulnerability and Spring Boot

POより今後の方針の共有

これまでに判明した情報を元に、今後の対応方針が打ち出されました。

顧客対応
- 連絡を受けた顧客
  - 再現出来ないことを確認した資料を添えつつ、SpringBootの見解を添えて、ESの設定変更が必要になるのでその対応をスケジュールする
    - セキュリティ関係についてシビアなため
- ESにOpenSearch Serviceを使っていない顧客
  - SpringBootの見解を添えて、ESの設定変更(JVMオプション指定)が必要になるのでその対応をスケジュールする
- ESにOpenSearch Serviceを使っている顧客
  - SpringBootの見解を添えて、ESはAWSの対応次第ということを伝える(=何もしない)
チームの動き
- ESについての対応可否(バージョンごとの対応可否含む)の調査
  - 対応可能なら必要な手順とダウンタイムをもとに運用チーム、顧客フロントチームと調整

ES対応

POからの方針共有後、ES公式見解が発表されました。

Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31 - Announcements / Security Announcements - Discuss the Elastic Stack

Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Investigation into Elasticsearch 5 is ongoing. Elasticsearch running on JDK8 or below is susceptible to an information leak via DNS which is fixable by the JVM property identified below. The JVM option identified below is effective for Elasticsearch versions 5.5+, 6.5+, and 7+. Soon we will make available Elasticsearch 6.8.21 and 7.16.1 which will set the JVM option identified below and remove the vulnerable Log4j component out of an abundance of caution.

おおざっぱにES6、7はJava Security Managerを使っているため問題なし、古いESはJVMプロパティにより修正可能という内容です。ただし、記載のない古いバージョンを使っているOpenSearch ServiceについてはAWSの情報を待つことになりましたが、後日公開されました。

Apache Log4j2 セキュリティ速報 (CVE-2021-44228)

この問題に対処するバージョンの「Log4j2」を使用するように、すべての Amazon OpenSearch Service ドメインを更新しています。

Apache Log4j2 のセキュリティ速報 (CVE-2021-44228) の更新情報

Amazon OpenSearch Service は、すべてのリージョンで Log4j2 の更新バージョンを含む重要なサービスソフトウェアアップデートである R20211203-P2 をリリースしました。OpenSearch クラスターを可能な限り早期にこのリリースに更新することを強くお勧めします。

これにより、prismatixとしての緊急対応はおそらく不要であることが固まりました。