Webセキュリティ 2022.05.26

Log4j脆弱性を振り返って考える、これからのWebセキュリティ対策とは？

Log4j
RASP

3行でわかる！本記事のサマリ

・Log4jの脆弱性（CVE-2021-44228）は、攻撃者によってサーバー情報を盗まれたり、乗っ取られたりする重大な脆弱性。

・ゼロデイ攻撃の検知・防御は難しく、攻撃のスピードが加速している。

・セキュリティ対策において、多層防御とRASP（Runtime Application Self-Protection）が効果的なアプローチとなる。

はじめに

2021年末、ログ出力ライブラリ「Apache Software Foundation Log4j」（以下、Log4j）の脆弱性が公表され、世界中に大きな影響を与えました。多くのセキュリティ担当者が、現状把握やアップデートなどの対応に追われたと考えられます。今後も新しい脆弱性が発見されるたびに対応に追われるのは避けたいとお考えなら、これを機に、ゼロデイ攻撃に対応できるセキュリティ対策について考えてみませんか。今回はLog4jの脆弱性の問題を振り返りながら、Webアプリケーションのセキュリティ対策における課題と解決方法について考察します。

企業活動に大きな影響を及ぼした「Log4j脆弱性」の問題
Webアプリケーションのセキュリティ対策における課題
課題解決に向けたアプローチ〜多層防御でセキュリティ強化～
ゼロデイ攻撃対策に効果的なソリューション〜未知の攻撃にも対処できるRASPとは？〜

企業活動に大きな影響を及ぼした「Log4j脆弱性」の問題

日本時間2021年12月10日、Log4jの脆弱性(CVE-2021-44228)に関する情報が公表されました。「Log4Shell」とも呼ばれるこの脆弱性は、悪用すれば、サーバーの情報を盗むことも、サーバーを乗っ取ることも容易にできてしまう、非常に重大な脆弱性です。公表直後から、日本国内のWebサイトでも脆弱性を突いた攻撃を多く観測。既存の脆弱性スキャナーにLog4Shellの攻撃パターンが組み込まれ、

最も攻撃が活発となった12月下旬には、わずか20分の間に、Log4Shell含めた様々な脆弱性の狙った攻撃リクエストを15,000リクエスト以上受け取った国内Webサイトもありました。こうした事態を受けて、企業のセキュリティ担当者は自社のリソースがLog4jを直接的・間接的に利用しているかどうか、確認しなければなりませんでした。Log4jはJavaのログ出力ライブラリとして広く利用されているため、調査対象は自社開発アプリケーションだけではありません。他社製品に関してベンダーへの問い合わせも必要です。しかし、ベンダー側でも該当有無の調査を行っていたため、返答には時間がかかりました。

防御側は、脆弱性への対応が早ければ早いほどリスクを抑えられますが、早く対応したくても限界があります。一方で攻撃側にとっては、攻撃対象数が多かったことや、攻撃に関する情報や環境構築の手法が公開されたことなど、有利な条件がそろっていました。こうした理由により、Log4jの脆弱性は多数の企業に大きな影響を及ぼす問題となったのです。

Webアプリケーションのセキュリティ対策における課題

脆弱性のパッチが公開される前に脆弱性を悪用して行われる攻撃を、ゼロデイ攻撃と呼びます。パッチを適用するまでの期間に被害に遭わないためには、ゼロデイ攻撃を検知して防御するセキュリティ対策が不可欠です。しかし、ゼロデイ攻撃の検知・防御は容易ではありません。セキュリティ対策における課題について考察します。

(1) 攻撃のスピードが加速していること

アプリケーションやライブラリに脆弱性が発見されてから、攻撃が始まるまでの期間が短くなっています。Log4Shellの場合、脆弱性が公表された翌日には脆弱性スキャンサービスが一般公開され、誰もがLog4Shellの攻撃対象サイトを探すことができる状態でした。これまで、既知の不正な通信や攻撃パターンを識別するシグネチャ型セキュリティが多く用いられてきました。しかし、受けた攻撃を分析してシグネチャを作成する手法では、対応が後手に回り、攻撃のスピードに追いつけない可能性があります。さらに今回の場合、WAFのシグネチャを回避するようなパターンも次から次へと出現しています。シグネチャ型セキュリティのみに頼る防御では限界があるといえるでしょう。

(2) 一貫したセキュリティの展開が困難であること

近年では、アプリケーションの展開方法として、オンプレミス・仮想マシン・クラウド・サーバレス・コンテナなど、ビジネスやアプリケーションの特性に合わせて、幅広く選択されることが多くなりました。さらに最近では、2つ以上の環境を組み合わせて展開する、いわゆるマルチクラウドやハイブリッドといった構成も主流です。負荷分散や、一つの環境で障害が発生しても処理を継続できるなどのメリットがありますが、セキュリティに関してはデメリットもあります。環境によって導入できるセキュリティソリューションが異なるため、セキュリティレベルやオペレーションを統一するのが難しいという点です。

例えば、パブリッククラウドでは、その環境下でのみ使用可能なWAFサービスを併せて提供するケースがあります。また、コンテナやサーバレスには、それらの環境に適したセキュリティソリューションがあります。ハイブリッドにアプリケーションを展開する場合、それらの環境に適したセキュリティソリューションを配置しなければなりませんが、それらのセキュリティソリューション間での検出精度の違いや、設定方法の違いに伴うオペレーションの煩雑さが課題となることが多々あります。今回のように特に即座に対応が必要なケースでは、これらの課題をいかにして解決するかということが重要になってきます。

課題解決に向けたアプローチ〜多層防御でセキュリティ強化〜

Log4j脆弱性の問題が収束しても、新たな脆弱性はいつどこで発見されるかわかりません。情報処理推進機構（IPA）が公開した「情報セキュリティ10大脅威 2022」でも、
「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」が7位に新規ランクインしているように、ゼロデイ対策はこれからのセキュリティを考えていくうえで重要になってきます。新しい脆弱性が公表されてから慌てないよう、平常時からゼロデイ攻撃に備えておくことが重要です。そのためのセキュリティ対策としては、多層防御のアプローチが有効です。

情報処理推進機構（IPA）が2015年に公開した「ウイルス感染を想定したセキュリティ対策と運用管理を」という注意喚起文書には、「多層防御」を考慮したセキュリティ対策と運用管理を継続的に実施する必要性について記載されています。

多層防御とは、一つのセキュリティソリューションが突破されたとしても、その先のソリューションで防御できるように、複数の対策を多層で行うことです。多層防御を実現するためには、従来型のWebセキュリティソリューションであるWAFとは異なる監視ポイントや検知手法を持ち、WAFでカバーできない部分を防御できるソリューションが必要となります。その一つが、RASP(Runtime Application Self-Protection)です。

ゼロデイ攻撃対策に効果的なソリューション〜未知の攻撃にも対処できるRASPとは？〜

RASPは、Webアプリケーションにセキュリティ機能を持たせることで自分自身を監視し、悪意のある入力や動作に対して自分自身を保護するソリューションです。例えばアプリケーションがどこかへ通信するとき、何かのコマンドを実行するとき、データベースへアクセスするとき、それらのアクションの実行直前にRASPが割り込みチェックを行います。

続きは以下のホワイトペーパーにて、RASPの長所や具体的なソリューションについて紹介しています。

ご興味のある方は是非以下よりダウンロードの上、ご確認ください。