ゆめさくセキュリティ

2021年11月24日に発覚、海外、ソフトウェア部品 (Java のログ出力ライブラリ)

Log4Shell (Apache Log4j の脆弱性)

広く組み込まれたログの部品に欠陥があり、どこに入っているか誰も分からなかった

何があったか

Apache Log4j は、Javaで書かれた仕組みの動きを記録するための、無料で使えるログ出力の部品で、数千のソフトウェアに組み込まれていた。2013年7月、利用者の求めに応じてJNDIという仕組みで外のデータを引く機能が加わり、2.0-beta9から入った。この機能は、攻撃者が用意したLDAPなどの接続先を防げず、ログに書かれる文字列を操れる攻撃者に、外のサーバから任意のコードを読み込ませて実行させられる欠陥になっていた。

2021年11月24日、中国のAlibaba Cloudのセキュリティの技術者が、この脆弱性をメールでApache Software Foundation (ASF) に報告した。ASFは修正を進め、12月6日に修正版の候補を作ったが、その時点で注意喚起は出していなかった。12月9日、技術者は脆弱性がWeChatで話題になっているとASFに知らせた。悪用が進んでいるとの報告も受け、ASFは予定を早めて12月10日に修正版2.15.0を公開し、CVE-2021-44228を公にした。

CSRBが知る最も早い悪用は12月1日からの2日間で、公表後は大量の悪用の試みと調査の通信が観測された。Log4jの利用者の一覧はどこにもなく、各組織はどの製品に入っているかを探すことから始めた。修正版にも欠陥が見つかり、関連の脆弱性が続いた。CISAは12月17日に緊急指令ED 22-02を出し、連邦機関に2週間での対応を求めた。CSRBは2022年7月の報告書で、Log4jの脆弱性は長く残る「風土病のような脆弱性」だとした。

入口
Log4j 2 のJNDIの機能が攻撃者の用意したLDAPなどの接続先を防げず、ログに書かれる文字列を操れる攻撃者が、外のサーバから任意のコードを読み込ませて実行させられた
決め手の失敗
数千のソフトウェアに組み込まれた部品に、攻撃しやすく系を大きく奪える欠陥があった。Log4jの開発側も誰がどう使っているかを知らず、多くの組織は自分の環境のどこに脆弱な部品があるかを洗い出せなかった
被害
CVSS 3.xの基本値は10.0 (CRITICAL)。公表後に大量の悪用の試みが観測され、仮想通貨の採掘やボットネットのマルウェアを入れる試みもあった。ある連邦の省は対応に33,000時間を費やした

攻撃の流れ

  1. 入口ログに記録される文字列を通じて、Log4jのJNDIの機能に攻撃者の用意したLDAPなどの接続先を引かせ、外のサーバから任意のコードを読み込ませる。修正されていないインターネットに面した仕組みが狙われた
  2. 偵察公表から2時間足らずで脆弱な仕組みを探す通信が急に増え、ボットネットで探す作業を自動にする動きも観測された。研究者の調査の通信と悪意ある通信の見分けが難しかった
  3. 権限の奪取悪用に成功すると攻撃者は遠隔からコードを実行し、系を完全に支配できる。CISAが対応した連邦機関の例では、修正されていないVMware Horizonのサーバへの悪用で、管理者とシステムの権限を持つサービスアカウントを得た
  4. 広がり同じ連邦機関の例では、攻撃者は仮想通貨の採掘のソフトを入れ、ドメインコントローラへ移り、資格情報を盗み、居座るための中継の道具を複数の端末に置いた
  5. 影響仮想通貨の採掘、ボットネットのマルウェア、ランサムウェアへの悪用が観測された。各組織は自分の環境のどこにLog4jがあるかを探し、更新と隔離に長く追われた

数字で見る

  • 10.0 (CRITICAL) CVSS 3.x の基本値[2]
  • 16日 報告から修正版の公開まで[1] 2021年11月24日から12月10日。資料の日付から数えた
  • 毎秒400回 公表から5日後に Cloudflare が観測した悪用の試み[1]
  • 33,000時間 ある連邦の省が対応に費やした時間[1]
  • 4件 公表のあとに見つかり修正された関連の脆弱性[1] CVE-2021-45046、CVE-2021-4104、CVE-2021-45105、CVE-2021-44832
  • 2週間 ED 22-02 が連邦機関に求めた対応の期間[1]

気づいたきっかけ

2021年11月24日、Alibaba Cloudのセキュリティの技術者が、脆弱性の説明、該当するコードの場所、概念実証、画面の写しをメールでASFに送った。12月9日には同じ技術者が、脆弱性がWeChatで話題になっているとASFに知らせた

対応と復旧

ASFは11月29日には修正のコードの検討を始め、12月5日に修正をコードに入れ、12月6日に修正版の候補を作った。12月9日の知らせと悪用の報告を受けて予定を早め、12月10日に2.15.0を公開してCVEを公にした。その後も見つかった関連の脆弱性を2.16.0、2.17.0、2.17.1で直した。CISAは12月13日に情報をまとめたWebページと、影響を受ける製品の一覧のGitHubのリポジトリを開き、12月17日に緊急指令ED 22-02を出した

組織が認めた原因と、決めた対策

認めた原因

  • JNDIの機能が、設定、ログのメッセージ、引数の中で、攻撃者の用意したLDAPなどのJNDIの接続先を防いでいなかった (ASF)
  • Log4jはほかのソフトウェアの部品に入り込んでいることが多く、組み込みの後の段階では知られていないため、一般的な調べ方では見つけにくかった (CSRB)
  • Log4jとASFのチームは、慣例どおり、誰がどう使っているかを管理しておらず知らなかった (CSRB)
  • Log4jのようなオープンソースの計画は有志の人手に頼り、開発の流れの全体にセキュリティの専任の人手がいるとは限らない (CSRB)

公表した再発防止策

  • Log4jの脆弱性に、この先何年も備える (CSRB の勧告 1)
  • 脆弱な仕組みを見つける力に投資し、ITの資産とアプリケーションの正確な一覧を保つ (CSRB の勧告 5、6)
  • 脆弱性への対応の手順を文書にして持つ (CSRB の勧告 7)
  • ソフトウェアの開発者と保守する人が安全な開発の慣行を取り入れる (CSRB の勧告 9)
  • ソフトウェア部品表 (SBOM) の道具と使いやすさを高める (CSRB の勧告 12)

自分のサービスで確かめること

  • 自分のサービスと使っている製品のどこにLog4jなどの部品が入っているか、版まで含めて一覧で答えられるか確かめる
  • インターネットに面した仕組みが、悪用が知られた脆弱性の修正版にすぐ上がる手順と、止められない時の回避策を持っているか確かめる
  • サーバから外への通信が、要る宛先だけに絞られているか確かめる
  • 脆弱だった資産を侵害されたものとみなして、隔離し、侵入の痕跡を探す手順が決まっているか確かめる

関わる攻撃とレッスン

学べるレッスン

時系列

  1. 2021年
  2. 11月24日 発覚 Alibaba Cloudのセキュリティの技術者が、Log4jの脆弱性をメールでASFに報告した[1]
  3. 12月1日 侵入 ある技術サービスの会社が、知られている中で最も早い悪用を2日間にわたり観測した。報告した技術者の概念実証を試した動きと合うとされた[1]
  4. 12月5日 対応 ASFが修正をLog4jのコードに入れた。翌6日に修正版の候補を作ったが、注意喚起は出さなかった[1]
  5. 12月9日 公表 脆弱性がWeChatで話題になっていると、技術者がASFに知らせた。CSRBはこの日を脆弱性の公開の日としている[1]
  6. 12月10日 公表 ASFが修正版2.15.0を公開し、CVE-2021-44228を公にした。同じ日にCISAが声明を出した[1]
  7. 12月13日 対応 CISAが情報をまとめたWebページと、影響を受ける製品の一覧のGitHubのリポジトリを開いた[1]
  8. 12月14日 対応 遠隔でコードを実行できるCVE-2021-45046が出され、2.16.0で直された。ASFは2.15.0の修正が一部の設定では不完全だったとしている[1]
  9. 12月17日 処分 CISAが緊急指令ED 22-02を出し、連邦機関に影響を受ける資産の洗い出しと、インターネットに面した脆弱な機器の即時の修正を求めた[3]
  10. 12月22日 処分 CISA、FBI、NSAと豪加新英の機関が共同の注意喚起AA21-356Aを出し、資産の洗い出し、隔離、修正、侵入の痕跡の調査を求めた[4]
  11. 12月28日 対応 ログの設定のファイルを書き換えて遠隔でコードを実行できるCVE-2021-44832が出され、2.17.1で直された[1]
  12. 2022年
  13. 2月 侵入 ある連邦の行政機関で、修正されていないVMware HorizonのサーバがLog4Shellで侵害された[5]
  14. 7月11日 公表 CSRBが報告書「Review of the December 2021 Log4j Event」を公表した[1]
  15. 11月16日 公表 CISAとFBIが、連邦機関の侵害はイランの政府に支援されたAPTの攻撃者によるものと評価する注意喚起AA22-320Aを出した[5]

攻撃した側について

Log4Shellは1つの攻撃者による1つの事件ではなく、公表のあと多くの攻撃者に悪用された。CSRBは、12月9日の公開より前に中国、イラン、北朝鮮、ロシアの攻撃者を含めて悪用を確かめる証拠は見つからなかったとしている。名指しはCISAとFBIのAA22-320Aだけで、2022年2月に連邦の行政機関を侵害した攻撃者を、イランの政府に支援されたAPTの攻撃者と評価した (likelyの評価で、集団の名は出していない)

出典

2026年10月24日に開いて確かめました。本文の [1] などの数は、この一覧の番号です。

  1. Review of the December 2021 Log4j Event Cyber Safety Review Board (CSRB)、2022年7月11日、調査委員会の資料
  2. Apache Logging Services のセキュリティ情報 (CVE-2021-44228 の項) Apache Software Foundation、被害組織の資料
  3. ED 22-02 Mitigate Apache Log4j Vulnerability (Closed) CISA、2021年12月17日、公的機関の資料
  4. AA21-356A Mitigating Log4Shell and Other Log4j-Related Vulnerabilities CISA、FBI、NSA、ACSC、CCCS、CERT NZ、NZ NCSC、NCSC-UK、2021年12月22日、公的機関の資料
  5. AA22-320A Iranian Government-Sponsored APT Actors Compromise Federal Network, Deploy Crypto Miner, Credential Harvester CISA、FBI、2022年11月16日、公的機関の資料