数日前に公開された脆弱なシステムを容易に遠隔操作される恐れがあるLog4jのゼロデイ脆弱性は、これまでで最も深刻な脆弱性の一つと言われています。この脆弱性とは一体どのようなものなのか、企業にとってはどのような意味を持つのか。そして、どのように悪用され、リスクは何か、パッチを待っている場合はどうすればよいのか等々を、エフセキュアのCISOであるErka Koivunen（エルカ・コイヴネン）をCyber Security Sauna Episode 62にお招きして、この問題を分析し、なぜこの脆弱性がセキュリティ担当者や開発者に警鐘を鳴らすべきなのかについて説明いただきました。
Janne：先週末、「Log4jのゼロデイ脆弱性」と呼ばれるものが多くの人の目に留まっていますが、これは一体どのようなものなのでしょうか？
Erka: これは、イベントログを作成し、そのイベントログ情報を操作するために広く使用されているツールに存在する、リモートで悪用できる脆弱性です。インターネットのインフラの中でも、ユーザーが普段目にすることも、接することもないような、はっきりしない存在なのですが、この脆弱性によって、インターネット上の誰もが攻撃コードを送信し、バックエンドのコンポーネントを爆発させることができるのです。実にやっかいな脆弱性です。
Erka Koivunen, F-Secure CISO
素人でもわかるように、この脆弱性は何なのか、何をするものなのかについて説明してもらえないでしょうか？
フィンランド語で会話していた時に私の心に響いた例えがあるので、それをこれから英語で再現してみます。例えば、オフィスビルの正面玄関からお客様が入ってくるとします。受付の担当者は、訪問者一人ひとりの記録を取ります。彼らが誰なのか、どの会社の社員なのか、誰のところを訪問しようとしているのか。その記録が受付の仕事です。そして、訪問者の一人が話しかけてきます。その受付担当者は、訪問者の希望を一つひとつ丁寧に叶えるようにプログラムされていて、訪問者に対して美味しいエスプレッソを提供するだけでなく、CEOの金庫の中身も提供するのです。受付担当者であるこの人物は、一日中そうしたきっかけを待っていたのですから。
そうですよね。では、Log4jがどこにあるのかというと、これはどこで見つけることができるのでしょうか？
一般的には、Webアプリケーションやポータルなどのバックエンドコンポーネントで、基本的に遠隔測定情報を収集しています。例を挙げると、週末、人々は自分のiPhoneやTeslaの車の名前を、攻撃文字列や攻撃ペイロードに合わせて変更して遊んでいました。Teslaのサービスでも同じことが行われています。
なるほど。つまり、Apache Webサーバー自体は、「これは何をするものか」というようなものですが、私たちが話しているフレームワークのようなものは、他のアプリケーションの分野にも存在するわけですね。
ええ。これはApacheのWebサーバーとは関係ありません。このログツールは、他の多くのデータ処理ワークフローにも組み込まれています。F-Secureでもこれを使っています。
わかりました。つまり、リモートコードの実行は、基本的にその段階では常に悪質なものだと。唯一の制限要因は攻撃者のイマジネーションですが、この脆弱性には何か緩和された状況があるのでしょうか？
最も明白なものは、かなり広く黙殺されてきたようです。このツールには、いわゆるルックアップ機能を無効にするオプションがありました。このオプションは2017年からあったのですが、週末から今日までにわかっていることによると、これはほとんど利用されていませんでした。つまり、このルックアップ機能を無効にしていれば、このような大騒動は起こらなかったはずです。現在、バックエンドシステムにあるログの作成や操作のコンポーネント。もしこれらのコンポーネントが適切に隔離されていれば、このようなコールバック機能を起動することはなかったでしょう。アウトバウンド接続は、実際にチェッカーの数を増やしてしまうことになります。そのため、基本的なITハイジーンのガイダンスに従えば、極めて簡単にこのような脆弱性から免れることができたでしょう。しかし、インターネットはまさにハイジーン的な方法で構築されています。
その通りです。これは、サービスプロバイダーからパッチが提供される前に、人々がすでにできることですね。しかし、そのパッチの提供を待っている間に、他にできることはありますか？
このコンポーネントと機能は、ユーザーの入力をデータとして解析しているようです。このような機能に情報を渡す前に、入力の検証や入力のクリーンアップを行うことは、もちろん非常に有効です。ですから、パッチを当てたり、不要なコンポーネントを無効にしたり、セグメンテーションや入力検証によってネットワークを構成したりすることは、この脆弱性だけでなく、他の多くの類似した問題に対しても免疫力を高めるのに役立ちます。
ええ、入力の検証は良いアイデアだと言いたかったんです。
そして、これらはいずれもエンドユーザーの手には渡らず、完全にサービスプロバイダー側の問題です。ですから、エンドユーザーとしては、サービスプロバイダーやソフトウェアメーカーが対応してくれるのをじっと待つしかないのがもどかしいところです。
まさにその通りですよね。つまり、Log4jフレームワーク自体はすでにアップデートされており、そのためのパッチも用意されていますが、現在は、そのフレームワークを使用している様々なプロジェクトが、それぞれのサービスや製品にパッチを発行するのを待っている状態です。そのため、これらのチームは今、必死になって作業しています。
金曜日の朝、この問題がインターネットコミュニティに広く知れ渡った時、これをサポートするパッチや機能するパッチはありませんでした。そのため、ヨーロッパ時間の午前中になってパッチが利用可能になったのですが、そのパッチが利用可能になる前に、この脆弱性はMinecraftコミュニティで広く利用されていました。想像するに、笑いを取るために使われていたのではないでしょうか。私たちのような真面目なセキュリティの専門家は、この脆弱性や、この脆弱性に対する保護を提供する必要性について全く知らなかったのですが、10代の子供たちは、この脆弱性を利用して、世界中の、そして基本的にはマイクロソフトのMinecraftサーバーを喜んで悪用して回っていたのです。これは、この業界によって謙虚さのレベルが違うことを表していますよね。
それはとても興味深いことですね。子供たちは、自分たちが実際にどんな爆弾の上に座っているのかを知らずに、これを使ってお互いにいたずらをしていたのです。
確かに、子供たちはこの問題がMinecraftのサーバーに限ったことだと思っていたのでしょう。例を挙げると、私はエフセキュアの経営陣に今回の件について伝えて、その中の一人がたまたま彼の10代の子供にこの話をしたところ、子供はすぐに「あぁ、その現象なら知ってたよ。なんでみんなはこんなに遅く気付いたの？」と。
では、Minecraftのいたずら以外に、この脆弱性が攻撃者に利用されているという兆候や証拠はありますか？
金曜日に広範囲に渡って悪用された後、私の記憶が正しければ、最も早く一般に目撃されたのは12月1日にCloudflare社が記録したものでした。その日は、この脆弱性の存在を探るためのテストと呼ばれていました。しかし、金曜日以降、事態は拡大しています。もちろん、たくさんのテストや冗談が飛び交っていますが、当初は基本的に、この脆弱性を利用して、コンピュータに影響を与えるために、クリプトマイナーを投下していました。そのため、それ以上の壊滅的な効果はありませんでした。同時に、遠隔操作されたトロイの木馬RATが被害を受けたデバイスにインストールされていることも確認されました。このことは明らかに、これが攻撃の足掛かりを築こうとする試みであることを意味しています。つまり、最初の脆弱性が修正されても、攻撃者は標的となる企業内に足場を確保することができるのです。そしてもちろん、それを利用してランサムウェア攻撃を仕掛けたり、褒章目当てにサイバー犯罪組織にアクセス権を売ったりすることができます。
攻撃者の目的が持続性の獲得であることを考えると、この脆弱性の影響を受けた全ての企業は、インシデントレスポンスを開始し、脅威の検知を開始すべきだということでしょうか？
そのため、ログには攻撃が行われたことや、少なくともこの脆弱性が列挙されていると考えてよいでしょう。厄介なことに、攻撃が成功した場合、ログのエントリーはもっとつまらないものになります。ですから、プロのスレット (脅威) ハンターは、ログを見て、何が起こったのかを理解し、インシデントレスポンスやフォレンジック活動を次にどこへ持っていけばいいのかを考えるのに適した場所なのです。
もし、ログファイルを見ていて、それが非常に良い状態であるように見えたら、逆にそれ自体が少し疑わしい状態であることを示す赤信号かもしれないですよね？。
ええ、エラーしか表示されないという意見がありましたが、これは大きな警告サインです。そもそも、このエラーは発生するべきではなかったんです。
では、この脆弱性に対抗するために、現時点で人々と共有しておきたいヒントやコツがあれば教えてください。
セキュリティコミュニティでは先週末、「これは明らかにまずい状況だ」というコンセンサスが得られました。私たちは、一般の人々や主要メディア、あるいはエンドユーザーに、目に見える影響は出ていないが状況は悪いということを説明するのに非常に苦労しています。私はまだ家で電気を使っていますし、iCloudも使えますが、影響があるのであえて使わないようにしています。そしてF-Secure製品も対応を行い、今は何も問題はありません。(木を叩く音) これは私が木を叩いて安全を確認している音です。しかし、今週中には目に見える影響が現れてくるのではないかと思います。ですから、この月曜日の朝の時間に最初にアドバイスすることは、自分自身を受け入れることです。何かが新たに発見されるに違いありませんし、それに値するだけの真剣さをもって接するべきです。戦術的なレベルからより戦略的なレベルに引き上げようとすると、これは多くのセキュリティ専門家や開発者に警鐘を鳴らし、アプリケーションを開発しているときに行う、一見孤立したリスク決定が、実際には、便利な機能のセット、将来的に持つべき機能のセットが、実際には企業やユーザーをインターネット全体の悪用に晒してしまうものであるかどうかをチェックするための、より一層の注意が要求されることを理解してもらう必要があります。このログ処理コンポーネントの機能は、2013年に導入されました。何か馬鹿げた理由で、デフォルトで有効になっていました。Log4jのメンテナンス担当者でさえこの機能を嫌っていて、そもそもこの機能の存在やデフォルト化を望んでいなかったはずです。そして、遂にこうした問題が発生しました。このコンポーネントを使用する実装者は、2017年以降、このルックアップ機能を取り除くために、その無効化機能を使用することができました。しかし、彼らはそうしなかった。そして、AppleのiCloudバックエンドコンピュータでさえ、なぜか無制限にどこへでもインターネット接続を開始することができるのです。世に出て広く使用されるツールの開発におけるこのような楽天的な考え方は今後、真剣に検討されるべきでしょう。
というのも、2021年にはソフトウェアのサプライチェーンや様々なソフトウェアに関する法律などが話題になっていて、「これが私のソフトウェア製品を構成するコンポーネントです」というように、何が起こっているのかをかなり詳細に理解する必要があります。もしあなたがLog4jフレームワークのロギング機能を知っていて、そのリストに載っていたとしても、それが潜在的なRCEを意味するとは思わないでしょう。
そうですね、その通りです。また、情報セキュリティコミュニティの一員として、私にそのような先見性があったというと、決してそうではありません。金曜日以前は、このようなコンポーネントがあることさえ知らなかったし、ルックアップ機能があることも知りませんでした。実際に2016年のBlack Hatの講演において大きく取り上げられたことも知りませんでした。だから私は、彼らのインターネット上のファサードの裏に何があるのかを知らずに、幸せに過ごしていました。アプリケーションを構成する各コンポーネントのパーツリストがあれば、どのような脆弱性があるか、どのような可能性があるか、どのような悪用があるかがすぐにわかるだろうと主張するのはフェアではありません。それは不可能なことであり、だからこそ、他の種類のITハイジーンにおける優れた行動が必要なのです。つまり、適切なトラフィックフィルタリングやネットワークセグメンテーションを行えば、この機能を悪用することは実際には困難であり、根本的な原因を軽減するための対策を講じる前に、ある程度の時間的な猶予を得ることができたはずです。今、私たちはそれがどこにあるのかをようやく理解しているところです。
インプットバリデーションに関してもそうですよね？
入力の検証ですね。もし開発者との間で合理的な議論がなされていれば、「このコンポーネントを使ってイベントフィードに基づいてログを作成しているが、そのイベントフィードには実際にユーザーの入力が含まれているかもしれない、ユーザーが任意に作成できる入力は危険な場所のように思える。このコンポーネントに渡す前に正規化すべきなのか？といったことを考えることができたでしょう。しかし、これはバックエンドのコンポーネントなので、これらのシステムを変更して、実際にこれらのコンポーネントがデータを解析するデータフローの中の10番目のサーバーや10番目のコンポーネントのようにすることができます。例えば、インターネットからはアクセスできないようにして、この一連のサーバーからの入力だけを受け入れることができます。このような場合、多くの開発者が時間的に余裕があったり、ドキュメントを見たりすることができないほど、アーキテクチャの全体的な理解が必要になります。
Log4jに関する状況について語っていただき、ありがとうございました。まだまだ今週は対応で忙しいと思いますが、頑張ってください。
あれ？今週はもうこないだの金曜日から始まっているんじゃなかったっけ？幸運を祈ってくれるのがちょっと遅いですよ。
カテゴリ