AppSec and Software Community Respond to Log4j
2021/12/30 SecurityBoulevard — アプリケーション・セキュリティとオープンソース・ソフトウェアのコミュニティは、Java Log4j の脆弱性の問題に立ち向かい、ソフトウェアへのパッチ適用／情報の共有／緩和策やツールの提供などを行っている。まだ危機を脱したわけではないが、彼らのこれまでの行動には感銘を受けた。
何が起こったのか？
Log4Shell と呼ばれる Log4j の脆弱性により、世界は厳戒態勢を敷いている。この脆弱性は、2021年11月24日に Alibaba Cloud セキュリティ・チームの従業員により Apache Software Foundation に報告されたが、12月9日には PoC エクスプロイトが匿名で Twitter に投稿されている。
この PoC エクスプロイトが投稿された直後から、攻撃が急激に増加している。しかし、PoC エクスプロイトが広く知られるようになる、最大で２週間ほど前から、この脆弱性がワイルドに悪用されていたことが、その後に判明した。
そして、この脆弱性に対する PoC エクスプロイトが公開されたことで、2021年12月10日〜12月12日までは軍拡競争のような有様となり、セキュリティ・コミュニティの多くの人々が、週末や深夜を費やして、この脆弱性がどのように機能するのか、どうすればこの脆弱性を検出して防御できるかといった点について、理解を深めようと躍起になっていった。
脆弱性の深刻度は？
この Log4j の脆弱性は、きわめて深刻なものである。米国の Cybersecurity Defense Official である Jen Easterly はブリーフィングにおいて、この脆弱性は「私がこれまで見てきた中で、最も深刻ではないにしても、最も深刻なものの１つである」と述べている。
この脆弱性は、悪用が容易であること、悪用が成功した場合の影響が大きいこと、Log4j (脆弱な Javaライブラリ) が広く使用されていることなどから、CVSS 値は最大の 10 とされている。
この脆弱性は、全世界で数十万の組織と数億のデバイスに影響を与える可能性が高いと考えられている。Heartbleed や Shellshock などの大きな影響力を持つ脆弱性と同様に、この脆弱性を持つ製品の数は、これからの数週間・数ヶ月の間に増え続け、その影響は数年に渡って続くだろう。
脆弱性の概要
この脆弱性は、MITRE により CVE-2021-44228 と指定され、アプリケーション・セキュリティ・コミュニティでは Log4Shell というニックネームで呼ばれている。この脆弱性の概要は、以下のとおりである。
- Apache Log4j 2.x パッケージの Lookup 機能
- Java オブジェクトを実行する Java Naming and Directory Interface (JNDI) API
- リモートの Java オブジェクトを取得するための LDAP と RMI
- 機密データを盗み出すための DNS クエリ＋変数解決
これらは悪意の文字列にまとめられ、脆弱な Log4j ライブラリで解析されると、最も単純なケースでは、攻撃を受けたシステムの環境変数からの機密情報の取得などが生じ、最悪のケースでは、システムの完全な乗っ取りにつながるリモートコード実行 (RCE) が生じることになる。
この脆弱性について、現時点で分かっている技術的な詳細については、すでに多くの素晴らしい記事があので、ここでは改めて説明しない。
何が危険なのか？
この脆弱性により、攻撃者は侵害したシステム上で、任意のコードを実行 (RCE) する能力を極めて容易に得られる。ターゲット・システム上で RCE を実行する能力が、攻撃者の目標となる。Log4j が制限された権限で実行されいるとしても、いったん攻撃者がシステムに足場を築くと、その権限をエスカレートさせ、より大きなダメージを与える可能性が高くなる。しかし、危険にさらされるのは、ダイレクトに攻撃されるシステムだけではない。
エッジ・システムだけではない
この脆弱性により、ターゲットとなる Log4j システムに至るまでの、コール・チェーン内の任意のシステムに、攻撃者はアクセスできる (脆弱な Log4j を用いてロギングしている場合に限る)。そして、対象となるシステムは、ファイアウォール内のバックエンドシステム、中間的なサードパーティ・サービス、クライアント・アプリケーション、IoT デバイス、モバイル・アプリケーションなどになる可能性がある。基本的には、ログを取得するために、Log4j ライブラリが使用されている場所であれば、どこでも構いということになる。
攻撃者がターゲットを特定する必要がないことも、この脆弱性を極めて危険なものにしている一因である。攻撃者たちは、エクスプロイトのペイロードをランダムに送信し、影響を受けたシステム (WAF／API ゲートウェイ／ファイアウォール などの境界保護の内側のシステムも含む) が悪意のサーバーに反応するのを待ち、悪意のコードを実行できる。したがって、リモートからの攻撃が可能な被害者を手に入れられる。
データにもリスクがある
あなたのソフトウェアが、脆弱な Log4j ライブラリを実行している場合、あなたは危険にさらされている。あなたのシステムは悪用されずに済むのだろうか？残念ながら、答えは NO であり、安全ではない。あなたの通信やデータが危険にさらされているのだ。
たとえば、Go のサービスが Python のサービスとデータを共有し、Python のサービスが Log4j を使用する Java のサービスとデータを共有していたとする。その場合、攻撃者が Go サービスに送った攻撃文字列が、Python サービスに渡され、Java サービスに渡される。
Go と Python のサービスは脆弱ではないが、Log4j を使用しているJavaサービスが脆弱になる可能性がある。もし、その Java サービスが機密データを扱っていたら、その機密データが危険にさらされる可能性が生じる。
対策
この Log4j の脆弱性からアプリケーションを守るために、誰もが早急に実装を検討すべき３つの緩和策がある。これらは相互に排他的なものではなく、複数の緩和策を実施することで、徹底した防御を実践することが推奨される。
シールド
最初の緩和策は、すべてのアプリケーションをシールドし、他の緩和策を実施するための時間を稼ぐことだ。他の緩和策を導入するには、どこに脆弱性があるのかを知り、それを改善する必要がある。そのためには、実行時に攻撃のシグネチャを識別し、トラフィックを停止することで、攻撃を検知してブロックできるシールドを構築する。
この方法は、最も簡単で迅速、かつ、侵入が少なくなる緩和策だが (アプリのコードや設定を変更しない)、欠点は、関連する全てのエクスプロイトを捕捉できない可能性があること、また、高い偽陽性を生じる可能性があることだ。もちろん、ランタイム防御ソリューションの性能に依存する。
パッチ
最良かつ最も効果的な解決策は、誰もが可能な限り早急に実装すべきことである。Log4j ライブラリを、最新の非脆弱性バージョン (この記事の執筆時点では Log4j 2.17.0) にパッチすることだ。これは、存続する脆弱性に対する、唯一の真の解決策である。
しかし、脆弱な Log4j ライブラリはアプリケーションの奥深くに、様々な方法で隠されている可能性があり、それを見つけることは非常に困難である。したがって、これは徹底的に行うべき、最も困難な緩和策となる。Snyk のような、優れたソフトウェア構成分析 (SCA) ツールは、開発段階におけるプロセスをスピードアップし、単純化するのに有効だ。
しかし、脆弱性のあるライブラリが見つかったとしても、その変更をプロダクション環境に投入する前に、あらゆる場所でテストするには時間がかかる可能性がある。これがシールドのステップが重要な理由となる。
無効化
最後の、しかし確実に最小ではない緩和策は、基本的に脆弱な機能を OFF にする、一連の一時的な対策を実装することだ。それは、Lookup を無効にする (環境変数またはJava のプロパティで構成を設定することで）か、または Log4j パッケージから JNDI ライブラリを完全に削除することにより達成される。いずれにしても、これらの変更は、一部のアプリケーションにとっては破壊的なものとなり、また、デフォルトの設定ではないため、誤って元に戻されてしまう可能性がある。
機能横断的なコミュニティの結集
ソフトウェア・コミュニティとアプリケーション・セキュリティ・コミュニティが一丸となって、この脆弱性を修正するという呼びかけに応え、それを継続している。私は、この２つのコミュニティが、最初の脆弱性が公開されてから数日のうちに、余暇や睡眠を犠牲にして、研究／情報提供／ツールの作成と共有／パッケージの更新／アプリケーションの保護などのために、きわめて迅速に集結したことを非常に誇りに思っている。彼らの努力／協力／情報共有には感銘を受けた。
私たちも負けてはいられない。私たちは、すべての Log4j パッケージにパッチを適用することを推進し続けなければならない。今まで以上に、私たちは安全なソフトウェアのために、協力し続ける必要がある。
この世界では、相互に結びつきが強まっている。私たちには、自分たちだけでなく、隣人やその隣人など、より大きなソフトウェア・エコシステムを構成している人々の安全を守るために、開発／セキュリティ／運用の各部門が一体となり取り組んでいく必要がある。
次のステップ
今回の危機から脱却するとき、そしてこれから脱却するとき、私たちは学んだ教訓を活かし、将来の脆弱性へのリスクを軽減する機会を得ることになるだろう。そのためには、業界のリーダーとして５つのことを実践する必要があると考えている。
- 第１に、今回のインシデントが API レベルの攻撃であることを認識し、この危機から得られた教訓を共有する必要がある。
- 第２に、今回のような API の脆弱性を、緩和／ブロックする方法を、業界全体で教育していくために、教育リソースのフレームワークを共同で作成する必要がある。
- 第３に、API セキュリティを先行して効果的に行うために、API セキュリティの設計とコーディング・パターンについてエンジニアを教育する必要がある。
- 第４に、バグバウンティ・プログラムへの投資と取り組みを強化し、他の隠れた脆弱性を早期に発見し、積極的にパッチや緩和策を講じる必要がある。
- 第５に、ベンダーは、API セキュリティの露出度を測定／管理／改善する際に、開発／セキュリティ／運用を１つのチームに統合するための、ツールを開発する必要がある。
現在の危機を解決するために、我々が行っていることの詳細については、別のブログで紹介している。
かなりの長編ですが、2021年末の時点における Log4j 脆弱性の 5W1H として、とても良くまとまっています。なお、文中にある Log4Shell CVE-2021-44228 に続いて、CVE-2021-45046／CVE-2021-45105／CVE-2021-4104／CVE-2021-44832 の脆弱性も出ていますので、その点だけ補足しておきます。→ Log4j まとめページ
IoT OT Security News 