1. はじめに 3
2. アラーム情報 3
3. NFR の検出 8
5. 脆弱性の説明 15
6.概要 20
1. はじめに
NFR (Network Flight Recorder) は、元々はファイアウォールのマスターである Marcus J. Ranum によって一般的なネットワークとして作成されました。トラフィック分析および記録ソフトウェアが実装されており、分析ツールの柔軟性を最大限に高めるために、NFR は多くの評価で優れたパフォーマンスを発揮する完全で強力な N コード スクリプト言語を提供します。 L0pht は NFR に何百もの署名ライブラリを提供してきましたが、信頼できる署名セットが存在しないことが常に彼の弱点でした。
NFR をしばらく使ってみたところ、NFR には多くの問題があることがわかりました。中国語との互換性が悪いために AI が頻繁に終了することは言うまでもなく、NFR のバージョンもアップグレードされませんが、攻撃イベントの説明は常に古いバージョンの説明を使用します。IDS の中で最も重要な攻撃シグネチャ ライブラリだけでも驚きました。アップグレードが遅いだけでなく、間違った署名も多数あります。このシリーズの記事では、NFR 製品をより効果的に活用できるように、私が発見したいくつかの問題を分析して詳しく説明します。また、IDS での攻撃シグネチャ ライブラリの準備についても同僚と話し合いたいと思います。知識と時間の制限があるため、間違いは避けられません。また、ご意見やご提案があれば、benjurry@xfocus.org までお送りください。
SQL Server は、Microsoft が競合するために立ち上げたデータベースです。オラクルは、オラクルに次ぐ市場シェアを誇り、世界第 2 位ですが、そのセキュリティについては常にユーザーから疑問の声が上がっています。 Microsoft が 1996 年に発売した SQL Server 6.5 から、1998 年に発売した SQL Server 7.0、そして 2000 年 8 月の SQL Server 2000 に至るまで、バージョンと機能は継続的にアップグレードされてきましたが、セキュリティの問題は十分に解決されていませんでした。 SQL Server のセキュリティ情報とパッチを継続的に改善し、継続的にリリースすること。 2003 年 1 月 24 日、SQL Server をターゲットとする「Slammer」ワームがインターネット上で猛威を振るい、ネットワーク トラフィックの急増を引き起こし、世界中のコンピュータとネットワーク システムに深刻な影響を与えました。 SQL Server の脆弱性は大手セキュリティ企業やメーカーの注目を集めたため、NFR はただちに、2002 年 8 月 7 日に Immunity Company の Dave Aitel によって発見された Hello Buffer Overflow 脆弱性を含む、SQL Server をターゲットとした複数の攻撃シグネチャを公開しました。しかし、使用中に、NFR がこの脆弱性に対して多くのアラームを発していることが判明したので、記録のために分析し、この記事を書きました。
2. アラーム情報
MS SQL Hello Buffer Overflow の NFR のアラーム情報です:
重大度: 攻撃
時間: 13:54:21 2003 年 7 月 15 日
ソース ファイル: package/mssql/sql2k.nfr
行: 226
ホスト: benjurry-xfocus
アラート ID: mssql_sql2k:buffered_hello
ソース ID: mssql_sql2k:source_me
ソース: mssql_sql2k:source_me
ソースの説明: Sqlserver 2k オーバーフロー検出器 36531 900 秒
: 3
送信元 IP: 192.168.0.110
宛先 IP: --
これイベントの重大度、時間、NFR センサー名、攻撃元 IP、宛先 IP、およびその他のアラーム情報が含まれます。
実際に使用すると、このようなアラームが 1 日に数百件発生します。これは誤ったアラームであると考えられます。
3. NFR の検出
まず、NFR によってリリースされた署名ライブラリ MSSQL.fp を開き (または AI パッケージ内で表示することもできます)、NFR の攻撃を確認します。この脆弱性のシグネチャ:
…..
変数定義など…
…
scope());リスト %c", "sqlserv_schema");
HELLO_SIG = "x12x01x00x34x00x00x00x00x00x00x15";
MIN_LEN = strlen(HELLO_SIG);
…….
フィルターこんにちはtcp (client, dport: 1433) {
tcp.connsym 内で $Blob を宣言します;
if ($Blob == NULL) {
$Blob =
} else {
$Blob = cat($Blob, tcp.blob);
}
if (strlen($Blob)
if (prefix ( $Blob, HELLO_SIG)) {
if (COUNTHELLO[tcp.connsrc]) {
COUNTHELLO[tcp.connsrc] = COUNTHELLO[tcp.connsrc] 1;
COUNTHELLO[ tcp .connsrc] = 1;
}
if (do_alert(hello_overflow_alert, tcp.connsrc)) {
アラート(source_me, hello_overflow_alert, tcp.connsrc,
tcp.connsport, tc p.conndst, tcp.conndport,
"--AlertDetails",
"ALERT_ID", "40-8",
"ALERT_CONFIDENCE", 60,
"ALERT_SEVERITY", "medium",
" ALERT_IMPACT"、"不明"、
"ALERT_EVENT_TYPE"、"攻撃"、
"ALERT_ASSESSMENT"、"不明"、
"IP_ADDR_SRC"、tcp.connsrc、
"PORT_SRC"、tcp.connsport ,
"IP_ADDR_DST", tcp.conndst,
"PORT_DST", tcp.conndport,
"IP_PROTO_NUM", 6);
}
レコード packet.sec, tcp .conndst, tcp .conndport、tcp.connsrc、
tcp.connsport、$Blob から sqlserv_rec;
misc_攻撃:rec(packet.sec,scope(),
"Mssql HELLO オーバーフロー!"、tcp.connsrc、tcp。 conndst);
}
}
上記の N-CODE から、NFR が次の手順でこの検出を実行することがわかります。
1. 攻撃シグネチャを定義します。
HELLO_SIG = "x12x01x00x34x00x00x00x00x00x00x15";
攻撃シグネチャの長さ:
MIN_LEN = strlen(HELLO_SIG);
2. TCP ペイロード データからデータを取得し、長さを比較します。このデータの長さが攻撃シグネチャの長さより小さい場合、次の検出ステップは実行されません。
3.文字列が一致している場合、それは攻撃とみなされ、ブロックまたは警告されます。
次に、NFR IDS レコードのデータを分析しましょう。AI でパッケージ -> クエリ -> MSSQL -> MSSQL Server 200 を選択し、条件を設定し、テーブルを押してデータを見つけ、いずれかを選択してコピーします次の内容を取得します:
時刻: 15-Jul-2003 13:54:21
NFR: benjurry-xfocus
宛先アドレス:192.168.0.135
宛先ポート: 1433
送信元アドレス: 192.168.0.110
送信元ポート: 1391
ペイロード: x01x02x00x1cx00x0cx03x00(x00x04xffx08x00x00xc2x00
NIDS センサー名、宛先 IP、宛先ポート、送信元 IPおよびソースポート、そして私たちが気にするのはペイロードですこれは、NIDS が攻撃署名ライブラリと比較するために使用するデータであるためです。ただし、NFR にはいくつかの小さな問題があります。
1. ASCII 文字に変換できるペイロード内の 16 進数を ASCII に変換します。コード;
2. Unicode 文字を処理できません。これは今後の分析で判明する予定です。
この例では、分析の便宜上、上記のペイロード内の文字署名部分を 16 進数に変換します:
x12x01x00x34x00x00x00x00x00x00x15x00x06x01x00x1b
x00x01x02x00x1cx00x0c x0 3x00x28x00x04xffx08x00x00
xc2x00x00x00MSSQLServerx00xx03x00x00
NFR はデータ グループ パッケージをキャプチャした後、それが SQL Server パッケージであることを発見し、その内容を SQL Server 攻撃ライブラリと比較しました。明らかに、上記のデータは攻撃ライブラリと一致しているため、アラームが発生しました。ということが起こるのですが、これは本当に攻撃なのでしょうか？以下の分析を続けてみましょう。
4. プロトコル分析
Xfocus のプロトコル分析プロジェクト (プロジェクトの結果は近日中に発表されます) によると、MS SQL 2000 は TDS8.0 を使用しており、その形式は次のとおりです。以下:
----------------------------------------------- ---- --
| TDS ペイロード データ | --------------------
MS SQL SERVER 2000 TDS のヘッダー構造は次のとおりです:
----------- -------------------------------------------------- -- ----
| 署名済みパケット数 | -- --------------------------------------------------
このうち、TOKEN フィールド 1 バイトは、TDS オペレーション要求タイプを示すために使用されます。この脆弱性では、NFR レコードのペイロードの最初のバイトである 0x12 がログイン前検証コマンド リクエストです。その目的は、クライアントが TDS パッケージを構築するための基礎として、SQL SERVER のバージョン、暗号化がサポートされているかどうか、その他の情報など、現在の MS SQL SERVER2000 の設定を取得することです。 SQL Server がこのタイプのパッケージを受け取ると、SSlibnet.dll 内の対応する関数によって処理されます。私のシステム SQL Server 2000 (SP なし) の場合、対応する関数は次のとおりです。
.text:42CF6DDD ; 属性: bp ベースのフレーム
.text:42CF6DDD
.text:42CF6DDD public ConnectionPreLogin
.text:42CF6DDD ConnectionPreLogin proc Near
.text:42CF 6DDD
。 text:42CF6DDD var_4 = dword ptr -4
.text:42CF6DDD arg_0 = dword ptr 8
.text:42CF6DDD arg_4 = dword ptr 0Ch
.text:42CF6DDD arg_8 = dword ptr 10h
。 :42CF6DDD arg_C = dword ptr 14h
.text:42CF6DDD arg_10 = dword ptr 18h
.text:42CF6DDD
.text:42CF6DDD プッシュ ebp
.text:42CF6DDE mov ebp, sp
。 text:42CF6DE0 Push ecx
.text:42CF6DE1 mov eax, [ebp arg_0]
.text:42CF6DE4 mov ecx, [eax 94h]
.text:42CF6DEA mov [ebp var_4], ecx
.text:42CF6DED cmp [ebp var_4], 1
.text:42CF6DF1 jz short loc_42CF6E01
.text:42CF6DF3 cmp [ebp var_4], 1
.text:42 CF6DF7 jle short loc_42CF6E3D
。 text:42CF6DF9 cmp [ebp var_4], 3
....
STATUS フィールドが 0x01 の場合、このパケットがパケット内の最後の TDS であることを意味します。現在の TDS セッション。
LENGTH フィールドは 2 バイトで、TDS パケット ヘッダーの長さを含む TDS パケットの全長を示します。
SIGNED NUM フィールドは 2 バイトで、現在予約されており未使用です。
PACKET NUM フィールドは 1 バイトで、現在の TDS 操作リクエスト内のこの TDS パケットのシーケンス番号を示します。
WINDOW SIZE フィールドは 1 バイトで、現在予約されており未使用です。
MS SQL SERVER 0X12 TDS の主なパッケージ形式は次のとおりです:
---------------------------- -- ------------
| TDS ヘッダー (8 バイト) | フィールド表示ヘッダー | -- --------------------------------------------------
フィールド指示ヘッダーは可変長のテーブルであり、テーブル内の各項目は情報内のフィールドのオフセット アドレスと長さの情報を表します。SQL2000 には主に 4 つのフィールドがあり、対応するフィールド指示ヘッダーの構造は次のとおりです。 :
{
バイト CNETLIBVERNO;
ワード CNETLIBVERLEN;
ワード CENYFLAGOFFSET;
単語 SINSTNAMEOFFSET;
WORD SINSTNAMELEN;
BYTE CTHREADIDNO;
WORD CTHREADIDLEN;
BYTE CNETLIBVER[CNETLIBVERLEN]
BYTE S INSTNAME[SINSTNAMELEN]
DWORD CTHREADID[CTHREADIDLEN];
}
ここで:
CNETLIBVERNO フィールド ドメイン
オフセット: 0
長さ: 1
意味: のバージョン番号情報のフィールド番号クライアントが使用するネットワーク接続ライブラリ (NETLIB)。
説明:
備考: この値は 0 に固定されます
CNETLIBVEROFFSET フィールド
オフセット: 1
長さ: 2
意味: クライアントが使用するネットワーク接続ライブラリ ( NETLIB) バージョン番号情報フィールドのオフセット。
説明: フィールドの形式はネットワーク バイト オーダーです
備考:
CNETLIBVERLEN フィールド
オフセット: 3
長さ: 2
意味: クライアントによって使用されるネットワーク接続ライブラリ(NETLIB)のバージョン番号情報のフィールド長。
説明: フィールドの形式はネットワークバイトオーダーです
備考: 値は 6 に固定されます
CENYFLAGNO フィールド
オフセット: 5
長さ: 1
意味: 顧客エンドが暗号化を強制するために使用するマークされたフィールドのフィールド番号。
説明:
備考: この値は 1 に固定されています。
CENYFLAGOFFSET フィールド field
オフセット: 6
長さ: 2
意味: クライアントは強制暗号化を使用して、フィールドオフセット。
説明: フィールドの形式はネットワーク バイト オーダーです
備考:
CENYFLAGLEN フィールド
オフセット: 8
長さ: 2
意味: クライアントは必須暗号化フラグを使用します。フィールドの長さ。
説明: フィールドの形式はネットワークバイトオーダーです
備考: 値は 1 に固定されます
SINSTNAMENO フィールド
オフセット: 0XA
長さ: 1
意味: Customer Theクライアントにはサーバーのインスタンス名フィールドのフィールド番号が必要です。
説明:
備考: この値は 2 に固定されています
SINSTNAMEOFFSET フィールド
オフセット: 0XB
長さ: 2
意味: クライアントはサーバーのインスタンス名を必要としますセグメントオフセット。
説明: フィールドの形式はネットワーク バイト オーダーです
備考:
SINSTNAMELEN フィールド
オフセット: 0XD
長さ: 2
意味: クライアントはサーバーのインスタンス名フィールドの長さ。
説明: フィールドの形式はネットワーク バイト オーダーです
備考:
CTHREADIDNO フィールド
オフセット: 0XF
長さ: 1
意味: クライアント プロセスのスレッド ID フィールドフィールドの番号。
説明:
備考: この値は 3 に固定されます。
CTHREADIDOFFSET フィールド field
オフセット: 0X10
長さ: 2
意味: クライアントプロセスのスレッド ID フィールドオフセット。
説明: フィールドの形式はネットワーク バイト オーダーです
備考:
CTHREADIDLEN フィールド
オフセット: 0X12
長さ: 2
意味: クライアント プロセスのスレッド ID 長さフィールドの。
説明: フィールドの形式はネットワークバイトオーダーです
備考: 値は 4 に固定されます
FILEDEND フィールド
オフセット: 0X14
長さ: 1
意味: これフィールドマークフィールドはヘッダーが統合されていることを示し、以下がフィールド情報です。
説明: 終了タグは 0XFF です。
備考:
CNETLIBVER フィールド
オフセット: 0X15
長さ: 6
意味: クライアントが使用するネットワーク接続ライブラリ (NETLIB) ) バージョン番号。
注: バージョン番号は DBNETLIB.DLL のバージョンです
注: 形式はネットワーク バイト形式です。バージョン番号が 80.528.00 の場合、
08 00 02 10 00 00
CENYFLAG フィールド
オフセット: 0X1B
長さ: 1
意味: クライアント強制暗号化フラグ。
説明: 0 はクライアントが暗号化を強制しないことを意味し、1 はクライアントが強制暗号化を使用することを意味します
備考:
SINSTNAME フィールド
オフセット: 0X1C
長さ: SINSTNAMELEN
意味: クライアントが必要とするインスタンス名。
説明: シングルバイト形式
備考: デフォルトのインスタンスは MSSQLserver という名前を使用します
CTHREADID フィールド field
オフセット: 0X1C SINSTNAMELEN
長さ: 4
意味: クライアントプロセスのスレッドID。
注: フィールドの形式はホスト バイト オーダーです
備考:
上記の形式からわかるように、デフォルトのインスタンス名 MSSQLserver に接続された SQL TDS パッケージ形式は次の形式になります。 :
x12x01x00x34x00x00x00x00
x00x00x15x00x06x01x00x1b
x00x01x02x00x1cx00x0cx03
x00x28x00x04xffx08x00x00
xc2x00x00x00MSSQ
LServerx00
x78x03x00x00
しかし、NFR の攻撃シグネチャ ライブラリは
HELLO_SIG = "x12x01x00x34x00x00x00x00x00x00x15";
明らかに、これは通常の TDS 0x12 ログイン前パッケージの一部です。これほど多くのアラームがあるのも不思議ではありません。では、この NFR 攻撃シグネチャをどのように取得したのでしょうか。
脆弱性の説明から始めましょう!
5. 脆弱性の説明
NFR N-CODE のこの脆弱性の説明は次のとおりです。
誤検知
の性質上、誤検知は起こりそうにありません。攻撃
参考文献
Bugtraq 投稿
http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00125.html
悪用
http:/ / www.scan-associates.net/papers/sql2kx2.txt
この脆弱性は http://www.immunitysec.com/ の Dave Aitel と http://cert.uni-stuttgart からのものであることがわかります。 de/archive/bugtraq/2002/08/msg00125.html にリストされている MS SQL Server Hello Overflow NASL スクリプトでは、この脆弱性の鍵は次のステートメントにあることがわかります:
0x12 ,0x01 ,0x00 ,0x34 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x15 ,0x00 ,0x06 ,0x01 ,0x00 ,0x1b, > 0x00、0x01、0x02、 0x00 ,0x1c ,0x00 ,0x0c ,0x03 ,0x00 ,0x28 ,0x00 ,0x04 ,0xff ,0x08 ,0x00 ,0x02,
0x10 ,0x00 ,0x00 ,0x00
); 🎜>pkt_tail = raw_string (
0x00 ,0x24 ,0x01 ,0x00 ,0x00
);
…..
if(get_port_state(port))
{
soc = open_sock_tcp(port);
if(soc)
{
攻撃文字列=crap(560)
sql_packet = pkt_hdr 攻撃文字列
send(socket:soc, data:sql_packet);
r = recv(socket:soc, length:4096);
close(soc); "n");
if(!r)
{
display("MSSQLn のセキュリティ ホール")
security_hole(port:port, data:report); > }
このうち、pkt_hdr は TDS プロトコルに従って構築されたパケットで、途中に 560 文字の X が付加されており、pkt_tail は構築された TDS パケットの末尾です。
ここから、貧弱な NFR が MS SQL Server Hello Overflow NASL スクリプトの pkt_hdr から無責任に 11 文字を取り出し、それらを署名として断固として使用したことがわかります。さらにばかげているのは、「攻撃の性質上、誤検知の可能性は低い」と実際に述べていることです。
これは多くのレビューではるかに先を行っている NFR ですか?その後、この件についてスターダストと話したとき、多くの評価機関がIDS製品を評価する際に、製品の誤検知の検出に注意を払い、誤検知の評価を無視しているという事実と、この現象が関係しているのではないかと思いました。製品を評価する場合、ほとんどはブラックボックス評価であるため、偽陰性を検出するには、いくつかのエクスプロイトを収集するだけで済みます。ただし、ここで説明する SQL Server などの一部のシステムは、通常のパッケージを生成する必要があります。 , そのプロトコルのパケット形式を理解していないと、生成するのは困難です。したがって、一部の IDS はこの抜け穴を利用し、脆弱性の本当の原因を分析せずに、エクスプロイトを収集するだけで、攻撃コードを攻撃シグネチャとして直接公開します。
この脆弱性の理由を分析しましょう。その後、この分析に基づいてより完全な攻撃シグネチャを作成できます。
6. 脆弱性分析
IDA を使用して SSlibnet.dll を逆アセンブルすると、次のことがわかります:
.text:42CF6F49 loc_42CF6F49: ; CODE XREF: sub_42CF6E4F EA j
.text:42CF6F49 mov eax, [ebp 0xc]
.text:42CF6F4C add eax, [ebp-0x218]
.text:42CF6F52 Push eax
.text:42CF 6F53 lea ecx, [ ebp-0x214]
.text:42CF6F59 Push ecx
.text:42CF6F5A call strcpy
.text:42CF6F5F add esp, 8
.text:42CF6F62 Push offset unk_42D01104
.text: 42CF6F67 lea edx, [ebp-0x214]
.text:42CF6F6D Push edx
.text:42CF6F6E call strcmp
.text:42CF6F73 add esp, 8
この脆弱性の理由プログラムが strcpy を使用してコピーする場合、ソース文字列が 0x214 (つまり 532) を超えると、ターゲット アドレスの後の環境変数が上書きされ、オーバーフローが発生します。この脆弱性は非常に初期のものであり、「Slammer」ワームに遭遇した後、基本的にすべてのシステムがこの脆弱性にパッチを当てているため、攻撃コードはここでは提供されなくなりました。興味のある人は自分で分析して作成できます。
ここでもう 1 つ注意すべき点は、TDS プロトコルとこの脆弱性の原因を分析すると、完全な攻撃プログラム内の TDS パケットの長さが計算に基づいて生成され、明らかにSQL Server での TDS パケット長チェックを回避するため (もちろん、このバージョンの SQL Server にはこのチェックは含まれていません)、または攻撃プログラムが攻撃コードを複数のパッケージに分割するため、"x00x34" " にしないでください。 TDS 形式のステータス 0x01 にはならないため、NFR は完全な攻撃プログラムを検出できません。つまり、この脆弱性については、NFR には誤検知と脆弱性の両方が存在します。
この脆弱性の原因を分析した後、この問題に対する独自の NFR 検出コードを作成できます:
sqlserv_schema = library_schema:new(1, ["time" ,"ip ","int","ip","int", "str"],
scope());
sqlserv_rec = Recorder("bin/list %c", "sqlserv_schema"); " フィールドヘッダーの全長を示します
....
filter hello tcp (client, dport: 1433) {
tcp.connsym 内で $Blob を宣言します。 > if ($Blob == NULL) {
$Blob = tcp.blob;
} else {
$Blob = cat($Blob, tcp.blob);
if (strlen($Blob) < MIN_LEN)
return;
if (prefix($Blob, HELLO_SIG) && strlen($Blob) > 295) {
#例 名前は 255 を超えることはできないため、ここでの長さは 40 (ヘッダー) 255=295
# ユーザーがイベント
#Alarm
に従って調整できるように、値を追加することもできます。
}
7. 要約
NFR 攻撃シグネチャの分析を通じて、完全な IDS 攻撃シグネチャを公開するのは簡単なことではないことがわかります。アプリケーションプロトコルの形式と脆弱性の原因を理解します。ネットワーク上に存在するエクスプロイトを単に収集してシグネチャを傍受するのではなく。
現在、IDS 開発者を含む多くの人々が、IDS に将来性があるかどうか、またその必要性について議論しています。そこで議論するよりも、腰を据えて脆弱性を分析し、攻撃シグネチャを改善し、IDSをより正確にする方が良いと思います。
座って話すのではなく、立ち上がって行動を起こしましょう! ！ (出典: www.xfocus.net)
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
