Bypassing Web Application Firewalls
Total Page:16
File Type:pdf, Size:1020Kb
Bypassing Web Application Firewalls Pavol Lupták [email protected] CEO, Nethemba s.r.o Abstract The goal of the presentation is to describe typical obfuscation attacks that allow an attacker to bypass standard security measures such as various input filters, output encoding mechanisms used in web-based intrusion detection systems (IDS), intrusion prevention systems (IPS) and web application firewalls (WAFs). These attacks may include different networking tricks, polymorphic shellcode and various code techniques. At the beginning we analyse and compare different HTML parsing and interpretation approaches used by most-common browsers that can lead to unique attack vectors. Javascript, with a full range of features, represents another effective way that can be used to obfuscate or de-obfuscate code – some existing obfuscation tools are mentioned. We describe how it is possible to construct “non-alphanumeric Javascript code” which does not contain alphabetic or numeric characters, but still can contain malicious executable code. Despite the fact that most current applications are immune to SQL injection attacks, it is still possible to find many vulnerable applications. We focus on different fuzzy techniques (and useful open source SQL injection tools that implement them) which can still be used to bypass weak input validation controls. We conclude our presentation with a demonstration of the most basic obfuscation techniques that can be successfully used to bypass traditional web application firewalls (WAFs). Finally, we briefly describe current mitigation techniques that are recommended for efficient malicious Javascript code analysis and sanitizing user input containing untrusted code. Keywords: WAF, IPS, IDS, obfuscation, SQL injection, XSS, CSS, CSRF. 1 Web Application Firewalls implementations, common problems and vulnerabilities 1.1 What is a Web Application Firewall (WAF)? According to the OWASP definition[1]: A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL injection. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified. Web Application Firewalls (WAFs) were emerged from IDS/IPS systems that were specifically focused on HTTP protocol and HTTP related attacks. They usually contain a lot of complex regular expression rules that match most known input/output validation attacks. Especially commercial ones support extra features like cookie encryption, transparent CSRF protection etc. Except of free mod_security[2], PHPIDS[3] and AQTRONIX[4] they are quite expensive and often there is no correlation between their price and their filtering capabilities. Security and Protection of Information 2011 79 Choosing the right WAF is not easy, but there are at least two documents that can be helpful in this process – using Best Practices: Use of Web Application Firewalls and/or the Web Application Firewall Evaluation Criteria. 1.2 Common WAF implementations Web Application Firewalls are usually deployed in so called “blacklisting mode” which is much more vulnerable to bypasses and targeted attacks. Blacklisting according to the OWASP definition[5] means “Reject known bad”: This strategy, also known as “negative” or “blacklist” validation is a weak alternative to positive validation. Essentially, if you don't expect to see characters such as %3f or JavaScript or similar, reject strings containing them. This is a dangerous strategy, because the set of possible bad data is potentially infinite. Adopting this strategy means that you will have to maintain the list of “known bad” characters and patterns forever, and you will by definition have incomplete protection. A more secure strategy is Whitelisting. According to the OWASP definition[6], it means “Accept known good”: This strategy is also known as “whitelist” or “positive” validation. The idea is that you should check that the data is one of a set of tightly constrained known good values. Any data that doesn't match should be rejected. Data should be: Strongly typed at all times Length checked and fields length minimized Range checked if a numeric Unsigned unless required to be signed Syntax or grammar should be checked prior to first use or inspection In whitelisting mode for WAF configuration it is necessary to know an application context (i.e. type of all allowed inputs for all forms) which can be quite handy yet difficult to obtain, especially in the case of huge web applications. Despite the fact that the blacklisting approach is vulnerable to bypasses and targeted attacks, a web application firewall can still be a cost-effective security solution, especially when a customer has no control over his protected application (the supplier does not provide the application security updates anymore or the customer has no access to the application's source code). It is necessary to emphasize that a WAF is just workaround, not a 100% secure replacement for a secure application that correctly validates all user input and output. 1.3 WAF filter rules WAF filter rules directly reflect WAF effectiveness. Unfortunately, for most WAF vendors, they are closely guarded secrets[7] that follow the “Security through obscurity” concept [8]: Security through (or by) obscurity is a pejorative referring to a principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to provide security. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that the flaws are not known, and that attackers are unlikely to find them. A system may use security through obscurity as a defense in depth measure; while all known security vulnerabilities would be mitigated through other measures, public disclosure of products and versions in use makes them early targets for newly discovered vulnerabilities in those products and versions. An attacker's first step is usually information gathering; this step is delayed by security through obscurity. The technique stands in contrast with security by design, although many real-world projects include elements of both strategies. 80 Security and Protection of Information 2011 Most determined attackers are able to bypass these rules even without seeing them. Open-source WAFs (mod_security, PHPIDS) have open-source rules, which is beneficial due to the added public scrutiny by skilled penetration testers. Blocked Attack Undetected modification 'or 1=1-- ' or 2=2-- alert(0) %00alert(0) <script>alert(0)</script> <script type=vbscript>MsgBox(0)</script> ' or ''''='r '/**/OR/**/''''=' <script>alert(0)</script> <img src=”x:x” onerror=”alert(0)”></img> <img src=x:x onerror=alert(0)//></img> <img src=http://url onload=alert(0)//></img> 1 or 1=1 (1)or(1)=(1) eval(name) x=this.name X(0?$:name+1) Table 1: Typical WAF bypasses. 1.4 WAF vulnerabilities Although WAF is considered to be a network element that significantly increases the overall security of customer applications, WAF can also increase the attack surface of a target organization. WAF may be the target of and vulnerable to malicious attacks, e.g. XSS, SQL injection, denial-of-service attacks, and remote execution vulnerabilities [14]. Increased complexity of any application usually also increases the number of its potential vulnerabilities and this is also the case of security products including WAFs. 2 Bypassing Web Application Firewalls In the following section we describe how a typical bypass flow looks like and how it is possible to make javascript and SQL obfuscation code including practical composition of non-alphanumeric javascript code. 2.1 Typical bypass flow Typical bypass flow for the determined attacker can be described in the following 4 steps: 1. Find out which characters or sequences are allowed by WAFs HTTP response codes are useful for revealing which characters or sequences can be included in the target GET/POST requests. Security and Protection of Information 2011 81 2. Make an obfuscated version of your injected payload Making the obfuscated version of the injected payload may require a deep knowledge of Javascript or SQL language. Be aware that the obfuscated version can be much longer than the original one. If there is no GET/POST parameter size limit, this should not be a problem. 3. Test it and watch for the WAF/application response It is necessary to carefully check which injected characters or sequences are accepted by the application and passed to the web application firewall. Analysing WAF/application responses will reveal which characters or sequences can bypass the given WAF or application validation filter. 4. If it does not bypass, modify your payload and repeat step 2 2.2 Javascript obfuscation Javascript is a very dynamic, expressive and loosely typed language that has powerful features. Javascript payload is used in XSS attack vectors. For obfuscation, Javascript supports many useful functions: evals (possibility to evaluate any expression), expression closures (something similar to a typical Lambda notation), e.g.: (function() alert(1)) () (function($)$(1)) (alert) generator expressions, e.g.: for ([]in[$=alert])$(2) $=[(alert)for([]in[0])][0],$(1) iterators (an object that knows how to access items from a collection one at a time, while keeping