導入するだけでは足りない？WAFの意外な弱点とは？

　WAFは、Webアプリケーションのセキュリティを高める方法として広く導入されています。典型的な攻撃を防ぐためのシグネチャやルールセットが用意されており、適用するだけで簡単にセキュリティを向上させられるところが利点の1つです。

　しかし、ただWAFを導入するだけでは攻撃による被害を十分に防げない場合があることをご存じでしょうか。サイバー攻撃者はWAFの仕組みを熟知しており、WAFの防御機能を回避して攻撃することもあります。そこで今回はNTT東日本のセキュリティ診断チームが、AWS WAFを使って防御機能を回避できてしまうのかを実際に検証してみました。Webアプリケーションセキュリティの考え方も交えながら、セキュリティ診断の実例を基に徹底解説しますので、ぜひ最後までお読みください。

　WAF（Web Application Firewall）とは、Webアプリケーションに対する攻撃を防御することに特化したファイアウォールです。Webトラヒックを監視し、Webアプリケーションへの悪意のあるアクセスや攻撃を検出・ブロックする機能を持ちます。WAFを利用することで、SQLインジェクションやクロスサイトスクリプティング（XSS）などの攻撃からWebアプリケーションを保護できます。

　WAFを導入することで、以下のようなメリットがあります。

・Webアプリケーションに対する典型的な攻撃から防御できる

・定期的にシグネチャを更新することで新たな脅威にも対応できる

・特定パターンの攻撃をすぐに防御する必要がある場合に、柔軟に対応できる

　一方で、WAFを導入すればすべての攻撃を防御できるわけではありません。WAFは一般的に、事前に定義された検知リスト（シグネチャ）に基づいて攻撃かどうかを判別します。そのため、シグネチャで定義されていない攻撃や、定義できないような脆弱性については防御できません。また攻撃者は、工夫してWAFを回避するような攻撃（WAFバイパス）を行うこともあります。WAFバイパスについては、このあと詳しく触れます。

　AWS WAFは、AWSが提供するマネージド型のWAFサービスです。

　AWS WAFは、AWS環境内のWebアプリケーションへのWebリクエストを監視し、許可やブロックといったルールを設定することで、攻撃からWebアプリケーションを保護します。AWSのインフラストラクチャと統合し、マネージド型のサービスとして提供され、API Gateway、CloudFront、ALBなどのAWSサービスとシームレスに連携できます。

　また、AWS WAFではマネージドルールというルールセットが提供されており、SQLインジェクションやXSSなどの一般的な攻撃パターンに対応したルールがあります。定期的に更新されるため、最新の脅威に対しても効果的です。

　WAFバイパスとは、何らかの手法を使ってWAFの機能を回避することを指します。

　WAFバイパスが可能な場合、WAFによる防御機能を回避されWebアプリケーションへ直接攻撃できるため、WAFが意味を成さない状態となります。もしWebアプリケーションに脆弱性が存在する場合、攻撃者はWAFをバイパスすることで脆弱性を悪用し、機密情報の窃取やサービスの停止などの攻撃をする可能性があります。

　WAFをバイパスする手段として考えられる方法を3つほど挙げてみます。

1.シグネチャに引っかからないような攻撃リクエストを工夫して作成する

2.WAF自体に存在する脆弱性を悪用し、防御機能を回避する

3.WAFの仕様を逆手に取って、リクエストが検査されないようにする

　このうち今回は3の「WAF仕様を逆手に取る」方法で、AWS WAFのマネージドルールを回避する方法を検証します。検証に用いた方法は、NTT東日本が実施している脆弱性診断において実際に脆弱性が検出された事例を基にしています。

　実際に検証環境を用意して、AWS WAFのバイパスができるか検証します

　MySQLに対して問い合わせるLambda関数を作成します。Lambda関数には、データベースへの問い合わせ処理を行う部分にSQLインジェクションの脆弱性を組み込みます。

　通常の処理は以下の通りです。

1.商品検索画面の検索カテゴリにカテゴリ名を入力し、検索ボタンをクリック

2.POSTメソッドのリクエストで入力したカテゴリ名を送信

3.データベースで検索した結果を含むレスポンスを受信

4.受信したデータを表示

　このLambda関数に対して、WAFを通すエンドポイントと通さないエンドポイントを用意しました。WAFによって攻撃が検知されると403レスポンスを返信し、ブラウザ画面ではalert関数が実行されるようにしています。

　WAFのルールには、マネージドルールからSQLインジェクションを検知するものを設定します。

　攻撃リクエスト（データベース内の機密データを表示させる、不正な命令を含むリクエスト）をWAFでブロックできるか確認するために、以下の検証を実施します。

・WAFを通していないエンドポイントに対して攻撃リクエストを送信

・WAFを通したエンドポイントに対して攻撃リクエストを送信

　まずは、WAFを通していないエンドポイントに対して攻撃リクエストを送信します。送信したリクエストでSQLインジェクションが成功することを確認します。

検証結果

　SQLインジェクションにより、データベース内の機密データを表示させることに成功しました。WAFを通していないため、攻撃リクエストはブロックされずにWebアプリケーションで実行されました。攻撃が成功した場合は、このように機密データが表示される結果になります。

　次に、WAFを通したエンドポイントに対して攻撃リクエストを送信します。攻撃リクエストがWAFによってブロックされた場合、403レスポンスを受信しブラウザ画面ではalert関数が実行されます。これによりWAFがSQLインジェクションの危険性のあるリクエストを検知してブロックすることを確認します。

検証結果

　SQLインジェクションによる、データベース内の機密データの表示に失敗しました。WAFによってSQLインジェクション攻撃が検知され攻撃をブロックしたことで、403レスポンスを受信しています。よって、この攻撃リクエストはWAFのマネージドルールでブロックされることが確認できました。

　AWS WAFのデフォルト設定では、リージョンのウェブACLの場合はリクエストボディの先頭8KB（CloudFrontウェブACLの場合は16KB）までしか確認しないという仕様があります。これは、公式のドキュメントにも明記されています。制限を設けているのは、過大なデータ量によるサービスのパフォーマンス低下などを防ぐ目的があると考えられます。

参考：AWS WAF でのオーバーサイズウェブリクエストコンポーネントの処理

　この仕様を利用してWAFバイパスができるか検証します。検証では図のように dummyというパラメータに8KB分のダミーデータを挿入し、そのあとに攻撃コードを記述しています。

検証結果

　WAFで攻撃を検知できず、SQLインジェクションが成功しました。よってWAFによる保護を回避できたことがわかります。

　今回の検証環境では、WebリクエストをJSON形式で送信しているため、JSONのUnicodeエスケープを使用できます。Unicodeエスケープは、Unicode文字をASCII文字で表現するための手法です。図に示すように、シングルクォートなどをエスケープすることで同じ文字列を異なる表現方法で表すことができます。

　このJSONのUnicodeエスケープを利用してWAFバイパスができるか検証します。検証では図のように、シングルクォートを\u0027に変換して行います。

検証結果

　この場合もWAFで攻撃を検知できず、SQLインジェクションが成功しました。この方法でもWAFによる保護を回避できたことがわかります。

　紹介したWAFバイパス手法を用いた攻撃の痕跡を確認する方法ですが、残念ながら調査した限りでは有効な方法が見つかりませんでした。

　今回扱った方法では、POSTメソッドで送信されるデータを細工することでWAFをバイパスしています。AWS WAFでは、デフォルトで直近3時間のリクエストログを閲覧できますが、送信されたデータの中身までは確認できませんでした。CloudWatchなどにログを送信して保持している場合、それ以前のログも確認可能ですが、同様にデータの中身までは確認できないようです。

　一方で、検証1の方法を試みた場合、リクエストのサイズは8KBを超えます。もしログにリクエストヘッダの情報が残っている場合、Content-Lengthヘッダの値が8192以上のリクエストを絞り込むことで、疑いのあるリクエストを特定できる可能性があります。（ただしファイルアップロードなどの機能がある場合は、通常のリクエストでも8KBを超える可能性があるためご注意ください）

　また、検証2の方法については、リクエストをJSON形式で送信できる場合に限定されるため、そうでない仕様の場合は心配ありません。JSONによるリクエストを許容している場合は、Webアプリケーション側でログを取得していれば攻撃を特定できる可能性がありますが、正規の通信との区別は難しいかもしれません。

　ただいずれの手段でWAFをバイパスされた場合も、Webアプリケーションの脆弱性対策が十分であれば、被害につながることはありません。

　AWS WAFのマネージドルールでは、巨大なリクエストやUnicodeエスケープには対応できませんでした。これらの攻撃を防御するにはマネージドルールに加え、以下のような独自のルールを作成することで対処できます。

独自ルール例

　リクエストのサイズが制限を超える場合に対応するため、Oversize handlingをMatchに設定します。Oversize handlingは、制限を超えるサイズのリクエストである場合にどのように処理するかを設定する機能です。この機能をMatchに設定することで、リクエストが制限サイズを超えている場合、WAFはそのリクエストをブロックします。一方でこの機能を利用した場合、サイズ超過した部分のリクエストは評価せずリクエストサイズだけでブロックしてしまうため、正規のリクエストもブロックしてしまう可能性があります。設定する場合には十分に注意を払って対応する必要があります。

　またText transformationのJSDecodeを使用すると、JSON形式の文字列内に含まれるUnicodeエスケープされた文字を元の文字に変換してから評価します。これにより、WAFはエスケープ文字が利用された攻撃も検出し、適切に遮断できるようになります。

参考：AWS WAF でのオーバーサイズウェブリクエストコンポーネントの処理

参考：テキスト変換

　ただしこうした設定を導入する場合、適切な設定をするには専門的な知見が必要となり、WAFの設定管理も複雑になります。また日々のログ監視・分析や万が一の対応まで実施する場合、さらに高度なスキルが要求されます。自社で運用しきれない場合は、SOCサービスを利用して運用を外部の専門業者に委託することも有効な選択肢となります。

　WAFを導入すればすべての攻撃を防御できるということはなく、WAFで防御できない攻撃やWAFをバイパスする攻撃などがあり、万全の対策にはなりません。IPAが公開しているWeb Application Firewallの導入に向けた検討項目では、WAFは脆弱性による被害の緩和策として位置付けられており、WAFの導入は保険的対策であるとされています。根本的な対策として、開発段階からセキュリティを考慮し脆弱性を作りこまないこと、脆弱性を発見したらレビューして修正することが重要です。

参考：安全なウェブサイトの作り方（改訂第7版）

　これにはセキュリティ・バイ・デザインという考え方が有効です。セキュリティ・バイ・デザインとは、製品の企画や設計のフェーズから情報セキュリティ対策を組み込むことで、サイバーセキュリティを確保する考え方です。実際の脆弱性診断でも、設計の段階から見直すべき脆弱性が多数発見されていることから、設計段階からセキュリティを考慮することで開発コストを抑えられると考えられます。詳細については、IPA刊行のセキュリティ・バイ・デザイン導入指南書をご覧ください。

　脆弱性とはセキュリティを脅かすシステムのバグであり、バグのないシステムを構築することは非常に困難です。脆弱性があることに気付けなければ、攻撃対象として選定され高度なテクニックを駆使して侵害されるおそれがあります。隠れた脆弱性を洗い出すには、専門的な知見と高度なスキルを持ち合わせた専門家による脆弱性診断やペネトレーションテストを受検することが望ましいです。こうした診断を受けることで脆弱性が明らかになるだけでなく、是正に関するアドバイスも受けられます。診断結果を基に検出された脆弱性と同様のバグがないかレビューし、修正をシステム全体に展開することで、脆弱性への根本対処が可能です。

　今回のコラムではAWS WAFのマネージドルールを設定するだけでは、WAFバイパスが可能となる場合があることを検証しました。公式のドキュメントに記載されている情報を基に、攻撃リクエストに少し工夫を加えるだけで、簡単にWAFを突破できてしまうことがお分かりいただけたのではないでしょうか。

　WAFはWebアプリケーションのセキュリティを強化し、脆弱性から保護を提供するのに不可欠なツールです。一方で、ただ導入しただけでは攻撃の標的とされた場合に対処が遅れることがあるため、日々の運用は必須です。運用には高度な専門知識が必要となるため、SOCサービスを利用して運用を委託することも1つの手段です。

　一方で、WAFでは防げないWebアプリケーションへの攻撃も多く存在します。こうした攻撃への対策として、セキュリティ・バイ・デザインに則った設計と発見された脆弱性の修正が重要です。システムを開発または改修したタイミングで脆弱性診断を受検し、根本的なセキュリティ対策を実施することが望ましいです。

　NTT東日本では、最新のセキュリティ情報をリアルタイムで収集・分析し、脅威を素早く検出して防御策を講じるSOCサービスとしてダイヤモンドサポートを展開しています。また、システムやアプリケーションに存在する潜在的な脆弱性を診断するソリューションも提供しています。SOC、脆弱性診断に関するご相談は、ぜひNTT東日本へお気軽にお問い合わせください！