世界が震撼したLog4jの脆弱性 脚光を浴びたWebセキュリティ対策「WAF」の真価 “現場の負荷”を減らす切り札か？

[PR／ITmedia]

PR

　Java環境で標準的に使われているログ出力ライブラリ「Apache Log4j」で発覚した重大なゼロデイ脆弱性「Log4Shell」。その危険性と影響の大きさは世界を震撼させ、“Webセキュリティ史上最悪級”の事件と位置付けられることもある。瞬く間に広がる攻撃を前に、対応に追われる現場は大きな混乱に陥った。

　2021年12月9日（米国時間）にゼロデイの脆弱性が報告された直後から、この問題を突く攻撃は急激に増加。同時に新たな脆弱性も次々と明らかになった。悪用は比較的容易とされ、機密情報を盗み出す高度なハッキング集団から恐喝目当てのランサムウェア集団までLog4Shellを狙うサイバー犯罪集団は増加の一途にある。

　今回はLog4Shellの一件を振り返りながら、Webサイトのセキュリティ対策の在り方について考えていく。

「自社でLog4jを使っているか」把握しづらく、現場の負担が急増

　Log4Shellは、ログに書き込まれた文字列を基に任意のコードを実行してしまう脆弱性だ。攻撃者が悪意あるコードにつながる文字列をログに残すだけで攻撃できる危険性から、脆弱性の深刻度を表す「共通脆弱性評価システム」（CVSS）のスコアは最高の10.0で、深刻度は「緊急」（Critical）と判断された。

　Log4Shellや関連するサイバー攻撃の報告を受け、世界中の情報セキュリティ機関や各国政府が、Log4jを利用する企業や組織に緊急対応を取るよう促した。Log4jの提供元である米Apache Software Foundationが脆弱性に対応した修正バージョンを公開したことで、Log4jを製品に採用していた各社は相次いで脆弱性修正パッチをリリースして事態は収拾したかに見えた。

　ところが、ユーザー企業にとっては「自社のどこでLog4jが使われているのか」「どこが攻撃を受けているのか」といった影響範囲の特定すら難しい状況だった。Log4jはオープンソースのライブラリとして公開されていたため、Log4jはサーバ、エンタープライズアプリケーション、組み込みシステム、IoT製品などあらゆるシステムに採用されていたからだ。自社で直接導入したシステムならLog4jの利用状況を把握できるかもしれないが、サードパーティー製品の裏側に使われているサーバなどのチェックは困難だ。

　こうした状況で、情報システム部門の担当者などは年末の多忙な時期にもかかわらず対応を余儀なくされた。年末年始の休暇が潰れた人もいるだろう。突如現れたLog4Shellは現場の大きな負担になった。

Log4Shell対策で脚光を浴びた「WAF」　　しかし評価は真っ二つ？

　深刻度と緊急性が高いLog4Shellの対応を巡り、攻撃の防御に役立つセキュリティ対策ツールとして脚光を浴びたのが「WAF」（Web Application Firewall）だった。WAFはWebサーバの前面に配置して通信を解析し、Webアプリケーションの脆弱性を悪用する攻撃を検知して防御することでWebサイトを守るファイアウォールだ。

　今回のLog4jのようなケースでも、WAFを導入しておけば状況把握や修正バージョンにアップデートするまでの時間を稼げる。自社内や導入しているシステムの対応が完了するまでの間、WAFによる攻撃の防御をできれば関係者の大きな安心感につながる。自動で攻撃を防御できれば、情報セキュリティ担当者の負担を大きく軽減できる。

　Log4Shellを悪用した攻撃を事前に察知して防御することは困難だが、脆弱性報告後に多くのWAFベンダーが対策を打ち出したことで、WAFに注目が集まった。しかしWAFのLog4Shell対策を巡っては「WAFが素早く対応してくれたから安心できた」と評価する声と「WAFを回避する攻撃方法があるからWAFは役に立たない」と効果を疑問視する声の両方がある。

　同じWAFなのになぜ評価が割れたのだろうか。原因の一つは、各社のWAF製品が攻撃の手口の巧妙化にどう対応しているかの違いにあった。Log4Shellを狙う攻撃者は、攻撃をWAFで阻止されると分かると、すぐにその防御をかいくぐろうとした。そのために使われた手口が、攻撃パターンをさまざまに変化させる「難読化」だ。

　WAFで攻撃を判定する手法のうち、特定の攻撃パターンに当てはまるかどうかだけをチェックする「シグネチャ」というシンプルな検知方法がある。この方法では、攻撃側がその内容を少し難読化しただけで、簡単に検知をすり抜けることができる。シグネチャで検知する幅を広げると、今度は誤検知が多発してしまう。Log4Shellの発覚初期に報告された基本的な攻撃パターンしか対応できなかったWAFのユーザーが「WAFは役に立たない」と評価したのだ。

　一方で、セキュアスカイ・テクノロジーが提供するクラウド型WAF「Scutum（スキュータム）」（以下、Scutum）はLog4jと同じアルゴリズムで文字列を解析できるプログラムを開発することで、脆弱性が報告され始めた2日後には難読化された攻撃を幅広く検知できるようにした。つまり一言でWAFによる防御といっても、その性能はベンダーや製品の差が大きいのが実態だ。これがWAFの評価が分かれた原因だった。

“何か起きたら対応”ではなく、「ゼロデイ防御」をWAFで実現

　オープンソースソフトウェアがあらゆる製品やサービスに使われるようになった今、Log4jのように広範な影響を及ぼす脆弱性の問題は深刻化している。

　例えばJavaでWebアプリケーションを開発するためのフレームワーク「Apache Struts2」は、16年〜20年にかけて脆弱性を悪用する攻撃が相次いで発生し、中長期的な影響が続いた。Struts2の脆弱性放置が原因で米国の大手信用情報機関から大量の個人情報が流出した事件などは、大々的に報じられた。

　この一連のStruts2攻撃に関してもWAFの真価が問われた。次々に発覚する脆弱性に対して、個々に対応するシグネチャを作成していくアプローチでは、脆弱性が公表されてから対策を行う必要があるため常に後追いの防御になってしまう。

　Scutumでは、Struts2の脆弱性を狙う攻撃の多くで「OGNLインジェクション」と呼ばれる手口が共通して使われている点に着目。Struts2の脆弱性が報告される度に個別に対応するのではなく、「OGNLインジェクションを根本的に防ぐ」アプローチを採用して、WAFの検知ロジックに反映させた。その結果、新たに報告されたStruts2の脆弱性の多くに対して先回りして汎用的に防御できている状態、いわば「ゼロデイ防御」を実現できた。

　近年はパッチのリリース前に悪用が先行するゼロデイ攻撃も後を絶たない。そうした中で、WAFが汎用的な防御能力を実装していれば、攻撃に対抗するための盾になる。一方で個々の脆弱性情報など見てその都度シグネチャを追加する単純な対応しかしないWAFは、攻撃者とのいたちごっこを繰り返す状況に陥りかねない点に注意が必要だ。

脆弱性対策が手遅れになる前に……WAF選定で見極めるべきポイント

　今やWebサイトを運営する企業にとってWAFの導入は当たり前の対策となり、多数の製品が登場したことで選択肢も増えた。しかし、さまざまなWAF製品やサービスがどう違うのか、どのサービスが自社にマッチするかといった判断も難しくなっている。

　WAFの選定に当たっては、日頃から世界中の情報にアンテナを張ってWebセキュリティの最新動向を迅速につかんでいるベンダーを選ぶ必要がある。さらに、脆弱性情報のキャッチから検知ロジックの開発、WAFへの実装に至るまでのスピードにも目を向けなければならない。

　今や脆弱性対応にはかつてない程のスピードが要求され、IPAやJPCERT／CCから広く注意喚起が行われるような主要な脆弱性を、2日以上放置することは大きな危険が伴う。脆弱性を悪用した攻撃は、脆弱性の発覚直後から一斉に広がって被害が多発するため、管理者が朝出社してパッチや新バージョンを認識したときにはすでに手遅れ、という悪夢が現実のものになりつつあるのだ。

　例えばLog4Shellの場合は、12月9日（米国時間）にゼロデイ脆弱性が発見された同日から攻撃が観測され、日を追うごとに急増。ScutumではJPCERT／CCやIPAが注意喚起する前の10日（日本時間）には基本的な対策を施し、翌11日にはWAFの防御をすり抜けようとする攻撃パターンの増加を見越して追加の対策を実装。12日までに国内サーバにある483サイトに対して2553件以上の攻撃を検知し、防御に成功した。

　もちろん、基本的な検知性能がどれほど優れたWAFでも、特定のミドルウェアやプラットフォームの仕様に起因する脆弱性や、過去に類を見ない新しい攻撃手法など全ての攻撃を事前にカバーできるわけではない。

　このためWAFサービスの選定に際しては、最新の脆弱性や攻撃手法に素早く対応しているか、対応状況を速やかにレポートとして公開しているかといった実績を確認することが重要だ。「新たな脆弱性に素早く対応した」とうたっていても、実際には対応するまでタイムラグがあった可能性もある。「対応した」という結果を見るだけでなく、初期対応した時期や、脆弱性の報告からWAFベンダーが対応するまでのスピードといった時系列も含めてチェックしてほしい。

　Scutumでは主要な新脆弱性への対応履歴を詳細に公開している他、Log4jに関する脆弱性について解説した技術ブログを公開している。Log4jに対するWAFの取り組みについて詳細な情報を知りたい読者は目を通してみると、収穫が得られるはずだ。

　Log4ShellやStruts2の危機が去ったとしても、似たような脆弱性は今後も出現するだろう。もしかしたら、記事を読んでいる今この時にもゼロデイ攻撃が発生しているかもしれない。そうした事態に対応できるWAFを選ぶことは、組織を守る情報セキュリティ対策の要だ。

　しかし慌ててWAFを導入するのは禁物だ。自動で脆弱性に対応して情報セキュリティ担当者の負担を減らすはずが、誤検知が多くてかえって手間がかかるといった事態は避けたい。WAF選びの際には、ベンダーに検知ロジックや過去の実績、脆弱性対応のスピード感などをしっかり確認することをお勧めする。