はじめに

2021年12月9日に、任意のコード実行ができるApache Log4jの脆弱性(Log4Shell:CVE-2021-44228)が公開されました。

この脆弱性は、非常に影響度が高く、HeartBleedやShellShockに並ぶとも言われました。また、脆弱性の公開から攻撃開始までが非常に早く、しかも、修正版にも何度も脆弱性が公開され、対応に多くの負担がかかるものでした。組織/システムによって、何も影響がなかったところ、対応が落ち着いたところ、まだまだ対応中のところ等あるかと思いますが、今一度セキュリティ対策について見直す機会になったかと思います。

そこで、次回以降、大きな脆弱性が公開された際にスムーズに対応できるようにするために、また、被害を最小限に抑えるために、今回のLog4Shellを例にして、いくつかの観点から対策案をご紹介します。

FWでのアウトバウンド制限

Log4Shellは、攻撃者から対象のサーバに対してリモートでコマンド実行できるものです。PoCの詳細は他に譲りますが、攻撃の概要としては、Webサーバ等に対して攻撃リクエストを投げ、OSコマンドを含む攻撃コードの本体部分は、攻撃者が用意したサーバからロードされる、というものです。

そのため、もし脆弱性を突ける状態だったとしても、攻撃者のサーバと通信できなければ、攻撃コマンドは実行されず攻撃者としては攻撃失敗となります。尚、攻撃者サーバとの通信に用いられるプロトコルはDNSやRMI等複数ありましたが、最も多く観測されたのはLDAPでした。

図1.Log4Shell攻撃の仕組み概要

リモートコード実行の脆弱性は全般において、攻撃で観測されるOSコマンドの大半は、wget/curl等の外部からHTTPでファイルをダウンロードするものです。まず攻撃者のサーバからスクリプトをダウンロード/実行し、次にC2サーバと通信できるようにして、さらなる侵入/目的実行につなげる、マイニングマルウェアをダウンロードする、といったものが多くあります。Log4Shellでも、攻撃コマンドとしてwgetを意図したものが多く観測されました。

図2.リモートコード実行の脆弱性で最も多い攻撃

システムを構築する上で基本的なことではありますが、許可する通信は必要最小限とし、不要な通信は閉じる、HTTP(S)通信はProxyを使用する等して外部への通信の送信元を限定する、DNS等も送信元/送信先を限定する、といった対策は非常に重要です。仮に脆弱性を突かれてしまったとしても、攻撃としては失敗、もしくは侵入を遅らせることができます。

オンプレ環境ではFWで制限していることが多いかと思いますが、クラウド環境だとなかなかできていないこともあるかと思います。クラウドサービスの通信制御機能や、サーバでのiptables等で適切に制限できているか見直すことをおすすめします。システムによっては、運用中のものに制限を加えるのは難しかったり、過剰な構成になる場合もあるかとは思いますが、効果は非常に大きいため、可能な範囲で実施するのがよいかと思います。

尚、外部通信のログ等をモニタリングしやすくしておくことも、影響確認時に重要となります。

図3.アウトバウンド通信の制御例

Webサーバの設定

Log4Shellは攻撃が非常に容易ですが、攻撃者にとってさらに成功確率を上げるためのいくつかの傾向が見られました。

一つは、攻撃コードを挿入する箇所です。挿入する箇所はヘッダー、URL、パラメータがありますが、攻撃コストが高いパラメータはほとんど使用されず、ヘッダーを利用したものが大半です。さらに、１リクエスト内で様々なヘッダー(多いもので20近く)に攻撃コードが挿入されているケースが多く観測されました。

他には、同一送信元IPアドレスから不特定多数を狙ったスイープ(IPアドレスを連番で総なめ)が非常に多くありました。そのようなばらまきリクエストは、URL(Hostヘッダー)にFQDNではなくIPアドレスを指定します。Log4Shellだけでなく、他の脆弱性を狙ったものでも日常的に多く観測されます。

「不正アクセスの傾向分析とクラウドWAF利用時の注意点」でも触れましたが、IPアドレス指定でのリクエストが必須でないシステムであれば、Webサーバ等でHostヘッダーをチェックして拒否することで、多くの攻撃を防ぐことができます。

図4.ばらまきリクエストの拒否

構成管理

セキュリティ対策に限ったものではありませんが、どこにどんな製品/ソフトウェアが使用されているのかは、普段からしっかり管理しておくことで、いざという時に影響対象、パッチ適用対象等の確認がスムーズになります。

ただ、今回の脆弱性が危険だと言われた理由のうちの一つに、広く利用されているJavaに関するものであり、Log4jも様々な製品に含まれていて、使用しているどの製品のどこに含まれているかの確認が難しい、といった点があります。使用している製品のライブラリまで含めて全てを管理するのは難しい場合もあるかと思いますが、必要な範囲で、メンテナンスが可能な範囲で、しっかり管理することが重要かと思います。

尚、Log4Shellについては、今後もし別の脆弱性等で侵入された後に、ネットワーク内での横移動で利用される可能性が高いと思われます。運用/管理関連の製品等、外部に直接公開されていないものについても、各製品メーカが情報を公開していますので、確認/対応しておくことを推奨します。

WAF

こういった時にはWAFがとても有効です。「SOCアナリストによるWAF解説」でも触れたように、構成管理、脆弱性情報チェック、パッチ適用等をしっかりやっていても、攻撃者の方が先に攻撃してしまうことが多々あります。特にLog4Shellにおいては、攻撃が非常に容易な脆弱性であったということもあり、MBSD-SOCでの最初の観測は脆弱性公開から数時間後といういまだかつてない早さで、さらに24時間経たずに大量の攻撃を観測し始めました。

Log4Shellに対しては各メーカで迅速な対応が見られましたが、MBSD-SOCで取り扱いのあるWAF製品での事例を紹介します。

【F5 ASM/AWAF】

脆弱性公開直後は検知できなかったセキュリティ製品も多かった中、ASM/AWAFは、既存の複数のシグネチャで最初から検知できていました。検知できていたのは攻撃を汎用的に検知するシグネチャで、それゆえに検知精度は低く誤検知が多いシグネチャではありましたが、一部のお客様では遮断設定にしていて、最初から防御できていた攻撃もありました。このように、検知ルールが汎用的に作られており、既存のシグネチャでも新しい脆弱性に対応できるのがWAFの強みです。

攻撃が開始されてからすぐに、検知精度の高いLog4Shellに特化したシグネチャもリリースされました。

尚、Log4Shellを狙った攻撃は、様々な検知回避が試みられ攻撃コードが日々目まぐるしく変わる状況でした。F5社に限らず、各WAF/IPSメーカもLog4Shell用のシグネチャを検知回避の変化に追随して追加のシグネチャを何度もリリースする傾向が見られましたが、F5社の最初から検知できていたシグネチャは、引き続き多くの検知回避パターンにも対応できていました。

【Cloudflare】

12月10日夜に、Log4Shell専用シグネチャがリリースされました。その後も様々な検知回避パターンにも随時追随したと思われ、多くの攻撃を遮断できていました。

様々な検知回避パターンに対応すると、トレードオフで誤遮断リスクも高くなります。しかしながら、誤遮断しないかどうかいくつかのパターンで検証した限りでは、誤遮断はなく攻撃のみを遮断できていました。

さらに、これも以前の記事で触れたものではありますが、クラウド型WAFはその特性上、FQDN指定のリクエストのみ処理します(IPアドレス指定は処理しない)。そのため、オンプレ環境にセキュリティ製品を設置しているケースと比較して、検知数は非常に少ない状況です。クラウド型WAFは、シグネチャの有無に関わらずただ利用するだけで、不特定多数を狙ったスイープから防御することができます。

また、Cloudflareブログでも連日多くの情報を発信されており、大変参考にさせて頂きました。

IDS/IPS

MBSD-SOCで取り扱いのある各IPS製品においても、Log4Shellの脆弱性公開から早いタイミングでシグネチャがリリースされました。公開サーバの防御に対して、IPSを使用することももちろん可能です。ただ、どちからといえば公開Webサイトの防御目的であれば、WAFの方が適切なケースが多いかと思われます。

しかしながら、先述の通り、侵入後の横移動にLog4Shellを利用されることが想定されます。直接公開されていない部分については、優先度が低くなってしまいパッチ適用や緩和策の対応が遅れることもあるかと思います。そういった内部の対策にセキュリティデバイスを利用する際には、WAFよりもIPSの方が、導入の容易さやコスト面で優位性があると思われます。考え方は様々あるかと思いますが、一つの例として、WAFはWebサイト単位に導入するもの、IPSはネットワーク単位に導入するもの、といった分け方ができるかと思います。

IPSとしてインラインに導入するのは構成変更等のハードルが高い場合もありますので、まずは侵入されたことの検知を目的とすることによって、IDSとして利用して導入ハードルを下げるといったこともできます。サーバならホスト型IPS製品も選択肢としてあります。

また、公開システムの内部ネットワークに限定せず、イントラ環境内等の横移動対策でも利用するのもよいかと思います。

図5.WAFとIDS/IPSの使い分けイメージ

WAF/IPSのSOCサービス

WAF/IPSは、製品や利用の仕方次第ではありますが、基本的には運用負荷や求められるスキルレベルが高い製品です(運用負荷と効果はトレードオフ)。

アラートログは常に監視する必要があります。遮断できなかった攻撃でも、攻撃がきたことを早期発見/対応することで、攻撃者の目的達成を阻止したり、被害を最小限に抑えたりすることができます。しかし、特にWAFは誤検知も非常に多くあり、ログ量が膨大になります。適切に監視しないと、せっかく検知した攻撃のログも、誤検知のログに埋もれてしまいます。また、攻撃を検知しても、それが何を狙った攻撃なのか、対象システムに影響があるものなのかを判断できるスキルが必要となります。尚、影響有無を判断するためにも、先述の構成管理も重要となります。

シグネチャチューニングにおいても、膨大なログを確認して、数多くある各シグネチャに対して、遮断/検知、有効/無効を判断するスキルが必要になります。

これらの運用は、内製で行うよりも、SOCベンダーにアウトソーシングすることをおすすめします。Log4Shellにおいても、MBSD-SOCを利用していたからこそ、専用シグネチャが提供される前からLog4Shellの攻撃として検知/通知できていたケースや、既存のシグネチャで遮断できていたケースがありました。また、メーカシグネチャを補うカスタムシグネチャも提供しました。SOCサービスに興味がありましたら、是非お気軽にお問い合わせください。

まとめ

セキュリティ対策は、費用があまりかからないものから、やろうと思えばいくらでもできることはありますが、守るべきシステムに応じて、計画的に実施することをお勧めします。

最後に、突然な大型脆弱性の発生で、攻撃が開始された12月10日(金)から週末、翌週にかけて、MBSD-SOCにおいても非常に慌ただしい状況でした。そのような中でも、大きな問題もなく、標準サービス外のご要望にも可能な範囲で柔軟に応えながら、なんとか嵐を凌ぐことができました。ただ、Log4Shellへの一連の対応は、MBSD-SOCにとっても監視運用やサービス内容について見直すよい機会となりました。よりよいサービスができるよう見直し、改善していきたいと考えています。今後ともよろしくお願い致します。