Optimizing NFR One--MSSQL Hello Buffer Overflow_PHP Tutorial-PHP Tutorial-php.cn

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. Introduction
NFR (Network Flight Recorder) is an old commercial network IDS product. It was originally created by Marcus J. Ranum, the master of Firewall, as a general network traffic Analysis and recording software is implemented. In order to maximize the flexibility of analysis tools, NFR provides a complete and powerful N-Code scripting language, which has performed well in many evaluations. Although L0pht has provided hundreds of signature libraries for NFR, the lack of a reliable signature set has always been his weakness.

After using NFR for a while, I found that NFR has many problems. Not to mention that AI often exits due to its poor compatibility with Chinese, nor does the NFR version upgrade but the attack event description always uses the old version description. The most critical attack signature library in IDS alone surprised me. In addition to the slow upgrade, there are even many wrong signatures. This series of articles analyzes and elaborates on some of the problems I discovered so that you can better utilize NFR products. I also want to discuss the preparation of attack signature libraries in IDS with my colleagues. Due to limitations of knowledge and time, mistakes are inevitable. I also hope to get your advice. Please send any comments or suggestions to: benjurry@xfocus.org

SQL Server is a database launched by Microsoft to compete with Oracle. , the market share it occupies is second only to Oracle, ranking second in the world, but its security has always been questioned by users. From the SQL Server 6.5 version launched by Microsoft in 1996 to the SQL Server 7.0 launched in 1998, and to the launch of SQL Server 2000 in August 2000, while the versions and functions have been continuously upgraded, security issues have not been well addressed. to continuously improve and continuously release security bulletins and patches for SQL Server. On January 24, 2003, the "Slammer" worm targeting SQL Server raged on the Internet, causing a surge in network traffic and seriously affecting computers and network systems around the world. The vulnerabilities of SQL Server have attracted the attention of major security companies and manufacturers, so NFR immediately released multiple attack signatures targeting SQL Server, including the Hello Buffer Overflow vulnerability discovered by Dave Aitel of Immunity Company on August 7, 2002. However, during the use, I found that NFR had a lot of alarms for this vulnerability, so I analyzed it and wrote this article for record keeping.

2. Alarm information
The following is the alarm information of NFR for MS SQL Hello Buffer Overflow:

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 900 seconds
: 3
Source IP: 192.168.0.110
Destination IP: --

This includes the event severity, time, NFR Sensor name, attack source IP, destination IP and some other alarm information.
In actual use, hundreds of such alarms are generated a day. It seems that this is a false alarm. We can analyze it carefully.

3. Detection of NFR
We first open the signature library MSSQL.fp released by NFR (or you can also view it in the AI package) and take a look at NFR’s attack signature for this vulnerability:

…..

Variable definitions etc…

…

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

HELLO_SIG = "x12x01x00x34x00x00x00x00x00x00x15";
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, tc p.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, t cp.conndst, tcp.conndport, tcp.connsrc,
tcp.connsport, $Blob to sqlserv_rec;
misc_attacks:rec(packet.sec, scope(),
"Mssql HELLO overflow!", tcp.connsrc, tc p .conndst);
}
}

From the N-CODE above, we can see that the steps for NFR to do this detection are as follows:

1. Define An attack signature:
HELLO_SIG = "x12x01x00x34x00x00x00x00x00x00x15";
And the length of the attack signature:
MIN_LEN = strlen(HELLO_SIG);

2. Get the data from the TCP payload data , compare the length of this data with the length of the signature. If the length of this data is smaller than the length of the attack signature, then the next step of detection will not be performed;

3. Otherwise, compare this data with the signature String matching, if consistent, it is considered an attack, and then blocked or alerted.
Next, let’s analyze the data of NFR IDS Record, select package->Query->MSSQL->MSSQL Server 200 in AI, set the conditions, press Table to find the data, select any one, and 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: x01x02x00x1cx00x0cx03x00(x00x04xffx08x00x00xc2x00
NIDS sessor name, destination IP, destination port, source IP and source port, and what we care about is the payload, because it is the data used by NIDS to compare with the attack signature library. But NFR has several small problems here:

1. Will convert the hexadecimal numbers in the payload that can be converted into ASCII characters into ASCII codes;

2. Cannot handle Unicode characters, this will be seen in future analysis arrive.

In this example, for the convenience of analysis, we convert the character signature part in the payload above into a hexadecimal number:
x12x01x00x34x00x00x00x00x00x00x15x00x06x01x00x1b
x00x01x02x00x1cx00x0cx0 3x00x28x00x04xffx08x00x00
xc2x00x00x00MSSQLServerx00xx03x00x00

After NFR captured the data group package, it found that it was a SQL Server package, and compared the contents inside with the SQL Server attack library. Obviously, the data listed above is consistent with the attack library, so an alarm was issued It happens, but is this really an attack? Let’s continue with the analysis below.

4. Protocol Analysis

According to Xfocus’s protocol analysis project (project results will be announced in the near future), MS SQL 2000 uses TDS8.0, and its format is as follows:
-------------------------------------------------- --
| TDS header (8 bytes) | TDS payload data |
----------------------------- --------------------
The header structure of MS SQL SERVER 2000 TDS is as follows:
------------- -------------------------------------------------- ----
| TOKEN | STATUS | LENGTH | SIGNED NUM | PACKET NUM | WINDOW SIZE |
------------------------ ---------------------------------------------
Among them, the TOKEN field 1 byte, used to indicate the TDS operation request type. In this vulnerability it is 0x12, which is the first byte in the payload in the NFR record. 0x12 is the pre-login verification command request. Its purpose is to obtain some setting values of the current MS SQL SERVER2000, such as SQL SERVER version, whether it supports encryption and other information, as a basis for the client to construct a TDS package. When SQL Server receives this type of package, it will be processed 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
......

STATUS field is 1 byte. When it is 0x01, it means that this packet is the current TDS The last TDS packet in the session.
The LENGTH field is 2 bytes, indicating the total length of the TDS packet, including the length of the TDS packet header.
SIGNED NUM field is 2 bytes, currently reserved and unused.
PACKET NUM field is 1 byte, indicating the sequence number of this TDS packet in the current TDS operation request.
WINDOW SIZE field is 1 byte, currently reserved and unused.
The main package format of MS SQL SERVER 0X12 TDS is as follows:
-------------------------------- -----------------------
| TDS header (8 bytes) | Field indication header | Information |
------- -----------------------------------------------
The field indication header is a variable-length table. Each item in the table represents the offset address and length information of a field in the information. In SQL2000, there are mainly 4 fields, and the corresponding field indication header structure 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 CNETLIBVER[CNETLIBVERLEN]
BYTE CENYFLAG[CENYFLAGLEN];
BYTE SINSTNAME[SINSTNAMELEN]
DWORD CTHREADID[CTHREADIDLEN];
}
where:
CNETLIBVERNO field domain
Offset: 0
Length: 1
Meaning: The field number of the version number information of the network connection library (NETLIB) used by the client.
Description:
Remarks: This value is fixed at 0

CNETLIBVEROFFSET field
Offset: 1
Length: 2
Meaning: The network connection library used by the client ( NETLIB) version number information field offset.
Description: The field format is network byte order
Remarks:

CNETLIBVERLEN field
Offset: 3
Length: 2
Meaning: The network connection used by the client The field length of the version number information of the library (NETLIB).
Description: The field format is network byte order
Remarks: The value is fixed at 6

CENYFLAGNO field
Offset: 5
Length: 1
Meaning: Customer The field number of the marked field that the end uses to force encryption.
Description:
Remarks: This value is fixed at 1

CENYFLAGOFFSET field
Offset: 6
Length: 2
Meaning: The client uses forced encryption to mark the field offset.
Description: The field format is network byte order
Remarks:

CENYFLAGLEN field
Offset: 8
Length: 2
Meaning: The client uses the mandatory encryption flag The length of the field.
Description: The field format is network byte order
Remarks: The value is fixed at 1

SINSTNAMENO field
Offset: 0XA
Length: 1
Meaning: Customer The client requires the field number of the server's instance name field.
Description:
Remarks: This value is fixed at 2

SINSTNAMEOFFSET field
Offset: 0XB
Length: 2
Meaning: The client requires the instance name of the server segment offset.
Description: The field format is network byte order
Remarks:

SINSTNAMELEN field
Offset: 0XD
Length: 2
Meaning: The client requires the use of the server's The length of the instance name field.
Description: The field format is network byte order
Remarks:

CTHREADIDNO field
Offset: 0XF
Length: 1
Meaning: Thread ID of the client process The field number of the field.
Description:
Remarks: This value is fixed at 3

CTHREADIDOFFSET field field
Offset: 0X10
Length: 2
Meaning: The thread ID field of the client process offset.
Description: The field format is network byte order
Remarks:

CTHREADIDLEN field
Offset: 0X12
Length: 2
Meaning: Thread ID of the client process The length of the field.
Description: The field format is network byte order
Remarks: The value is fixed at 4

FILEDEND field
Offset: 0X14
Length: 1
Meaning: This The field mark field indicates that the header has been consolidated, and the following is the field information.
Description: The end tag is 0XFF
Remarks:

CNETLIBVER field
Offset: 0X15
Length: 6
Meaning: The network connection library used by the client (NETLIB ) version number.
Note: The version number is the version of DBNETLIB.DLL
Note: The format is network byte format, if the version number is 80.528.00, it is
08 00 02 10 00 00

CENYFLAG field
Offset: 0X1B
Length: 1
Meaning: Client forced encryption flag.
Explanation: 0 means the client does not force encryption, 1 means the client uses forced encryption
Remarks:

SINSTNAME field
Offset: 0X1C
Length: SINSTNAMELEN
Meaning: The instance name required by the client.
Description: Single-byte format
Remarks: The default instance uses the name MSSQLserver

CTHREADID field field
Offset: 0X1C+SINSTNAMELEN
Length: 4
Meaning: Client The thread ID of the end process.
Note: The field format is host byte order
Remarks:

As can be seen from the above format, a SQL TDS package format connected with the default instance name MSSQLserver will be in the following format:
x12x01x00x34x00x00x00x00
x00x00x15x00x06x01x00x1b
x00x01x02x00x1cx00x0cx03
x00x28x00x04xffx08x00x00
xc2x00x00x00MSSQ
LServerx00
x78x03x00x00

But NFR’s attack signature library is
HELLO_SIG = "x12x01x00x34x00x00x00x00x00x00x15";
Obviously it is part of the normal TDS 0x12 pre-login package. No wonder there are so many alarms. So how did you get this NFR attack signature?
Let’s start with its vulnerability description!

5. Vulnerability Description
The following is the description of this vulnerability in NFR N-CODE:
FALSE POSITIVES

False positives are 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 vulnerability comes from Dave Aitel at http://www.immunitysec.com/, and from http://cert.uni-stuttgart. In the MS SQL Server Hello Overflow NASL script listed in de/archive/bugtraq/2002/08/msg00125.html, we can see that the key to this vulnerability lies in 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 MSSQLn");
security_hole(port:port, data:report);
}
}

Among them, pkt_hdr is a packet constructed according to the TDS protocol, with a 560-character X added in the middle, and pkt_tail is the constructed TDS packet tail.

From here we can see that poor NFR irresponsibly took out 11 characters from pkt_hdr in the MS SQL Server Hello Overflow NASL script and resolutely used them as its signature. What’s even more ridiculous is that it actually says “False positives are unlikely due to the nature of the attack.”
Is this the NFR that is far ahead in many reviews? Later, when I talked about this matter with Stardust, I thought this phenomenon was related to the fact that when many evaluation agencies evaluate IDS products, they focus on the detection of false positives but ignore the evaluation of false positives. Because when evaluating products, most of them are black box evaluations. To detect false negatives, you only need to collect a few Exploits. However, to detect false negatives, you need to generate normal packages. Some systems, such as the Sql Server here, If you don't understand its protocol packet format, it is difficult to generate it. Therefore, some IDSs take advantage of this loophole. They just collect some Exploits and directly publish the attack code as an attack signature without analyzing the real cause of the vulnerability.

Let’s analyze the reasons for this vulnerability, and then we can write a more complete attack signature based on this analysis.

6. Vulnerability Analysis
Use IDA to disassemble 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: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

this The reason for the vulnerability is here. When the program is copied using strcpy, if the source string exceeds 0x214 (that is, 532), the environment variable after the target address will be overwritten and cause an overflow. Since this vulnerability is very early, after experiencing the "Slammer" worm, basically all systems have patched this vulnerability, so the attack code is no longer provided here. Interested friends can analyze and write it by themselves.

Another thing to note here is that if the TDS protocol and the cause of this vulnerability are analyzed, the length of the TDS packet in the complete attack program is generated based on calculation, and it will obviously not be "x00x34" ", in order to avoid the TDS packet length check in SQL Server (of course, this check is not included in this version of SQL Server), or the attack program divides the attack code into multiple packages, so the status in the TDS format It will not be 0x01, so NFR cannot detect a complete attack program. In other words, for this vulnerability, NFR has both false positives and vulnerabilities.

After analyzing the cause of this vulnerability, we can write our own NFR detection code for this problem:

sqlserv_schema = library_schema:new(1, ["time" ,"ip","int","ip","int", "str"],
scope());
sqlserv_rec = recorder("bin/list %c", "sqlserv_schema"); " The field indicates the total length of the header

…….

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) {
#Consider the example The name cannot exceed 255, so the length here is 40 (Baotou) + 255 = 295
# You can also add a Value so that the user can adjust it according to the event
#Alarm
….

}

7. Summary
Through the analysis of the NFR attack signature, it can be seen that publishing a complete IDS attack signature is not a simple matter. It requires understanding the application protocol format. and causes of vulnerabilities. Instead of simply collecting exploits that exist on the network and then intercepting the signatures.
Currently, many people, including IDS developers, are discussing whether IDS has a future and whether it is necessary. Instead of discussing it there, I think it would be better to sit down and analyze the vulnerability, improve the attack signature, and make the IDS more accurate.
Rather than sit back and talk, let’s get up and take action! ! (Source: www.xfocus.net)