セキュリティベンダーはLog4j脆弱性攻撃にどう対応したか 舞台裏からゼロデイ攻撃対策を再考する：「見えないWeb攻撃」──情報漏えい対策の盲点（1/2 ページ）

[中西一博，ITmedia]

　2021年末に発見された「Apache Log4j 2」（以下、Log4j）の危険度の高い脆弱性は、世界中のWebサイトへのゼロデイ攻撃の引き金を引いた。年末から年始にかけて、セキュリティ対策やアップグレード作業に追われたサイトも多いだろう。

　3月30日には、Webアプリケーションでも広く使われているJavaの「Spring Framework」へのゼロデイ攻撃（Spring4Shell）が確認された。インターネットに面しているWebベースのサービスは、特にゼロデイ攻撃の標的になりやすい。

　Log4j脆弱性の発覚直後から攻撃に対峙したセキュリティベンダーは、実際どのように緊急対処したのか。その舞台裏から、現在のゼロデイ攻撃の特性や、有効性を示した打ち手について考察してみたい。

連載：「見えないWeb攻撃」──情報漏えい対策の盲点

コンテンツデリバリーネットワーク（CDN）サービスを基盤に、各種のクラウド型セキュリティサービスを手掛けるアカマイ・テクノロジーズでWebセキュリティの動向を追う中西一博氏が、非常に発見が難しくなっているWeb攻撃の実態と手口を暴き、その対策について解説する。

以前の連載：迷惑bot事件簿

Log4j脆弱性に対する攻撃の傾向

　Log4jはJavaベースのロギングライブラリだ。柔軟で包括的なロギング機能を備えているため、Webアプリだけでなく組み込みデバイスに至るまであらゆるものに使われている。

　12月に発見された脆弱性「CVE-2021-44228」を利用した攻撃では、Log4jの「Lookup機能」という、ログとして記録された文字列の一部を変数として扱い、置換して処理する機能が悪用された。

　Lookup機能の一つ「JNDI Lookup」を使うと、HTTP GETなどの簡単なHTTPリクエストの中に特殊な文字列を入れるだけで、Log4jがその文字列をログとして記録。同時に指定した通信先に置かれたプログラム（例えば通信規格「LDAP」で指定したものなど）を読み込んで実行する。

　つまりリモートから、任意のコードを標的となったサーバ上で実行できてしまうわけだ。標的のサーバ内部で、環境変数として設定されているパブリッククラウドのシークレットアクセスキーなどを抜き出し、攻撃者の用意したDNSサーバにクエリとして送る試みも見られている。

　Akamai Technologies（アカマイ）でも、Web Application Firewall （WAF）による保護を提供しているサイトに対する攻撃の試みを観測した。試行回数のピークは1時間あたり最大で4200万回に達した。

Log4j脆弱性攻撃（試行）レートの推移

　その中から、日本の金融機関への攻撃試行回数を抽出したところ、21年11月に比べて、12月は約44倍に増加していた。12月10日に脆弱性が公開された後の攻撃の影響が顕著に表れている。

　件数に違いはあるものの、攻撃は業種を問わず発生していた。少なくともゼロデイおよび初期の攻撃は、全世界のWebサイトやWebベースのアプリケーションが対象になっていたと考えるのが妥当だろう。

　22年4月現在、攻撃は比較的沈静化している。しかし、過去に深刻な脆弱性が見られた「Apache Struts2」への攻撃では、脆弱性の公表から約半年後に、米信用情報機関大手のEquifaxが、攻撃による大規模な情報流出被害が報告したことなどを踏まえると、今後もしばらく警戒を継続する必要がある。

　アカマイでは、WebサイトやWebブラウザベースのアプリケーションだけではなく、Web APIエンドポイント（APIサーバ）に対する攻撃も観測している。

　スマホアプリの普及に伴い、そのサーバとなるAPIエンドポイントは増加を続けている。今回の攻撃でも改めてAPIが標的になっていることを確認した。未管理のAPIサーバが無いか、脆弱性パッチに加え、WAFでもAPIのフォーマットに対応した保護策が取られているか、いま一度確認が必要だろう。

脆弱性公開後、WAFベンダーの舞台裏

　新たに発見された脆弱性の根本的な対策は、やはり修正済みのバージョンへの速やかなアップデートだ。しかし今回は脆弱性と修正版の公開が金曜だったこともあり、週末にかけて緊急メンテナンスでの対応が難しいケースも多かったようだ。

　そのためか、急に停止ができないWebやAPIサーバを無停止で保護する暫定策として、WAFによる「仮想パッチ」が多く使われた。短期的に複数の脆弱性が見つかり、何度も修正版がリリースされたので、仮想パッチで更新スケジュールをやりくりしたサイトもあるだろう。

　クラウド型WAFサービスを提供しているアカマイでも、今回のLog4j脆弱性公開の直後から、専門の緊急対策チームを組んで臨戦態勢に入った。それまでに得られた情報を整理し、保護対象のサイトの個々の通信を確認しながら、個別にカスタムルールの投入を進めた。

　公開直後の脆弱性情報だけを基にして、単純なWAFルールを作り全サイトに展開してしまうと、フォールスポジティブ（偽陽性による誤検知）によって、正常な通信を誤って止めてしまう恐れがある。

　それを避けるため、カスタムルールで世界中のサイトの保護を進めつつ、誤検知に関する知見を蓄積してから、全サイトで利用できる標準ルールに反映するというプロセスを踏んだ。

　Log4j脆弱性への攻撃では、WAFの単純な検知ルールをバイパス（回避）できるよう、難読化を施した亜種も見つかっている。それに対応していくためのWAFルールのチューニングは、WAFベンダーやSOCサービス（Security Operation Center、サイバー攻撃を検知・分析し、対応などを支援するサービス）プロバイダー独自の腕の見せどころだろう。

　アカマイでも、バイパスに対応できる標準ルールとカスタムルールによる継続的なチューニングに加え、基礎となる検知ロジックもアップデートした。亜種の可能性を検証する中で、日本のLog4j緊急対策チームがDoSを引き起こす新たな脆弱性をLog4jのコードの中から発見した。これはApache Software Foundationが「CVE-2021-45105」として正式に公表している。

　難読化によるWAFの検知バイパスは、他の脆弱性攻撃でもみられる一般的な手口だ。今回の経験から、それに対応するチューニングを継続的に施すWAF管理サービスの重要さを痛感したサイト管理者も多いのではないだろうか。特に重要なサービスの保護に向け、信頼できる外部のSOCサービスと契約するのも良いだろう。その際は、SOCサービスと緊急時の連絡先や作業分担と対応手順をまとめた「Runbook」を作っておくことをお勧めする。

ゼロデイ攻撃に有効だった対策は？

　WAFと信頼に足る管理サービスは、緊急対処を助ける強力なツールになる。とはいえ、新たな検知ルールを作成して投入するまでにゼロデイ攻撃を受ける可能性は残る。一方でアカマイによる分析の結果、この期間に「クライアント・レピュテーション」というWAFの多層防護機能が攻撃を防いでいたことが判明した。