1. Foreword
NFR (Network Flight Recorder) is an established commercial network IDs product, originally created by firewall's cattle Marcus J. Ranum, as a general-purpose network traffic analysis and recording software. To maximize the flexibility of the analysis tools, NFR provides a robust, N-code scripting language that works well in many evaluations. Although L0pht has hundreds of signature libraries for NFR, the lack of a reliable signature set has been his Achilles heel.
After using NFR for some time, it is found that NFR has many problems. And do not say that the AI for Chinese poor compatibility and often quit, also do not say NFR version upgrade and attack event description has been used in the old version of the description, only the IDs of the most critical attack signature library, but let me surprise. In addition to slow upgrades, there are even a number of false signatures. This series of articles on some of the issues I found to analyze and explain, so that you can better use the NFR products, but also want to discuss with colleagues in IDs attack Signature Library writing. Due to the knowledge and time constraints, errors are unavoidable, but also want to get your advice, any comments or suggestions please send to: benjurry@xfocus.org
SQL Server is Microsoft's database against Oracle, the occupation of the market share has been second only to Oracle, in the world, but its security has been questioned by users. From 1996, Microsoft introduced SQL Server version 6.5 to SQL Server 7.0, which was launched in 1998, and SQL Server 2000 was launched in August 2000, and with the release and functionality escalating, Security issues have not improved well, and security bulletins and patches for SQL Server are being released. On January 24, 2003, the "Slammer" Worm for SQL Server raged on the internet, causing a surge in network traffic, which severely affected computers and network systems worldwide. SQL Server vulnerabilities have been brought to the attention of major security companies and vendors, so NFR also immediately released a number of attack signatures against SQL Server, including the August 7, 2002 immunity company Dave Aitel found the Hello Buffer Overflow vulnerabilities. But in the course of use, I found that NFR for the vulnerability of the alarm is very much, so I analyzed it, so I wrote this article to make a record.
2. Alarm Information
The following is a NFR alert message for MS SQL Hello Buffer Overflow:
This includes the severity level of the event, the time, the NFR sensor name, the attack source IP, the destination IP, and some other alert information.
In the actual use, one day produced hundreds of such alarm, it seems that this is a false report, we can be a good analysis of the.
3. Detection of NFR
We first open the NFR release of the signature library MSSQL.FP (or can also be viewed in the AI package) to see the NFR's attack signature for this vulnerability:
From the n-code above, we can see that the NFR is doing this test when the steps are as follows:
1, defines an attack signature code:
Hello_sig = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
And attack the length of the 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 detection;
3, otherwise, this data and signature string matching, if consistent is considered an attack, and then to block or alarm.
Next, we analyze the data of NFR IDS record, select Package->query->mssql->mssql Server 200 in AI, set the conditions, check the data by table, select one randomly, Copy came out to get the following content:
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 to the attack signature library. But NFR has a few minor problems here:
1. Converts a 16-digit number in the payload to an ASCII character into an ASCII code;
2. Unicode characters cannot be processed, as will be seen in future analysis.
In this example, for the sake of analysis, we convert the character signature portion of the payload above into a 16-digit 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, the discovery is the SQL Server package, and then the contents of the SQL Server and the attack library to compare, it is obvious that the data listed above and the attack library is consistent, so an alarm is generated, but this is really an attack? Let's continue to look at the analysis below.
4. Protocol Analysis
Based on the Xfocus Protocol Analysis Project (which will be published in the near future), MS SQL 2000 is TDS8.0, which is formatted as follows:
-------------------------------------------------
| TDs Header (8 bytes) | TDS Load Data |
-------------------------------------------------
The header structure of MS SQL SERVER TDS is as follows:
-------------------------------------------------------------------
| TOKEN | STATUS | LENGTH | Signed NUM | PACKET NUM | WINDOW SIZE |
-------------------------------------------------------------------
Where the token field domain is 1 bytes, used to represent the type of TDS operation request. In this vulnerability is 0x12, which is the first byte of the payload in the NFR record 0x12, 0x12 is the pre-logon authentication command request. The goal is to obtain some of the settings for the current MS SQL SERVER2000, such as SQL Server version, or whether to support information such as encryption, as a basis for the client to construct the TDS packet. When SQL Server accepts a package of that type, it will be handled by the corresponding function in SSlibnet.dll, and in the case of my system SQL Server 2000 (no SP), the corresponding function is as follows:
The Status field 1 bytes when it is 0x01 indicates that the package is the last TDS packet in the current TDS session.
The Length field field is 2 bytes, representing the total length of the TDS package, including the length of the TDS header.
The Signed num field field is 2 bytes and is currently reserved.
PACKET num Field field 1 bytes representing the serial number of this TDS package in the current TDS operation request
The WINDOW size field field is 1 bytes and is currently reserved.
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 indicator header is a variable-length table, each item in the table represents the offset address and length information in a field in the information, the main 4 fields in the SQL2000, and the corresponding field indicator header is structured 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 used by the client for the Network Connection library (netlib).
Description
Note: This value is fixed to 0
Cnetlibveroffset Field Fields
Offset: 1
Length: 2
Meaning: The field offset of the version number information used by the client for 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 used by the client 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 field number used by the client to force the tag field.
Description
Note: This value is fixed to 1
Cenyflagoffset Field Fields
Offset: 6
Length: 2
Meaning: The client uses an offset that forces the tag field to be encrypted.
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 a field number that uses 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 offset of the instance name segment of the server to be used.
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 segment 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 for 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 marks the field indicating 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) that is used by the client.
Description: The version number takes the version of DBNETLIB.DLL
Note: The format is network byte format, such as version number 80.528.00;
08 00 02 10 00 00
Cenyflag Field Fields
Offset: 0x1b
Length: 1
Meaning: The client enforces the encryption flag.
Note: 0 does not force encryption on behalf of the client, and 1 uses force encryption on behalf of the client
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 you can see from the above format, a SQL TDS package format with the default instance name MSSQLSERVER connection will be the following:
\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";
is obviously a normal TDs 0x12 a part of the pre-landing package, it is no wonder there are so many alarms, that NFR the attack signature is how to get it?
Let's start by explaining its flaws.
5. Description of the vulnerability
The following is a description of this vulnerability in NFR n-code:
FALSE Positives
False positives are unlikely due to the 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 the http://www.immunitysec.com/Dave Aitel, and from http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/ The key to seeing this vulnerability in the MS SQL Server Hello Overflow NASL script listed in msg00125.html is the following statements:
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);
}
}
The PKT_HDR is a packet constructed according to the TDS protocol, with 560 characters in the middle, and the X,pkt_tail is the constructed TDS packet tail.
From here we can see that poor NFR incredibly irresponsible to take the pkt_hdr of MS SQL Server Hello Overflow NASL script out of 11 characters and resolutely take them as their signature. It's even more ridiculous to say "False positives are unlikely due to the" attack ".
Is this the NFR in many reviews? Later and Stardust talk about this matter, think this phenomenon and a lot of evaluation agencies in the evaluation of IDs products, pay attention to the detection of product omission and ignore the evaluation of false positives. Because in the evaluation of products, basically are mostly black box evaluation, to detect missing as long as the collection of a few exploits can be carried out, but to detect false omission but to produce a normal package, some systems such as the SQL Server here, if not understand its protocol package format, it is difficult to produce. As a result, some IDs generate the loophole, as long as the collection of some exploits, the attack code as a direct release of the attack signature, not to analyze the real cause of the vulnerability.
Let's analyze the cause of the vulnerability, and then we can write a better attack signature based on this analysis.
6. Vulnerability Analysis
Using IDA to disassemble the SSlibnet.dll, we can see:
The reason for this vulnerability is that when a program uses a strcpy copy, if the source string exceeds 0x214 (that is, 532), the environment variable after the target address is overwritten, causing the overflow. Since this vulnerability is very early, after the "Slammer" worm, basically all of the systems have made up the vulnerability, so the attack code is not available here, interested friends can analyze and write their own.
It is also necessary to explain here that if the TDS protocol and the cause of this vulnerability are analyzed, the length of the TDS packets in the perfect attack program is generated based on calculations and clearly not "\x00\x34" to circumvent the checksum for TDS packet lengths in SQL Server (of course, in this version of SQL Server does not contain this checksum, or the attack program to the attack code into multiple packets, so the status in TDS format will not be 0x01, so NFR is not detect a perfect attack program, that is, in response to this vulnerability, NFR at the same time the case of false positives and vulnerabilities.
After analyzing the cause of this vulnerability, we can write our own NFR detection code for this problem:
if (prefix ($Blob, Hello_sig) && strlen ($Blob) > 295) {
#考虑到实例名不可能超过255, so here the length was selected 40 (Baotou) +255=295
#也可以增加一个Value so that users can adjust themselves according to the event situation
#报警
....
}
7. Summary
By analyzing the signature of NFR, we can see that it is not a simple thing to publish a perfect IDs attack signature, it needs to understand the format of the Protocol and the causes of the vulnerabilities. Instead of simply collecting the exploits on the network, then intercepting the signatures.
At present, many people, including IDs developers, are discussing whether IDs has a future and need not. I think it's better to settle down and analyze the vulnerabilities and improve the signature of the attack to make IDs more accurate.
Instead of sitting on the line, it's better to go!! (Source: www.xfocus.net)
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
