Cloudflareが、自社のWAFを最新のAIモデルに攻撃させるテストをして、その結果を公開しました。
先に結論を書くと、AIは1,107回の攻撃を試して、人が確認したあとに残った「すり抜けの手がかり」は49件でした(攻撃が成功した数ではありません)。
ほとんどがコマンドインジェクションとSSRFで、CloudflareはSSRFまわりのルールを3つ直しています。
🎥 この記事の内容は動画でも解説しています。
世界のWeb事情の回です。
自分のサイトもCloudflareを使っているので、関係があるかも合わせて確かめました。
WAFとは？
WAF(Web Application Firewall)は、Webサイトに届くリクエストを見て、攻撃っぽいものを止める仕組みです。
たとえば、URLやフォームの入力にSQLを混ぜてデータベースを操作しようとする「SQLインジェクション」のようなものを、サイトに届く前に止めます。
Cloudflareでは、あらかじめ用意された「マネージドルール」と、リクエストが攻撃らしいかを点数で見る「WAF Attack Score」などを組み合わせて使います。
Cloudflareがやったこと
元になったのは、9月29日のCloudflareのブログ記事です。
やったことは、次のとおりです。
- 最新のAIモデルに攻撃役をやらせた(モデル名は書かれていません。同じ系統のモデルの2つのバージョン、とだけあります)
- AIには、ソースコードもWAFのルールも見せない。見えるのは、返ってきたHTTPの応答の一部だけ
- 知られている攻撃から始めて、止められたら書き方や送り方を変えて、また試す
- 相手は、許可を取った顧客の検証用(ステージング)環境
- 1つの場面につき25回まで、という上限つき
リクエストを実際に送るのはAIではなく、プログラムの側です。
宛先のホストを決めた一覧に限る、リダイレクトを追わない、回数の上限を守る、といった制御もプログラムでかけていました。
試した攻撃は6種類です。
- XSS(クロスサイトスクリプティング)
- SQLインジェクション
- コマンドインジェクション
- SSRF(サーバーに内部のURLを取りに行かせる攻撃)
- パストラバーサル(本来見せないファイルを読ませる攻撃)
- Log4j
結果: 1,107回試して、残ったのは49件
数字を並べると、こうなります。
- 試行: 1,107回(45の場面)
- 使えるリクエストにならなかったもの、相手に届く前に失敗したもの、攻撃になっていないものなどを除いて、残ったのは607件
- そのうちWAFが止めたのは558件
- 人が確認して残った「すり抜けの手がかり」は49件
49件のうち48件は、コマンドインジェクションとSSRFでした。
XSS・パストラバーサル・SQLインジェクション・Log4jは、ほぼ止められていた、と書かれています。
ここで大事なのは、49件は「すり抜けた手がかり」であって、「攻撃が成功した」ではないことです。
Cloudflareも、止められなかったリクエストは「人が確かめるための手がかり」として扱ったと書いています。
WAFをすり抜けても、サイトの側に穴がなければ、攻撃は成功しません。
直したのは、SSRFのルール3つ
この結果から、Cloudflareはマネージドルールを3つ変えています。
どれもSSRFに関するものです。
- 内部のアドレスを、ふつうと違う数字の書き方で隠したリクエストを見つける、新しいルール
- 使ってはいけない種類のURL(プロトコル)を見つける、新しいルール
- クラウドの内部アドレスを狙うリクエストを見つける、既存のルールの改善
ルールは、実際の通信で試してから出したそうです。
ちょっと気になったところ
読んでいて、そのまま受け取らないほうがいいと思った点もあります。
まず、テストしたWAFの設定は、かなり強めでした。
マネージドルールを全部有効にして、さらにOWASPのルールも厳しい段階(Paranoia Level 3)にしていたとあります。
同じ数字が、どのサイトの設定にもそのまま当てはまるわけではなさそうです。
次に、試したのは「外から応答だけを見て攻める」やり方だけです。
Cloudflare自身も、次はアプリの弱点やWAFのルールをAIに教えたうえで試す、と書いています。
今回の49件は、条件をしぼったテストの結果、と読むのがよさそうです。
それと、AIが出した答えを、そのまま正解として扱っていない点は参考になりました。
どれが本当に問題かは、人が見て、送り直して確かめています。
自分のサイトには関係ある？
自分のサイトは、ドメインの管理(DNS)にCloudflareを使っています。
ただ、10月21日と22日に確かめたところ、サイトへの通信はCloudflareを経由していませんでした。
応答にCloudflareを通ったときの印(cf-ray)がなく、サーバー名もnginxでした。
Cloudflareを経由せず、契約しているサーバーから直接返ってきている、ということです。
つまり今は、CloudflareのWAFの前を、自分のサイトへの通信は通っていません。
今回のルールの変更も、自分のサイトには効いていない、ということになります。
Cloudflareを使っているからWAFもある、とは限らないんですよね。
先日のPHPの緊急更新のときも、同じことを確かめました。
そのときの話は、PHPとNode.jsの緊急更新の記事に書いています。
WAFを使っている人への、Cloudflareのおすすめ
元の記事では、同じ実験をやり直す必要はないとしたうえで、こんなことをすすめています。
- マネージドルールとWAF Attack Scoreが、ちゃんと設定されているか確かめる
- 新しいルールは、まず記録だけするモードで動かし、ふつうのアクセスが止まらないのを見てから、止める設定にする
- テストは、本番と同じ守りをかけた検証用の環境でやる
- ソフトウェアを最新に保つ
最後の1つは、WAFがあっても変わらないんですよね。
すり抜けたリクエストが通るのは、サイトの側に穴があるときです。
まとめ
Cloudflareは、自社のWAFを最新のAIに攻撃させて、1,107回の試行から49件のすり抜けの手がかりを見つけ、SSRFのルールを3つ直しました。
ただし強めの設定で、外から攻めるやり方だけを試した結果です。
自分のサイトは、CloudflareのDNSを使っていても、WAFは通っていませんでした。
使っているつもりの守りが、本当に効いているかは、一度確かめておくと安心です。
