1. Preface 3
2. Alarm Information 3
3. Detection of NFR 4
4. Protocol Analysis 8
5. Vulnerability Description 15
6. Vulnerability Analysis 18
7. Summary 20
1. Preface
NFR (Network Flight Recorder) is an established business networking IDs product that was originally created by Firewall's cattle man Marcus J. Ranum, and is implemented as a generic network traffic analysis and recording software. To maximize the flexibility of analysis tools, NFR provides a robust N-code scripting language that excels in many evaluations. Although L0PHT has provided over hundreds of signature libraries for NFR, the lack of a reliable signature set has been his Achilles heel.
After a period of time using NFR, there are many problems found in NFR. And do not say that the AI is poor compatibility with Chinese and often quit, do not say that the NFR version upgrade and attack event description has been using the old version of the instructions, only the most critical attack signature database in IDs, but let me surprise. In addition to the slow upgrade, there are even many wrong signatures. This series of articles for some of the issues I found in the analysis and elaboration, in order to make better use of NFR products, but also want to discuss with colleagues in IDs of the attack signature Library writing. Due to the limitations of knowledge and time, mistakes are unavoidable, but also hope to receive your advice, any comments or suggestions, please send to: benjurry@xfocus.org
SQL Server is Microsoft's database against Oracle, occupying a market share second only to Oracle, and its security has been questioned by users. From 1996, Microsoft introduced the SQL Server 6.5 version to SQL Server 7.0 that was introduced in 1998, and to August 2000 launched SQL Server 2000, in the case of a version and feature escalation, Security issues are not well improved, and security bulletins and patches for SQL Server are constantly being released. On January 24, 2003, the "Slammer" worm against SQL Server raged on the internet, causing a surge in network traffic that severely impacted computer and network systems worldwide. The vulnerability of SQL Server has attracted the attention of major security companies and vendors, so NFR also immediately released multiple attack signatures for SQL Server, including the August 7, 2002 immunity company Dave Aitel found the Hello Buffer Overflow vulnerability. But in the process of use, I found that NFR to the vulnerability of the alarm very much, so I analyzed this, and wrote this article to do the record.
2. Alarm Information
The following is the alarm information for the MS SQL Hello Buffer overflow for NFR:
Severity:attack
Time:13:54:21 15-jul-2003
Source FILE:PACKAGES/MSSQL/SQL2K.NFR
line:226
Host:benjurry-xfocus
Alert ID:mssql_sql2k:buffered_hello
Source ID:mssql_sql2k:source_me
Source:mssql_sql2k:source_me
Source description:sqlserver 2k Overflow Detector
Source pid:36531
Alert Message:saw 8 Mssql HELLO overflows from 192.168
0.110 in seconds
: 3
Source ip:192.168.0.110
Destination IP:--
This includes the severity level of the event, time, NFR sensor name, attack source IP, destination IP, and some other alarm information.
In the actual use of the day produced hundreds of of such alarms, it seems that this is a false alarm, we can properly analyze it.
3. Detection of NFR
We first open the signature library published by NFR MSSQL.FP (or can also be viewed in the AI's package) to see the NFR attack signature for this vulnerability:
.....
Variable definition, etc...
...
Sqlserv_schema = library_schema:new (1, ["Time", "IP", "int", "IP", "int", "str"],
Scope ());
Sqlserv_rec = Recorder ("Bin/list%c", "Sqlserv_schema");
Hello_sig = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
Min_len = strlen (Hello_sig);
.......
Filter Hello TCP (client, dport:1433) {
declare $Blob inside Tcp.connsym;
if ($Blob = = NULL) {
$Blob = Tcp.blob;
} else {
$Blob = Cat ($Blob, Tcp.blob);
}
if (strlen ($Blob) < Min_len)
Return
if (prefix ($Blob, hello_sig)) {
if (Counthello[tcp.connsrc]) {
COUNTHELLO[TCP.CONNSRC] = counthello[tcp.connsrc] + 1;
} else {
COUNTHELLO[TCP.CONNSRC] = 1;
}
if (Do_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", "Medium",
"Alert_impact", "Unknown",
"Alert_event_type", "Attack",
"Alert_assessment", "Unknown",
"Ip_addr_src", TCP.CONNSRC,
"Port_src", Tcp.connsport,
"Ip_addr_dst", TCP.CONNDST,
"Port_dst", Tcp.conndport,
"Ip_proto_num", 6);
}
Record Packet.sec, TCP.CONNDST, Tcp.conndport, TCP.CONNSRC,
Tcp.connsport, $Blob to Sqlserv_rec;
Misc_attacks:rec (Packet.sec, scope (),
"Mssql HELLO overflow!", TCP.CONNSRC, TCP.CONNDST);
}
}
As we can see from the above N-code, NFR is doing this test with the following steps:
1. Defines an attack signature:
Hello_sig = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
And the length of the attack signature:
Min_len = strlen (Hello_sig);
2, the data from the TCP load data, the length of the data and the length of the signature comparison, if the length of the data is less than the length of the attack signature, then the next step is no longer detected;
3, otherwise, the data and the signature string matching, if consistent is considered an attack behavior, and then to block or alarm.
Next we analyze the data of the NFR IDS record, select Package->query->mssql->mssql Server 200 in the AI, set the conditions, according to table to find the data, randomly select a bar, Copy it to get the following content:
time:15-jul-2003 13:54:21
Nfr:benjurry-xfocus
Destination address:192.168.0.135
Destination port:1433
Source address:192.168.0.110
Source port:1391
Payload:
\x12\x01\x004\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b\x00
\x01\x02\x00\x1c\x00\x0c\x03\x00 (\x00\x04\xff\x08\x00\x00\xc2\x00
\x00\x00mssqlserver\x00x\x03\x00\x00
The above record contains the time of the attack, the NIDs sessor name of the attack, the destination IP, the destination port, the source IP, and the source port, and we are concerned about payload payload because it is the data that NIDs uses to compare against the attack signature library. But NFR has a few minor problems here:
1. Converts the 16 binary numbers in the payload to ASCII characters into ASCII code;
2. Unicode characters cannot be processed, this will be seen in a later analysis.
In this example, for ease of analysis, we convert the character signature portion of the above payload to a 16 binary number:
\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b
\x00\x01\x02\x00\x1c\x00\x0c\x03\x00\x28\x00\x04\xff\x08\x00\x00
\xc2\x00\x00\x00mssqlserver\x00x\x03\x00\x00
NFR caught the packet, found that the SQL Server package, then the contents of the SQL Server and the attack database comparison, it is clear that the data listed above and the attack library is consistent, so an alarm is generated, but this is really an attack behavior? We continue to look at the following analysis.
4. Protocol Analysis
According to Xfocus's Protocol Analysis project (which will be published in the near future), MS SQL 2000 uses TDS8.0, which is in the following format:
-------------------------------------------------
| TDs Header (8 bytes) | TDS Load Data |
-------------------------------------------------
The BAOTOU structure of MS SQL SERVER TDS is as follows:
-------------------------------------------------------------------
| TOKEN | STATUS | LENGTH | Signed NUM | PACKET NUM | WINDOW SIZE |
-------------------------------------------------------------------
Where the token field is 1 bytes and is used to indicate the type of TDS operation request. In this vulnerability is 0x12, the first byte 0x12 in the payload in the NFR record, 0x12 is a pre-logon validation command request. The purpose is to obtain some of the current MS SQL SERVER2000 settings, such as the SQL Server version, whether encryption and other information, as a client in the construction of TDS packet basis. When SQL Server accepts a package of that type, it will be handled by the corresponding function in SSlibnet.dll, in the case of my system SQL Server 2000 (without SP), the corresponding function is as follows:
. text:42cf6ddd; attributes:bp-based Frame
. text:42cf6ddd
. text:42cf6ddd Public Connectionprelogin
. text:42cf6ddd Connectionprelogin Proc Near
. text:42cf6ddd
. 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
. text:42cf6ddd Arg_c = dword ptr 14h
. text:42cf6ddd arg_10 = dword ptr 18h
. text:42cf6ddd
. TEXT:42CF6DDD Push EBP
. Text:42cf6dde mov ebp, esp
. 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:42CF6DF7 Jle Short Loc_42cf6e3d
. TEXT:42CF6DF9 CMP [ebp+var_4], 3
......
The Status field 1 bytes when it is 0x01 indicates that this package is the last TDS package in the current TDs session.
The Length field is 2 bytes, representing the total length of the TDS package, including the TDS header.
Signed num Field field 2 bytes, currently reserved unused.
PACKET num Field field 1 bytes, indicating the ordinal of this TDS package in the current TDS operation request
WINDOW size Field 1 bytes, currently reserved unused.
The package main package format for MS SQL SERVER 0X12 TDS is as follows:
------------------------------------------------------
| TDs Header (8 bytes) | Field Indicator Header | Information |
------------------------------------------------------
Where the field indicates that the header is a table that can be changed, each item of the table represents the offset address and length information in a field in the information, the SQL2000 is mainly 4 fields, and its corresponding field indicates the structure of the header as follows:
{
BYTE Cnetlibverno;
WORD Cnetlibveroffset;
WORD Cnetlibverlen;
BYTE Cenyflagno;
WORD Cenyflagoffset;
WORD Cenyflaglen;
BYTE Sinstnameno;
WORD Sinstnameoffset;
WORD Sinstnamelen;
BYTE Cthreadidno;
WORD Cthreadidoffset;
WORD Cthreadidlen;
BYTE Filedend;
}
The structure of the information content is as follows:
{
BYTE Cnetlibver[cnetlibverlen]
BYTE Cenyflag[cenyflaglen];
BYTE Sinstname[sinstnamelen]
DWORD Cthreadid[cthreadidlen];
}
which
Cnetlibverno Field Fields
Offset: 0
Length: 1
Meaning: The field number of the version number information that the client uses for the network Connection library (NETLIB).
Description
Note: This value is fixed to 0
Cnetlibveroffset Field Fields
Offset: 1
Length: 2
Meaning: The client uses a field offset for the version number information of the Network Connection library (NETLIB).
Description: Field format is network byte order
Note:
Cnetlibverlen Field Fields
Offset: 3
Length: 2
Meaning: The field length of the version number information that the client uses for the network Connection library (NETLIB).
Description: Field format is network byte order
Note: This value is fixed to 6
Cenyflagno Field Fields
Offset: 5
Length: 1
Meaning: The client uses the field number of the Force Encryption flag field.
Description
Note: This value is fixed to 1
Cenyflagoffset Field Fields
Offset: 6
Length: 2
Meaning: The client uses force encryption to mark the offset of the field.
Description: Field format is network byte order
Note:
Cenyflaglen Field Fields
Offset: 8
Length: 2
Meaning: The client uses force encryption to mark the length of the field.
Description: Field format is network byte order
Note: This value is fixed to 1
Sinstnameno Field Fields
Offset: 0XA
Length: 1
Meaning: The client requires the use of the field number of the server's instance name segment.
Description
Note: This value is fixed to 2
Sinstnameoffset Field Fields
Offset: 0XB
Length: 2
Meaning: The client requires the use of the server's Instance Name field offset.
Description: Field format is network byte order
Note:
Sinstnamelen Field Fields
Offset: 0XD
Length: 2
Meaning: The client requires the length of the instance Name field of the server to be used.
Description: Field format is network byte order
Note:
Cthreadidno Field Fields
Offset: 0XF
Length: 1
Meaning: The field number of the thread ID field of the client process.
Description
Note: This value is fixed to 3
Cthreadidoffset Field Fields
Offset: 0X10
Length: 2
Meaning: The offset of the thread ID field of the client process.
Description: Field format is network byte order
Note:
Cthreadidlen Field Fields
Offset: 0X12
Length: 2
Meaning: The length of the thread ID field of the client process.
Description: Field format is network byte order
Note: This value is fixed to 4
Filedend Field Fields
Offset: 0x14
Length: 1
Meaning: This field marker field indicates that the header is strong, and the following is the information for the field.
Description: End tag is 0XFF
Note:
Cnetlibver Field Fields
Offset: 0X15
Length: 6
Meaning: The version number of the Network Connection library (NETLIB) used by the client.
Description: Its version number is DBNETLIB.DLL version
Note: The format is network byte format, if the version number is 80.528.00;
08 00 02 10 00 00
Cenyflag Field Fields
Offset: 0X1B
Length: 1
Meaning: The client enforces the encryption flag.
Description: 0 on behalf of the client does not force encryption, 1 for clients using force encryption
Note:
Sinstname Field Fields
Offset: 0X1C
Length: Sinstnamelen
Meaning: the instance name that the client requires to use.
Description: Single byte format
Note: The default instance uses the name MSSQLServer
Cthreadid Field Fields
Offset: 0x1c+sinstnamelen
Length: 4
Meaning: The thread ID of the client process.
Description: Field format is host byte order
Note:
As can be seen from the above format, a SQL TDS package with the default instance name MSSQLSERVER connection will be in the following format:
\x12\x01\x00\x34\x00\x00\x00\x00
\x00\x00\x15\x00\x06\x01\x00\x1b
\x00\x01\x02\x00\x1c\x00\x0c\x03
\x00\x28\x00\x04\xff\x08\x00\x00
\xc2\x00\x00\x00mssq
lserver\x00
\x78\x03\x00\x00
And NFR's Attack signature library is
Hello_sig = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
Obviously is the normal TDs 0x12 pre-landing package part, this is no wonder there will be so many alarm, that NFR the attack signature is how to get it?
Let's start with its loophole.
5. Vulnerability description
The following is a description of the vulnerability in NFR n-code:
FALSE Positives
False positives is unlikely due to the nature of the attack
REFERENCES
Bugtraq Post
Http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00125.html
Exploit
Http://www.scan-associates.net/papers/sql2kx2.txt
We can see that this loophole comes from http://www.immunitysec.com/Dave Aitel, and from http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/ The key to the vulnerability that we can see in the MS SQL Server Hello Overflow NASL script listed in msg00125.html is the following statements:
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_tcp (port);
if (Soc)
{
Attack_string=crap (560);
Sql_packet = Pkt_hdr+attack_string+pkt_tail;
Send (SOCKET:SOC, data:sql_packet);
R = recv (Socket:soc, length:4096);
Close (Soc);
Display ("Result:", R, "\ n");
if (!r)
{
Display ("Security Hole in mssql\n");
Security_hole (Port:port, Data:report);
}
}
Wherein the PKT_HDR is a package constructed according to the TDS protocol, with a 560-character x,pkt_tail in the middle of the TDS packet tail is constructed.
From here we can see that poor NFR incredibly irresponsible to take out 11 characters of PKT_HDR in MS SQL Server Hello Overflow NASL script, and resolutely take them as their signature. It's even more ridiculous to say "False positives is unlikely due to the nature of the attack".
Is this the NFR in many reviews? Later and Stardust chat about this matter, think of this phenomenon and many evaluation agencies in the evaluation of IDs products, pay attention to the detection of product false negatives and ignore the evaluation of false positives. Because in the evaluation of products, basically are mostly black box evaluation, to detect false negatives as long as the collection of several exploits can be carried out, but to detect false negatives but to produce a normal package, some systems such as the SQL Server here, if you do not understand its protocol package format, it is difficult to produce. As a result, some IDs produced such loopholes, as long as the collection of some exploits, the attack code as an attack signature directly published, not to analyze the actual cause of the vulnerability.
Let's analyze the cause of this vulnerability, and then we can write a more sophisticated attack signature based on this analysis.
6. Vulnerability Analysis
Using IDA to disassemble the SSlibnet.dll, we can see:
. 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:42cf6f53 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
The reason for this vulnerability is that, when the program is copied with strcpy, if the source string exceeds 0x214 (that is, 532), the environment variable after the destination address will be overwritten causing overflow. Because of this vulnerability early, after experiencing the "Slammer" worm, basically all of the system has to fill out the vulnerability, so here is not to provide the attack code, interested friends can analyze and write their own.
It is also necessary to explain here that if the TDS protocol and the cause of the vulnerability is analyzed, the length of the TDS packet in the perfect attack program is generated according to the calculation, obviously not "\x00\x34", to avoid SQL Server for TDS packet length verification (of course, in this version of SQL Server does not include this check), or the attack program to break this attack code into multiple packages, so the TDS format is not the status of 0x01, so NFR is not detected a perfect attack program, that is, for this vulnerability, NFR there is a false alarm and vulnerability situation.
After analyzing the cause of this vulnerability, we can write our own NFR detection code for this issue:
Sqlserv_schema = library_schema:new (1, ["Time", "IP", "int", "IP", "int", "str"],
Scope ());
Sqlserv_rec = Recorder ("Bin/list%c", "Sqlserv_schema");
Hello_sig = "\x12";
#考虑了分包和长度不固定的因素, removing the unreliable feature string at the back
Min_len = 29;
#包括TDS包头和字段指示头的总长度
.......
Filter Hello TCP (client, dport:1433) {
declare $Blob inside Tcp.connsym;
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, so the length chosen here is 40 (Baotou) +255=295
#也可以增加一个Value so that users can adjust themselves according to the event situation
#报警
....
}
7. Summary
By analyzing the signature of the attack on NFR, it can be seen that the release of a perfect IDs attack signature is not a simple matter, it needs to understand the application protocol format and the cause of the vulnerability. Instead of simply collecting the exploits that exist on the network, then intercept the signatures.
Many people, including IDs developers, are talking about whether IDs has a future and need not. I think it is better to calm down and analyze the loopholes, perfect the attack signature, and make IDs more accurate.
Rather than sitting and talking about the line!! (Source: www.xfocus.net)
http://www.bkjia.com/PHPjc/314964.html www.bkjia.com true http://www.bkjia.com/PHPjc/314964.html techarticle 1. Preface 3 2. Alarm Information 3 3.NFR Detection 4 4. Protocol Analysis 8 5. Vulnerability Description 15 6. Vulnerability Analysis 18 7. Summary 20 1. Preface NFR (Network Flight Recorder) is an established business network IDs product ...
