脆弱性って何？どこを気にすればいいの？
どうも、エンジニアのgamiです。
Log4jというソフトウェアに脆弱性が見つかったことが話題になっています。
僕はセキュリティの専門家ではありません。ただし、エンジニアになる前に比べると、今ではソフトウェアやITシステムに関する構造的な理解が進み、こうしたニュースが意味するところもある程度は分かるようになりました。
セキュリティの話は、ついつい自分とは関係のない難しい問題であると敬遠しがちです。しかし、あらゆる業務やサービスがソフトウェアを介するようになると、その導入や運用に当たってセキュリティに関する問題に対処しなければいけない局面も増えていきます。たとえば自身が関わるサービスで脆弱性への対策を怠ったことで個人情報流出を引き起こせば、社会的な信用を大きく落としてしまいます。
今回は、Log4jの脆弱性を題材に、そもそも脆弱性とは何か？われわれは脆弱性とどう向き合っていけばいいのかについて考えます。
脆弱性とは何か？
みんな大好きWikipediaの説明によれば、「脆弱性」とは次のようなものを指します。
脆弱性（ぜいじゃくせい、英: vulnerability）とは、情報セキュリティ・サイバーセキュリティの用語で、コンピュータに存在する情報セキュリティ上の欠陥をいう。セキュリティホールとも呼ばれる。
セキュリティ問題の前提として、世界には様々な理由でシステムを攻撃する攻撃者がたくさん存在します。攻撃者の多くは技術に長けたソフトウェアエンジニアであり、企業や政府のシステムに対してあらゆる手段で攻撃をしかけてきます。
セキュリティ対策とは、こうした攻撃者の存在を前提にして行われます。システムの管理者としては、悪意のある第三者にどんな攻撃を受けても深刻なシステムダウンやデータの流出を防げるような対策を講じる必要があります。
脆弱性とは、広くいえばこのセキュリティ対策における欠陥のことを言います。たとえば自社で開発しているWebサイトで、実装がしょぼくて簡単に他人のアカウントを乗っ取ることができるような作りになっているとすれば、それはそのシステムの脆弱性といえます。
米テクノロジーニュース・サイト「ZDNet」によると、「セブンペイ」のセキュリティー・システムに不備があり、利用者アカウントのパスワードを他人が簡単に再設定できた。いわゆる「2段階認証」が導入されておらず、パスワード再設定用のリンクを、アカウント利用者本人ではなく、ハッカーのメールアドレスに送らせることで、勝手にパスワードを設定し直し、アカウントを乗っ取ることができたという。
脆弱性の話で難しいのは、個々のシステム固有の問題だけではなく、世の中の多くのシステムに共通する脆弱性が見つかるケースもあるということです。今回のLog4jに冠する脆弱性もその1つです。
昨今のソフトウェア開発では、すべての機能を1から自社開発するということはまずありません。ではどうするかというと、普通は既存のソフトウェアやサービスを組み合わせながらソフトウェアを作るという戦術を取ります。具体的には、オープンソースのライブラリ（OSS）や商用のミドルウェア、開発者向けのSaaS製品などを導入します。
こうした開発者向けのソフトウェアの中には、より標準的で数多くのシステムに使われているものもあります。たとえばLinuxというオープンソースのOSは、世界中のかなり多くのサーバー上で動いています。今回のLog4jも、Javaプログラムからログを出力するための標準的なライブラリであり、Javaを使った世界中のシステムで導入されていました。
Webセキュリティ製品などを手掛ける米LunaSecの報告によると、Minecraftの他、ゲームプラットフォームのSteamやAppleの「iCloud」もこの脆弱性を持つことが分かっており、影響は広範囲に及ぶと考えられるという。
こうした広く使われるソフトウェアで脆弱性が発見されると、それに依存する世界中のシステムで脆弱性が発見されたのと同じことになります。
どんな攻撃が可能になるか？
「脆弱性が見つかった」と一言でいっても、その深刻さは様々です。主には、次のような要素によってインパクトが変わります。
・そのソフトウェアがどれだけ広く使われているのか
・その攻撃によってどれほど深刻な事態を引き起こしうるか
・その攻撃がどのくらい簡単か
特に理解が難しいのは、「その攻撃によってどれほど深刻な事態を引き起こしうるか」についてです。
現代で見つかる標準的なソフトウェアの脆弱性の多くは、それ自体が直接的に深刻なデータ流出等につながるものではありません。しかし、現実の泥棒が裏口のドアを突破した後で監視カメラを壊してから物を盗むように、システムへの攻撃でも様々な攻撃手法を組み合わせながら最終的な目的を達成します。
深刻さを判断するのにわかりやすい基準は、「攻撃者が任意のソースコードをシステム側で実行できる」ような攻撃かどうかです。その攻撃手法で入り口を突破することで、悪意のあるソースコードをシステムに実行させることができれば、より簡単にシステムをダウンさせたり重要なデータを抜き出して外部に送ったりができるようになります。
たとえば2018年に発見されたSpectreとMeltdownと呼ばれる脆弱性では、CPUに対する攻撃手法が発見され世界中のコンピュータが対象になりうるものだったので大きな話題になりました。ただし、その攻撃はかなり複雑であり、またOSアップデートで脆弱性を緩和できることから、実際の被害がニュースになることはあまりありませんでした。
いずれも「本来読めてはいけない秘密のデータなどが格納されているメモリを権限の低い別のプロセスから読めてしまう」というセキュリティ上の大問題だ。「ああ、またまた、いつものソフトウェア脆弱性の騒動か」と高をくくる人もいるかもしれないが今回は違う。OSやソフトウェアに関わりなく、「地球上のほとんどのプロセッサ」が原因である。
（中略）
こうして書くとどちらの脆弱性も簡単に攻撃が可能そうだが、何もないところから実際にちゃんと動作するコードを書くのは相当難しそうだ。さらに、緊急のパッチなどの対策でさらに難易度は高くなっていると思われる。
今回のLog4jの脆弱性では、条件が揃えば比較的簡単に任意のソースコードをシステム側で実行可能なことがわかっています。それもあって、インターネット上でも大きな話題になっており、脆弱性の深刻度を測るCVSSという指標も10.0とかなり高い値になっているようです。
思ってたよりずっとひどいバグだった。これは想像を超えてる。 https://t.co/RB3iq96Xtk
— Rui Ueyama (@rui314) December 10, 2021
具体的には、次のような流れで攻撃が可能なようです。
・あるバージョンのLog4jを利用しているシステムに、細工した文字列を含めてHTTPリクエスト等を送信する
・システム側はその内容をLog4jを使ってログに書き出そうとする
・そのとき、Log4jのLookup機能で「任意のサーバー上にある外部のJavaプログラム」を取得して実行できる
・結果として、システム側のサーバーに任意の攻撃用コードを実行させることができる
Log4jには「外部プログラムを実行する」という機能があり、その機能を外部の第三者が悪用できる状態になっている場合、そのシステムで任意のコードを実行される可能性があったという感じです。恐ろしいですね。
どんなシステムが影響を受けるか？
仮に一部のシステムで影響の大きい脆弱性であっても、全てのシステムに直接的な影響があるとは限りません。たとえばLog4jの脆弱性であれば、Log4jに全く依存していないシステムには直接的な影響はありません。また、一言にLog4jといっても今回の脆弱性は「Apache Log4j 2.15.0より前の2系のバージョン」のみに関するものであり、それ以前のバージョンを使っている場合はあまり気にする必要はありません。
さらに、実際に対象バージョンのLog4jに依存しているシステムであっても、第三者が入力できる値をそのままLog4jを使ってログに出力しているわけではなければ、実質的には攻撃のしようがないということもありそうです。
深刻な脆弱性のニュースを目にすると、全てのシステムが問答無用でダメになってしまうという印象を受ける人もいるかもしれません。しかし、現実はもうちょっと複雑であり、自社のシステムにどの程度影響があるかについては開発者が詳細に調査をして初めて明らかになることが多いです。逆にシステム担当者が脆弱性の見つかったソフトウェアを直接使っている認識が無くても、システムが依存するソフトウェアが間接的にその脆弱なソフトウェアに依存しているというケースもあります。難しいですね。
どう対策すればいいか？
メンテナンスがある程度ちゃんとしているソフトウェアであれば、脆弱性が見つかった場合には遅くとも数日以内にそれを防ぐような修正がされ、新しいバージョンとして公開されます。その修正が完了した後は、ソフトウェアのバージョンアップだけで対応が済むケースもあります。
厳密に言えば、こうしたソフトウェア提供側の修正作業やその利用者側の対応が完了するまでの間に最も攻撃のリスクが高い期間が存在します。この期間における攻撃を「ゼロデイ攻撃」と言ったりします。これを防ぐために、一時的な回避手段が案内されるケースもあります。
さらに難しいのは、脆弱性のあるソフトウェアを間接的に利用しているケースです。たとえばAWSのサービスがLog4jに依存していたときに、AWSの利用者がAWSの中の仕様を変更して脆弱性に対応するということがそもそもできない場合もあります。その場合は、AWSなどのプラットフォーマーが対応してくれるのを待つしかない状況もあります。
機能が便利になるほど、セキュリティ対策も難しくなる
人類はこれまで様々な脆弱性を経験し、情報セキュリティに関する知見を貯めてきました。にもかかわらず、新たな脆弱性が見つかるのはなぜでしょうか？
面白いのは「機能が増えるほど攻撃に使える手段が増える」という側面があることです。Log4jの脆弱性も、「ネットワーク上から値を取得した結果をログに出力できる」という便利機能を悪用されたものでした。また前述したCPUの脆弱性では、処理を高速化するための「投機的実行」という技術を悪用されたものでした。世界中のソフトウェアに便利な機能が追加されたり処理が速くなったりする度に、脆弱性のリスクは少しずつ高まってしまうわけです。
そんなわけで、自分が関わるシステムが急に脆弱性を抱えてしまうリスクは常にあります。脆弱性を恐れて保守的な技術選択をしても、完全に逃れることはできません。今回のLog4jの脆弱性を見ても、急な脆弱性の発見にすぐに対応できる体制をつくってアジリティを高めておくことが重要であることだなあと感じました。
ここから先は
仕事を楽しくするデジタルリテラシー読本
【初月無料】デジタル時代の歩き方について考えたことを発信します。ソフトウェアの時代とは何か。エンジニアの頭の中はどうなっているのか。NoC…
サポートをいただけると、喜びドリブンで発信量が増えます！初月無料のマガジン『仕事を楽しくするデジタルリテラシー読本』もおすすめです！