From vulnerability and attack analysis to NIDs Rule Design

From vulnerability and attack analysis to NIDs Rule Design

Created:
Article attributes: original
Article submitted: stardust (stardust_at_xfocus.org)

When talking about NIDs, this product is often criticized for a large number of false positives and false negatives. False positives with full screen scrolling make administrators feel numb and bored and lose interest in using it, if an error is reported, the Administrator may doubt the NIDs detection capability. It is clear that the host has been intruded into the NIDs log but no useful clues can be found. For NIDs, there are many causes of false positives and false positives, but the biggest reason is that the detection rules are not strictly defined.

For known network attacks, the current mainstream network intrusion detection and protection systems are mainly rule-based, because of specific attacks, in particular, packets based on specific attack codes can easily extract their packet features for matching. rules can be used to quickly and conveniently expand the detection capability.

The essence of network attacks is to use the design or implementation of the target system. From the perspective of the attacked process, the attack packets are either in the content structure or in the sequence of occurrence, or the attack packets must be malformed and cannot be correctly handled by the service program. Due to the limited length, this article does not discuss more complex attacks related to time series and statistics, but only considers relatively simple single request attacks. In order to successfully complete the attacks, the content and structure of packets under Network Attacks must meet certain necessary conditions. These packet characteristics are used to drive the Attack Process to trigger the vulnerability, we use feature set a to represent the set of necessary packet features.

Attackers can exploit security vulnerabilities by writing attack code, in addition to the features in feature set a, the packets sent by Specific Attack codes generally contain some special features of the attack code, for example, for specific shellcode and specific padding data, we use feature set B to indicate the packet Characteristics of Specific Attack codes.

The rule-based NIDS engine implements a basic detection framework. It provides various matching options and operators as application interfaces. You can combine options and operators to describe the network packet characteristics of interest, generates alarms for packets that meet the matching conditions. The rule Support Department of the NIDs vendor generally traces and analyzes new security vulnerabilities and attack code, extracts features, and compiles the NIDs rules used to detect the attacks, we use feature set C to indicate attack packet characteristics described by rules.

Obviously, the relationship between feature set a and feature set B is as follows:

+ ---------------- +
|
| + ------- + |
| <---- Feature set a: content or structure features required for packets to implement attacks
| |============> The matching feature is increased to reduce the number of packets meeting the condition
|
| + ------- + |
| <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

The feature set C described in the ideal attack detection rule should completely overlap with a. Because the features in feature set a describe the features of all attack code attack packets, therefore, it has nothing to do with the specific attack code, thus avoiding false positives. If we make a correct assumption about the protocol type of the detection object, because each feature in feature set a is necessary to cause an attack, it is indispensable, none of these features can trigger a vulnerability to complete the attack, so there is no possibility of a false positive. The figure is as follows:

+ ---------------- +
|
| + = + |
| "" <---- Feature set a: content required for packets to implement attacks
| "" | Or structural features
| "" <---- Feature set C: the characteristics of the packet content or structure described by the rule
| + = + |
| <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

In fact, due to the limitation of the Rule Description capability, in most cases, the rule cannot completely describe the features necessary for the attack packet content and structure to complete the attack. That is to say, feature set a does not completely overlap feature set C, but has various possible relationships:

If feature set C is a subset of A as shown in the following figure, the rule may cause false positives, but will not generate false negatives:

+ ---------------- +
|
| + ------- + |
| + --- + | <---- Feature set a: content or structure features required for packets to attack
| <------ Feature set C: the characteristics of the packet content or structure described by the rule
| + --- + |
| + ------- + |
| <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

If feature set C contains feature set A as shown in the following figure, the rule may cause false positives, but will not generate false positives:

+ ---------------- +
|
| + ------- + |
| + --- + | <---- Feature set C: the characteristics of the packet content or structure described by the rule
| <------ Feature set a: content or structure features required for packets to implement attacks
| + --- + |
| + ------- + |
| <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

If feature set C does not include a, but there is an intersection, the rule may both generate false positives and possibly cause false negatives:

+ ---------------- +
|
| + ------- + |
| <---- Feature set C: the characteristics of the packet content or structure described by the rule
| + --- + -- + |
| <------ Feature set a: content or structure features required for packets to implement attacks
| + --- + |
|
| + ------ + | <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

If feature set C and A do not mutually exclusive and do not overlap, then the rule itself is only detecting packets sent by specific attack code, but has nothing to do with the attack itself, by simply modifying the attack code, attackers can easily bypass the detection of such rules. If NIDs miss or report a false positive, the attack should be handled by the attacker:

+ ---------------- +
| + ------- + |
|
| <------- Feature set C: Characteristics of the packet content or structure described by the rule
| + ------- + |
| + ------ + |
| <------ Feature set a: content or structure features required for packets to implement attacks
|
| + ------ + | <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

So how can we make the feature set C and A overlap as much as possible? This mainly depends on two aspects: 1. Thoroughly analyzing the causes and utilization conditions of vulnerabilities, aiming to generate an accurate feature set a; 2. Improving the NIDs rule description capability, the feature set C described by this method can be as close as possible to feature set. The strength of NIDs vendors is often reflected in these two aspects. If the vendors do not have the ability to continuously and professionally analyze vulnerabilities and attacks, without analyzing the details of vulnerabilities, designing NIDs rules randomly will inevitably lead to a large number of false negatives and false positives. The use of NIDs can be imagined. The following describes the NIDs Rule Design of an actual vulnerability attack to make some abstract descriptions specific, highlighting the extreme importance of vulnerability analysis in the design of NIDs rules.

Serv-U is a Windows FTP server software. Last year, researchers found that the Serv-U server process had a stack overflow vulnerability when processing parameters of the MDTM command, remote attackers can initiate an overflow attack as long as they can log on to the FTP server without the write permission of the directory, and execute arbitrary commands on the FTP server to control the server. Because Serv-U is widely used, it is almost the preferred FTP service program on windows. In addition, FTP servers generally store a large amount of valuable information, therefore, the exploitation of this vulnerability is very popular.

The open-source NIDs tool snort provides the following detection rules for how to detect attacks against this vulnerability:

Alert TCP $ external_net any-> $ home_net 21 (MSG: "FTP invalid MDTM command attempt"; flow: to_server, established; content: "MDTM"; nocase; PCRE: "/^ MDTM/d + [-+]/D/SMI"; reference: Bugtraq, 9751; reference: CVE, 2001-1021; reference: CVE, 2004-0330; classtype: attempted-admin; Sid: 2416; Rev: 5 ;)

Packet characteristics described by this rule:
1. TCP packet whose destination port is 21
2. Include the MDTM command
3. The parameter starts with one or more numbers.
4. the digit string follows the character "+" or "-".
5. "+" or "-" followed by at least one non-Numeric Character

These features form feature set C.

Is this feature set C sufficiently compatible with the real attack features? Through vulnerability analysis, we will naturally draw a conclusion. Czy82 on the nsfocus Technology Forum published a detailed analysis of this vulnerability, see the original article: http://bbs.nsfocus.net/index.php? Act = se & F = 3 & t = 159298 & P = 299648

The code analysis snippets of server processing commands and parameters in the analysis document are as follows:

========================================================== ======================================
[0] determining whether it is an "MDTM" command

Loc_434748:; Code xref:. Text: 0043473a
. Text: 00434748 Push 4 // compare four bytes
. Text: 0043474a push EDI // The first address of the EDI command string
. Text: 0043474b Lea eax, [ESI + 354 H]
. Text: 00434751 push eax // get the command list
. Text: 00434752 call near PTR unk_59c008 // equivalent to strncmp
. Text: 00434757 add ESP, 0ch
. Text: 0043475a test eax, eax
. Text: 0043475c jnz short loc_43666d // compare the next command site if it is not MDTM
. Text: 0043475e push EDI // The second parameter is the first address of the command string
. Text: 0043475f push EBX
. Text: 00434760 call loc_41fae8 // if the same, jump to the MDTM command to process the Function
. Text: 00434765 add ESP, 8
. Text: 00434768 JMP loc_434ac7

[2] process and check the time zone

. Text: 0041fbb6 loc_41fbb6:; Code xref: sub_41fae8 + 9bj
. Text: 0041fbb6 push 20 h
. Text: 0041fbb8 Lea edX, [EBP + var_9fc] // store all commands in the ebp-9fc
. Text: 0041 fbbe push edX
. Text: 0041 fbbf call sub_59beb1 // find the space in the command and locate the space.
// Address in the ebp-78, that is, find the file name
. Text: 0041fbc4 add ESP, 8
. Text: 0041fbc7 mov [EBP + var_78], eax
. Text: 0041 fbca test eax, eax
. Text: 0041 fbcc JZ loc_41fe6d // The object name cannot be found. The Skip will be processed.
// MDTM autoexec. Bat command for viewing file time
. Text: 0041fbd2 Lea edX, [EBP + var_9fc]
. Text: 0041fbd8 push edX
. Text: 0041fbd9 call sub_59bda4 // obtain the command length.
. Text: 0041 fbde pop ECx
. Text: 0041 fbdf CMP eax, 10 h // command length less than 16 hops
. Text: 0041fbe2 JB loc_41fe6d
. Text: 0041fbe8 Lea ECx, [EBP + var_9fc]
. Text: 0041 fbee mov eax, [EBP + var_78]
. Text: 0041fbf1 sub eax, ECx // Do not be nervous about the length of the time zone.
. Text: 0041fbf3 CMP eax, 0eh
. Text: 0041fbf6 JL loc_41fe6d // The value must be greater than or equal to 14 bytes.
. Text: 0041 fbfc mov [EBP + var_88], 1
. Text: 0041fc06 xor edi, EDI
. Text: 0041fc08 Lea ESI, [EBP + var_9fc]
. Text: 0041fc0e
. Text: 0041fc0e loc_41fc0e:; Code xref: sub_41fae8 + 141j
. Text: 0041fc0e movsx eax, byte PTR [esi]
. Text: 0041fc11 push eax
. Text: 0041fc12 call sub_5a1304
. Text: 0041fc17 pop ECx
. Text: 0041fc6 test eax, eax
. Text: 0041fc1a jnz short loc_41fc24
. Text: 0041fc1c XOR edX, EDX
. Text: 0041fc1e mov [EBP + var_88], EDX
. Text: 0041fc24
. Text: 0041fc24 loc_41fc24:; Code xref: sub_41fae8 + 132j
. Text: 0041fc24 Inc EDI
. Text: 0041fc25 Inc ESI
. Text: 0041fc26 cmp edi, 0eh
. Text: 0041fc29 JL short loc_41fc0e
. Text: 0041fc2b CMP [EBP + var_88], 0
. Text: 0041fc32 JZ loc_41fd99 // determine the first 14 letters of the time zone
// If it is not a number, jump to 41fd99

// Verify the correctness of the time
. Text: 0041fd4f CMP [EBP + var_5c], 7bch
. Text: 0041fd56 JL short loc_41fd91 // 1980 hops per year
. Text: 0041fd58 cmp dword ptr [ebp-5Ch], 81bh
. Text: 0041fd5f JG short loc_41fd91 // year-over-2075 hops
. Text: 0041fd61 cmp dword ptr [ebp-60h], 1
. Text: 0041fd65 JL short loc_41fd91
. Text: 0041fd67 cmp dword ptr [ebp-60h], 0ch
. Text: 0041fd6b JG short loc_41fd91 // The monthly score can only be 1-12
. Text: 0041fd6d cmp dword ptr [ebp-64h], 1
. Text: 0041fd71 JL short loc_41fd91
. Text: 0041fd73 cmp dword ptr [ebp-64h], 1fh
. Text: 0041fd77 JG short loc_41fd91 // The number can only be 1-31
. Text: 0041fd79 cmp dword ptr [ebp-6Ch], 0
. Text: 0041fd7d JL short loc_41fd91
. Text: 0041fd7f cmp dword ptr [ebp-6Ch], 3bh
. Text: 0041fd83 JG short loc_41fd91
. Text: 0041fd85 cmp dword ptr [ebp-70h], 0
. Text: 0041fd89 JL short loc_41fd91
. Text: 0041fd8b cmp dword ptr [ebp-70h], 3bh // minutes only 0-59
. Text: 0041fd8f jle short loc_41fd99 // The time is valid until 41fd99.
[3] determine whether there is a +-number after the time zone

. Text: 0041fd99
. Text: 0041fd99 loc_41fd99:; Code xref: sub_41fae8 + 14aj
. Text: 0041fd99; sub_41fae8 + 2a7j
. Text: 0041fd99 CMP [EBP + var_88], 0
. Text: 0041fda0 JZ loc_41fe30 // do not skip commands such as MDTM 20020201112233 + 111 autexec. bat
. Text: 0041fda6 movsx eax, [EBP + var_9ee] // a string after processing the time zone
. Text: 0041 fdad CMP eax, 20 h
. Text: 0041fdb0 JZ short loc_41fe1c // skip with Space
. Text: 0041fdb2 movsx eax, [EBP + var_9ee]
. Text: 0041fdb9 CMP eax, 2dh
. Text: 0041 fdbc JZ short loc_41fdc3 // skip the minus sign!
. Text: 0041 fdbe CMP eax, 2bh
. Text: 0041fdc1 jnz short loc_41fe1c // skip to 41fe1c without the plus sign!

[4] handling the time zone with a +-Number

. Text: 0041fdc3 loc_41fdc3:
. Text: 0041fdc3 xor edi, EDI
. Text: 0041fdc5 Lea eax, [EBP + var_84] // get the last two digits of the time zone (ebp-84)
. Text: 0041 fdcb Lea ESI, [EBP + var_9ee] // address starting with "+"
. Text: 0041fdd1 JMP short loc_41fdda
. Text: 0041fdd3 loc_41fdd3:
. Text: 0041fdd3 mov DL, [esi]
. Text: 0041fdd5 Inc EDI // EDI is a counter
. Text: 0041fdd6 mov [eax], DL
. Text: 0041fdd8 Inc eax
. Text: 0041fdd9 Inc ESI
. Text: 0041 fdda
. Text: 0041 fdda loc_41fdda:
. Text: 0041 fdda movsx ECx, byte PTR [esi]
. Text: 0041 fddd CMP ECx, 20 h
. Text: 0041fde0 jnz short loc_41fdd3 // exit when a space is encountered

// ---------------------- The above is the vulnerability code program is intended to put the four bytes after the time zone plus sign in the ebp-84 variable
// But there is no check on the length, so not only will overwrite the ebp-84, if it is a super long string, it will also overwrite the ebp-54, ebp-78 and other reasons!

Q &:
[1] Why does a program exception occur when loc_41fe30 is executed?
Because the value of the ebp-78 variable was originally the address of the file name to change the file time
An operation on the variable ebp-84 overwrites its value if we enter the command
Quote mdtm 20020102112233 + aaaaaaaaaaaaaaaaaaaaaaaaaaaa/autoexec. bat
So then the value of the ebp-78 became 61616161, and this address can not be asked, of course, the exception is generated.

[2] How do we execute code after an exception occurs?
At the beginning of the analysis, we knew that the program's normal exception handler entry was in the ebp-50, so we could only
The address of the Code with jmp ebx in the system can be placed in the ebp-50. Then in the ebp-54 put nop jmp 6 (9090eb04)

[3] How many a to be sent to just overwrite ebp-50, ebp-54?
84 h-54 h = 30 h = 48D

========================================================== ======================================

From the above analysis, we can extract the necessary features of the FTP request packet to cause the attack:
1. The target port is the TCP packet of the FTP service control port (usually 21 ).
2. Include the MDTM command
3. The command parameters start with 14 numeric bytes.
4. The first 4 bytes of the number indicates that the number of the year is between 1980 and 2075.
5. The second byte after the year indicates that the number of the month is between 1 and 12.
6. The second byte after the month indicates that the number of the date is between 1 and 31.
7. 2 bytes after the date indicates that the number of minutes is between 0 and 59.
8. The two bytes after the minute indicate that the number of seconds is between 0 and 59.
9. The digit byte follows the character "+" or "-".
10. "+" or "-" followed by non-space data of more than 48 bytes
11. There must be one or more spaces after non-space data to separate the second parameter
12. The non-space byte containing at least one byte after the space is used as the second parameter.

These features form feature set.

Comparing with the feature set C described by the Snort rule, we can see that these two feature sets are far from overlapping, and there is only one small intersection, using this rule to detect false positives and false negatives is almost inevitable.

For example, messages with the following payload will cause false positives:
"MDTM 1 + ABC"

Effective attack packets with the following payload will cause omission:
"MDTM 20021122334455 + 1 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

Now that feature set a has been analyzed clearly, with the support of strong descriptive capabilities of regular expressions, we have improved the Snort rules so that they are as close as possible to feature set, you can modify the matching rule as follows:

Alert TCP $ external_net any-> $ home_net 21 (MSG: "ftp mdtm command Overflow Attempt"; flow: to_server, established; content: "MDTM"; nocase; PCRE: "/MDTM/S +/d {14} [+-] [^] {48,}/S +. +/SMI "; reference: Bugtraq, 9751; reference: CVE, 2004-0330; classtype: attempted-admin; Sid: 2416; Rev: 5 ;)

This rule matches the features numbered 1, 2, 3, 9, 10, 11, and 12 in feature set, the feature set C formed by this improved rule is a subset of feature set a. This rule may cause false positives and cannot cause false negatives.

It can be seen that the vulnerability and attack analysis are extremely important in the NIDs rule design process. It is the starting point and basis of the Rule Design. Only the attack feature set a is clearly defined, to design accurate and efficient NIDs detection rules.