Today virtually all websites are powered by CMSes, of which WordPress, Joomla and Drupal have racked up over 70% of the market share between them as per statistics from Web Technology Surveys. A CMS enables anybody to build a web application with minimum technical knowledge. This widespread popularity due to ease of developing has therefore lead many such sites to be targeted. The WPScan Vulnerability Database shows almost 6,000 known vulnerabilities with WordPress, related to the core code or the publicly available plugins.
A study of 500 cybersecurity service providing companies carried out by CMS Wire, revealed that “298 had some level of security concerns with their own corporate websites — from an out-of-date CMS or lack of a proper software firewall to something as severe as malware attacks.” The most concerning piece of information is that half of these companies do not know how to secure their own websites.
Impact
Vulnerable cms installations are highly prone to being hijacked and then become efficient launchpads where attacks to other systems originate. Systems can turn into DDoS zombies and remain at the beck and call of attackers as long as they stay undetected. Unless information is available or specific tools and security measures are properly tuned to be resourceful and proactive, such systems can remain compromised for a very long time relentlessly expanding the area of damages they can be capable of.
A compromised web server can become a propagator of malware and malicious codes like viruses, trojans, backdoors, thus spreading infection to website users or other web servers. A vulnerable CMS can suffer from a multitude of attacks including SQL injection, Cross-site scripting (XSS) and malicious code execution. Symantec has reported that CMS powered websites can be exploited over 60% and 30% of the time by XSS and SQL injection respectively.
Causes
Out-of-date CMS versions or unavailability of support
It is hardly possible to pin accountability in case of open source CMSs. Such scenarios can lead to uncertainties in receiving timely updates and patches.
As the source codes are publicly accessible to everyone including hackers, they can easily be reverse-engineered to construct exploits.
User accounts, that do not enforce strict secure password policies, can be broken by brute-force attacks
Insecure plugins and cracked themes can leave CMSs exposed to attacks and with millions of them being downloaded all the time, it is very grave. “On average, 76% of all identified vulnerabilities were located in extensions or add-on modules that can be installed on top of the core package of the application.”
Solution
Beside ensuring underlying operating systems and software packages are up-to-date, vulnerabilities can be addressed by always installing updates or security patches released by the CMS developers. This is the easiest and the most effective way to keep out malicious activities and threats.
Equally important, if not more, is observing caution in installing plugins. The process of installing a plugin should be vetted by gathering as much information about it as possible beforehand. System administrators should consider some important aspects like plugin ratings and number of times the plugin was downloaded. Some time must also be invested in reading through user reviews. Once the plugin has been integrated to the CMS core, then it should be maintained with every update and patch available.
Secure authentication policies should be enforced, which includes from using strong password to two-factor authentication. Use of captcha and strong regulation and monitoring of user authentication and failed login attempts will safeguard the system from brute-force and other automated attacks.
All default user accounts and administrator login urls must be changed. This is called security by obfuscation and can provide some degree of protection from novice attackers. Further account privileges and file permissions should be properly set.
CMSs should as far as possible disallow creation of accounts using automated tools. Creation and termination of user accounts should be carefully moderated. System owners if possible could create and follow user account policies uniformly across all their users.
The system should be configured to prevent it from revealing details like version numbers of the CMS, extensions, OS, web application servers and database platforms and avoid responding with self-incriminating information to automated scans, which could in turn help hackers to find or device exploits.
Use of SSL should be enforced wherever authentication and sharing of critical information exists.
Further refer The Open Web Application Security Project (OWASP) and US-CERT’s Technical Information Paper TIP-12-298-01 on Website Security for additional measures and practices. You can also find vulnerability assessments and remedies at the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD).