背景

WAFではCVE番号が発番されるような特定の脆弱性を検知するシグネチャだけでなく、攻撃やプロトコル違反などの不審な通信を汎用的に検知するシグネチャが多く実装されているものが多く、どうしても誤検知が生じやすくなります。
(もしお時間があれば MBSDブログ: SOCアナリストによるWAF解説 の記事も合わせてご参照ください)

やみくもに誤検知の生じているシグネチャを無効化してしまうと、(本来汎用的なシグネチャで検知できるはずだった)攻撃を検知できなくなる恐れがあるというジレンマもありますし、新しい攻撃(脆弱性)に対応するためにシグネチャを速やかにリリースしたり、既存のシグネチャの検知ロジックを更新し続けるのはWAFの運用側だけでなくシグネチャ提供側(メーカー側)にも負担になっていると思います。

近年では、専用のシグネチャが提供されていないような未知の攻撃(ゼロデイ)を検知/防御するためのアプローチとして、機械学習を用いた機能を提供するWAFが出てきています。今回はMBSD-SOCのマネージドセキュリティサービスの対応製品のひとつであるクラウドフレアWAFで提供されている"WAF Attack Score"の機能を検証してみましたのでご紹介します。

クラウドフレアWAFのWAF Attack Scoreについて

※当記事は2024年10月から11月にかけて確認・検証した内容を元に作成しております。

クラウドフレアWAFでは機械学習スコアリングモデルでHTTPリクエストをスコアリングする機能 WAF Attack Score が提供されています。

参考: Cloudflare Docs - WAF attack score
参考: Cloudflare Blog - Stop attacks before they are known: making the Cloudflare WAF smarter

使用できるスコアリング項目は以下の4種類です。

• WAF Attack Score (総合スコア的な立ち位置)
• WAF SQLi Attack Score (SQLインジェクション用)
• WAF XSS Attack Score (クロスサイトスクリプティング用)
• WAF RCE Attack Score (リモートコード実行用)

Attack Scoreは各スコアリング項目ごとに1～99で評価され、以下のようにスコアが小さいほど悪意のあるリクエストである可能性が高いと評価されたことを表します。

• 攻撃リクエスト: 1-20
• 攻撃リクエストの可能性が高い: 21-50
• 正規リクエストの可能性が高い: 51-80
• 正規リクエスト: 81-99

Attack ScoreはクラウドフレアWAFのセキュリティイベント画面 (WAFで検知したアラートログ) や、セキュリティ分析画面 (サンプリングされたHTTPリクエスト) 、或いはLogpushと呼ばれるログ転送機能で収集できるHTTPアクセスログで確認することが可能です。

[図:セキュリティイベント画面の例]

また、Attack ScoreはWAFのカスタムルールの条件として使用でき、例えば下図のように、www.example.comでWAF SQLi Attack Scoreが10以下のリクエストをBlockするなどのルールを作成することができます。

[図:カスタムルール作成画面の例]

検証

攻撃検知の観点

1. やられアプリに対する攻撃検知

まずは、OWASP Juice Shop (※)を検証用Webサーバで起動し、攻撃をどのように検知するか確認してみます。
(※OWASP Juice Shop: Webアプリケーションの脆弱性を学習できるやられアプリ)

Juice Shopのログイン画面にはSQLインジェクションの脆弱性が仕込まれています。ユーザ名(Email)として基本的なSQLインジェクションの構文をセットしてリクエストすると、adminユーザでログインできてしまいます。

[図:基本的なSQLiによりログインした例]

クラウドフレアWAF(デフォルト設定)を介してリクエストすると、ログイン用のリクエストがブロックされエラーが発生しました。WAFのブロックメッセージがエラーとして表示されています。

[図:ログイン用リクエストがブロックされた画面]

クラウドフレアWAFではWAF Attack Scoreが3、WAF SQLi Attack Scoreが9となり、SQLインジェクションの攻撃として評価されていました。

[図:基本的なSQLiリクエストのAttack Score (セキュリティイベント画面)]

次に、少し細工したリクエストを送信してみます。

[図:細工したリクエストでログインに成功]

クラウドフレアWAFのデフォルト設定では細工したリクエストがブロックされませんでしたが、WAF Attack Scoreが17となり、攻撃として評価されました。

[図:細工したリクエストのAttack Score (セキュリティイベント画面)]

2. 脆弱性スキャンツールによるリクエストの検知

もうひとつの観点として、とある脆弱性スキャンツールを使用し、約345種類ほどの脆弱性に関連するリクエストを別の検証用Webサーバへ発生させたところ、74件のリクエストが4種類のいずれかのAttack Scoreで攻撃として評価されました。

SQLインジェクションやクロスサイトスクリプティングに関連する脆弱性をスキャンするリクエストは、それぞれ対応したスコアリング項目で攻撃リクエストとして評価されていました。

/browse/book/TEST";window.stop();alert(document.domain);%2f%2f

[WAF XSS Attack Scoreで攻撃として評価されたペイロード例]

RCE Attack Scoreではコマンド実行関連の脆弱性以外に、パストラバーサルやファイルインクルージョンなどに関連するリクエストを攻撃リクエストとして評価していました。/etc/passwdファイルへのアクセスを試行するようなリクエストは、RCE Attack Scoreの算出にある程度関連していそうです。

data=AA_[<img012345>->URL`<?php system('cat /etc/passwd');?>`]_BB

[WAF RCE Attack Scoreで攻撃として評価されたペイロード例]

また、SQLi, XSS, RCEの各Attack Scoreは20以下とはならなかったものの、WAF Attack Score (総合スコア的な立ち位置) のスコア値が20以下となり、攻撃として評価されたリクエストもありました。以下のリクエストは、ある製品のテンプレートインジェクションとリモートコード実行の脆弱性をスキャンするリクエストのペイロード例です。

/login.do?jvar_page_title=%3Cstyle%3E%3Cj:jelly%20xmlns:j=%22jelly%22%20xmlns:g=%27glide%27%3E%3Cg:evaluate%3Egs.addErrorMessage(668.5*2);%3C/g:evaluate%3E%3C/j:jelly%3E%3C/style%3E

[WAF Attack Scoreで攻撃として評価されたペイロード例]

※なお、検知率の観点では345件中74件となりますが、使用したスキャンツールでは例えば特定製品の認証バイパスに関連する脆弱性など、Attack Scoreで評価される攻撃種別ではないスキャンリクエストが一定数含まれていたため、ここでは検知率の評価は対象外とします。

以上の2つの検証結果から、WAF Attack Scoreはシグネチャで検知していない攻撃の検知を補強する役割に期待できそうです。実際に、Cloudflare社からIvanti Connect Secureに対する攻撃を専用シグネチャのリリース前に検知できたとの報告が出ています。
参考: Cloudflare Blog - CloudflareのAI WAFがIvanti Connect Secureのzero-day脆弱性をプロアクティブに検出した経緯

誤検知の観点

WAFを運用するなかで、誤検知 (特に誤遮断の発生) はWebアプリケーションの運用へダイレクトに影響するため、WAFを運用されている方にとっては一番気になる観点だと思います。クラウドフレアWAFのGUIを使って、Attack Scoreによる誤検知の発生状況を簡易的に確認することができます。

セキュリティ分析のトラフィック分析の画面を使用し、確認したいAttack Scoreの値でフィルタリングしたうえで、WAFでブロックされていないリクエスト (緩和されている: いいえ) に絞ると対象を絞りやすいです。この画面で確認できるログはサンプリングされたHTTPリクエストなので、すべてのリクエストを確認するというよりかは全体的な傾向を掴むような使い方になるかと思います。

[図:セキュリティ分析のトラフィック分析の画面]

[図:セキュリティ分析のサンプリングログの確認例]

製品に依りますが、WAFではファイルアップロードなどが行われるリクエストで誤検知が発生しやすいです。クラウドフレアのWAF Attack Scoreでも同じような傾向が見受けられました。

以下の例はWordPressの記事編集画面において記事を作成した際のリクエストです。SQLi Attack Scoreが低めにスコアリングされる傾向が見受けられました。記事編集画面で自動的に埋め込まれたHTMLのコメント文で使用されている"--"などが、スコアの算出にある程度関連しているのではないかと想定しています。

POST /wp-json/wp/v2/posts/記事ID HTTP/2 Host: www.example.com {"id":記事ID,"content":"<!-- wp:paragraph -->記事の中身<!-- wp:paragraph -->・・・","title":"記事のタイトル"}

[図:Attack Scoreによる検知の例]

所感

機械学習はどうしてもブラックボックス感があり、取り扱うのに慎重になってしまいがちですが、現時点では以下の2つの観点で活用できると考えています。

1. 傾向確認の観点で活用できる
   • WAFでブロックできていない攻撃 (Attack Scoreで攻撃として評価されたリクエスト) がどの程度あるか？という観点でセキュリティ分析の画面で攻撃の発生傾向を確認できる。
   • WAFで提供されているマネージドルール (シグネチャ) で誤検知/誤遮断が発生していないか？という観点で、セキュリティイベントの画面でWAFのアラートが発生したリクエストのAttack Score値の傾向を確認できる。
     (例えば、クラウドフレアマネージドルールでWAFアラートを検知しているが、Attack Scoreでは攻撃として評価されていない など)
2. 柔軟にカスタムルールを構成することで、WAFアラートとして攻撃を検知させたりブロックすることに活用できる
   • カスタムルールを用いて攻撃をWAFアラートとして検知させたりブロックするために使用するには、以下のようなアプローチが必要になると考えます。
     • Attack Scoreのスコアリングの状況を確認する (セキュリティ分析の画面で確認するか、Logpush機能を使用してログを収集して分析)
     • 誤検知が発生しやすい条件を確認する (例えばファイルアップロード処理 など)
     • カスタムルールで使用するAttack Scoreのしきい値を決定する (例えばSQLi Attack Scoreが10以下のリクエストをブロックする など)
   • 誤検知が多い環境であれば、例えば送信元(国/地域)・リクエストパス・ユーザエージェントなど複数の条件を組み合わせることで、柔軟にルールを構成できる点がカスタムルールの利点であると考えます。

おわりに

近年では特にAIの台頭・発展により、様々なセキュリティ製品・ソリューションにおいて新しい技術や機能開発が活発に行われている印象を受けます。新技術・機能に追従していくのはとても大変ですので、「自組織にとって本当に必要なものであるのか？」とか「実運用に組み込んで活用できるものなのか？」という観点も大切にしながら、使えるものは上手く活用していきたいですね。