Sd_red · 2014/11/09 men

0x00 Background

  1. When it comes to WAF, in our security workers, or as a common white hat, it is very headache, because a lot of times, we sent malicious traffic to the server are blocked, so there are all kinds of topics around “WAF”, around, but also no more than so many, and most are based on URLDecode way.

  2. Although I will cover circumvention in this article, I will show you how powerful WAF rules are from a defensive perspective.

  3. The author emphasizes again, if you just want to learn WAF bypass, I suggest or do not follow my post, my purpose is mainly to help many people to build the whole framework, so as to talk about bypass.

0x01 Start with the Modsecurity module

  1. Asked a lot of friends in the circle “know WAF?” “And they tell me explicitly,” Yes.” But when I told them about Modsecurity, the Apache module, they started shaking their heads. The de facto standard for WAF is the open source Modsecurity. Modsecurity has been developed as an Apache module, and this module can protect virtually any Web application in the state of the reverse proxy.

  2. The power of Modsecurity lies in its rules language, which is a combination of configuration instructions and a simple programming language that applies to HTTP requests and responses. It should be called Lua. Typically, the end result of Modsecurity is the execution of an action, such as allowing the request to pass, or logging to the modSecurity_audit. log or HTTPD log file.

  3. The following is my local Modsecurity module, as shown in the figure below

  4. As you can see from the above figure, these rule libraries (only a portion of which is captured) constitute almost all of Modsecurity. The direction of the red arrow is to prevent the injection of some rules into our SQL. There are more than 100 rules. Store the necessary knowledge for later SQL injection bypasses.

  1. You can also easily see the payload that we use for SQL injection attacks. Sorry, that’s all taken into account by the rule base. Let’s start with Modsecurity’s rule library.

0x02 Modsecurity handles 5 stages of events

  1. Request-headers Request header Phase, also known as Phase 1. Modsecurity rules in this phase are executed as soon as Apache completes the request header. At this point, the request body has not been read, meaning that not all of the request parameters can be used.

  2. Request-body Phase of the Request Body, also known as Phase 2. This phase is the input analysis phase, and most application rules are not deployed in this phase. This phase can receive some parameters from a normal request. In the request body stage, Modsecurity supports three encoding modes, the specific encoding modes are as follows:

(1)Application/x-www-form-urldecode

(2) Multipart/form-data

(3) Text/xml

  1. Response_Headers Phase, also known as the “Phases3” phase. This phase occurs before the response header is sent to the client. At this stage, some of the response status codes (such as 404) were managed by the Apache server early in the request and we were unable to trigger the expected results.

  2. Response body Phase (Request_Body) The response header phase, also known as Phase4. This phase can run rules to truncate the response body.

  3. The Logging phase, also known as the “Phase5” phase, in which rules are written can only affect how the logger executes. This phase can detect error messages logged by Apache. Connections cannot be rejected or blocked during this phase. It is too late to block the user’s request at this stage.

  4. In order to show more intuitively after Apache loaded Modsecurity module, I made a flow chart:

0x03 Modsecurity Rule Description

SecRule variable operator [Actions] 1 Variable variable: used to describe which variable should be checked. 2 Operator variable: describes how to check. Operators are actually regular expressions, but Modsecurity itself provides many operators, [email protected] 3 Actions: the third part is optional. Describes what happens next when an operation successfully matches a variable variable.

SecRule: modSecurity_crs_41_SQL_injection_attacks.conf: SecRule: modSecurity_crs_41_SQL_injection_attacks.conf

SecRule REQUEST_COOKIES|! REQUEST_COOKIES:/__utm/|! REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(? i:(? I: \ [\ "d '` ´' '] [\ \ s +" '` ´' '] \ s + \ d) | (? :^admin\s*? [\ "` ´ '|'] + [\" (\ \ *) '` ´' '] + \ s? (? # : - | | | \ / \ * {)? | (? : [\ "' ` ´ ' '] \ s *? \b(x? or|div|like|between|and)\b\s*? [+<>=(),-]\s*? [\ \ "d '` ´' ']) | (? : [\ "' ` ´ ' '] \ s *? [^\w\s]? =\s*? [\ "` ´ ' ']) | (? : [\ "' ` ´ ' '] \ W *? [+=]+\W*? [\ "` ´ ' ']) | (? : [\ "' ` ´ ' '] \ s *? [!=|][\d\s!=+-]+.*? [\ "` ´ ' '(]. *? ($) |? : [\ "' ` ´ ' '] \ s *? [!=|][\d\s!=]+.*? \d+$)|(? : [\ "' ` ´ ' '] \ s *? Like \ W + [\ W, \ "' ` ´ ' '(]) | (? :\sis\s*? 0\W)|(? :where\s[\s\w\.,-]+\s=)|(? : [\ "' ` ´ ' '] [< > ~] + [\" '` ´' ']) "" phase: 2, the capture, t: none, t: urlDecodeUni, block, MSG: 'Detects basic SQL authentication bypass attempts 1/3',id:'981244',tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.id}-%{rule.msg}',setvar:tx.sql_injection_score=+1,setvar:tx.anomaly_s core=+%{tx.critical_anomaly_score},setvar:'tx.%{tx.msg}-OWASP_CRS/WEB_ATTACK/SQLI-%{matched_var_name}=%{tx.0}'"Copy the code

2.1 Parameters requested by this rule include all Cookie information (Request_Cookies and! Request_Cookies) and the name of the cookie (Request_name), the Post argument (Args) and the name of the Post argument (Args_names), and of course the XML file in it (XMLL: /*)

2.2 Most of them are regular expressions, regular expressions I will not give you analysis. Instead, post a picture:

2.3 Using the Request Body phase “Phase2”

2.4 Match each object against a regular expression and capture has been enabled for the regular expression

2.5 Let the request data undergo multiple transformations (t: None) before matching. The main transformations are urlDecode and Unicode. The main function of the former is to clear up all the transformation functions and rules that were previously set. The latter is mainly for URL encoding.

2.6 If the match is successful, the request will be blocked. And throws a prompt message (MSG). Indicates that this is an SQL injection attack and adds this injection attack to the rule. In addition, unique tags that distinguish attack types are added to logs.

2.7 This rule is also assigned a unique ID (ID: 981244)