JSOFと共同研究によるRipple20の重大な4つの脆弱性に関するシグネチャと検出ロジック

この内容は、McAfee Advanced Threat Researchが、脆弱性を発見し開示したJSOFとともに共同で作成したものです。これは、ネットワーク管理者とセキュリティ担当者がこれらの脆弱性をさらに理解して悪用を防ぐための貴重な洞察を生み出すための共同研究活動として機能することを目的としています。ここで作成されたシグネチャは、本番環境で使用する前にステージング環境で十分に検討および精査する必要があり、ターゲット展開への特定のチューニングから利益を得ることが可能です。これらの脆弱性を検出するには、より複雑な検出方法が必要になる可能性があるなど、この作業には技術的な制限があります。たとえば、カプセル化の複数の層は、欠陥の悪用を難読化し、検出の困難さを増す可能性があります。

以下のシグネチャまたは検出ロジックに基づいてカスタマイズされたシグネチャをテストおよび展開するためのアーティファクトとして、脆弱性の概念実証から取得したパケットキャプチャも提供しています。署名とLuaスクリプトは、それぞれATRのGithubページ、このドキュメントのインラインとAppendixにあります。

また、2020年8月5日、JSOFはBlack Hat USA 2020で、DNSの最も重大な2つの脆弱性に関する追加の技術的詳細と悪用分析を発表しています。

ここに提供される情報は、予告なしに変更される可能性があり、「現状のまま」で提供されます。特定の状況または状況に対する情報の正確性または適用性に関する保証または保証はなく、お客様の責任で使用してください。また、シグネチャのパフォーマンスや有効性のベンチマークは保証できません。


ヒープオーバーフローとRCEにつながる tfDnsExpLabelLength の整数オーバーフロー

CVE: CVE-2020-11901 (Variant 1)
CVSS: 9
Protocol(s): DNS over UDP (and likely DNS over TCP)
Port(s): 53

脆弱性の説明：
Treckスタックでは、DNS名は関数tfDnsExpLabelLengthを介して計算されます。この関数にはバグが存在し、unsigned shortを使用して計算が実行されるため、特別に作成されたDNS応答パケットで計算値をオーバーフローさせることができます。 tfDnsExpLabelLengthは、解凍後にDNS名の完全な長さを計算するため、216バイトよりはるかに小さいDNSパケットを使用してオーバーフローを引き起こす可能性があります。一部のコードパスでは、tfGetRawBufferがtfDnsExpLabelLengthの直後に呼び出され、tfDnsExpLabelLengthによって計算されたサイズを使用してDNS名が格納されるバッファーをヒープに割り当て、ヒープオーバーフローと潜在的なRCEを引き起こします。

新しいバージョンのTreckスタックは、英数字またはハイフン以外の文字に到達するとすぐにDNS名のバッファーへのコピーを停止しますが、古いバージョンにはこの制限がなく、さらにDNSクエリに予測可能なトランザクションIDを使用して、この脆弱性が悪用されやすくなります。

検出に関する制限または特別な考慮事項：
理想的には、この脆弱性の検出ロジックには、着信DNS応答に含まれるすべてのDNS名の非圧縮長を個別に計算することが含まれます。残念ながら、特に各DNS応答に多数のDNS名が含まれている可能性があるため、これはデバイスがすべての着信DNS応答に対して実行する計算コストがかかる可能性があります。代わりに、ヒューリスティックの組み合わせに依存する必要があります。

さらに、EDNS（0）またはTCP over DNSを使用している場合に、この脆弱性の行使が可能かどうかは現在不明です。検出ロジックを実装する目的で可能であると想定することをお勧めします。テスト中に、SuricataがDNS over TCPを処理する方法に不整合が発見されました。DNSトラフィックとして正しく識別される場合とそうでない場合がありました。その結果、TCP over DNSトラフィックのサイズを決定する2つのルールが作成されました。 2番目のルールは、DNSプリミティブの代わりにTCPプリミティブを使用します。ただし、2番目のルールは、最初のルールによってフラグが立てられていない場合にのみ評価されます。

dns_invalid_size.rulesのSuricataルールはDNS応答のEDNS UDP長を使用するため、攻撃者が制御する可能性があるため、2番目の上限である4096バイトが適用されます。

推奨される検出基準：

  • デバイスは、DNSトラフィックを処理し、対応する要求に対する応答を照合できる必要があります。
  • デバイスは、個々のDNSパケット内の個々のDNS名を識別できる必要があります。
  • デバイスは、サイズが「予想」を超えるDNS応答にフラグを設定する必要があります。予想されるサイズは、送信されるDNSパケットのタイプによって異なります。
    • DNS over TCPの場合、サイズはTCPペイロードの最初の2バイトで指定された値を超えてはなりません。
    • EDNS（0）を使用したDNS over UDPの場合、サイズは、要求でネゴシエートされた値（存在する場合、OPT RRのCLASSフィールドで指定されている）を超えてはなりません。
    • EDNS（0）のないDNS over UDPの場合、サイズは512バイトを超えてはなりません。
    • これらはすべてdns_invalid_size.rulesでチェックされ、ロジックに対してdns_size.luaまたはdns_tcp_size.luaを呼び出します。
  • デバイスは、255バイトを超えるDNS名を含むDNS応答にフラグを立てる必要があります（解凍前）。
    • これは、ロジックのdns_invalid_name.luaを呼び出すdns_invalid_name.rulesでチェックされます。
  • デバイスは、a-z、A-Z、0-9、「-」、「_」、および「*」以外の文字で構成されるDNS名を含むDNS応答にフラグを設定する必要があります。
    • これは、ロジックのdns_invalid_name.luaを呼び出すdns_invalid_name.rulesでもチェックされます。
  • デバイスは、多数のDNS圧縮ポインター、特に次々と続くポインターを含むDNS応答にフラグを立てる必要があります。特定の許容範囲はネットワークによって異なります。
    • トレックスタックの脆弱なバージョンは、最初の2ビットが0b00ではないすべてのラベルを圧縮ポインターとして分類するため、デバイスはこのポインターの合計に対してビット0b10、0b01、または0b11で始まるすべてのラベルをカウントする必要があります。 Luaスクリプトでは、この理由により、63（0x3F）を超える値はポインターとして扱われます。その範囲内の値には、これらのビットの少なくとも1つが設定されるためです。
    • このルールを実装するために、特定のしきい値は、単一のDNSパケット内の合計40ポインタまたは4つの連続したポインタに設定されました。これらの値は、非常に大きなテストPCAPでは誤検知を引き起こさないように選択されましたが、ルールが展開されるネットワークの一般的なトラフィックに合わせて必要に応じて変更する必要があります。連続したポインタのテストは、各ドメイン名に（最後に）ポインタが1つだけあるため、特に役立ちます。つまり、通常のトラフィックでは、多数のポインタが連続して表示されることはありません。
    • これは、dns_heap_overflow.rulesによって呼び出されるdns_heap_overflow_variant_1.luaに実装されています。
  • 上記の検出ロジックの実装は、ポインターのカウントロジックのみがこの脆弱性に固有であるため、いくつかのSuricataルールファイルに分割されています。この脆弱性を利用するエクスプロイトの検出は、他のルールに実装されたDNSレイヤーサイズチェック、ドメイン名圧縮長チェック、およびドメイン名文字チェックの追加で強化されていますが、これらは「ヘルパー」シグネチャと見なされ、これらの1つにフラグを立てますこの特定の脆弱性の悪用の試みを必ずしも示すものではありません。

誤検知条件（悪意のないトラフィックを検出する署名）：
英数字以外の文字を使用したDNS名または異常に多数のDNS圧縮ポインターを含む悪意のないトラフィックを予期するネットワークは、誤検知を生成する可能性があります。残念ながら、悪意のあるパケットがパケット内の任意のオフセットを指す圧縮ポインターを使用する可能性があるため、ドメイン名フィールドのみのポインターのチェックでは不十分であるため、代わりにDNSレイヤーのすべてのバイトをチェックします。その結果、トレックのDNS圧縮ポインタの過度に自由な分類は、私たちのルールがDNSペイロード内の無関係なバイトをポインタとして誤って分類することを意味します。

テストでは、スペースを含むドメイン名や「https：//」などの誤検知が発生しました。 RFCによると、「：」や「/」などの文字はドメイン名に含まれていてはいけませんが、実際の悪意のないトラフィックでは時々現れることがあります。許容される文字のリストは、過剰な誤検知を回避するために、ターゲットネットワークの必要に応じて拡張する必要があります。とは言っても、受け入れ可能な文字のリストをできるだけ小さくしておくと、シェルコードに潜入してRipple20のDNSの脆弱性の1つを利用することが難しくなります。

SuricataがパケットをDNSパケットとして適切に分類しない場合、DNS over TCPを使用すると、DNSサイズルールの誤検知が発生する可能性があります。これは、テスト中に複数回発生したものです。これにより、2番目のサイズチェックが発生します。これは、ポート53上のすべてのトラフィックがDNSトラフィックであると想定し、それに応じてペイロードを処理します。その結果、TCPポート53上の非DNSトラフィックは、この特定のケースで誤検知を引き起こす可能性があります。ルールのポート番号は、ポート53で異なるプロトコルが予想されるネットワークに合わせて調整することをお勧めします。

TCPを介したDNSトラフィックの断片化により、誤検知が発生する場合もあります。 DNSペイロードでルールが実行されるときにストリームが適切に再構築されない場合、添付されているLuaスクリプトで使用されているバイトオフセットが誤ったデータを分析する可能性があります。 MTU値が特に低く設定されていない限り、DNS応答パケットの断片化は標準ネットワークでは一般的ではありません。 各ルールは、特定のネットワーク要件と条件に基づいて、本番環境で使用する前に個別に評価する必要があります。

偽陰性（脆弱性/悪用の検出に失敗した署名）：
この検出ロジックは非圧縮DNS名の長さの計算が非常に計算コストが高いため、ヒューリスティックに依存しているため、偽陰性の可能性が高くなります。 注意深く作成された悪意のあるパケットは、提案されたポインタの制限を回避し、それでもこの脆弱性を引き起こす可能性があります。

Signature(s):
dns_invalid_size.rules:

alert dns any any ‑> any any (msg:"DNS packet too large"; flow:to_client; flowbits:set,flagged; lua:dns_size.lua; sid:2020119014; rev:1;)
Lua script (dns_size.lua) can be found in Appendix A

alert tcp any 53 -> any any (msg:"DNS over TCP packet too large"; flow:to_client,no_frag; flowbits:isnotset,flagged; lua:dns_tcp_size.lua; sid:2020119015; rev:1;)
Lua script (dns_tcp_size.lua) can be found in Appendix A

dns_invalid_name.rules:

alert dns any any -> any any (flow:to_client; msg:"DNS response contains invalid domain name"; lua:dns_invalid_name.lua; sid:2020119013; rev:1;)
Lua script (dns_invalid_name.lua) can be found in Appendix A

dns_heap_overflow.rules:

# Variant 1
alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_1.lua; sid:2020119011; rev:1;)
Lua script (dns_heap_overflow_variant_1.lua) can be found in Appendix A


DNS CNAMEレコードのRDATA長の不一致でヒープオーバーフローが発生

CVE: CVE-2020-11901 (Variant 2)
CVSS: 9
Protocol(s): DNS/UDP (and likely DNS/TCP)
Port(s): 53

脆弱性の説明：
Treckスタックの一部のバージョンでは、CNAMEレコードを含むDNS応答をスタックが処理する方法に脆弱性が存在します。 このようなレコードでは、DNS名を格納するために割り当てられたバッファーの長さはRDLENGTHフィールドから取得されますが、書き込まれるデータは完全な圧縮解除されたドメイン名であり、nullバイトでのみ終了します。 その結果、RDATAで指定された圧縮解除されたドメイン名のサイズがCNAMEレコードで指定されたRDLENGTHを超えると、超過分が割り当てられたバッファーの終わりを超えて書き込まれ、ヒープオーバーフローとRCEが発生する可能性があります。

検出に関する制限または特別な考慮事項：
この脆弱性の悪用は、UDPパケットを介した悪意のあるDNSを使用して確認されていますが、DNS over TCPを使用してテストされておらず、そのようなパケットが同じ脆弱なコードパスを実行するかどうかは不明です。 これが確認できるまで、検出ロジックは両方のベクターが脆弱であると想定する必要があります。

推奨される検出基準：

  • デバイスは、着信DNS応答を処理できる必要があります。
  • デバイスはDNS応答内のCNAMEレコードを識別できる必要があります
  • デバイスは、CNAMEレコードのRDATAフィールドの実際のサイズが同じレコードのRDLENGTHフィールドで指定された値を超えるすべてのDNS応答にフラグを付ける必要があります。
    • この場合、「実際のサイズ」は、トレックスタックの脆弱なバージョンがRDATAの長さを計算する方法に対応します。これには、nullバイト、DNS圧縮ポインター、またはペイロードの最後のいずれかが検出されるまで、すべてのラベルのサイズを追加します。 Treckスタックは、ドメイン名を終了するポインターを追跡して解凍します（存在する場合）。ただし、前述のように、この計算は非常にコストがかかるため、スクリプトは実行しません。

誤検知条件（悪意のないトラフィックを検出する署名）：
誤検知は発生する可能性は低いですが、ネットワークデバイスがRDLENGTHがRDATAのサイズと等しくない非悪意のあるトラフィックを送信するシナリオでは、RFC 1035を破る可能性があります。

偽陰性（脆弱性/悪用の検出に失敗した署名）：
検出ロジックはRDATAの「実際のサイズ」を計算するときに解凍を実行しないため、解凍後に長さがRDLENGTHを超えるドメイン名を含む悪意のあるパケットの検出に失敗します。 残念ながら、このようなパケットは実際にはRFCに準拠しているため、このケースのカバレッジは重要です。 RFC 1035のセクション4.1.4によると、

長さフィールドの対象となるメッセージの一部（RRのRDATAセクションなど）にドメイン名が含まれていて、圧縮が使用されている場合、長さの計算では、長さではなく、圧縮された名前の長さが使用されます。 拡張名の。

計算のオーバーヘッドに加えて、そのようなチェックを実施すると、非常に高い誤検知率が発生する可能性があります。

Signature(s):
dns_heap_overflow.rules:

# Variant 2
alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_2.lua; sid:2020119012; rev:1;)
Lua script (dns_heap_overflow_variant_2.lua) can be found in Appendix A


Routing Header Type 0を使用して範囲外を書き込む

CVE: CVE-2020-11897
CVSS: 10
Protocol(s): IPv6
Port(s): N/A

脆弱性の説明：
IPv6着信パケットを処理するときに、IPv6ルーティングヘッダーの解析の不整合がトリガーされ、ヘッダー長がフラグメント長ではなくパケット全体に対してチェックされます。つまり、全体のサイズが指定されたルーティングヘッダー長以上の断片化されたパケットを送信する場合、現在のフラグメントに十分なバイトがあることを前提としてルーティングヘッダーを処理します（全体で十分なバイトがある場合）再構成されたパケットのみ）。したがって、ルーティングヘッダータイプ0（RH0）を使用して、境界外のメモリ位置への読み取りと書き込みを強制できます。

また、デバイスから返されたICMPパラメータのソースIPv6アドレスで情報リークが発生する可能性があるという副次的な影響もあります。

検出に関する制限または特別な考慮事項：
RH0のRFCでは、長さフィールドを「ヘッダー内のアドレス数の2倍」と定義しています。たとえば、ルーティングヘッダーの長さが6の場合、ヘッダーには3つのIPv6アドレスが必要です。フラグメント化されたパケットが再構築されると、報告されたアドレス数は、後続のフラグメントからのデータで埋められます。これにより、ヘッダーに「無効な」IPv6アドレスが作成され、パケットの次の層が不正になる可能性があります。悪用中、パケットの次の層が不正な形式になる可能性もあります。 ICMPを使用して情報漏えいを実行できますが、次の層が任意のタイプであり、したがって長さが異なる可能性があります。したがって、この層の長さの検証は、非常に費用がかかり、非決定的である可能性があります。

推奨される検出基準：

  • デバイスは、断片化されたIPv6トラフィックを処理できる必要があります
  • デバイスは、ルーティングヘッダータイプ0（RH0）を含む断片化されたパケットを検査する必要があります。 RH0 IPv6パケットがフラグメント化されている場合、脆弱性が悪用されている可能性があります
  • RH0ヘッダーを含むパケットフラグメントのIPv6レイヤーの長さがルーティングヘッダーで報告された長さよりも短い場合、脆弱性が悪用されている可能性があります
  • 断片化されたパケットの再構築時に、IPv6に続くレイヤーのヘッダーが不正な形式である場合、脆弱性が悪用される可能性があります

ノート：
ルーティングヘッダータイプ0は、2007年12月の時点でRFC 5095のIPv6トラフィックで非推奨になりました。その結果、この基準を使用してパケットを検出するだけで実現できる場合があります。このシナリオでは、レガシーデバイスまたはプラットフォームの誤検知が発生する可能性があります。 Suricataはすでにこのシナリオのデフォルトルールを提供しており、以下に追加されています。 RFCによると、ルーターはIPv6パケットをフラグメント化することは想定されておらず、MTUが1280をサポートする必要があります。これは、異常な量のヘッダー拡張または異常に大きなヘッダーが使用されない限り、常にすべてのRH0ヘッダーを含みます。これに従った場合、RH0ヘッダーを使用するパケットはRH0拡張ヘッダーの境界を越えてフラグメント化されるべきではなく、この方法でフラグメント化されたRH0パケットは潜在的に悪意のあるものとして扱われるべきです。フラグメント化されたRH0パケットを潜在的に悪意のあるものとして扱うだけで十分な場合があります。さらに、フラグメントサイズがしきい値を下回るフラグメント化されたRH0パケットや、複数の拡張ヘッダーまたはしきい値を超える異常に大きいヘッダーが含まれるIPv6パケットを処理すると、高精度の検出が可能になります。

誤検知条件（悪意のないトラフィックを検出する署名）：
上記のすべての検出基準を使用する場合、報告されるパケットの長さが実際の長さと一致し、次のヘッダーに不正な形式のデータが含まれることはないため、誤検知は最小限に抑えられます。ルーティングヘッダータイプ0のみがチェックされている場合、誤検知が発生する可能性が高くなります。追加で提供されるルールでは、RH0が廃止され、ICMPヘッダーに無効なチェックサムや不明なコードが含まれることはないため、誤検知は最小限に抑える必要があります。

偽陰性（脆弱性/悪用の検出に失敗した署名）：
署名がIPv6に続くレイヤー（ICMPなど）に過度に固有に開発されている場合、偽陰性が発生する可能性があります。 攻撃者は別の層を潜在的に利用し、情報漏えいなしに脆弱性を悪用する可能性があります。 ただし、これでもデフォルトのRH0ルールがトリガーされます。 以下の2番目のルールでは、以下の場合に偽陰性が発生する可能性があります。

  • 攻撃者がIPv6レイヤーに続いて非ICMPレイヤーを使用する場合
  • 有効なICMPコードが使用されている場合
  • チェックサムが有効であり、ペイロードは5バイト以下の場合（この値は署名で調整可能）

Signature(s):
Ipv6_rh0.rules:

alert ipv6 any any -> any any (msg:"SURICATA RH Type 0"; decode-event:ipv6.rh_type_0; classtype:protocol-command-decode; sid:2200093; rev:2;)

alert ipv6 any any -> any any (msg:"IPv6 RH0 Treck CVE-2020-11897"; decode-event:ipv6.rh_type_0; decode-event:icmpv6.unknown_code; icmpv6-csum:invalid; dsize:>5; sid:2020118971; rev:1;)


IPv4/UDP トンネリングのリモートコード実行

CVE: CVE-2020-11896
CVSS: 10.0
Protocol(s): IPv4/UDP
Port(s): Any

脆弱性の説明：
Treck TCP / IPスタックは、断片化されたペイロードデータを持つ着信IPv4-in-IPv4パケットを適切に処理しません。これにより、特別に細工された複数のトンネルUDPパケットを脆弱なホストに送信するときに、リモートでコードが実行される可能性があります。

この脆弱性は、（パケットヘッダー内の）アドバタイズされたIPの合計の長さが、利用可能なデータよりも厳密に短い場合に、不適切なトリミング操作が原因で発生します。合計IP長の値が小さい複数のフラグメントを使用してトンネル化IPv4パケットを送信すると、TCP / IPスタックはトリミング操作を実行します。これにより、パケットが短い長さに基づいて割り当てられた宛先パケットにコピーされるときに、ヒープオーバーフローの状況が発生します。トンネリングされたIPv4パケットがリスニングポートに送信されるUDPパケットである場合、UDP受信キューが空でない場合、このエクスプロイトをトリガーする可能性があります。これにより、悪用可能なヒープオーバーフローが発生し、Treck TCP / IPスタックが実行されているコンテキストでリモートコードが実行される可能性があります。

推奨される検出基準：
進行中の攻撃を検出するには、カプセル化を解凍できる場合、次の条件を満たす必要があります。

  • UDP受信キューは空でない
  • 着信UDPパケットはフラグメント化する
    • フラグMF = 1、オフセットあり、または
    • フラグMF = 0、ゼロ以外のオフセット
  • 断片化されたパケットには、カプセル化されたIPv4パケットが必要です（アセンブリ時）
    プロトコル= 0x4（IPIP）
  • カプセル化されたIPv4パケットは、2つのパケットフラグメントに分割する
  • 再構成された（最も内側の）IPv4パケットのIPヘッダーに格納されているデータ長が正しくない

    上記の4番目の条件は、脆弱なコードパスをアクティブにするために必要です。これは、コピーされるデータを複数のメモリ内バッファーに分散するためです。 最後の検出ステップは、バッファオーバーフローの原因であり、これでトリガーするだけで十分な場合があります。

    問題のネットワーク検査デバイスの制限によっては、誤検知が発生しやすくなる可能性がありますが、緩い条件を使用することもできます。

    カプセル化を解凍できない場合に進行中の攻撃を検出するには、以下のような状態である必要があります。

    • UDP受信キューは空でない
    • 着信UDPパケットはフラグメント化する
      • フラグMF = 1、オフセットフィールドに任意の値を含む、または
      • フラグMF = 0、オフセットフィールドにゼロ以外の値
    • 最終フラグメントの合計フラグメント長がオフセットフィールドよりも長くなっている

    上記の最後の状態は、通常のネットワークで見られるものではありません。

    フラグメンテーションが発生するのは、特定のパケットタイプのMTUでデータがオーバーフローした結果です。これは、最終的なフラグメントが他のどのフラグメントよりも大きくてはいけないことを示しています-実際にはおそらくより小さくなります。最終的なフラグメントが以前のフラグメントよりも何らかの形で大きい逆は、フラグメント化がMTUオーバーフローの結果ではなく、何か別の結果であることを示しています。この場合、悪意があります。

    一般的な使用法のネットワークモニターはカプセル化を展開する機能を備えている可能性が高いため、そのルールセットのみが提供されます。

    検出に関する制限または特別な考慮事項：
    Treckスタックは、（少なくとも）2つのレベルのトンネリングをサポートします。各トンネルレベルは、IPv4-in-IPv4、IPv6-in-IPv4、またはIPv4-in-IPv6にすることができます。上記のロジックは、IPv4-in-IPv4の単一レベルのトンネリングケースに固有です。ネストが深い場合は、再帰的なチェックまたはすべてのトンネリングレイヤーの完全な展開が必要になります。

    誤検知条件（悪意のないトラフィックを検出する署名）：
    上記のすべての検出基準がトンネリングをアンパックできる場合に使用される場合、誤検知は最小限に抑える必要があります。トンネリングをアンパックできない場合、これは、標準に準拠したアプリケーションの存在下で多くの誤検知をトリガーすることはほとんどありません。ここで見られるような断片化は一般的ではありません。

    偽陰性（脆弱性/悪用の検出に失敗した署名）：
    偽陰性は、より深いレベルのネスト、またはIPv6のネストで発生する可能性があります。

    Signature(s):
    ipv4_tunneling.rules:

    alert ip any any -> any any (msg:"IPv4 TUNNELING EXPLOIT (CVE‑2020‑11896)"; ip_proto:4; lua:tunnel_length_check.lua; sid:2020118961; rev:1;)
    Lua script (tunnel_length_check.Lua) can be found in Appendix A


    Appendix A

    Appendix Aには、対応するSuricataシグネチャでの使用に必要なLuaスクリプトが含まれています。 これらのスクリプトは、McAfee ATRのGitHubにもあります

    dns_tcp_size.lua: 

    dns_size.lua: 

    dns_invalid_name.lua:

    dns_heap_overflow_variant_1.lua:

    dns_heap_overflow_variant_2.lua:

    tunnel_length_check.lua:

    ※本ページの内容は2020年8月5日（US時間）更新の以下のMcAfee Blogの内容です。
    原文：Ripple20 Critical Vulnerabilities – Detection Logic and Signatures
    著者：, ,  and