🎐 👩🏻‍🤝‍👨🏼 👨🏽‍🌾 ハッカーの目から見たWAF 🏊 👨🏾‍🌾 🧚🏽

こんにちは、Habr！今日は、Webアプリケーションを保護するための最新のメカニズムの1つ、つまりWAF、Web Application Firewallについて説明します。最新のWAFのベースとその機能、どのバイパス方法とバイパス技術が存在するか、それらの使用方法、どのような場合でもWAFに完全に依存しない理由を説明します。 WAFの開発に一度も参加したことがなく、オープンソースから情報を収集した経験に基づいて、WAFの複雑さを疑わないようにするペンテスターの視点を提示します。

内容

はじめに
最新のWAFとは何ですか？
WAFを特定します
WAFバイパスのチートシート
実際にWAFを移動する
おわりに

この記事は非常に大規模であることが判明したため、技術専門家とWAFの使用理由を読むことに興味のない人、およびWAFのメカニズムを説明する必要のない人は、すぐに練習から回避策と例を設定することができます。

はじめに

最近、WAFは非常に人気があり、ベンダーはさまざまな価格カテゴリで多くのソリューションを提供し、小企業から大企業まで、さまざまな消費者にパッケージとオプションを提供しています。現代のWAFは、Webアプリケーションを保護するための包括的なツールと見なされ、幅広いタスクを持っているため、人気があります。そのため、Webアプリケーション開発者は、いくつかのセキュリティ問題を当てにすることができます。ただし、このソリューションは絶対的な保護を保証できません。

それで、WAFは実際のプロジェクトでその実装を正当化できるものは何でしょうか？その主な機能は、要求を検出してブロックすることです。WAF分析によれば、いくつかの異常があるか、攻撃ベクトルが追跡されます。このような分析は、正当なユーザーとWebアプリケーションとの相互作用を妨げるものではなく、同時に試行された攻撃を正確かつタイムリーに検出する必要があります。この機能を実装するために、WAF開発者は通常、正規表現、トークン、行動分析、評判分析、機械学習を使用し、多くの場合、これらのテクノロジーはすべて一緒に使用されます。さらに、WAFは他の機能も提供できます：DDoSに対する保護、攻撃者のIPアドレスのブロック、不審なIPアドレスの追跡、セキュリティヘッダーの追加（X-XSS-Protection、X-Frame-Optionsなど）、httpの追加-Cookieのみのフラグ、HSTSメカニズムの実装、CSRFトークンの機能の追加。また、一部のWAFにはJavaScriptで記述された組み込みのクライアントモジュールがあります。

もちろん、WAFはハッカーやペンテスターの仕事に多くの困難をもたらします。もちろん、攻撃者が特定のWAFをバイパスするための効果的な0day-wayを知らない限り、脆弱性の検出と悪用はより時間がかかるタスクになります。 WAFで保護されたWebアプリケーションを分析するときに自動スキャナーを使用してもほとんど役に立ちません。 WAFは、少なくともスクリプトキディからサイトを確実に保護します。ただし、適切な動機を持たない経験豊富な専門家またはハッカーも、回避策を探すのに多くの時間を費やさないことを決定する場合があります。それとは別に、Webアプリケーションがより複雑で多機能になればなるほど、攻撃される可能性のある領域は大きくなり、WAFをバイパスする方法を見つけやすくなります。

最近、監査で頻繁に異なるWAFがありますが、いくつかのケースについても以下で説明します。 2つの主なシナリオで、いくつかの独自のWAFを既にテストしました。

Webアプリケーションの特定の脆弱性を知っており、それを悪用するためにWAFを回避しようとしています。
特定の脆弱性は不明であり、タスクはWAFに関係なくそれを検出し、WAFをバイパスして悪用することです。

しかし、最初に、WAFの基本的なメカニズムを詳しく見て、これにどのような問題が存在するかを見てみましょう。

最新のWAFとは何ですか？

WAFをバイパスするさまざまな方法を効果的に検出するには、専門家は最新のクエリ分類メカニズムを理解する必要があります。各WAFは個別であり、独自の内部構造を持っていますが、分析に使用される典型的な方法がいくつかあります。それらを見てみましょう。

正規表現ルール

既存のほとんどのWAFは正規表現ルールに基づいています。それらを作成するために、いくつかの有名な攻撃のセットがWAF開発者によって研究されており、その結果、重要な構文構造は攻撃の存在が可能であるかどうかによって決まります。得られた結果に基づいて、そのような構造を見つけることができる正規表現が作成されます。すべてがシンプルに思えますが、このアプローチにはいくつかの欠点があります。正規表現の適用範囲は1つのクエリに限定され、特定のクエリパラメータに限定されることも多く、そのようなルールの有効性が明らかに低下し、そのようなメカニズムの「ブラインドゾーン」が多数作成されます。第二に、正規表現の構文、同等の構成で置き換えることができるテキストプロトコルの複雑なロジック、および異なる文字表現の使用により、そのようなルールの作成でエラーが発生します。ウラジミール・イワノフによるこのトピックに関する優れた研究があります。

スコアビルディング

このメカニズムは、ファイアウォールとウイルス対策の設計に関心のある人なら誰でも知っているはずです。それ自体では、攻撃を検出しませんが、他の方法を補完し、より正確で柔軟にします。ツールが表示される理由は、リクエストに何らかの「疑わしい」デザインが存在するだけでは、攻撃を検出するのに十分な条件ではないか、逆に多数の誤検出エラーが発生する可能性があるためです。この問題は、ポイントシステムを導入することで解決されます。たとえば、正規表現に基づく各ルールには、その操作の重要性に関する情報が補足されます。トリガーされたすべてのルールを特定した後、それらの重要性が要約されます。特定のしきい値を超えると、攻撃が検出され、リクエストがブロックされます。このメカニズムは、その単純さにもかかわらず、このクラスのタスクで実証されており、どこでも使用されています。

トークナイザー

Black Hat 2012では、攻撃を検出するこのアプローチがC / C ++ libinjectionライブラリとして導入されました。これにより、SQLインジェクション攻撃を迅速かつ正確に検出できます。現時点では、PHP、Lua、Pythonなど、さまざまなプログラミング言語用のlibinjectionライブラリのポートがあります。実際、メカニズムは、一連のトークンとして表される署名の検索に要約されます。一部の署名は組み込みのブラックリストに追加され、無効または悪意があると見なされます。つまり、リクエストを分析する前に、まずトークンのセットに導かれます。トークンは、変数、文字列、通常の演算子、不明、数値、コメント、ユニオンのような演算子、関数、コンマなど、さまざまなタイプに分けられます。このメソッドの主な欠点の1つは、次のような構造を構築できることです。トークンの不正な形成につながるため、リクエストの署名は予想とは異なります。このような構造は通常トークンブレーカーと呼ばれます。これについては後ほど説明します。

行動分析

クエリパラメータで脆弱性の悪用の試みを検出することだけがWAFタスクではありません。スキャンの試行、ディレクトリの総当たり攻撃、ファジングパラメーター、および自動化ツールでよく使用される脆弱性検出のその他の方法で明らかになる脆弱性を検索する手順を特定することが重要です。より高度なWAFは、通常のユーザーの動作に「典型的な」リクエストチェーンを構築し、標準の動作とは異なる順序でリクエストを送信する試みをブロックする方法を知っています。このメカニズムは攻撃に対抗するだけでなく、脆弱性を見つけるプロセスを複雑にします。 1分あたりのリクエスト数の制限は一般的なユーザーには影響しませんが、スキャナーが複数のスレッドで動作するための大きな障害になります。

評判分析

ファイアウォールおよびウイルス対策から直接継承された別のメカニズム。現在、ほとんどすべてのWAFには、VPNサービス、アノニマイザー、Torネットワークノード、ボットネット参加者のアドレスのリストが含まれており、疑わしいアドレスからの要求をブロックするために使用できます。より高度なWAFは、データベースを自動的に更新し、分析されたトラフィックに基づいてデータベースに追加エントリを作成できます。

機械学習

WAFで最も物議を醸す問題の1つ。このメカニズムは説明が最も難しく、これには多くの理由があります。そもそも、「機械学習」の概念自体は非常に広範であり、実際には多くのテクノロジーとテクニックが含まれていることに注意する価値があります。さらに、「機械学習」はAIメソッドのクラスの1つにすぎないと見なされます。機械学習または「AIの使用」の「実装」は、非常に人気のあるマーケティングの動きです。実際にどのメソッドやアルゴリズムが使用されているかが不明確な場合が多く、WAFでの機械学習は単なる良い言葉であると攻撃者の側から思われることもあります。機械学習の全力を実際に征服することができたマーケットプレーヤーのうち、彼らの経験を喜んで共有する人はほとんどいません。このすべてが、この問題を理解しようとする「外部からの人」にとってはかなり悲しい絵になります。それでも、入手可能な情報に基づいて、少なくともいくつかの健全なアイデアを強調するよう努めています。

第一に、機械学習は実行に基づいたデータに完全に依存しており、これは多くの場合大きな問題です。開発会社は、既存の攻撃とその適用方法を最新かつ完全に収集する必要がありますが、これはかなり困難です。このため、多くのベンダーはWAFの結果を注意深く記録し、IDS、SIEMシステムを提供する他の企業と協力して、実際の攻撃例にアクセスします。第二に、「真空中の球状のWebアプリケーション」でトレーニングされたモデルは、実際のクライアントWebアプリケーションにインストールされた場合、単純に無効になることがあります。最良の効果を得るためには、クライアントでのWAF実装の段階で追加のモデルトレーニングを実施することが正しいと考えられます。これは、追加のコスト、時間、組織上の困難を必要とし、最良の結果を保証するものでもありません。

WAFを特定します

WAF開発者は、WAFがリクエストをブロックしたことをユーザーに警告する別のアプローチを持っています。したがって、攻撃要求への応答を分析すると、WebアプリケーションによってどのWAFが保護されているかを正確に理解できます。このために、WAF指紋という用語がよく使用されます。これは、何らかの理由でWAFが更新されていない場合に役立ちます（通常、これはオープンソースWAFに適用されます）。専有のWAF開発者が顧客の面倒を見て、自動更新メカニズムを実装します。また、WAFを特定でき、最新バージョンに更新されたことが判明した場合、とにかく、特定のWAFに関する情報は、その作業の詳細について少し学ぶのに役立ちます。

WAFを識別できる主な場所をリストします。

追加のクッキー
回答またはリクエストに追加されるヘッダー
応答の内容（要求をブロックする場合）
応答コード（要求のブロックの場合）
IPアドレス（Cloud WAFを参照）
JSモジュール（クライアント側WAF）

明確にするために、いくつかの例を示します。

PT AF

ロック応答コード：403

応答ページにwaf.jsクライアントモジュールを埋め込むことができます

応答本文をロックする：

<h1>Forbidden</h1> <pre>Request ID: 2017-07-31-13-59-56-72BCA33A11EC3784</pre>

追加のヘッダーwaf.jsは次を追加します。

 X-RequestId: cbb8ff9a-4e91-48b4-8ce6-1beddc197a30

ネメシダワフ

ロック応答コード：403

応答本文をロックする：

 <p style="font-size: 16px; align: center;"> Suspicious activity detected. Access to the site is blocked. If you think that is's an erroneous blocking, please email us at <a href="mailto:nwaf@pentestit.ru">nwaf@pentestit.ru</a> and specify your IP-address. </p>

ウォールアーム

ロック応答コード：403

オプションの見出し：nginx-wallarm

Citrix NetScaler AppFirewall

追加のCookie：

 ns_af=31+LrS3EeEOBbxBV7AWDFIEhrn8A000; ns_af_.target.br_%2F_wat=QVNQU0VTU0lP TklEQVFRU0RDU0Nf?6IgJizHRbTRNuNoOpbBOiKRET2gA

Mod_Securityバージョン 2.9

ロック応答コード：403

応答本文をロックする：

 <head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access /form.php on this server.<br /></p>

Mod_Securityバージョン <2.9

ロック応答コード：406または501

応答本文をロックする：

応答本文には、mod_security、Mod_Security、またはNOYBがあります。

ニスファイアウォール

応答にビューヘッダーを追加します。

 X-Varnish: 127936309 131303037. X-Varnish: 435491096 Via: 1.1 varnish-v4

WAF開発者は、要求がブロックされた場合に返す応答コードを自分で決定します。特定のコードがあります。たとえば、要求がブロックされている場合、コード999はWeb_Knight WAFを返し、dotDefenderは空の応答本文またはエラーメッセージを含むコード200を返します。

また、WAFは、他のアプリケーションと同様に、開発および変更されることを忘れないでください。したがって、既知の「指紋」の関連性を常に確認することが重要です。さらに、開発者は他のコンテンツでブロックするときにカスタムレスポンスページを作成できます。

WAFバイパスのチートシート

WAFをバイパスする方法を見つけるという一般的な考え方は、攻撃されたWebアプリケーションがまだ理解できる形式に必要な要求を持ち込むことですが、WAFには明確ではないか、無害であると思われます。 1つのタイプのWAFは、Unicorn、Tornado、Weblogic、Lighttpdなどのエキゾチックなサーバーを含む多数の異なるタイプのサーバーに対応できる必要があることに注意することが重要です。各サーバーは、HTTPリクエストを異なる方法で解析する異なる例外的なケースを認識できます。 WAFで説明されます。したがって、攻撃者は、WAFをバイパスする方法を見つけるために、攻撃されたサーバーのHTTPリクエストの解析の詳細を使用できます。

WAFを回避するすべての可能な方法は、使用可能なWAF保護メカニズムまたはアプリケーションの分野に従って分類するのが困難です。同じ回避策を相互接続して、異なるWAFコンポーネントに同時に影響を与えることができます。また、攻撃の種類ごと、およびアプリケーションの特定の場所ごとの両方で、検出バイパス技術の適用の可能性のある大きな領域を検討する価値があります。以下に説明する手法は、オープンソースから収集され、私たち自身の研究の過程で発見され、最も効果的な手法の1つとして定着しています。 Bo0oMとTelegramのチャンネルに感謝します。

特殊文字を追加する

さまざまな特殊文字がWAFのロジックに違反し、サーバー自体に理解される可能性があります。特殊文字のバリエーションも任意です。それらはurlencode（ただし、ほとんどのWAFはこれを長い間扱ってきました）または他のエンコードに変換できます。また、エンコードせずに生の形式でリクエストに特殊文字を挿入することもできますが、これはWAFにとっては予期しないことです。たとえば、この形式の\ r \ n \ r \ nはHTTPリクエストの本体の終わりとして認識される可能性があり、nullバイトは通常、さまざまなデータ形式の正規表現およびパーサーのロジックに違反する可能性があります。 ASCIIテーブルの最初の20文字からの他の特殊文字も有用です。

便利な特殊文字の例：

0x00-ヌルバイト。
0x0D-キャリッジリターン。
0x0A-改行;
0x0B-垂直タブ。
0x09-水平タブ。
0x0C-新しいページ

バイパスを検索する場合、値にパラメーターを含めることに限定されず、リクエスト本文のさまざまな場所に特殊文字を挿入すると便利です。たとえば、リクエストがJSON形式で提示される場合、JSONの最初と最後の両方で、パラメーターの1つとパラメーターの両方にnullバイトを挿入できます。同じことは、POST要求の本文の他の形式にも当てはまります。一般的には、WAFが確認または解析できる場所を探し、そこにあるさまざまな特殊文字を試して、楽しむことをお勧めします。

例：

 {"id":1337,"string0x00":"test' or sleep(9)#"} {"id":1337,"string":"test'/*0x00*/ or sleep(9)#"} {"id":1337,"string"0x0A0x0D:"test' or sleep(9)#"}

 <a href="ja0x09vas0x0A0x0Dcript:alert(1)">clickme</a> <a 0x00 href="javascript:alert(1)">clickme</a> <svg/0x00/onload="alert(1)">

 id=1337/*0x0C*/1 UNION SELECT version(), user() --

明確にするために、特殊文字を16進表記に置き換えました。

空白の置換

別のカテゴリでは、スペースを同等の文字に置き換えることを強調する価値があります。たとえば、ほとんどの構文では、キーワードと演算子を空白で区切りますが、使用する文字を厳密に示しているわけではありません。したがって、通常の0x20 （スペース）、 0x0B （垂直タブ）、 0x09 （水平タブ）の代わりに使用できます。また、このカテゴリには、セマンティックの負荷を持たない分離構造による空白文字の置換を含める必要があります。たとえば、SQLでは、これは/ ** / （複数行のSQLコメント）、 ＃\ r \ n （改行で終わる単一行のSQLコメント）、 -\ r \ n （改行で終わる代替の単一行のSQLコメント）です。以下に例を示します。

 http://test.com/test?id=1%09union/**/select/**/1,2,3 http://test.com/test?id=1%09union%23%0A%0Dselect%2D%2D%0A%0D1,2,3

言語構文を使用してスペースを削除するように、式を変更することもできます。たとえば、SQLでは、括弧を使用できます。

 UNION(SELECT(1),2,3,4,5,(6)FROM(Users)WHERE(login='admin'))

そして、JSでは/文字を使用します。

 <style/onload=confirm(1)>

エンコーディングの変更

この方法は、WAFが特定の場所でデータをデコードしないように、さまざまなエンコーディングの使用に基づいています。たとえば、1つの文字をそのURLコードで置き換えた後、WAFはデータをデコードする必要があることを理解できず、リクエストをスキップしますが、同じパラメーターが受け入れられ、Webアプリケーションによって正常にデコードされます。

HTML文字の10進表記： ＆＃106または＆＃0000106 。 WAFは（最初のバージョンのように）文字の短い表現を知っているかもしれませんが、ゼロを追加したオプションについては知らないので、文字の総数は7を超えてはいけません。同様に、HTML文字の16進表現： ＆＃x6Aまたは＆＃x000006A 。

また、 \文字を使用して一部の文字をエスケープするトリックもあります。次に例を示します。

 <svg/on\load=a\lert(1)>

ただし、これはWebアプリケーションがそのような入力を処理する方法に依存します。つまり、文字シーケンス\ lはエスケープされたlとして解釈され、1文字に変換されますが、WAFは各文字を個別に認識できます。したがって、WAFにはキーワードが表示されません。この手法を使用すると、文字\ n 、 \ r 、 \ tをエスケープできません。これらの文字は、改行、キャリッジリターン、およびタブというまったく異なる文字に変換されるためです。

HTMLエンコードは、タグプロパティ内でも使用できます。次に例を示します。

 <a href="javascript&colon;alert(1)">clickme</a> <input/onmouseover="javascript&colon;confirm&lpar;1rpar;">

そのような文字の代わりに、ターゲット文字の他のHTML表現を置き換えることは完全に可能です。さまざまな文字変換オプションがここにあります。

HTMLエンコードに加えて、\ uを使用して文字を挿入できます。

 <a href="javascript:\u0061lert(1)">Clickme</a> <svg onload=confir\u006d(1)>

また、特殊文字の挿入に関連するベクトルに触れます。 HTMLエンコードでペイロードを壊しましょう：

 <a href="ja&Tab;vas&#x0000A;cript:alert(1)">clickme</a>

この場合、他の区切り文字に置き換えることができます。

したがって、たとえば、特殊文字をエンコードするために、さまざまなエンコードを他の方法と組み合わせることをお勧めします。

非定型の同等の構文構成要素を検索する

この方法は、WAF開発者によって考慮されていない可能性のある操作方法を見つけること、またはベクトルが機械学習のトレーニングセットから欠落していることから成ります。一部のjavascript関数は、単純な例として指定できます：this、top self、parent、frames、tagプロパティ：data-bind、ontoggle、onfilterchange、onbeforescriptexecute、onpointerover、srcdoc、およびSQLステートメント：lpad、field、bit_count。

以下に例を示します。

 <script>window['alert'](0)</script> <script>parent['alert'](1)</script> <script>self['alert'](2)</script>

 SELECT if(LPAD(' ',4,version())='5.7',sleep(5),null);

JavaScript式の文字フリー表現を使用することもできます。

このJSのビューに関する明らかな問題は、結果のペイロードが長いことです。

これとは別に、この手法を使用したWAFのバイパスは、特定の攻撃と使用中のテクノロジースタックに依存することに注意してください。例は、センセーショナルなエクスプロイトImageTragickの状況です。

この攻撃から保護するためのほとんどのWAFは、この脆弱性を説明するほとんどの記事およびPoCで使用されているキーワードurl、capacity、labelをブラックリストに載せました。しかし、これらのキーワードに加えて、一時的なもの、パンゴなど、他のキーワードも使用できることがすぐにわかりました。その結果、これらのキーワードをベクターとして使用してWAFを回避できました。

HTTPパラメーター汚染（HPP）およびHTTPパラメーター断片化（HPF）

HPP攻撃では、サーバーが同じ名前のパラメーターを処理する機能を使用します。 WAFの可能な回避策は次のとおりです。

サーバーは最後に受け取ったパラメーターを使用し、WAFは最初のパラメーターのみをチェックします

サーバーはすべて同じパラメーターの値を結合し、WAFはそれらを個別にチェックします。次の表を使用して、異なるサーバー間で同じパラメーターを処理する際の違いを比較できます。

次に、HPF攻撃は、Webアプリケーションのロジックがリクエスト内の2つ以上のパラメーターを組み合わせる場合、攻撃者がリクエストを部分に分割し、それによって一部のWAFチェックをバイパスできるという事実から成ります。

このような攻撃の例は、次の形式のSQLインジェクションです。

 http://test.com/url?a=1+select&b=1+from&c=base

HPFとHPPは非常によく似た攻撃ですが、最初の攻撃がWebアプリケーションを対象としている場合、2番目の攻撃はそれが機能する環境に対するものです。これらの手法を同時に使用すると、WAFを回避する可能性がさらに高まります。

Unicode正規化

Unicodeには、Unicode正規化という1つの機能があります。これは、スペルが似ている一部のUnicode文字を比較できるようにするために行われました。たとえば、文字「 '」と「ᵃ」には異なるコードがありますが、もはや違いはなく、正規化後は両方とも単純な文字になります'と同じと見なされます。正規化を使用すると、一部の複雑なUnicode文字をより単純なUnicode文字に変換できます。すべての可能なUnicode文字が、可能な正規化とともに示されている表があります。その助けを借りて、さまざまなペイロードを作成し、他の方法と組み合わせることができます。ただし、これはすべてのWebアプリケーションで機能するわけではありません。

たとえば、上の表では、文字＜

と﹤

文字<

変換されることがあります。ただし、アプリケーションが正規化後にHTMLエンコードを使用する場合、おそらく正規化後に取得される<

文字は<

エンコードされるため、正規化の段階が重要であることに注意してください<

。ただし、別のケースでは、開発者はこの機能を考慮に入れず、Unicode文字をエンコードできませんでした。したがって、XSSに変換できるエンコードされていない<および>文字を取得します。また、WAFにはUnicode文字の理解に問題がある場合があり、そのようなトリックのルールがない場合があり、機械学習も無力な場合があります。 Unicode正規化を使用するWebアプリケーションでWAFの回避策を見つけた場合、 <>文字だけでなく、ペイロードのその他の文字も変更できます。

例：

 ＜img src﹦x onerror＝alert︵1)>

Rockstarは最近、HackerOneでもこの問題を発見しましたが、WAFはなく、ユーザー入力の厳密なフィルタリングのみがありました。

hackerone.com/reports/231444

hackerone.com/reports/231389

トークンブレーカー

トークンに向けられた攻撃は、いわゆるトークンブレーカーを使用してリクエストをトークンに分割するロジックを破ろうとする試みに関連しています。これらは、特定のトークンへの文字列要素の対応の選択に影響を与え、それによって署名による検索をバイパスできるようにするシンボルです。トークンブレーカーを使用した攻撃の例は、次のクエリです。

 SELECT-@1,version()

ここで-@ -これはトークンブレーカーです。

パブリックドメインには、mysqlファジングによって取得され、libinjectionでリクエストをチェックすることにより得られるチートシートがあります。

libinjectionで問題を見つけるというトピックは新しいものではなくなりました;詳細はここにあります：

別のフェイザー

記事の時間

記事2

RFC機能の使用

HTTP / 1.1プロトコルおよびさまざまな要求形式（multipart / form-dataなど）の仕様では、ヘッダーとパラメーターを処理する際の境界ケースまたはトリックに関連する興味深い点を見つけることができます。 WAF開発者は、そのような瞬間を考慮に入れないことがよくあります。その理由は、WAFが要求を誤って解析し、攻撃ベクトルが隠されている可能性のあるデータの一部を失う可能性があるためです。 WAFの問題のほとんどは、multipart / form-dataの処理と、そのようなリクエストのパラメーターの境界を定義する境界パラメーターの特定の値に関連しています。さらに、サーバー開発者もミスを犯す可能性があり、仕様を常に完全にサポートしているわけではありません。そのため、サーバーのHTTPパーサーに文書化されていない機能があります。

前述のように、multipart / form-dataを使用したHTTP要求の境界パラメーターは、要求本文のさまざまなパラメーターを区切る役割を果たします。 RFCによれば、新しい各POSTパラメーターの前に、「-」を含むプレフィックスを持つ以前に指定された境界が示されるため、サーバーはさまざまな要求パラメーターを区別します。

 POST /vuln.php HTTP/1.1 Host: test.com Connection: close Content-Type: multipart/form-data; boundary=1049989664 Content-Length: 192 --1049989664 Content-Disposition: form-data; name="id" 287356 --1049989664--

攻撃は、境界パラメーターが空白のままの場合、サーバーとWAFが状況を異なる方法で処理することです。 RFCに基づいて、この状況では、パラメーター間の境界は文字シーケンス「-」になります。ただし、WAFでは、この機能を考慮しないパーサーを使用できます。このため、POST要求のパラメーターからのデータはアナライザーに入らないため、WAFは要求をスキップします。 Webサーバーは、この状況を問題なく解析し、処理のためにデータをさらに転送できます。

 POST /vuln.php HTTP/1.1 Host: test.com Connection: close Content-Type: multipart/form-data; boundary= Content-Length: 192 -- Content-Disposition: form-data; name="id" 123' or sleep(20)# ----

ZeroNights 2016でのBo0omのレポートから、さらに興味深い例を挙げて説明します。

 POST /vuln.php HTTP/1.1 Host: test.com Content-Type: multipart/form-data; boundary=FIRST; Content-Type: multipart/form-data; boundary=SECOND; Content-Type: multipart/form-data; boundary=THIRD; --THIRD Content-Disposition: form-data; name=param UNION SELECT version() --THIRD--

この攻撃では、WAFが受け入れる境界パラメーターとWebサーバーを決定しようとしています。したがって、WebサーバーとWAFが異なる境界パラメーターを受け入れる場合、WAFが認識しない最終境界を指定することで攻撃を実行することができます。このような攻撃はHPPにいくらか似ています。

 POST /vuln.php HTTP/1.1 Host: test.com Content-Type: multipart/form-data; xxxboundaryxxx=FIRST; boundary=SECOND; --FIRST Content-Disposition: form-data; name=param UNION SELECT version() --FIRST--

この攻撃は、WAFとWebサーバーの間でHTTPリクエストを解析する際に考えられる別の違いのために設計されています。違いは次のとおりである必要があります。Webサーバー側のパーサーは「境界」の最初の出現を検索し、記号「=」を検索し、その後でのみ境界の値を決定し、WAFパーサーは文字列「境界=」の出現のみを検索してから決定します境界値。これらの条件が満たされている場合、そのような要求を受信すると、WAFは指定された境界を見つけることができず、したがって、パラメーターを見つけて分析することができません。 Webサーバーは要求を受信し、パラメーターを処理します。この攻撃は、Webサーバーパーサーがエントリ「boundary =」を探しており、WAFパーサーが「境界」のみを探している場合に機能します。この場合、実際の境界をFIRSTからSECONDに変更するだけです。

 POST /somepage.php HTTP/1.1 Host: test.com Content-Type: multipart/form-data; boundary=Test0x00othertext; --Test Content-Disposition: form-data; name=param Attack --Test--

この攻撃は、特殊文字の追加にも関連しています。 Webサーバーが境界パラメーターをNULLバイトにトリムし、WAFが全体としてそれを受け入れると想定して、境界パラメーターにNULLバイトを追加しました。この場合、境界を見つけられないため、WAFは再びパラメーターを分析できません。

機械学習のバイパス

バイパスの本質は明らかです-訓練された統計モデルのパラメーターを満たすような攻撃を行うこと。ただし、どのWAFサンプルがどのようにトレーニングされたかに大きく依存します。抜け穴が見つかることもあれば、原則として迂回ができないこともあります。通常、機械学習を備えたWAFをクライアントに展開する場合、クライアントのWebアプリケーションで受信したリクエストに基づいた追加のトレーニングが必要です。そして、ここでのペンテスターの問題は、次のようなものである可能性があります：同じ外観を持っているか、要求ごとに大きく変化しないパラメーターは、通常の形式のパラメーターから離れたステップがすでに異常として認識されている可能性があるため、何らかの方法でテストすることは不可能です。例で説明しましょう。 http://api.test.com/getuser?id=123

への条件付きリクエストがある場合、idパラメーターは常に数値であり、トレーニングセットでも常に数値のままです。機械学習モジュールがこのパラメーターの数値以外を検出した場合、これは異常であると判断する可能性が最も高くなります。また、別のケースでは、WAFが、マークダウンを持つPOSTパラメーターを使用してhttp://api.test.com/setMarkDown

へのPOST要求を分類することを学習したとします。もちろん、引用符と特殊文字、そして実際には他のものは、マーケットダウンに存在する可能性があります。この場合、WAFは引用符と特殊文字を許容するため、機械学習モジュールのバイパスがはるかに簡単になります。

また、実践の例を使用して、上記の回避策が原因の解析パラメーターの問題により、ビジネスが機械学習モジュールに常に到達するとは限らないことを示します。

一般に、テストされたリクエストとその中のパラメーターの詳細を考慮し、WAFが許容できるパラメーター値の可能なバリエーションを想定して、それらから開始する必要があります。

WAFはいつ役に立ちませんか？

WAFはクエリを分析し、クエリの異常な動作を探すことを目的としていますが、WAFが検出できない脆弱性のクラスがいくつかあります。論理的な脆弱性である可能性があります。この場合、リクエストには異常な動作はありませんが、Webアプリケーションのロジックに違反するアクションがいくつかあります。 WAFは、競合状態、IDOR、安全でないユーザー認証などの脆弱性の識別にも役に立たない可能性があります。

既存のアプリケーション

WAFをバイパスする方法の検索を自動化するために、この分野の愛好家によって書かれたいくつかのツールがあります。

注目すべき最も興味深いものは次のとおりです。

電球フレームワークは、WAFで保護されたWebアプリケーションをテストするためのフレームワーク全体です。Pythonで書かれており、さらにBurp Suiteのプラグインとして移植されています。その主な機能は2つのアルゴリズムです。

GOFAはアクティブな学習アルゴリズムであり、Webアプリケーションのフィルタリングとサニタイズのパラメーターを分析できます。
SFADiffは、シンボリック有限状態マシン（SFA）を使用したトレーニングに基づくブラックボックス差分テストアルゴリズムです。これにより、Webアプリケーションの動作の違いを見つけることができます。これにより、WAFを識別し、回避策を見つけることができます。

Bypass WAFはBurp Suiteのプラグインです。これにより、HPP攻撃の自動化など、不必要な困難を伴うことなく、さまざまなルールおよびコーディングの変更に従って、リクエスト本文の要素に自動変更を構成できます。

WAFW00Fは、Pythonで書かれたWAF認証プログラムです。それはかなり良いWAFベースを持ち、今日までサポートされています。ただし、さまざまなWAFはプロジェクト自体が更新されるよりもはるかに高速に更新されるため、結果は依然として不正確になる可能性があります。

実際にWAFを移動する

私たちは練習から実際の事例に目を向けます。サイトがPT AFによって保護されているオンラインストアの監査を実施しました。 WAFのため、脆弱性を発見し、そこからビルドして回避策を探すことは困難でした。しかし、すぐに、WAFがフィルタリングしなかったWebアプリケーションの一部で非標準の動作が発見されました。購入した商品の履歴の検索機能で異常が見つかりました。これは次のもので構成

されていました。リクエストはJSON形式で送信され、次のようになりました。

 {"request":{"Count":10,"Offset":0,"ItemName":"Phone"}}

ItemNameパラメーターの値Phone 'およびPhone' + 'を代入すると、これら2つのケースのサーバーが異なる応答を返すことがわかりました。Phone 'からのリクエストへの応答は空で、Phone' + 'からのリクエストへの応答には、ItemNameパラメータの値がPhoneのみであるかのように、名前にPhoneという単語が含まれる同じ製品データが含まれていました。この動作は多くのハッカーやペンテスターによく知られており、Webアプリケーションでのユーザー入力のフィルタリングに問題があることを明確に示しており、SQLインジェクションを引き起こします。

なぜわからないのか、SQLインジェクションの例でこれが起こる理由を説明しましょう。ポイントは、この動作がWebアプリケーションで検出された場合、ほとんどの場合、SQLクエリのデータはクエリ自体と単純に連結し、最初のケースではPhone 'パラメーターを渡すとSQLクエリが生成されるということです。

 SELECT item FROM items WHERE item_name='Phone''

このようなリクエストは、構文が正しくないため明らかに実行されず、結果を返しません。そして、Phoneパラメーター'+'を持つ2番目のリクエストは、次のようになります。

 SELECT item FROM items WHERE item_name='Phone'+''

このようなリクエストは正しい構文を持ち、Phoneという名前の製品を選択します。

この脆弱性を検出する方法は、WAFで保護されているWebアプリケーションをテストするときに大きな利点があります。単一引用符文字は、ほとんどの最新のWAFではパラメーターの十分な異常とは見なされず、それを伴う要求をスキップします。

検出を見つけましたが、今度はWAFをバイパスして脆弱性を悪用する方法を教えてください。いくつかの回避策を整理した後、調査中のWAFで問題が見つかりました。 WAFはJSONパラメーターに追加された特殊文字に対して脆弱であることが判明しました。基本的に、JSONテキストフィールドに\ r \ n文字を代入するエンコードなしの生の形式で、WAFは単にリクエストを渡し、Webアプリケーションはデータが正しいと見なして処理しました。どうやら、問題はJSONパーサーであり、特殊文字とJSONパーサーがこれらの文字が現れる場所に正確に現れるように設計されていなかったようです。したがって、WAFアナライザーは完全な要求を受信せず、特殊文字の後に特殊な攻撃ベクトルを挿入できます。改行に加えて、他の特殊文字、たとえばヌルバイトも機能しました。その結果、次のクエリを作成することができました。実際、このクエリ全体を検証しようとするとWAFがオフになりました（改行文字と復帰文字はテキスト表現に置き換えられました）。

 {"request":{"kill-waf":"die\r\n", "Count":10,"Offset":0,"ItemName":["'+(SELECT 'Phone'+CHAR(ASCII(substring(@@version,1,1))-24))+'"]}}

その結果、脆弱性の有無についてすべてのパラメーターを迅速かつ便利にテストすることができました（その結果、他のクエリでまだいくつかが見つかりました）。 WAFをバイパスしてこのインジェクションを悪用すると、Webアプリケーションのすべてのユーザーが完全に侵害されました。

Nemesida WAFでも同様の問題が見つかりました。唯一の違いは、リクエストがJSON形式ではなく、パラメーター付きの通常のPOSTリクエストであり、Webアプリケーションのパラメーター自体が数値としてSQLクエリに置き換えられたことです。残念ながら、Nemesida WAFの開発者は現時点で公開を禁止しているため、現時点では技術的な詳細を公開することはできません。ただし、後で公開します。問題はPentestitに報告され、修正されました。

ご覧のとおり、WAFは非常に近代的で非常にインテリジェントですが、残念ながら1つの特殊文字を挿入するだけでバイパスできる場合があります。ここでの問題は、現時点ではWAFで、可能なすべてのサーバーの可能な入力データのすべてのオプションを配置することは不可能であり、機械学習はWAFで必要なものであり、パーサーでつまずき、一部の特殊文字が見えることです恐ろしい。

おわりに

だから、WAFに完全に依存する価値はありますか？答えはノーです。

残念ながら、すべての開発者がこれを理解しているわけではなく、何らかの理由でWAFをハッカーからの特効薬と考えています。たとえば、監査の1つで、WAFをバイパスする方法も発見しました。これにより、脆弱性を悪用できるようになりました。監査後に学んだように、開発者は既にWAFで保護されていないWebアプリケーションを監査しており、前回の監査でこれらの脆弱性はすでに発見されていましたが、それらを閉じる代わりに、機械学習を備えた最新のWAFを購入することにしましたそして彼に完全に依存しています。 Webアプリケーション開発者が既知の脆弱性を修正することをWAFベンダーが主張しなかったことは残念です。または、開発者自身が、コード内のバグを修正するよりもWAFの方が優れていると判断しました。しかし、詳細はわかりません。いずれにせよ、これらはどちらもWAFベンダーの非常に悪い習慣であり、開発者から。

また、WAFでの機械学習はブラックボックスのままですが、実際の効果的な保護方法というよりもマーケティングの動きとして認識されることに注意してください。

全体的に、Webアプリケーションファイアウォールは最新の優れたセキュリティツールであり、Webアプリケーションにとって冗長になることはありません。しかし、現時点では、WAFが脆弱性とその悪用の検索を複雑にするだけであり、脆弱性を完全に軽減するわけではないことを覚えておく必要があります。そして、この状況は、どうやら、長い間続くでしょう。これらの脆弱性を引き起こすコードを修正することによってのみ、Webアプリケーションの脆弱性を取り除くことができます。そうしないと、何も、誰もあなたを保護しません。

彼らはWAFを巡り、資料を収集しました：

Bulatov Ilya barracud4

Rybin Denisthefaeriedragon

Romanov Alexander web_rock

ハッカーの目から見たWAF

内容