In the final part of the series, I am going to show a few practical tips and tricks for protecting your WordPress blog.
We have seen earlier how a simple XSS vulnerability can lead to the total compromise of the hosting environment. We not only managed to deploy a backdoor, dump all data from the databases and retrieve each file from the hosting server, but also used the hacked server as a gateway for further attacks.
Recommended
The Old and Boring Mantra
… which is patching, patching and patching.
The latest WordPress release could have prevented the exploitation of the bug, and we would have not been able to elevate our privileges on Ubuntu.
So patch WordPress/Drupal/Joomla/etc. along with their plugins and themes regularly. Besides, do not forget to apply the latest updates to the OS.
Two Is Better Than One
Two-factor authentication is a good idea in many situations. Generally it prevents malicious people from logging in with stolen passwords.
Duo Security has a nice WordPress plugin that provides an additional layer of security for the admin dashboard. Even if the attacker steals the password of the admin user, he or she cannot log in without your mobile phone linked to Duo. The plugin is super-easy to install and improves security a lot.
WordPress Hardening
These tips are coming from Acunetix’s 10 WordPress Security Tips. I found restricting access to wp-admin, disabling file editing and preventing PHP files from executing quite handy, so give them a look.
Privilege Separation
Are you running multiple websites on the same host (e.g. Apache VirtualHost)?
First of all use dedicated MySQL users for each web app, and their privileges should be limited to the application’s data. So even if one of the web apps is compromised, data of the others will remain safe.
In addition files like wp-config.php also contain sensitive things such as database credentials. Plus we do not want to end up serving exploit kits from each VirtualHosts because one of the web apps have been compromised.
So run the individual web apps with SuExec under different Linux users and set the file permissions correctly.
Finally this might be a no brainer, but never run Apache, MySQL, Tomcat or similar as ‘root’.
‘Meh’ Protections
Web Application Firewalls (WAF)
This firewall does not monitor packets but HTTP requests and responses for common attack scenarios. WAFs like ModSecurity could be effective to prevent web application based attacks.
The reason I moved WAFs into this category because the default rules (such as OWASP ModSecurity Core Rule Set) are good for keeping low-skilled attackers away. However these generic rules are usually based on the blacklist approach, so funky encodings and other tricks can bypass application level firewalls.
What is a good idea is brewing your own rules based on the whitelist approach. Although it might be time consuming, tailored rulesets could be an effective companion to your website.
CPU Features
Protection mechanisms such as ASLR, NX bit or SMEP may prevent certain attacks against the OS. SMEP is a relatively new security mechanism in later Intel processors.
In Part 3 we used a local root exploit to get access as the superuser. If you remember we had to disable SMEP, otherwise the exploit just crashed Ubuntu instead of giving us a root shell. Probably a determined and skilled attacker could have circumnavigated this kind of protection, but it definitely keeps script kiddies away.
So try enabling these features, and give EMET or Malwarebytes a spin.
File Integrity Monitoring
Tripwire, Samhain or OSSEC can detect unwanted changes to your existing files on your server.
Although Meterpreter and other backdoors run in the memory, WSO Remote Administration Toolkit was not altering any existing file on the disk. Although file integrity monitors could be an effective part of a defence-in-depth strategy, a smart attacker can dodge this protection too.
My recommendation is to try monitoring files that matter and rarely change, such as passwd and wp-config.php. Otherwise system or WordPress upgrades will generate a large amount of false alerts wasting everyone’s time.
DMZ
The zoning concept is widely used in enterprise environments. The theory is that if web servers are running in a DMZ and the database resides in some sort of backend zone. The latter is not accessible from the Internet, and each zone is segregated by a firewall. SANS has a nice whitepaper on the concept.
The problem is that this approach originates from the time when most of the attacks were network rather than application based. DMZs will not prevent SQL injections and many other app-level attacks from the OWASP Top 10 list. Parts 1-3 have proved that a single XSS vulnerability can be exploited no matter where the web servers are running. Once we get a foothold on the web server, the database becomes accessible via the compromised WordPress host.
What makes sense is preventing hosts from communicating with each other
- inside the zone, and
- cross-zone
So compromised WordPress site #1. cannot be used as a pivot (shown in Part 3) to attack WordPress site #2.’s OS and its database.
Ineffective Defenses
NoScript, ScriptSafe etc.
Browser plugins such as NoScript prevents JavaScript from running in the browser. The general idea is that if we only rely on static content, or disable scripts from third-party websites, we can protect ourselves from malicious code.
If you remember we used a malicious payload written in JavaScript to turn the WordPress admin page into a phishing site.
Websites generally rely on JavaScript to function properly, so scripts from the same domain are enabled. In Parts 1-3 the malicious payload was injected into the website as a visitor’s comment and it was effectively hosted from the same domain afterwards. This is generally called as Type 2, Persistent or Stored XSS exploits. Unfortunately NoScript only provides protection against Type 0 (DOM) and Type 1 (reflective) client-side attacks.
Nevertheless, keep using these extensions as they provide an good layer of protection, but be aware of their limitations.
OS Hardening “Best Practices”
Everyone loves checklists. Running SSH on a different port? Disabling CTRL+ALT+DEL key combination? Changing the MOTD banner? Remount /tmp filesystem with noexec flag?
Probably we can charm auditors with these OS hardening recommendations, but many of them are useless against our scenario in Part 1-3.
Summary
Recommended
- Patching
- Two-factor Authentication
- WordPress Hardening
- Privilege Separation
‘Meh’ Protections
- WAF
- CPU Flags
- File-integrity Monitoring
- DMZ
Ineffective
- NoScript, ScriptSafe etc.
- OS Hardening
What is your top tip? Scroll down for the comment box and let us know!
This is the final part of a series demonstrating total data exfiltration by exploiting XSS
- Part 1 – WordpreXSS Exploitation
- Part 2 – XSS Harvest Festival
- Part 3 – Data Exfiltration with XSS
- Part 4 – Suit Up and Protect WordPress
