WAF Defense Capability Evaluation and tools
This article describes how to evaluate a WAF from the defense capability of conventional attacks. A total of 16 attack types are covered, each of which ranges from the Use scenario (The purpose of the attack operation) to the injection point (where the vulnerability is generated, for example, most WAF comprehensively covers the GET request attacks, selectively covers the POST request attacks, and ignores the attacks from the request header.) and the bypass method is used for evaluation, the evaluation code is attached.
I. SQL Injection)
1. Use Cases
From the perspective of the attacker's SQL Injection stage, it is generally divided into two stages: Detection and attack (p.s. Attack Stage is the key defense stage of WAF)
(1) detection phase
1) Check whether SQL Injection exists: Check whether the target website has an SQL injection point based on the SQL error echo (e. g. extractvalue) or time response (Benchmark, sleep ).
2) identify the database type: Based on the slang of the database, determine the database and database version used by the target website, such as @ version and user ()
(2) exploitation phase
I. select Type SQLi
1) read Metadatabase: Read the metadata database of the database management system (information_schema of e.g. MySQL, and sysobjects of SQL Server) to test basic information such as the data storage database, table, and column.
2) extract data: Use the union query or the one-by-one detection in the blind note (e. g. length, substr) or condition detection (Select if (1 = 1, 'A', 'B');) to extract data from the database management system, functions such as concat () and group_concat () are often used,
3) read system files: read important system files in the operating system where the database management system is located (load_file of eg. MySQL)
4) Write System File: Write a backdoor file to the operating system where the database management system is located (select into outfile of e.g. MySQL)
5) execute system commands: execute system commands (exec master of e.g. SQL Server... Xp_mongoshell)
Ii. update SQLi
Iii. insert-type SQLi
2. Injection Point
Remember: Any input is harmful.
(1) GET QueryString
(2) POST
(3) Referer
(4) Cookie
(5) X_Forwarded_For
(6) UserAgent
(7) Basic-Authorization
Note: injection points exist not only in parameter values, but also in parameter names and URLs. WAF that only detects parameter values has limited defense capabilities.
3. Bypass Mode
The bypass here is mainly for the WAF detection method that uses pattern matching to identify attacks (in fact, most of the basic methods of WAF are this, extended to IDS, IPS, this method is adopted by security products such as anti-virus)
The pattern matching detection method is bypassed for the following reasons:
1) HTTP protocol Parsing Vulnerability: WAF matches HTTP protocol variables during pattern matching. Attackers cannot normally extract variables by constructing abnormal HTTP packets, they cannot enter the pattern matching stage, and naturally they will bypass it.
2) Inherent defect of pattern matching: string matching, whether simple regular matching or logical matching (for example, weighted operation on different keywords and pre-and post-dependency judgment) in any case, the mode is fixed, leading to various side leaks.
For the second point, the problem with cloud WAF is the most serious. We know that the user types of cloud WAF are diversified (different construction technologies are PHP/ASP/JSP, And the runtime environment is Windows/Linux, access Mode PC/Mobile). Ideally, precise projection of defense rules by site type should be adopted, .. automatic site-based modeling (lack of data analysts among security personnel) is a "cutting-edge" technical activity. In the free mode, there is not much motivation to invest effort, therefore, the reality is that we tend to choose a more general approach (to discard a few people) to customize rules based on the hazard priority.
The above causes are derived from the following general bypass methods:
(1) parameter contamination
(2) URL rewriting
Http: // localhost/uyg/id/123 + or + 1 = 1/tp/456
(3) encrypted payload
MD5, SHA-1, and custom Encryption
(4) Buffer Overflow
(5) code Bypass
(6) Special Character insertion (% 00)
(7) abnormal HTTP Request Packet (e.g. Super Large, packet that does not comply with HTTP specifications but is fault-tolerant by the server)
(8) multipart data packet transmission: Transfer-Encoding: chunked
SQL Injection generally has the following bypass methods (in fact, this is the inherent defect of pattern matching)
1) code bypass: Uses Unicode encoding, hexadecimal encoding, and dual-URL encoding for Payload attacks to bypass detection rules.
2) annotation statement bypass: by inserting a comment Statement (Inline comment) in the SQL injection attack Payload, the detection rule is bypassed.
3) case-insensitive bypass: attackers can bypass detection rules by changing the case sensitivity of SQL injection attacks.
4) type conversion bypass: use type conversion functions such as hex, ascii, ord, char, chr, cast, and convert to change specific characters to bypass detection rules, feature http://danqingdani.blog.163.com/blog/static/186094195201331854938182/ of implicit type conversion in addition to the Type Conversion Function
5) uncommon SQL keyword Bypassing
6) Special SQL syntax (e.g. mysql .~ ! +-Symbol)
7) keyword splitting
8) Request mode conversion (convert GET to POST, because the POST rules are much looser than GET rules due to false positives)
(Refer to the bypass method summarized by Seay)
Ii. File Inclusion (File Operations)
One of the core targets of attacks is information manipulation, and the carrier of information is files (data). Illegal reads, writes, and deletes of files become the core of defense.
1. Use Cases
(1) include local files
The starting point of local file inclusion is generally divided into two types:
A. Read system files to obtain sensitive information, such as configuration files.
In addition to reading files under the same directory, it usually works with directory traversal.
B. Implement Code Execution
(1) files containing (executed) backdoor (there are many backdoor writing methods, such as SQLI write horse/File Upload write horse/code injection)
(2) include (execute) system executable files
(2) Use php: // input protocol to turn the File Inclusion Vulnerability into a code execution vulnerability http://danqingdani.blog.163.com/blog/static/1860941952013993810261/
(2) include remote files
2. Injection Point
Remember: Any input is harmful.
(1) GET QueryString
(2) POST
3. Bypass Mode
Attackers can bypass directory traversal detection (in fact, directory traversal is used in command execution and other places because it is listed separately)
1) code bypass:
B. % c0 % af Apache, Tomcat UTF-8 Encoding Error
C. % 25% 5c Unicode Vulnerability
D. % c0 % af
E. % c1 % 9c Unicode Vulnerability
F. % fc % 80% 80% 80% 80% af Unicode Vulnerability
2) truncation: % 00
Bypass Detection Method for reading system files
1) Use php: // filter protocol to read the content of a specified file in base64 encoding Mode
2) use the data: // URI schema protocol to execute system commands
Iii. File Upload/download (File Operation)
1. Use Cases
(1) directly upload a webshell File
Generally, the file upload module configures the File Upload whitelist (e.g. only allows the upload of image files). Therefore, this attack usually checks whether a whitelist exists and how to bypass the whitelist.
The webshell type is as follows:
1> asp shell
2> php shell
3> jsp shell
4> python shell
5> pl-cgi shell
6> sh shell
7> c shell
8> cfm shell
9> exe shell
(2) image writing and horse uploading
When the file name cannot be used as an article, it is usually used together with the Server Parsing Vulnerability or File Inclusion Vulnerability.
(3) download any file
Allows users to submit file paths when processing user requests. Attackers can download system sensitive files by changing directories or file addresses.
Supplement:
(1) put http Method
(2) ActiveX
(3) JavaApplets
2. Injection Point
File Upload form
3. Bypass
File Name whitelist Bypass
(1) the file name cannot be extracted normally by using the parsing vulnerability of the upload file request.
(2) in combination with the Server Parsing Vulnerability, construct a strange file name to bypass the White List, e.g. file.php000000.jpg
Server Resolution Vulnerability
(1) Apache Parsing Vulnerability
Xxx.php.jpg
Xxx.php.rar
Xxx. php. x1.x2. x3
Xxx. php. (windows vertices and spaces are automatically eliminated)
(2) Nginx Parsing Vulnerability
Xxx.jpg % 00.php
Xxx.jpg/a. php
(3) IIS resolution Vulnerability
Xxx.asp;.jpg xxx.asa%.jpg xxx.cer%.jpg xxx.cdx%.jpg
Xxx. asp:. jpg xxx. asa:. jpg xxx. cer:. jpg xxx. cdx:. jpg
Xxx. asp/xx.jpg xxx. asa/xx.jpg xxx. cer/xx.jpg xxx. cdx/xx.jpg
Reference http://drops.wooyun.org/papers/539
Iv. Command Execution (injection)
1. Use Cases
Enter a vertex to receive and run system commands
2. Injection Point
(1) POST
(2) GET
(3) Cookie
5. Code Execution (injection)
1. Use Cases
(1) Input points to receive and run PHP/JSP/ASP code
2. Injection Point
(1) POST
(2) GET
(3) Cookie
6. webshell (this classification is a bit tangled, mainly because it can be intercepted when it has been planted)
1. Use Cases
In combination with file upload, code execution, SQLI write horse and other operations, and webshell connection after being written to webshell
Webshell is classified by payload.
(1) payload uses the Request Header for submission, and most requests are submitted using cookies. The custom request header is more concealed.
(2) payload uses POST for submission
2. Injection Point
(1) GET QueryString
(2) POST
(3) Cookie
(4) other request headers
3. Bypass Mode
Webshell payload is usually encrypted when it is submitted.
The following lists common webshells. You can check whether these basic webshells can be intercepted by WAF.
Caidao connects to the client in one sentence
Lanker micro php Backdoor client 2.0 official version one-sentence Connection Client
Weevely php backdoor generation tool and client side
Webacco php webshell generation tools and clients
Phpspy. php
B374k. php
80sec. php
90sec. php
R57.php
C99.php
B4che10r
X14ob-Sh3ll
Aspxspy
Server_sync.php (phpadmin backdoor file)
VII. XSS
1. Use Cases
From the perspective of the XSS injection stage, attackers are generally divided into two phases: Detection and attack.
The test phase refers to the testing of the existence of xss in the pop-up box, common functions such as alert (), prompt (), and confirm, check whether html tags can be run );
The attack phase refers to the exploitation after the existence of XSS, such as session hijacking to forge user identity login, worm propagation, keylogger, download and install malware, and construct phishing pages.
(I know too little about xss. xss is a complicated one. There are reflected xss, stored xss, DOM XSS, mXSS (mutant XSS), UXSS (General XSS ), by platform, there is also a book on the attack methods of flash xss, xss, and sqli)
2. Injection Point
Remember: Any input is harmful.
(1) GET QueryString
(2) POST
(3) Cookie
3. Bypass Mode
1) code bypass (url unicode encoding, base64 encoding)
2) Use Data URI schema to bypass
3) use Javascript pseudo Protocol
4) event-based function Bypass
5) type conversion bypasses the quotation mark e.g. String. fromCharCode
6) xss payload submit the https://www.securusglobal.com/community/2014/10/13/bypassing-wafs-with-svg/ after the anchor
VIII. CSRF
(In fact, CSRF is more like an attack mode than just a vulnerability type)
1. attack scenarios
Because the http request is stateless, and the server only relies on the user's browser to send cookie information to determine the identity validity, the web browser will automatically send the session id (cookie) feature, attackers trick victims into accessing malicious requests and execute "constructed" requests as victims.
2. Injection Point
Remember: Any input is harmful.
(1) GET QueryString
(2) POST
3. Bypass Mode
Csrf is actually a logic error, and the defense of conventional csrf is actually not feasible (it cannot be based on referer, and some csrf combined with xss is initiated by the local domain; in addition, there are also scenarios where referer is lost during protocol conversion and the mobile platform loses referer)
9. automated tool attacks
According to statistics, attacks by automated tools account for 90% of total attacks. Whether or not these automated tools can be accurately intercepted is a test of WAF capabilities.
Automated tools include offline tools and online tools.
<1> online tools (basically comprehensive tools ):
Various CDN services are provided with the online network security detection function (cloud scanner), which is not mentioned here.
<2> offline tools are classified into the following types:
A. Vulnerability scanner
(1) comprehensive vulnerability scanner
List commonly used
License information reference http://www.sectoolmarket.com/price-and-feature-comparison-of-web-application-scanners-unified-list.html
AWVS
AppScan
WebInspect
NetSparker
Websecurify
WebCruiser
Nikto
Wikto
W3af
Vega
OWASP-ZAP
Arachni-Scheduler
Golismero
Brakeman ruby on rails vulnerability scanner
Grendel-scan
(2) Special Scanners
A. SQLI/NoSQLI
Havij, SQLMap, Pangolin
B. XSS
X5S, XSScrapy
C. File Inclusion
Fimap
D. Open-source framework vulnerability scanner
Wpscan
Joomscan
(3) password cracking tools
Hydra
Medusa
Patator
(4) Directory dictionary attack tools
Pker
Dirbuster
(5) Others
Burpsuit
MSF
There are also various self-written script tools sh/perl/python (e.g. pycurl, python-urllib)/php/ruby/java
10. Malicious crawlers/collectors/robots
Malicious crawlers, collectors, and robots can cause terrible harm to small websites with insufficient bandwidth. Therefore, they are also an important aspect in evaluating WAF defense capabilities, it is always a challenge for WAF to distinguish it from a search engine (which does not provide its complete IP segments) and a normal API call.
1. attack scenarios
(1) disguised as search engine bypass detection, this scenario is suitable for the lack of accurate search engine judgment methods
(2) automatically send spam comments to robots, etc.
11. Information Leakage
1. attack scenarios
(1) system files
Direct access to backup, hide, and other information files
(2) Error echo
Brute-force directory, brute-force path
(3) column directory
(4) management background exposure: how to deal with search engine indexing Management Background
12. Redirection
Mainly used for phishing
Generally, WAF does not defend against such vulnerabilities.
Session-based attacks
1. attack scenarios
(1) Use a fixed session
(2) The session ID generation algorithm can be guessed.
(3) hijack session ID using xss and other vulnerabilities
Iv. Permission Verification Vulnerability
1. attack scenarios
Vertical/horizontal elevation of Permissions
(1) Request Parameters to control permissions
(2) referer to control access permissions
Generally, WAF does not defend against such vulnerabilities (basic logic vulnerabilities are not supported by cloud WAF)
15. Denial of Service
1. attack scenarios
(1) xml billion laughs (memory consumption)
(2) CC (bandwidth consumption)
(3) slow HTTP DoS (bandwidth consumption)
16. Other vulnerabilities
(1) HTTP Response Splitting
(2) XML Entity attacks can be found in "XML Entity attacks-from Intranet detection to command execution step by step surprise" by pnig0s.
(3) hiding parameter tampering
1) hidden form value tampering
2) viewstate value tampering
(4) Other Injection
1) XXE Injection
2) XPath Injection
3) LDAP Injection
4) CRLF Injection
(5) Cloud WAF does not defend against logical errors !!
The method of Appeal evaluation is based on the WAF defense coverage. The more comprehensive the coverage, the better.
In fact, the evaluation of WAF defense capability generally refers to the detection rate (false negative) and accuracy rate (false
Positive ). The detection rate is generally the core of the WAF vendor's publicity, and the actual accuracy (many cloud WAF for the management background, API interface call, fuwen
This false positive is more important (security must not affect normal use). In the future, we will discuss the issue of false positive.
17. WAF testing tools
The WAF capability evaluation method is to construct an attack scenario, send an attack packet, and view the WAF response.
Test Tool address: https://github.com/tanjiti/WAFTest
Source code introduction:
(1) attack scenarios
Https://github.com/tanjiti/WAFTest/tree/master/vulCode (in continuous addition)
(2) packaging tools
Https://github.com/tanjiti/WAFTest/blob/master/HTTP.pl (reference: HTTP. pl-learn about HTTP through HTTP packet sending tools)
Https://github.com/tanjiti/WAFTest/blob/master/HTTPFromFile.pl (read and send HTTP package content from a file)
(3) Attack Packets
Https://github.com/tanjiti/WAFTest/tree/master/t (in continuous addition)
Test example:
Git clone https://github.com/tanjiti/WAFTest.git
Perl HTTPFromFile. pl-host www.tanjiti.com-dir t-code 403
The options are described as follows:
Perl HTTPFromFile. pl -- helpUsage: perl HTTPFromFile. pl [-code 403] [-uri 127.0.0.1] [-host example.com] [-port 80]-file request_file_path-code: Specifies the interception response code, the default is 403, different WAF will customize different response codes for interception responses-uri: Specify the IP address or domain name that uses WAF. 127.0.0.1-host by default: Specifies the Host Header for sending the request. If the uri is not specified, the uri is set to the host value. The default value is localhost-port: Specifies the port number for using WAF. The default value is 80-file: T file path-dir: directory path for storing T files.