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.
<SCRIPT> var str1 = "http://"; var str2 = "www.modsecurity.org"; var str3 = "/beacon.html"; var result = str1 + str2 + str3; window.location=result</SCRIPT> As has been reported by many news outlets, WordPress login pages have been under a heavy brute force attack campaign as another method of web server botnet recruitment. There are are number of methods which can be used to help mitigate these attacks including:
Changing the default "admin" user account name - which can be done by either editing the wp_users table or by adding a new user with admin privledges and then deleting the "admin" account.
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.
Adobe CQ Admin Login - ModSecurity Example
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!
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.
ModSecurity Mitigations
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.
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.
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.
The ModSecurity Development Team has released version 2.6.6 in response to a multipart bypass vulnerability that was disclosed to us. Users are strongly encouraged to update. Please see the release notes included into CHANGES file.
Users are strongly encouraged to update to v2.6.6 (download).
CHANGES:
Added build system support for KfreeBSD and HURD.
Fixed a multipart bypass issue related to quote parsing Credits to Qualys Vulnerability & Malware Research Labs (VMRL).
ModSecurity v2.7.0-RC1 Available
The ModSecurity Development Team is pleased to announce the availability of ModSecurity 2.7.0-RC1 Release Candidate. This version includes many security enhancements including the ability to add cryptographic hash validation tokens to outbound data to prevent parameter tampering. The release also includes many performance enhancements to the Lua API and PCRE code. Please see the release notes included into CHANGES file.
This update includes security fixes related to multipart content-type bypasses so users are strongly encouraged to update (download). In addition, we have included many cool integration updates.
CHANGES:
Improvements:
Renamed main config file to modsecurity_crs_10_setup.conf
Updated the rule IDs to start from OWASP ModSecurity CRS reserved range: 900000
Updated rule formatting for readability
Updated the CSRF rules to use UNIQUE_ID as the token source
At the recent OWASP AppSecDC conference, I presented on this topic. I received a lot of feedback from the attendees afterwards so I wanted to get this out to a wider community. In past blog posts, I showed example scripts that would convert XML report data from the following DAST scanners into virtual patching rules for ModSecurity:
While this process does have great value for implementing compensating controls and mitigations for identified web application vulnerabilities until the code can be fixed, it still has some limitations.
Time-to-Fix vs. Time-to-Hack
There are many tasks that must be completed as part of this data sharing:
Spidering/crawling the entire site to enumerate resources
As has been reported by many news outlets, WordPress login pages have been under a heavy brute force attack campaign as another method of web server botnet recruitment. There are are number of methods which can be used to help mitigate these attacks including:
As has been reported by many news outlets, WordPress login pages have been under a heavy brute force attack campaign as another method of web server botnet recruitment. There are are number of methods which can be used to help mitigate these attacks including:
