IDS署名に問題があります

SnortおよびSuricata IDSという名前は、ネットワークセキュリティの分野で働くすべての人によく知られています。 WAFとIDSは、ネットワークトラフィックを分析し、最高レベルのプロトコルを解析し、悪意のあるまたは不要なネットワークアクティビティを通知する2つのクラスのセキュリティシステムです。 最初のシステムがWebサーバーが特定の攻撃のみを検出および回避するのに役立つ場合、2番目のIDSはすべてのネットワークトラフィックで攻撃を検出できます。



多くの企業がIDSをインストールして、企業ネットワーク内のトラフィックを制御しています。 DPIメカニズムにより、トラフィックフローを収集し、IPからHTTPおよびDCERPCへのパケットの内部を調べ、脆弱性の悪用と悪意のあるプログラムのネットワークアクティビティの両方を特定します。



両方のシステムの中心である既知の攻撃を識別するための署名セットは、ネットワークセキュリティの専門家と世界中の企業によって開発されています。 @attackdetectionチームである私たちは、ネットワーク攻撃や悪意のある活動を検出するための署名も開発しています。 記事の残りの部分では、IDS Suricataシステムを混乱させ、そのような活動を隠す可能性があることがわかった新しいアプローチに焦点を当てます。

IDSの仕組み

このIDS回避方法の詳細と、発見された方法が適用される段階に進む前に、IDS操作の一般原則の理解を更新する必要があります。







まず、着信トラフィックはTCP、UDP、またはその他のトランスポートストリームに分割され、その後、パーサーがそれらをマークし、高レベルのプロトコルとそのフィールドに分割します-必要に応じて正規化します。 結果のデコード、拡張、および正規化されたプロトコルフィールドは、ネットワークトラフィックの中に悪意のあるアクティビティに固有のネットワーク攻撃またはパケットがあるかどうかを識別するシグネチャセットによってチェックされます。



ちなみに、署名セットは多くの個人研究者や企業の製品です。 Cisco Talos、Emerging Threatsなどのベンダーから名前が見つかります。また、オープンルールセットには20,000を超えるアクティブなシグネチャがあります。

一般的なIDSの回避策

ソフトウェアのIDSの不完全性とエラーにより、ネットワークトラフィックの攻撃を検出できない条件を見つけることができます。 ストリーム分析の段階を回避するためのかなりよく知られた手法の中で、次のものをリストできます。

• IP、TCP、または、たとえばDCERPCでの非標準のパケットフラグメンテーション。IDSは時々処理できません。
• 境界線または無効なTTLまたはMTU値を持つパケットも、IDSによって誤って処理される場合があります。
• 重複するTCPフラグメント（TCP SYN）の認識のあいまいさは、このTCPトラフィックが意図されたサーバーまたはクライアントとは異なる方法でIDSによって解釈される可能性があります。
• たとえば、チェックサムが正しくない（いわゆるTCP非同期）偽のTCP FINパケットは、無視されるのではなく、セッションの終了と見なすことができます。
• IDSとクライアント間のTCPセッションのさまざまなタイムアウトも、攻撃を隠すツールとして機能します。

プロトコル解析およびフィールドの正規化フェーズに関しては、多くのWAFバイパス手法をIDSに使用できます。 それらの数ははるかに大きいため、そのうちのいくつかのみを示します。

• HTTPダブルエンコーディング。
• 対応するContent-EncodingヘッダーのないHTTPパケットのGzip圧縮は、正規化段階ではまだ圧縮されていない場合があります。このような手法は、マルウェアのトラフィックで見つかることがあります。
• POP3 / IMAPプロトコル用のQuoted-Printableなどのまれなエンコードを使用すると、一部の署名が無力になる可能性もあります。

構成内の各ベンダーIDSまたはサードパーティライブラリに固有のバグを忘れないでください。これらは、パブリックバグトラッカーで見つけることができます。

特定の条件下で署名チェックを無効にすることを可能にするこれらの特定のバグの1つは、Suricata IDSの@attackdetectionコマンドによって発見され、このエラーを悪用して、たとえばBadTunnelなどの攻撃を隠すことができます。



この攻撃中、脆弱なクライアントは攻撃者によって生成されたHTMLページを開き、それによって両側のポート137に対してネットワーク境界を介して攻撃者サーバーへのUDPトンネルを確立します。 トンネルが確立された後、攻撃者は脆弱なクライアントのネットワーク内で名前を偽装し、NBNS要求に偽の応答を送信する機会を得ます。 3つのパケットが攻撃者のサーバーに送られたという事実にもかかわらず、攻撃者がそのうちの1つだけに応答してトンネルを確立するのに十分でした。



見つかったエラーは、クライアントからの最初のUDPパケットへの応答がICMP宛先不明などのICMPパケットであった場合、不正確なアルゴリズムが原因で、このストリームはICMPプロトコルの署名のみでチェックされるようになったことです。 名前のなりすましを含むそれ以上の攻撃は、UDPトンネルを介して実行されたため、IDSに気付かれませんでした。 この脆弱性に対するCVE番号はありませんでしたが、IDSのセキュリティ機能を回避しました。







上記のバイパス手法は古くから知られており、最新の開発中のIDSで修正されており、特定のバグと脆弱性はパッチを当てていないバージョンでのみ機能します。



私たちのチームはネットワークセキュリティとネットワーク攻撃の研究に取り組み、ネットワーク署名を直接開発およびテストするため、署名自体とその欠陥に関連する回避策に注意を向けざるを得ません。

署名の回避

待って、どうやって署名が問題になるの？



研究者は新たな脅威を研究し、運用上の機能やその他のネットワークアーティファクトによって特定の攻撃がネットワークレベルでどのように検出されるかについて理解を深め、結果のビューをIDSフレンドリーな言語の1つ以上の署名に変換します。 システムの機能が制限されているか、研究者のエラーが原因で、脆弱性を悪用する発見されていない方法が残っています。



同じマルウェアファミリのプロトコルとメッセージの形式とその生成が変わらず、シグネチャがそれらに対してうまく機能する場合、脆弱性を悪用する場合、プロトコルの複雑さとその変動性が高いほど、攻撃者が機能を失うことなくエクスプロイトを変更しやすくなり、シグネチャをバイパスします。

最も危険で知名度の高い脆弱性については、さまざまなベンダーからの質の高い署名が多数見つかりますが、他のいくつかの署名は簡単なトリックで回避できます。 HTTPプロトコルの非常に一般的な署名エラーの例を挙げましょう。署名検証をバイパスするには、HTTP GET引数の順序を変更するだけで十分な場合があります。









そして、たとえば「？Action = checkPort」または「action = checkPort＆port =」のように、署名に引数の順序が固定された部分文字列チェックが含まれていると思う場合は正しいでしょう。 署名を注意深く調べて、同じハードコードがあるかどうかを確認するだけです。



確認するのが難しくない他のプロトコルと形式は、たとえば、DNS、HTML、またはDCERPCであり、その変動性は非常に高くなっています。 したがって、すべての攻撃および開発のバリエーションのシグネチャを高品質だけでなく高速のシグネチャでカバーするには、開発者はネットワークプロトコルに関する幅広いスキルと確固たる知識を持っている必要があります。



IDS署名の不完全性については長い間議論されてきましたが、他の著者の意見はそのレポートで見つけることができます： 1、2、3 。

署名の重量はいくらですか？

既に述べたように、署名の速度は開発者の責任にあり、署名が多いほど検証に多くのコンピューティングリソースが必要になるのは当然です。 中間原則では 、Suricata IDSの場合、1000個のシグネチャごと、またはネットワークトラフィックの0.5ギガビットごとに1つのCPUを追加することを推奨しています。









ここで、署名の数とネットワークトラフィックの量への依存。 この式は完全に見えますが、署名が高速であったり低速であったり、トラフィックが非常に多様であったりするという事実は考慮されていません。 それでは、遅い署名が悪いトラフィックにヒットしたらどうなりますか？



Suricata IDSは、署名のパフォーマンスデータをログに書き込むことができます。 最も遅いシグネチャに関するデータがそこに到達し、その実行時間を示すトップを形成します。これは、ティックで表されます-CPU時間とチェック数。

雑誌の一番上には、最も遅い署名があります。







専用の署名は、低速と呼ばれるものです。 上部は常に更新されており、さまざまなトラフィックプロファイルでは、他の署名で構成されている可能性が高いです。 これは、署名が一般に、特定の順序で配置された部分文字列や正規表現の検索などの単純なチェックのサブセットで構成されるためです。 ネットワークパケットまたはストリームをチェックするとき、署名はすべての有効な組み合わせのすべてのコンテンツをチェックします。 したがって、同じシグニチャの検証ツリーはより分岐している場合や少ない場合があるため、実行時間は分析されたトラフィックによって異なります。 開発者のタスクは、とりわけ、可能なトラフィックで動作するように署名を最適化することです。



IDSの電源が正しく選択されておらず、すべてのネットワークトラフィックのチェックに対応していない場合はどうなりますか？ 原則として、CPUコアの負荷が平均で80％を超える場合、IDSはすでにいくつかのパケットのチェックをスキップし始めています。 カーネルの負荷が高いほど、ネットワークトラフィックに未確認の場所が多く表示され、悪意のあるアクティビティが気付かれない可能性が高くなります。



署名がネットワークパケットを長時間チェックするときにこの効果を高めようとするとどうなりますか？ このような操作スキームでは、ゲームからIDSを削除して、パケットと攻撃を強制的にスキップする必要があります。 そもそも、ライブトラフィックのトップシグネチャを既に取得しており、それらに対する効果を高めようとしています。

営業しています

これらのシグネチャの1つは、トラフィックの脆弱性CVE-2013-0156 RoR YAML Deserialization Code Executionを不正利用する試みを識別します。







企業WebサーバーへのすべてのHTTPトラフィックは、「type」、「yaml」、「！Ruby」という厳密な順序で3行が存在するかどうかを確認し、正規表現で確認します。



「悪い」トラフィックの生成を開始する前に、これに役立ついくつかの仮説を示します。

• 部分文字列の一致を見つけることは、そのような一致がないことを証明するよりも簡単です。
• IDS Suricataの正規表現チェックは、部分文字列を見つけるよりも時間がかかります。

つまり、署名からの長いチェックが必要な場合、これらのチェックは失敗し、正規表現を使用する必要があります。



正規表現による検証を行うには、パッケージに3つの部分文字列が次々に存在する必要があります。







これらをこの順序で接続し、IDSを実行して検証を試みます。 テキストからPcap形式のHTTPトラフィックでファイルを構築するために、 Cisco Talos file2pcapツールを使用しました。







別のkeyword_perf.logログを使用すると、チェックチェーンが正常に到達（コンテンツ一致-3）し、正規表現（PCRE）と失敗（PCRE一致-0）に到達したことがわかります。 さらに高価なPCREチェックの恩恵を受けたい場合は、完全に分解して有効なトラフィックを選択する必要があります。











正規表現をリバースエンジニアリングするタスクは、手動で実行するのは簡単ですが、たとえば、後方参照や名前付きキャプチャグループなどの構造のため、自動化が不十分です。あらゆる種類の正規表現を正常に渡すための文字列を自動的に選択する方法は見つかりませんでした。







このような式に最低限必要な文字列は、次の構成でした。 失敗した検索は成功した検索よりも費用がかかるという仮説をテストするには、この行から右端の文字を切り取り、通常の検索を再度実行します。

<a type="yaml" !ruby : 32 steps, match <a type="yaml" !rub : 57 steps, no match
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同じ原則が正規表現にも当てはまることがわかります。失敗したチェックは、成功した対応よりも多くのステップを踏みました。 この場合、差は50％以上でした。 あなた自身で見ることができます。



別の興味深い事実は、この正規表現のさらなる研究で発見されました。 最後の文字なしで必要最小限の行を繰り返し複製する場合、テストを完了するためのステップ数の増加を期待するのは合理的ですが、そのような成長の依存性は完全に爆発的です：

 2 x (<a type="yaml" !rub) : 209 steps 10 x (<a type="yaml" !rub) : 9885 steps 100 x (<a type="yaml" !rub) : timeout
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

数十のそのような行をチェックする時間はすでに約1秒であり、その数を増やすと、タイムアウトエラーが発生します。 正規表現でのこの効果は、破局的バックトラッキングと呼ばれ、 Habréを含む多くの記事がそれに取り組んでいます。 このようなエラーは、今日まで一般的な製品に見られます。 たとえば、最近Apache Strutsフレームワークで発見されました。



見つかった行をSuricata IDSに戻し、チェックします。

  Keyword Ticks Checks Matches -------- -------- ------- -------- content 19135 4 3 pcre 1180797 1 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、ファンファーレと致命的なバックトラッキングの代わりに、IDSの負荷はほとんど目立たず、わずか100万ティックです。 これは、デバッグ後、Suricata IDSのソースコードと内部で使用されるlibpcreライブラリを調べた後、PCREの制限に遭遇したことに関するストーリーです。

• MATCH_LIMIT DEFAULT = 3500
• MATCH_LIMIT_RECURSION_DEFAULT = 1500

これらの制限は、多くの正規表現ライブラリで正規表現が災害に陥ることを制限します。 同じ制限は、正規表現のチェックが優先されるWAFにもあります。 もちろん、これらの制限はIDS構成で変更できますが、デフォルトで配布されており、変更を推奨していません。



正規表現のみを操作しても、目的の結果を得るのに役立ちません。 しかし、そのようなコンテンツを含むネットワークパケットをIDSで確認する場合はどうでしょうか。









この場合、ログに次の値が記録されます。

 Keyword Avg. Ticks Checks Matches -------- ---------- ------- -------- content 3338 7 6 pcre 12052 3 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チェックの数は4でしたが、元の行が重複したために7になりました。 メカニズムは不明のままですが、まだ行を複製すると、雪崩のようにチェック数が増加することが予想されます。 最終的に、次の値を達成することができました。

 Keyword Avg. Ticks Checks Matches -------- ---------- ------- -------- content 1508 1507 pcre 1492 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

署名によってチェックされるコンテンツに関係なく、部分文字列と正規表現のチェックの総数は3000を超えません。 明らかに、IDS自体にも内部リミッターがあり、これは今回はInspection-recursion-limitと呼ばれ、デフォルトでは3000になります。PCRE、IDS、およびチェックされるコンテンツの1回限りのサイズの制限のすべての制限数内容と正規表現の雪崩のようなチェックを使用すると、結果はあなたが必要なものです：

 Keyword Avg. Ticks Checks Matches -------- ---------- ------- -------- content 3626 1508 1507 pcre 1587144 1492 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1つの正規表現チェックの複雑さは変わっていませんが、そのようなチェックの数は大幅に増え、1.5万に達しました。 チェックの数に各チェックに費やされたメジャーの平均数を掛けると、切望されている30億ティックが得られます。

 Num Rule Avg Ticks -------- ------------ ----------- 1 2016204 3302218139
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これは千倍以上の利益です！ 操作には、最小限のHTTP POST要求をコンパイルするためにcurlユーティリティのみが必要です。 次のようになります。







繰り返しパターンを持つHTTPフィールドとHTTP本文の最小限のセット。

そのようなコンテンツは無限に大きくすることはできず、IDSがそれをチェックするために膨大なリソースを費やす必要があります。なぜなら、TCPセグメント内では単一のストリームストリームに接続されているにもかかわらず、ストリームと収集されたHTTPパケットは完全にチェックされないためです彼らは大きくありませんでした。 代わりに、サイズが約3〜4キロバイトの小さな断片でチェックされます。 チェックするセグメントのこのサイズとチェックの深さは、構成で設定されます（IDSのすべてとまったく同じです）。 セグメントのサイズは、そのようなセグメントの断片化境界への攻撃を避けるために、最初から最初にわずかに「震えます」-デフォルトのセグメントサイズを知っている攻撃者がネットワークパケットを分割できるため、攻撃は2つの隣接するセグメントに分割され、署名によって検出されません。



そのため、1つのアプリケーションで3,000,000,000以上のCPUティックにIDSをロードする強力な武器が手元にありました。 それはどういう意味ですか？

実際、得られた数値は平均CPUの約1秒です。 単純な関係は、サイズが3 KBの1つのHTTP要求を送信することにより、IDSに1秒間作業をロードすることです。 IDSのコアが多いほど、同時に処理できるデータストリームが増えます。







IDSはアイドル状態ではないことを忘れないでください。原則として、バックグラウンドネットワークトラフィックをチェックすることでリソースの一部を取り、この攻撃のしきい値を下げます。



8/40コア、バックグラウンドトラフィックのないIntel Xeon E5-2650 v3 2.30 Ghz CPUを備えた動作中のIDS構成で測定を実行すると、8個のCPUコアすべてが100％ロードされるしきい値は、わずか250キロビット/秒になりました。 そして、これは何ギガビットものネットワークフローを処理するように設計されたシステム向けです。



この特定の署名を使用するには、攻撃者は保護されたWebサーバーに毎秒約10のHTTP要求を送信するだけで、ネットワークパケットのキューをIDSで徐々に満たすことができます。 バッファが使い果たされると、パケットはIDSを通過し始め、その時点から、攻撃者は任意のツールを使用したり、任意の攻撃を実行したり、検出システムに気付かれることはありません。 一定レベルの悪意のあるトラフィックにより、このトラフィックが内部ネットワークへの攻撃を停止するまでIDSを無効にできます。短期的な攻撃の場合、攻撃者はそのようなパケットから短いスパイクを送信し、検出システムで失明を達成することができますが、短期間です。



遅い署名の操作は既存のメカニズムでは検出できません。IDSにはプロファイリングコードがありますが、単純に遅い署名と壊滅的なほど遅い署名を区別して自動的に通知することはできません。 適切なコンテンツが不足しているため、署名のトリガーに関するシグナリングも発生しないことに注意してください。



チェックの数の原因不明の増加を覚えていますか？ IDSエラーが実際に発生し、不要なチェックの数が増加しました。 この脆弱性の名前はCVE-2017-15377で 、現在Suricata IDS 3.2および4.0ブランチで修正されています。



上記のアプローチは、1つの特定の署名インスタンスに対してうまく機能します。 これは、オープンなシグネチャセットの一部として配布され、原則としてデフォルトで有効になっていますが、最もホットなシグネチャの上部には、新しいシグネチャが時々ポップアップしますが、他のトラフィックはまだトラフィックを待っています。 IDS SnortおよびSuricataの署名記述言語は、base64デコード、コンテンツジャンプ、数学演算など、多くの便利なツールを開発者に提供します。 検査の他の組み合わせも、検証のために消費されるリソースの爆発的な増加を引き起こす可能性があります。 パフォーマンスデータの注意深い監視は、運用の出発点となります。 CVE-2017-15377の問題が修正された後、ネットワークトラフィックをチェックするために再びSuricata IDSを起動し、まったく同じ画像を確認しました。ログの一番上にある最もホットな署名ですが、番号が異なります。 これは、そのような署名が多く存在すること、およびそれらの操作へのアプローチを示唆しています。



IDSだけでなく、アンチウイルス、WAF、および他の多くのシステムも署名検索に基づいています。 したがって、同様のアプローチを適用して、パフォーマンスの弱点を見つけることができます。 彼は、検出システムによる悪意のあるアクティビティの検出を静かに停止することができます。 それに関連付けられたネットワークアクティビティは、保護装置や異常検出器では検出できません。 実験のために、検出システムでプロファイリング設定をオンにし、パフォーマンスログの上部を確認します。











@ attackdetection、 TwitterからKirill Shipulinが投稿 | 電報