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.
The Trustwave Spiderlabs team frequently
responds to E-commerce data breaches. The number of website breaches
that we are working continues to rise. There are a handful of reasons
for this rise.
We are approaching saturation in the
"brick and mortar" Point of Sale breaches. Attackers have been after
these systems very aggressively for the past few years. They're not
going to stop stealing, they are just going to find new targets.
It's
getting easier. There are some very sophisticated scanning tools on the
market that are either free, cheap or already pirated by attackers.
These tools are incredibly efficient at pinpointing and exploiting
website vulnerabilities. We see Havij and SQLmap on a weekly basis.
The
payoff! E-commerce sites are still storing large databases full of
personal information and cardholder data. The black market for this
information is well established and an attacker can easily monetize what
they steal. It's not unusual to see 50,000 - 100,000 records in an
E-Commerce database. The sale price of a data record can vary from a few
dollars up to about $25 per record. That's a lot of money!
On February 27, 2013, the ModSecurity project team was notified by security researchers from Positive Technologies that they had identified an XXE flaw in ModSecurity. Here is the CWE info for XXE -
<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!
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.
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.
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.
