While all of these defenses are good, and I encourage WP users to implement them, I also wanted to show how ModSecurity WAF can be used to protect WP logins as many hosting providers already run it as part of their infrastructure. With ModSecurity v2.7.3, users can add in these example rules to Apache htaccess files to implement custom rules.
One of the many useful features of a web application firewall (WAF) is its ability to add on addition security checks or logic to third party web applications. One common request that my team often receives from WAF customers is that they want to restrict down access to certain portions of their web applications to specified IP addresses or ranges. Oftentimes this type of functionality is not available natively within the application and fortunately it can be added in using a WAF.
One such example is for the Adobe Experience Manager (CQ) application. How can an Adobe CQ admin restrict down who is allowed to log into the portal interface as the "admin" user? Well, it just so happens that Adobe's Help portal addressed this very issue here where they showed how this can be achieved using Trustwave's open source ModSecurity WAF!
The ModSecurity web application firewall project has grown a lot in the past year including, releasing versions for both Microsoft IIS and Nginx web server platforms and migrating the source code to SpiderLabs GitHub Repo. We even won some community awards and WAF comparison tests. It is good to look back on past accomplishments but it is also important to look ahead. Where will ModSecurity go in the future?
As part of this effort, the ModSecurity Team in SpiderLabs Research has developed a new user survey for 2013.Click here to take survey.
If you are a user of ModSecurity, I encourage you to take the Survey as it will give us a better understanding of how ModSecurity is being used and also get feedback on what we are doing well and what we need to improve. It is only 15 questions. As an added incentive, you can also enter your email address into a Raffle to win a copy of my new book "The Web Application Defender's Cookbook: Battling Hackers and Protecting Users."
Thanks for using ModSecurity and for helping us to make it better!
Trustwave is a corporate sponsor of the National Collegiate Cyber Defense Competition (CCDC) where the SpiderLabs team members actively participate on the Red Teams and simulate attackers. While we have been highly active in the "attack" portion of CCDC over the years, we haven't done much to help the competitors themselves (the Blue Team). The purpose of this blog post is to help the CCDC defenders with the challenge of fending off the web attackers during the competition!
In a previous blog post, I outlined how you could use ModSecurity to inject defensive JS into the HTML response page sent to the client web browser. The goal of this technique was to override many common JS elements that are often used by security researchers/attackers when conducting reconnaissance testing for XSS flaws. While this was an interesting PoC for using ModSecurity in combination with defensive JS, it had one fatal design flaw: the detection logic was exposed to the attacker. By sending our defensive JS code to the client, we are tipping our hand to the attacker as to our intention and methods. This allows attackers to then play around with various evasion methods.
Ideally, we need to keep this type of detection logic server-side, away from the prying eyes of attackers. But how then do we detect Browser/DOM events server-side? This blog post will demonstrate another PoC that uses ModSecurity's Lua API to execute PhantomJS to evaluate HTML data sent to end users and thus gain insight into XSS payloads that actually execute in the web browser.
As part of our recent release of ModSecurity v2.7.2, not only did we fix many bugs (CHANGES), but
this is also the first version where we labeled the IIS7 version as STABLE release quality! You can download the 2.7.2 MSI Installer here. Microsoft's IIS Engieering Team conducted extensive testing and opened many JIRA tickets.
In a previous blog post, I outlined some ModSecurity defenses to help protect Ruby on Rails users from the XML parsing vulnerabilities. Hopefully you have had a chance to update RoR for your site. If not, you might want to stop what you are doing and fix it now... We identified a few attack probes on our WASC Distributed Web Honeypot Project sensors recently looking for this vuln.
There is big trouble in Ruby on Rails (RoR) land... The issue is related to XML parsing of YAML document elements or Symbols and results in remote code execution. The vulnerabilities have been confirmed by multiple sources and proof of concept code is available: Rails PoC Exploits by Postmortem.
The primary recommendation is of course to update your Ruby on Rails code to the latest patched version. If, however, you are unable to do so in a timely manner or at all, then here are some options to use ModSecurity to help prevent these attacks.
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.