Eight Methods for hackers to bypass IDS for HTTP requests

 

During attacks, hackers can disguise themselves and bypass IDS detection. This is mainly used for IDS pattern matching to avoid IDS monitoring. This article describes how to bypass IDS detection for HTTP requests.

 

IDS is used by many enterprises as an enterprise security protection system. However, enterprises that install IDS cannot be completely at ease. With the development of hacking technology, many hackers can bypass IDS detection in various ways to launch attacks on enterprises. This article mainly introduces how hackers bypass IDS for HTTP requests during attacks.

 

HTTP requests to bypass IDS monitoring

 

(I) For URL encoding, you can avoid some NIDS that adopt rule matching.

 

In binary encoding, the HTTP protocol allows any ASCII characters to be used in the URL. The binary characters are represented in hexadecimal codes such as "% xx", and some IDS are not decoded. For example, "cgi-bin" can be expressed as "% 63% 67% 69% 2d % 62% 69% 6e". Some IDS rules cannot be matched, but the web server can correctly handle them. However, most IDS are decoded before matching rules. Currently, this method is not applicable. Generally, IDS can be detected! # % U Encoding is used to represent Unicode/wide feature characters. However, Microsoft IIS web server supports this non-standard web Request Encoding Method because % u Encoding is not a standard encoding, the IDS system cannot decode % u, so it can bypass IDS detection. For example:

 

We can bypass some NIDS to detect ". ida" attacks using the following encoding methods.

 

GET/abc. id % u0061 HTTP/1.0

 

However, snort1.8 can detect this encoding attack, but some companies do not notice this problem. The solution is to decode and match the % u Encoding of the URL content before matching the rule. # Unicode encoding, mainly for IIS, uses unicode encoding to represent some specific characters or strings in the URL (mainly for some IDS matching rules). For example:

 

We can bypass some NIDS to detect ". ida" attacks using the following encoding methods.

 

GET/abc. id % c1 % 01 HTTP/1.0

 

Snort1.8 currently does not seem to be able to detect this encoding attack. Many IDS that use wildcards such as "* string *" must have such problems. The solution is to decode and match the unicode encoding of the URL content before matching the rule.

 

(Ii) the diagonal lines in the network are "/" and "\". # "/" Question:

 

If '/' is converted to '/' in the HTTP request, for example, "/cgi-bin/test. cgi "to" // cgi-bin // test. cgi ", although the two strings do not match, the explanation for many web servers is the same. The same is true if you change the double slash to a three-slash or more. Currently, some IDS cannot detect such requests. # "\" Problem: Microsoft uses '\' to separate directories, Unix uses '/' to separate directories, and http rfc uses '/' to separate directories '/', microsoft web servers, such as IIS, convert '/' '\'.

 

For example, send "/cgi-bin \ test. IIS can correctly identify cgi and other commands, but IDS won't match "/cgi-bin/test. cgi ", this method can escape some IDS.

 

(Iii) added directory issues:

 

Insert unnecessary special characters so that they do not match the IDS detection content. For example '.. 'indicates the parent directory ,'. 'indicates the subdirectory, "c: \ tmp \. \. \. \. \ "means" c: \ tmp \ "; corresponding unix"/tmp /. /. /. /. /"is equivalent to"/tmp. The format of "/cgi-bin/phf" can be changed to "/./cgi-bin/././phf and so on.

 

For example:

 

GET/cgi-bin/blahblah/../test. cgi HTTP/1.0 is actually the same as "/cgi-bin/test. cgi"

 

Currently, IDS can be recognized. Many smart IDS restore requests to a normal form.

 

(Iv) irregular methods:

 

# Use a tab to replace spaces (not applicable to IIS): smart IDS generally extracts URL requests from client data and intercepts them.

 

Check the request according to the HTTP syntax format. In the http rfc, the request format of http v1.0 is as follows: Method uri http/Version crlf crlfhttp divides the request into three parts according to spaces. However, Apache 1.3.6 and later versions (earlier versions may also be) allow the use of tab requests: method uri http/Version CRLF this will cause programs that process this request in RFC format to fail. However, some IDS use spaces for matching to reduce false positives. For example, "/phf" can easily match strings, but "/phf (Space)" can reduce many false positives, and thus the request using tab cannot match.

 

# NULL method: Construct the following request: GET % 00/cgi-bin/test. cgi HTTP/1.0. In c, many string processing functions use NULL as the end of a string. If IDS uses c functions to process strings, IDS cannot match strings after NULL. This method is suitable for IIS, and Apache cannot process % 00.

 

(V) command problems:

 

Many IDS systems use GET to submit requests, such as GET/cgi-bin/test. cgi, by default. However, the same request can also be implemented using the HEAD command, for example, the HEAD/cgi-bin/test. cgi, then some IDS systems that match the get method will not detect this scan.

 

(Vi) Session composition:

 

Separate requests in Different Packet texts and Issue D. Note that IDS may not match the attack if it is not a part. For example, the request "GET/HTTP/1.0" can be placed in different packet texts ("GE", "T", "/", "H", "T ", "TP", "/1 ",". 0 "), but cannot escape some IDS using protocol analysis and session restructuring technology.

 

(Vii) Long URL (Long URLs) Problem:

 

To improve efficiency, some original IDS only check the first xx bytes. Normally, this is correct because the request is at the beginning of the data, but if you construct a long request:

 

GET/rfprfprfprfp/../cgi-bin/test. cgi HTTP/1.0,

 

The length of IDS detection is exceeded, so that IDS cannot detect the subsequent CGI. Generally, 1-2 k random characters can be included in the request. However, some IDS determine whether the request is a buffer overflow based on the length of some protocol requests. In this case, IDS will report a buffer overflow as a false positive for this type of scan!

 

The following is a false request termination problem:

 

For some smart IDS, in order to improve efficiency and reduce the occupation of system resources, the data sent to the client is generally only processed in the request part.

 

For example, send the following request:

 

GET/% 20 HTTP/1.0% 0d % 0 aHeader: % 20/..././cgi-bin/test. cgi HTTP/1.0 \ r \ n

 

The decoded result is as follows:

 

GET/HTTP/1.0 \ r \ nHeader:/.../cgi-bin/test. cgi HTTP/1.0 \ r \ n

 

This is a correct request, but for some smart IDS, only GET command lines will be intercepted. It will end after "HTTP/1.0 \ r \ n" is found, then perform operations on the captured part. Therefore, intelligent IDS cannot correctly report the cgi-based attacks.

 

Case sensitivity:

 

Different from unix, DOS/Windows are not case sensitive. For example, for IIS, the case is the same, and for some older IDS, it may cause non-matching.

 

Whisker is the main tool for spoofing HTTP requests. It uses some of the above technologies for WWW scanning. Currently, IDS can detect most of the spoofing methods, however, for scanning using URL encoding (especially unicode encoding) and irregular methods (such as replacing spaces with tabs), a considerable number of IDS may not be detected!