Official Blog of Trustwave's SpiderLabs - SpiderLabs is an elite team of ethical hackers, investigators and researchers at Trustwave advancing the security capabilities of leading businesses and organizations throughout the world.
Following up my previous blog post which outlined how to activate additional HTTP ports to catch automated scanners, this blog post will discuss more HoneyTrap techniques for catching malicious users who visist your real site. I will show how ModSecurity can be used to share data with Project Honeypot.
This blog post will show an easy configuration update that you can make to your web servers running ModSecurity so that you can catch automated web attack tools that are scanning IP network ranges looking for web ports.
Instead of developing and deploying an entirely new honeypot web server or application, we can easily reuse the existing legitimate web server platform you are already running. We will implement our honeytrap by adding more network ports that will accept HTTP request traffic. These ports have no legitimate purpose, so any traffic we receive is suspect by definition. This blog post shows you how to enable these honeytrap ports using the Apache web server. This process, however, can be duplicated on any other web server software.
Do you know when an attacker or security researcher successfully finds a Cross-site Scripting (XSS) vulnerability in your web application?
This blog post will demonstrate a proof of concept that uses ModSecurity to add defensive Javascript to response pages that will identify when web browsers execute certain code and then will send back a beacon alert to the web server.
ModSecurity for Nginx is a web server plug-in for the Nginx web server platform. This module was created through a collaboration between Trustwave SpiderLabs Research, Microsoft Security Research Center (MSRC), Yandex and community members. With the addition of the Nginx platform to go along with Apache and Microsoft IIS, ModSecurity is now able to run on ~86% of web server platforms (according to Netcraft).
I have been asked this question more and more over the years as organizations are dealing with both external vulnerabilty scanning as part of requirements such as PCI and intenal scanning efforts. The short answer to this question is: it depends on your exact circumstance. When looking at vulnerability scanning, you need to first decide what the goal of scanning is and then you can select the appropriate WAF configuration for handling the traffic.
If your web application defensive strategy against injection attacks relies solely upon the use of blacklist regular expression for input validation, it is only a matter of time before an attacker finds an evasion. Want proof? Check out our SQL Injection Challenge post mortem. Just to clarify, there is value in using regular expressions for input validation:
Positive Security Model (Whitelisting) - where web application developers (Builders) define what is acceptable input and deny anything that does not match. Examples would be the OWASP Validation Regex Repository.
Negative Security Model (Blacklisting) - where web applicationd defenders (Defenders) define filters to detect and block known malicious input. Examples would be the OWASP ModSecurity Core Rule Set.
Where organizations get into trouble is when they do not utilize a positive security model and instead only use a negative security model to try and block attacks.
Web application firewalls must be able to handle Internationaliztion (I18N) and thus properly handle various data encodings including Unicode and UTF-8 in order to prevent not only evasion issues but also to minimize false positives. In an earlier blog post, we highlighted ModSecurity's new support for Unicode mapping and decoding. This capability helps us to more accurately decode characters from different Unicode code points. While this certainly helps our accuracy, we still had the issue of UTF-8 encodings.. This is a challenge for any WAF as it must be able to handle UTF-8 encodings of characters for different languages such as Portuquese. So, if you are running ModSecurity to protect a non-English language website then this blog post is for you! We introduce a new transformation function called utf8toUnicode that helps to normalize data for inspection.
Greg Wroblewski, Microsoft Security Engineering Center
Ryan Barnett, Trustwave SpiderLabs
Vulnerabilities in on-line services, like cross-site scripting, cross-site request forgery, or even information disclosure, are important areas of focus for the Microsoft Security Response Center (MSRC). Over the last few years Microsoft has developed a number of tools capable of mitigating selected web specific vulnerabilities (for example, UrlScan). To help on this front we have participated in a community effort to bring the popular open source module ModSecurity to the IIS platform. Yesterday at Black Hat Las Vegas, we have announced the availability of an RC version and we expect that stable release will be available soon.
Installation
Although the source code of ModSecurity’s IIS components is fully published and the binary building process is publicly described (see mod_security/iis/winbuild/howto.txt in SourceForge repository), it is highly not recommended to self-build the module for non-research or non-development purpose.
A standard MSI installer of ModSecurity for IIS 7 and later versions is available from SourceForge files repository of ModSecurity project and in the future designated maintainers will be keeping it updated with latest patches and minor versions of the module.
For as long as companies rely on web sites to do business with their customers and partners, attackers will keep targeting these web applications searching for new (and old) vulnerabilities and trying to exploit them. Reducing the attack surface has been a good practice for quite some time, hardening applications and web servers usually accomplishes this. In this blogpost we are presenting a Hmac-Based protocol that can be implemented in order to reduce the attack surface with minimum impact to the users and zero changes on the web application itself. Basically, the proposed method consists in parsing HTTP Response data sent by the web application server and signing HTML elements of this response before it is sent back to the client browser, from that point on, the integrity of the communication between the client and the web application will be checked using the protected Request Header or Request Body fields. With this mechanism, no modifications are allowed during a new HTTP Request using the signed elements, reducing quite a number of known web application attacks.
Expedited Virtual Patching: Through its participation in the Microsoft Active Protections Program (MAPP), Trustwave is able to quickly provide virtual patches for vulnerabilities identified within IIS or ASP/ASP.Net software. These virtual patches are available in the Trustwave SpiderLabs commercial ModSecurity Rules Feed. We currently have more than 1400 virtual patches for IIS/Asp/Asp.Net vulnerabilities.
Embedded WAF Deployment Model Option: Deployment of an Apache reverse proxy server in front of IIS web servers is no longer required to gain ModSecurity protection.
High Performance Reverse Proxy WAF Architecture: For those users who want to leverage a reverse proxy architecture, they can now use the highly performant Nginx platform.
In support of this announcement, Greg Wroblewski of Microsoft’s Security Response Center (MSRC) and Ryan Barnett of Trustwaves SpiderLabs Research Team will be presenting “ModSecurity as Universal Cross-Platform Web Protection Tool” (Wednesday July 25th at 2:15 pm) and giving live demonstrations as part of Arsenal Tools demos (Pod 2 - Wednesday July 25th at 3:30 pm and Thursday July 26th at 10:15 am) at the Blackhat USA 2012 security conference.
