Protecting Against Unknown Software Vulnerabilities
Bugs exist in every piece of code. It is suggested that for every 1,000 lines of code, there are on average 1 to 5 bugs to be found.
Some of these bugs can have a security implications, these are known as vulnerabilities. These vulnerabilities can be used to exploit and compromise your server, your site and your users.
As long as there are people involved in the process of writing code and setting up systems, mistakes will happen as it is part of human nature. As such, security problems will always be something we have to deal with.
Impact of Vulnerabilities on Websites
Why does it matter that much? Last week, both WordPress and Drupal released new versions of their Content Management System (CMS) to patch important security vulnerabilities. Other popular WordPress plugins also released updates to fix their vulnerabilities.
Once a vulnerability is found and a patch is available, the solution is simple: Apply the patch (by doing an update) and you are now protected. It is the endless cycle that is known as software development. A bug will be found, a patch will be available, patch is applied, another bug is found, a new patch is available, patch is applied. Every time a new feature is introduced, new bugs are also introduced with it.
It seems like a simple process for a webmaster that as long as he is updated, he is safe.
However…
How do you protect against unknown software vulnerabilities?
What if you do not know about a specific vulnerability, how do you patch and protect your website?
What if an update goes out over a long weekend? A 0-day gets disclosed before an update is available? Or what if a vulnerability is discovered by the bad guys and they start using it without telling anyone?
- The latest SQL injection vulnerability in the Drupal platform was being exploited within 7 hours of it’s disclosure.
- Sites were being compromised via TimThumb before the public knew about it and a patch was available
- We have hits in our logs from days before the latest XSS vulnerability in WordPress was disclosed.
So the question is, how do you increase your security, so that you can minimize the risk and the chances of being compromised when (not if) someone tries to attack your site misusing an unpatched / unknown vulnerability?
You have options:
- Restrict who can access parts of your site to minimize the attack footprint.
- Employ prevention solutions that try to block exploit behaviors (generally called WAF’s or IPS’s).
- Harden parts of your stack, to minimize the effect of an exploit.
- Constant network and log monitoring to identify Indicators of Compromise (IoC).
These are just some examples. They may sound hard or too advanced, but they are actually doable and every web site owner should look into it.
Think about your desktop / notebook computer for a second. Why does every (or almost every) desktop have a personal firewall, an anti-virus, a spam filter and other similar tools? Yes, even Mac’s have them as well.
Why do most networks (including home networks) run behind a router with basic / advanced firewalls working to filter and prevent attacks from the Intranet?
The reason is simple: minimize the footprint and options for an attacker.
Now think about your website[s]. Let’s look at a few examples into how that can be applied to your Website security:
WordPress 4.0 long Password DOS
Both Drupal and WordPress had a vulnerability disclosed last week that allowed an attacker to DoS (Denial of Service) a site by sending many, very long passwords in the login requests.
Prevention: Access Restriction / Reduced Footprint. Block wp-login and wp-admin access only to authorized IP addresses. If an attacker can’t reach your login page, he won’t be able to exploit this vulnerability.
Simple solution that anyone can do by adding an .htaccess to your wp-admin allowing just a few IPs. We find this feature important enough that we employ it to our stack by default and set it as default for all users of our Website Firewall product.
Paid Memberships Pro Path Traversal
Paid Memberships Pro is a popular WordPress plugin that had a path transversal (arbitrary file download) vulnerability disclosed last week. The exploit is possible by accessing: wp-admin/admin-ajax.php and passing a file to be downloaded via getfile:
wp-admin/admin-ajax.php?action=getfile&/../../wp-config.php
Prevention: Access restriction / reduced footprint. The same as before, restrict access to only whitelisted IPs.
Prevention 2: WAF/IPS: Even if the previous restriction was bypassed, an Intrusion Prevention System (IPS) or Web Application Firewall (WAF) would prevent it from being exploited through generic Local File Inclusion / Remote File Inclusion (LFI/RFI) rules.
WordPress 3.9.x stored XSS
WordPress versions 3.9.2 and earlier are affected by a critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site. This was reported and patched last week as well.
This vulnerability abuses the core commenting system, an attacker is able to craft a simple comment to send a malicious payload that when viewed by the administrator, allows the attacker to take over the site. This explains it’s severity.
Prevention: Reduced footprint First, don’t allow comments via your main website’s core commenting system. This isn’t the first time this has happened, leverage third party commenting systems that take the noise off your web server. If your site does not allow comments, you can also block wp-comments-post via .htaccess.
Prevention 2: Prevention technology Employing a WAF or IPS would have provided you a means blog most XSS vulnerabilities with simple signatures, most come with them default. A simple detection signature would have triggered and blocked this attack.
WP-Statistics XSS
Our research team found a stored XSS in the very popular wp-statistics plugin.
Prevention: WAF/IPS: This is where having a good WAF / IPS solution in place becomes a must. A WAF have (or should have) a XSS detection that will block this attack generically, without even knowing about this specific vulnerability. On our own WAF, we were blocking it automatically before even knowing about this bug, in a way that we did not even need to write a virtual patching for it.
Staying ahead of Unknowns
Last weeks releases are growing in number each month, as they do the importance of being able to tackle the problem of unknowns grows. Following some of the steps above would improve your over Security posture allowing you to better recognize and respond to these issues, reducing your overall risk footprint.
Yes, we offer a product that can do this all for you, but many of the recommendations you too can employ on your own by leveraging open technologies and .htaccess changes:
- Restrict access to wp-admin/wp-login (and any other access point) only to authorized IPs.
- Limit footprint. Do you need comments? Do you use XMLRPC? Blocking everything and only allowing what you really need.
- Leverage a WAF / IPS and you can do this with products like Modsecurity and OSSEC.
We’ve obviously built a technology that automates all these things for you, allowing you to get back to running your business, but you can see there are various options available to you. If you’re interested in a free trial, ping us at info@sucuri.net.