Log4shellは、最初のCVEから最高スコアであるCriticalとしてマークされ、Web上にデプロイされたJavaアプリケーションの大部分に影響を与えた、過去の歴史の中でも最も重大な脆弱性のひとつである。誰もがホリデーシーズンのプレゼントに思いを馳せる中、多くの開発者にとって、その年のホリデーシーズンは石炭の塊(訳注: "a lump of coal"、サンタが悪い子にプレセント代わりに与えるもの)から始まることになった。騒動の後になっても、一部の技術リーダは、この脆弱性への対処作業が"自分のキャリアの中で最も熾烈な日々のひとつ"だったと考えている — Martin Verburg氏は、脆弱性発見後の出来事を振り返る中で、このように述べた。
現在のシステムの持つ重要性を考えれば、従来のWAF(Web Application Firewall)のようなアプローチでは効果的ではないことから、新たなアプローチが求められていた。AWSやMicrosoftといったビッグプレーヤたちは、これらの障害の修正にJava Agentを使用している。Contrast Securityの採用したアプローチも、これと同じようなものだ。他の方法が失敗する中で、このアプローチが成功すると言えるのはなぜなのか — その理由を理解するため、InfoQは今回、Contrast Securtyの創業者でチーフサイエンティストのArshan Dabirsianghi氏に話を聞くことにした。
InfoQ: 読者の質問に答える時間を頂いて、ありがとうございます。Contrast Securityのミッションと、日々の業務におけるあなたの役割について教えてください。
Dabirsianghi: Contrastのミッションは、開発者がアプリケーションセキュリテイをセルフサービスできるように支援することです。今日存在するツールはどれも、実行時やトリアージに専門家の手を必要としています — その最も大きな理由はノイズの多さにあります。開発と同じペースでセキュリテイを推進するには、極めて正確なツールが必要であり、それが私たちの原動力になっています。
プロダクトの大半はもともと私が書いたものですが、現在はチーフサイエンティストを務めています。開発者がセキュリテイを自分のものにできるような方法で、アプリケーションのセキュリテイ問題を解決できるように、当社のビジネスの全機能を導くのが私の役割です。そのために当社では、共感を得られるような明確なストーリテリングを伴った、極めて精緻な結果を容易に生み出せることに重きを置いています。
InfoQ: 他の脆弱性に比較して、Log4Shellのスコープが非常に大きかった理由は何なのでしょう？
Dabirsianghi: まず挙げられるのは、脆弱性を持ったライブラリがあらゆるJavaアプリケーションで使用されている、という点です。当社のデータでは、64パーセントのアプリケーションが該当するライブラリを参照し、40パーセント近くが積極的に使用している、という結果が出ています。これはおもに、Javaロギングライブラリの選択肢が少ないことが原因になっています。
第2の理由は、脆弱性のエクスプロイトが簡単なことです — エンドユーザの提供するデータをログ記録するだけで、そのアプリケーションが脆弱になるのです。不都合なことに、これはロギングライブラリの主要な機能です。私たちの調査でも、この条件に当てはまらないアプリケーションはほとんどありませんでした。攻撃者が企業の対外的なアプリケーションに対して、ペイロードを盲目的に打ちまくるかも知れません。最近のスパゲッティ化した分散アーキテクチャであれば、脆弱なバージョンのlog4j2を実行しているJavaアプリケーションに突き当たる可能性は非常に高いでしょう。
InfoQ: 事態が急を要したゼロディに、AWSとMicrosoftはどちらもJava Agentを使ってシステムを防御しました。エージェントとは何で、なぜ両社はこの方法を選択したのでしょう？
Dabirsianghi: 注目すべきなのは、Webアプリケーションファイアウォールでもすぐにルールが作成されたのですが、コミュニティがそれらを即座に、なおかつ完全に除外(バイパス)したことです。log4j内部で使用されている変数補間(variable interpolation)が、Web Application Firewallのような対外的コントロールにおいて、すでに困難になっていた署名攻撃(signaturing attack)を不可能なものにしていたのです。さらにWAFが有効なのはHTTPのみです — 現在のアプリケーションは昔のような3層アーキテクチャを持っていません。HTTPはアプリが通信する多様な方法のひとつに過ぎないのです。
エージェントがAWSとMicrosoftの最初の選択肢になったのは、この攻撃に対する防御手段として、パフォーマンスや安定性の面でのトレードオフを伴わない、極めて堅牢なコントロールであるからです。危険性のあるJava NamingおよびDirectory Interfaceのルックアップメソッドの実行を阻止すれば、それだけで攻撃の停止には十分です。
当社のエージェントであるContrast Protectは2018年から、多くの防御層を通じてこの攻撃を防止してきましたが、インストルメンテーションによってバグクラス全体の悪用を防止する方法についての検討は、まだ緒についたばかりです。
InfoQ: Log4Shellの騒動から、どのような教訓を得たのでしょうか？
Dabirsianghi: "終末は近い(The End Is Nigh)"というサインを掲げた者のひとりとして、アプリケーションのセキュリティこそがおそらくは最も重要なセキュリティであるということが、多くの人たちに認識された点は感慨深く思っています。それこそが、ファイアウォールを意図的にプログラムして世界に公開するものだからです。エージェントを中心としたアプローチによるセキュリティとアプリケーションの監視(IASTおよびRASP)については、これまで以上に自信を持つことができました。多数のバグクラスに対して、効果的かつ安全な保護を実現して、アプリケーションと、その使用するライブラリのライブなインベントリビューを作るというのは、エージェントがあって初めて可能になることです。
InfoQ: より堅牢なエコシステムを実現するためには、ソフトウェア開発ライフサイクルをどのように改善すればよいと思いますか？
Dabirsianghi: コミュニティとしてあえて言うならば、一般論としての安全なコードの作成方法は分かっています。ですが、それには費用と時間が必要ですし、それを実行してくれる人材もなかなか見つからないのです。log4j2の主要なコンポーネントの設計にセキュリティの概念が欠けていると認めることは、この素晴らしい無償ユーティリティの開発者を侮辱することではありません。開発チームのこの領域のスキルが十分でない、ということなのだと思います。これは私たち全体の問題でもあります。
例えば、セキュリティに関わる人たちは、最小特権の原則を理解しています。この考え方をlog4j2に適用していれば、JNDI機能はオプトインになっていたか、あるいは完全に分離した別モジュールにパッケージされていたでしょう。そうであれば、今回の脆弱性が影響するのはごく一部のアプリケーションに留まって、事実上すべてのアプリケーションに影響を与えるようなことはなかったと思います。
もうひとつ、誰も指摘していない問題は、私たちがセキュリテイ問題のテストに使用するツールのほとんどが単一のコンポーネントではなく、アプリケーション全体をスキャンするように作られているという点です。この分野には新しいツールが必要だと思いますが、ライセンスを買う人がいるでしょうか。
InfoQ: 今回の脆弱性は、OSSエコシステムにどのような影響を与えたと思いますか？企業についてはどうでしょう？
Dabirsianghi: 私は楽観的なので、よい影響があると思っています。今回の脆弱性は、AppSecとしてはかつてないほどの注目を集めましたから、そうなると考えるのは自然でしょう。
OSSエコシステムの大半が熱意でプロジェクトを行う無報酬の労働者であることを考えれば、彼らの行動だけでは長期的な変革は望めないでしょう。ですが、彼らの作品から収益を得ているすべての利用者が集まれば、より安全なコードを生み出すエコシステムを実現することは可能です。そういった人たちが資金面や専門知識、標準化の面で貢献すれば、FAANG内でミッションクリティカルかつ高度に注目されるプロジェクトに従事するハイファンクショナルなチームに見られるような、セキュアな開発ライフサイクルをOSS開発で実現することも不可能ではないでしょう。
これが非現実的だというのであれば、それはすなわち、セキュアなオープンソースコンポーネントの実現が不可能だということになります。どちらが正しいのかは、時が明らかにしてくれるでしょう — 私としては、その過程において、Log4Shellのインシデントがこれ以上発生しないことを祈るのみです。
こういった脆弱性が再び起こることは避けられませんから、何らかの根本的な改革が必要でしょう。だからこそ、プロテクションが重要なのです。ゼロディだけではありません。事実、実務に従事している人たちは、自社からLog4Shellを根絶することは不可能であると、内心では認めていると思います。シャドーITが多すぎる、インベントリ機能が不十分である、メンテナンス不能なアプリが多数ある、といったことがその理由です。OSSエコシステムが続く限り、そのダメージは今後も長く続くことになります。
Log4Shellという猛吹雪の結果として我々は、WAFのような従来の防御メカニズムが、攻撃者の持ちうる高度にポリモーフィックなペイロードに対しては無力である、という事実への理解を深めることになった。そのため、ファイアウォールを堀として外部からシステムを保護するのではなく、内部から積極的にパッチすることが必要になったのだ。Java Agentは、MicrosoftやAWSが同様なアプローチを採用したことで、これを実現するための極めて効果的なメカニズムであることが証明された。