NFR One の最適化 -- MSSQL Hello Buffer Overflow_PHP チュートリアル-PHPチュートリアル-php.cn

1. はじめに 3
2. アラーム情報 3
3. NFR の検出 4
5. 脆弱性の説明 15
6. 概要 20

1. Flight Recorder) は、ファイアウォールのマスターである Marcus J. Ranum によって作成された古い商用ネットワーク IDS 製品であり、分析ツールの柔軟性を最大限に高めるために、一般的なネットワークトラフィック分析および記録ソフトウェアとして実装されています。 NFR は、多くのレビューで優れたパフォーマンスを示している、完全かつ強力な N コードスクリプト言語を提供します。 L0pht は NFR 用に何百もの署名ライブラリを提供していますが、信頼できる署名セットが存在しないことが常に弱点でした。

NFR をしばらく使ってみたところ、NFR には多くの問題があることがわかりました。中国語との互換性が悪いために AI が頻繁に終了することは言うまでもなく、NFR のバージョンもアップグレードされませんが、攻撃イベントの説明は常に古いバージョンの説明を使用します。IDS の中で最も重要な攻撃シグネチャライブラリだけでも驚きました。アップグレードが遅いだけでなく、間違った署名も多数あります。このシリーズの記事では、NFR 製品をより効果的に活用できるように、私が発見したいくつかの問題を分析して詳しく説明します。また、IDS での攻撃シグネチャライブラリの準備についても同僚と話し合いたいと思います。知識と時間に限界があるため、間違いは避けられません。また、ご意見やご提案があれば、benjurry@xfocus.org までお送りください。 SQL Server は、Oracle と競合するために Microsoft が立ち上げたデータベースです。そのシェアはOracleに次いで世界第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 15-Jul-2003
ソースファイル: package/mssql/sql2k .nfr
行: 226
ホスト: benjurry-xfocus
アラート ID: mssql_sql2k:buffered_hello
ソース ID: mssql_sql2k:source_me
ソース: mssql_sql2 k:source_me
ソースの説明: 2k オーバーフロー検出器
ソース PID: 36531
アラートメッセージ: 192.168 から 8 個の Mssql HELLO オーバーフローが発生しました
900 秒で 0.110
: 3
送信元 IP: 192.168.0.110
宛先 IP: --

イベント重大度、時間、NFR S センサー名、攻撃元 IP、宛先 IP などを含むアラーム情報。
実際の使用では、このようなアラームが 1 日に数百件発生します。これは誤ったアラームであると考えられます。

3. NFR の検出
まず、NFR によってリリースされた署名ライブラリ MSSQL.fp を開き (または AI パッケージで表示することもできます)、この脆弱性に対する NFR の攻撃署名を確認します。 ;sqlserv_schema = library_schema:new(1, ["time","ip","int","ip", "int", "str"] ,
sqlserv_rec = レコーダー("bin/list %c", "sqlserv_schema");

HELLO_SIG = "x12x00x00x00x00x00x00x00x15"; (HELLO_SIG);

…….
filter hello tcp (client, dport: 1433) {
if ($Blob == NULL) {
$Blob = tcp.blob; } else {
$Blob = cat ($Blob, tcp.blob);
}

if (strlen($Blob) return;
if (prefix($Blob, HELLO_SIG)) {
if (COUNTHELLO[tcp.connsrc]) {
COUNTHELLO[tcp.connsrc] = COUNTHELLO[tcp.connsrc] + 1;
} else {
COUNTHELLO[tcp.connsrc] = 1; _alert(hello_overflow_alert, tcp .connsrc)) {
alert(source_me, hello_overflow_alert, tcp.connsrc,
tcp.connsport, tcp.conndst, tcp.conndport,
"--AlertDetails",
"ALERT_ID", "40-8",
"ALERT_CONFIDENCE "、60、
"ALERT_SEVERITY" 、"中"、
"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, t cp.conndport , tcp.connsrc,
tcp.connsport , $Blob から sqlserv_rec;
miss_attachs:rec(packet.sec,scope(),
"Mssql HELLO オーバーフロー!", tcp.connsrc, tcp.conndst);
上記の N-CODE から、NFR がこのテストを実行するときの手順は次のとおりであることがわかります。

1、攻撃機能コード:
Hello_sig = "x12x01x00x34x00x00x00x00x00x15" および攻撃機能コード長:
を定義します。 min_len = stren (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.1 10 CEポート: 1391
ペイロード:

DS セッション名、宛先 IP、宛先ポート、送信元 IP および送信元ポート、およびペイロードペイロードは NI によって使用されるデータであるため、ただし、DS は攻撃シグネチャライブラリと比較します。ここにはいくつかの小さな問題があります:

1. ASCII 文字に変換できるペイロード内の 16 進数を ASCII コードに変換します。これは今後の分析で判明します。

この例では、分析の便宜上、上記のペイロード内の文字署名部分を 16 進数に変換します:
x12x01x00x34x00x00x00x00x00x00x15x00x06x01x00x1b
x00x01x02x00x1cx00x0cx03x00 x 28x00x04xffx08x00x00
xc2x00x00x00MSSQLServerx00xx03x00x00

NFR がデータグループパッケージをキャッチし、それが SQL Server であることが判明しましたパッケージを作成し、その内容を SQL Server の攻撃データベースと比較したところ、明らかに上記のデータは攻撃データベースと一致しているため、アラームが生成されました。以下の分析を続けてみましょう。

4. プロトコル分析

Xfocus のプロトコル分析プロジェクト (プロジェクトの結果は近い将来発表されます) によると、MS SQL 2000 は TDS8.0 を使用しており、その形式は次のとおりです。 -- --------------------------------------
| TDS ヘッダー (8 バイト) | 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: ; 4
.text:42CF6DDD arg_0 = dword ptr 8
.text:42CF6DDD arg_4 = dword ptr 0Ch
.text:42CF6DDD arg_8 = dword ptr 10h
.text:42CF6DDD arg_C = dword ptr 14h
.text:42CF 6DDD arg_10 = dword ptr 18h
.text:42CF6DDD
.text:42CF6DDD ebp をプッシュ
.text:42CF6DDE mov ebp、esp
.text:42CF6DE0 ecx をプッシュ
.text:42CF6DE1 mov eax, [ebp+arg_0]
.text:42CF6DE4 mov ec ×、 [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:42CF6DF7 jle short loc_42CF6E3D
.text:42CF6DF9 cmp [ebp+var_4], 3
……

STATUSフィールドが1バイトの場合、このパケットが最後のTDSパケットであることを意味します。現在の TDS セッション内。
LENGTH フィールドは 2 バイトで、TDS パケットのヘッダーの長さを含む TDS パケットの合計長を示します。
SIGNED NUM フィールドは 2 バイトで、現在予約されており未使用です。
PACKET NUM フィールドは 1 バイトで、現在の TDS 操作リクエスト内のこの TDS パケットのシーケンス番号を示します。
WINDOW SIZE フィールドは 1 バイトで、現在予約されており未使用です。
MS SQL SERVER 0X12 TDS の主なパッケージ形式は次のとおりです:
---------------------------------- -------------- ------------------
フィールド表示ヘッダー | ------------------------ -------------------------------------------- --
フィールド指示ヘッダーは可変長テーブルであり、テーブルの各項目は情報内のフィールドのオフセットアドレスと長さの情報を表します。SQL2000 では、対応するフィールド指示ヘッダーの構造は主に 4 つです。次のように:
バイト CNETLIBVERNO;
ワード CNETLIBVERLEN;
ワード CENYFLAGLEN;
WORD SINSTNAMELEN;
WORD CTHREADOFFSET; WORD CTHREADLEN;
BYTE FILEDEND
}
情報コンテンツの構造は次のとおりです:
{ BYTE CNETLIBVER[CNETLIBVERLEN]
BYTE SINSTNAME[SINSTNAMELEN]
DWORD CTHREADID[CTHREADLEN]
}
どこ:
CNETLI BVERNOフィールド
オフセット: 0
長さ: 1
意味: クライアントが使用するネットワーク接続ライブラリ(NETLIB)のバージョン番号情報のフィールド番号。
説明:
備考: この値は0固定です。

CNETLIBVEROFFSETフィールド field
Offset: 1
Length: 2
意味: クライアントが使用するネットワーク接続ライブラリ(NETLIB)のバージョン番号情報のフィールドオフセット。
説明: フィールドの形式はネットワークバイトオーダーです。
備考:

CNETLIBVERLENフィールド
Offset: 3
Length: 2
意味: クライアントが使用するネットワーク接続ライブラリ(NETLIB)のバージョン番号情報のフィールド長。
説明: フィールド形式はネットワークバイトオーダーです。
備考: 値は 6 に固定です。

CENYFLAGNO フィールド
Offset: 5
Length: 1
意味: クライアントは必須暗号化マークフィールドのフィールド番号を使用します。
説明:
備考: この値は 1 に固定されます。

CENYFLAGOFFSET フィールド field
Offset: 6
Length: 2
意味: クライアントは必須の暗号化マークフィールドのオフセットを使用します。
説明: フィールド形式はネットワークバイトオーダーです
備考:

CENYFLAGLEN フィールド
オフセット: 8
長さ: 2
意味: クライアントは強制暗号化を使用してフィールドの長さをマークします。
説明: フィールドの形式はネットワークバイトオーダーです。
備考: 値は 1 に固定されます。

SINSTNAMENO フィールド
Offset: 0XA
Length: 1
意味: クライアントはサーバーのインスタンス名フィールドのフィールド番号を必要とします。
説明:
備考: この値は 2 に固定です。

SINSTNAMEOFFSET フィールド
オフセット: 0XB
長さ: 2
意味: クライアントはサーバーのインスタンス名フィールドのオフセットを必要とします。
説明: フィールド形式はネットワークバイトオーダーです。
備考:

SINSTNAMELEN フィールド
オフセット: 0XD
長さ: 2
意味: クライアントはサーバーのインスタンス名フィールドの長さを必要とします。
説明: フィールド形式はネットワークバイトオーダーです。
備考:

CTHREADIDNO フィールド
オフセット: 0XF
長さ: 1
意味: クライアントプロセスのスレッド ID フィールドのフィールド番号。
説明:
備考: この値は 3 に固定です。

CTHREADIDOFFSET フィールド
オフセット: 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 フィールド
オフセット: 0X1C+SINSTNAMELEN
長さ: 4
意味: クライアントプロセスのスレッド ID。
説明: フィールドの形式はホストバイトオーダーです
備考:

上記の形式からわかるように、デフォルトのインスタンス名 MSSQLserver に接続された SQL TDS パッケージの形式は次のようになります:
x12x01x00x34x00x00x00x00
x00x00x15x00x06x01x00x1b
x0 0x01x02x00x1cx00x0cx03
x00x28x00x04xffx08x00x00
xc2x00x00x00MSSQ
LServerx00
x78x03x00x00

NFR の攻撃署名ライブラリは
HELLO_SIG = "x12x01x00x34x00x0 0x00x00x00x00x15";
明らかに通常の TDS 0x12 ログイン前パッケージの一部、非常に多くのアラームがあるのも不思議ではありません。 NFR どうやって知りましたか？
脆弱性の説明から始めましょう!

5. 脆弱性の説明
以下は、NFR N-CODE のこの脆弱性の説明です:
誤検知

攻撃の性質上、誤検知は起こりそうにありません

参考資料
Bugtraq Post
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 スクリプトから、この脆弱性の鍵は次のステートメントにあります:

pkt_hdr = raw_string(
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_ tc p(ポート); if (soc)

攻撃文字列=crap(560);
sql_packet = pkt_hdr+攻撃文字列+pkt_tail;

r = recv(ソケット:soc、長さ:4096) ;
close(soc);
display ("Result:",r,"n");
if(!r) {
security_hole(port:port, data:)このうち、pkt_hdr は TDS プロトコルに従って構築された 560 文字のパケットです。

ここから、貧弱な NFR が MS SQL Server Hello Overflow NASL スクリプトの pkt_hdr から無責任に 11 文字を取り出し、それらを署名として断固として使用したことがわかります。さらにばかげているのは、「攻撃の性質上、誤検知の可能性は低い」と実際に述べていることです。
これは多くのレビューではるかに先を行っているNFRですか？その後、この件についてスターダストと話したとき、多くの評価機関がIDS製品を評価する際に、製品の誤検知の検出に注意を払い、誤検知の評価を無視しているという事実と、この現象が関係しているのではないかと思いました。製品を評価する場合、ほとんどはブラックボックス評価であるため、偽陰性を検出するには、いくつかのエクスプロイトを収集するだけで済みます。ただし、ここで説明する SQL Server などの一部のシステムは、通常のパッケージを生成する必要があります。 , プロトコルのパケット形式を理解していないと、生成するのは困難です。したがって、一部の IDS はこの抜け穴を利用し、脆弱性の本当の原因を分析せずに、エクスプロイトを収集するだけで、攻撃コードを攻撃シグネチャとして直接公開します。

この脆弱性の理由を分析しましょう。その後、この分析に基づいてより完全な攻撃シグネチャを作成できます。

6. IDA を使用して SSlibnet.dll を逆アセンブルすると、次のことがわかります:

.text:42CF6F49 loc_42CF6F49: ; CODE eax, [ebp+ 0xc]
.text:42CF6F4C add eax, [ebp-0x21] 8]
.text:42CF6F52 プッシュ eax
.text:42CF6F53 lea ecx, [ebp-0x214]
.text:42 CF6F59 プッシュ ecx
.text:42CF6F5A call strcpy
.text:42CF6F5F add esp,
.text:42CF6 F62プッシュ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 パケットの長さは計算に基づいて生成され、明らかに「x00x34」ではないということです。 SQL を回避するサーバーが TDS パケットの長さをチェックします (もちろん、このバージョンの SQL Server にはまだこのチェックが含まれていません)。または、攻撃プログラムが攻撃コードを複数のパケットに分割するため、TDS 形式のステータスは表示されません。したがって、NFR は完全な攻撃プログラムを検出できません。これは、この脆弱性に関して、NFR には誤検知と脆弱性の両方があることを意味します。

この脆弱性の原因を分析した後、この問題に対する独自の NFR 検出コードを作成できます:

sqlserv_schema = library_schema:new(1, ["time","ip","int"," ip", "int", "str"],
scope());
sqlserv_rec = records("bin/list %c", "sqlserv_schema");

HELLO_SIG = "x12 "; 、末尾の信頼性の低い機能文字列を削除します
MIN_LEN =29;
#TDS パケットヘッダーとフィールド指示ヘッダーの合計長を含みます

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 (Baot ヘッダー) + 255 = 295 です
# ユーザーがイベントの状況に応じて調整できるように、値を追加することもできます
# アラーム
…

}

攻撃を通して 7. NFR についてシグネチャ分析から、完全な IDS 攻撃シグネチャを公開するのは簡単なことではないことがわかります。それには、アプリケーションプロトコルの形式と脆弱性の原因を理解する必要があります。ネットワーク上に存在するエクスプロイトを単に収集してシグネチャを傍受するのではなく。
現在、IDS開発者を含む多くの人々が、IDSに将来性があるのか、必要なのかについて議論しています。そこで議論するよりも、腰を据えて脆弱性を分析し、攻撃シグネチャを改善し、IDSをより正確にする方が良いと思います。
座って話すよりも、立ち上がって行動を起こす方が良いです! ！ (出典: www.xfocus.net)