根強く残る脅威：Log4ShellやSpring4Shellのような重大な脆弱性が今も重要な理由

開発者は、機能追加やバグ修正、納期への対応に日々追われています。それでも、意外なほど見過ごされている問題があります。多くのプロジェクトで、脆弱なLog4jやSpring Frameworkのバージョンが使われ続けていることです。Log4ShellやSpring4Shellの脆弱性が大々的に報じられたにもかかわらず、時限爆弾のようなこれらのライブラリを使い続けているアプリケーションが驚くほど多くあります。これは単なる小さな見落としではなく、重大なリスクです。私たちはものづくりをする開発者ですが、ものを作るということは、その構造が安全であることを確かめることでもあります。

開発者が直面するジレンマ

開発者は、新機能のリリースと既存のプロジェクトや機能の保守を常に両立させなければなりません。時間と集中力を存分に要する、難しいバランス調整です。あらゆるプロジェクトの依存関係を把握し、最新の状態に保つのは、特に新機能の提供を急ぐ状況では、なかなか骨の折れる作業です。こうした対応に追われるなかで、Log4ShellやSpring4Shellのような重大な脆弱性を見落としてしまうことがあります。それは怠慢ではなく、日々こなすタスクの多さが原因です。しかし、魅力的なアプリケーションの安全性とセキュリティが、現代のソフトウェア開発に欠かせない要素であることを認識する必要があります。

Log4Shellの現在の状況

Log4Shellを覚えていますか？2021年に見つかったApache Log4jの厄介な脆弱性で、攻撃者が特殊な文字列をログに記録させることで、サーバー上でコードを実行できるものでした。攻撃者はLDAPプロトコルを使ったJNDIルックアップを利用して、コンパイル済みのクラスファイルを注入し、悪意のあるコードを実行できました。新しいバージョンのJavaでも、デシリアライゼーション攻撃によって被害が生じる可能性がありました。この重大な脆弱性は攻撃の難易度が非常に低く、通常以上に大きな脅威となっています。問題の全容については、こちらのブログ記事をご覧ください。

20％を超える企業が、今もLog4Shellの脆弱性を抱えています。

現在も多くの企業が、プロジェクトのいずれかでLog4jライブラリの古い脆弱なバージョンを使用しています。本番コードの脆弱性をスキャンしている企業のうち、21%で、Log4Shellの影響を受けるプロジェクトが今も見つかっています。つまり、2年以上前に公表され、修正済みの脆弱性によって、6万件以上のプロジェクトが侵害されるリスクにさらされているのです。これは非常に深刻です。これらの企業はすでにセキュリティツールを使い、発見したセキュリティ上の問題に積極的に対処していることを考えると、実際に使われている脆弱なLog4jのバージョンは、はるかに多いでしょう。そう考えるだけでも恐ろしく、非常に憂慮すべきことです。

実環境で見つかるSpring4Shell

もう一つの悪名高い例が、2022年3月に公表されたSpring4Shellです。spring-beansの脆弱性も、悪意のあるリモートコード実行につながる可能性がありました。攻撃の難易度は低く、特定のケースではエクスプロイトも確認されましたが、その影響はLog4Shellほど大きくありませんでした。詳しくは、専用のブログ記事をご覧ください。

2022年4月、Snykのチームはこの脆弱性をGlassfishにも適用できるよう拡張し、新たなエクスプロイトを作成しました。これにより、この脆弱性は非常に重大であり、Tomcat向けの最初のエクスプロイト以外にも、さまざまなケースで悪用される可能性があることを実証しました。

Log4Shellと同様に、Spring4Shellも実環境で今なお影響を及ぼすことがわかりました。約35%の企業が、いずれかのプロジェクトでSpring4Shellの脆弱性を抱えています。Spring4Shellによる侵害のリスクはLog4Shellほど大きくないものの、SnykのチームはGlassfish向けの概念実証（POC）エクスプロイトを特定・開発し、悪用される可能性のあるケースを複数示しました。一見それほど危険ではない脆弱性でも、重大なセキュリティ問題につながる可能性があるのです。まだエクスプロイトが公開されていないからといって、脆弱性を抱えるアプリケーションが侵害されないわけではありません。

さらに、多くのSpringアプリケーションが古くなったフレームワークのバージョンに依存しており、既存アプリケーションの更新や保守が重要視されていないことも明らかになりました。しかし、これはいつ爆発してもおかしくない時限爆弾だと、私たちは心の底ではわかっています。

アプリケーションを保守するすべての人への警鐘

率直にお伝えします。コードが問題なく動いたときの誇らしい気持ちは、誰もが知っています。特にライブラリの更新のような面倒な作業のために、わざわざコードに手を加えたくないものです。しかし、Log4ShellやSpring4Shellの脆弱性は、放っておいても解決しません。無視してよい小さなバグではなく、アプリケーションの壁に開いた大きな穴です。Log4ShellやSpring4Shellのような脆弱性が今も残っているなら、深刻度の高い攻撃に不必要なリスクをさらしていることになります。

Snykは、アプリケーションのセキュリティ脆弱性を検出し、対処を支援します。Gitリポジトリ、コマンドラインインターフェース（CLI）、既存の継続的インテグレーション（CI）パイプラインなど、さまざまな方法で開発ワークフローに統合できます。これにより、開発者は開発サイクルの早い段階でセキュリティリスクを特定し、深刻な問題になる前に対処できます。無料で登録すれば、すぐに機能を利用できます。ただし、本当の価値は、発見した脆弱性をその後どのように管理し、解決するかにあります。

ここでは、私たち自身が責任を持って取り組む必要があります。手っ取り早くパッチを当てたり、簡単な更新で解決することを期待したりするだけでは不十分です。脆弱なライブラリを削除したり、置き換えたりするという難しい決断が必要なこともあります。少し開発のペースが落ちるかもしれませんし、楽しい仕事ではないかもしれません。それでも、非常に重要です。今だけでなく、長く使い続けられる堅牢なコードにすることが大切です。

誰かが問題を解決してくれるのを待つのはやめましょう。適切なツールを使えば脆弱性を早期に発見できますが、行動を起こすのは私たち自身です。防御を強化し、脆弱性を修正し、アプリケーションを安全に保つ責任は私たちにあります。単にコードを書く人としてではなく、自分たちの仕事に責任を持ち、可能な限り安全なものにする人として、今すぐ取り組みましょう。