One of the most popular CMS platforms in use internet today is WordPress. It’s popularity has risen dramatically over time to become an accepted and defacto standard for anyone looking to create their very own corner of the internet to showcase their writing talents. With the addition of plugins, the experience is enhanced further.
WordPress is also commonly used to host entire websites, and with the additional functionality provided by the extensive array of available plugins, putting together engaging content has never been easier. But simplicity for those without a comprehensive understanding of web design and it’s associated security can quickly turn into a minefield. WordPress.com hosted blogs are less susceptible to risk, as they traditionally do not permit the use of plugins – in fact, the only code that is permitted on the hosted platform is that generated by WordPress themselves. On the flip side, plugins written for self hosted WordPress blogs extend the functionality of the platform by hooking into the application core. The idea is to provide additional functionality to WordPress in varying forms, be it security, mailing, SEO, or an impressive collection of other utilities. Most of the plugins are very well written, and often updated when the need arises.
But what happens when a company decides to create their own website or e-commerce platform using WordPress in order to save on budget and the need to hire a website developer ? Once the website is completed, it doesn’t need any maintenance, right ? Actually, this couldn’t be further from the truth. WordPress plugins are extremely flexible, and because of the way they are able to interact with the core directly without having to modify the related files, this creates a vulnerability in the platform that, under the right circumstances, could provide a cyber criminal with a mechanism to leverage a weakness that particular plugin exposes. The weaknesses in question range from XSS (Cross Site Scripting) attacks to SQL Injections, but are by no means limited to these two threats alone.
The dangers of outdated WordPress plugins
Anyone can write and distribute a plugin for WordPress, but not every developer is committed to security, or even acknowledges it’s importance or indeed existence. Not every plugin is correctly maintained. You also do not need to be an actual developer – anyone with sufficient knowledge of coding (in this case, PHP) can write a plugin and upload it to WordPress.org for others to use in their own installations. In most cases, the author who wrote the plugin originally developed it to address a particular function they needed themselves, but then decided to upload it to WordPress.org in order to share it with everyone else.
Sounds ideal, doesn’t it ? Someone else does all of the hard work, provides the functionality you need, and best of all, it’s free.
Actually it isn’t ideal at all. In this “warts and all” scenario, poorly written code can easily propagate itself by being included in other WordPress installations, and as a result, actually introduce vulnerabilities to a previously safe installation. No overarching or governing body exists for plugin development – you simply upload it to WordPress.org as stated here, and can even declare that you will not be actively supporting it’s development. Surely, if you read that whilst on the lookout for a plugin to address functionality that is missing, would you really include it in your installation ?
In all cases, using community contributed plugins is only ideal if the developer who wrote it
- Possess the ability to write clean, well structured code, that makes use of accepted standards and security.
- Makes a considerable effort and commitment to maintain the plugin, and provides updates, new features and enhancements on a regular basis.
- Responds to questions concerning the plugin usage, and assists others with any installation issues.
- Provides full documentation on how the plugin works, and what is required in order to make it work as desired.
What are the security risks ?
The main underlying problem with WordPress plugins is that thousands of people write and submit them for others to download, yet after a while, lose interest for a variety of different reasons. The fact that a plugin can be completely abandoned at any time without any explanation is very common in an open source model. The plugin was provided on WordPress for free, with no obligation from the original author relating to support or resolution in terms of discovered vulnerabilities. The older a plugin in this situation becomes, the more vulnerable it is to compromise and exploit. As new vulnerabilities are identified, they are typically addressed and resolved by diligent plugin authors. However, those plugins that have been abandoned remain untouched, and more importantly, unresolved from the security vulnerability perspective. WordPress has made an effort to highlight the possible risks to users by displaying the below message
This plugin hasn’t been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.
Does this message go far enough to explain the real risks ? In my opinion, no – not all all. There is no mention that the plugin may contain security vulnerabilities, or even introduce security implications within your existing WordPress installation if you chose to install and activate it. Outdated plugins in use on a production WordPress installation can easily spell disaster from the cyber security perspective. If a vulnerability is discovered and exposed, it can be used to attack your site, and gain access to the underlying data. Even if the vulnerability is not a new one, organisations that do not perform regular updates within their installations can easily find themselves at significant risk.
Mossack Fonseca – “Panama Papers”
A well known breach from 2016 involving a WordPress site is one of the largest (of this type) on record. At 2.6Tb of data, and 11.5 million records stolen, the Mossack Fonseca (the Panamanian law firm embroiled in the #panamapapers scandal) data breach has entered history books as one of the worst (but unfortunately, not the last) – not only for the underlying data that cyber criminals were able to extract and subsequently dump online for the world to see, but the method used to gain access to the site in the first place.
The exploit performed allegedly involved leveraging a known weakness in the WordPress plugin “Revolution Slider”. This vulnerability allowed cyber criminals to obtain remote shell access to the web server running WordPress, allowing for further compromise. In addition, the secure client portal was running version 7.23 or Drupal – another CMS, which at this version was known to contain significant vulnerabilities – in fact, it was so bad that security experts around the world warned users that if they had not patched their systems immediately after the update was released, they should consider themselves as being hacked, and start again with a clean installation. Since that warning was issued in October 2014, Mossack Fonseca would have been running a platform wide open to exploit and attack for around 2 years at least. It would also appear that the same portal was vulnerable to the DROWN attack – a security exploit that targets weak SSLv2 protocols on web servers. In addition, the most notable vulnerability addressed by the Drupal security updates was a SQL injection Attack that would have allowed cyber criminals to execute arbitrary SQL commands in order to extract data. The icing on the proverbial cake was that Mossack Fonseca’s email server was running Exchange 2010 and an equally outdated version of Outlook Web Access. This would have made the extraction of emails (which as it turns out, were not encrypted) easy once the inferior mail platform had been identified.
Lessons learned and recommendations
The need to regularly patch CMS systems such as WordPress is paramount, and no installation should be left for long periods without updates. Failure to do so may render your site vulnerable to compromise. You should also be mindful that any plugins that have not been updated in a long time will more than likely leave your website wide open to attack. How can this be avoided ?
- Only use plugins from a reputable source. Those located on WordPress.org are perfectly fine for production use – provided they are regularly maintained, updated, and security issues addressed quickly and effectively. Do not upload plugins to your site from unknown sources such as websites you are not familiar with
- If a plugin has not been updated in a long time, then you should consider replacing it with another that offers the same or similar functionality, but is subjected to regular review and updates where necessary.
- Despite the plugins on WordPress.org being free, the “freemium verses premium” debate is one that should be considered. In this case, the “free” version may contain limitations, or not receive the attention that it’s premium counterpart would.
- There is no obligation from the plugin author to patch their plugin within a specific time frame if you are using the free version. The paid for version will typically come with additional support, and any identified vulnerabilities addressed quickly, but at a cost.
It is fairly clear from the above that paid for plugins are a better option than their free alternatives. If you purchase a plugin, along with support, then there is a much higher probability that you will receive timely updates to address vulnerabilities and other security risks. On the flip side, some may find the use of paid plugins on WordPress to be an unacceptable choice, or outside of their budget. In reality, there are some excellent plugins that are extremely well written, and they are typically not expensive. WordPress plugins are not the only vulnerability – themes are known to contain vulnerabilities. Choosing a theme that isn’t free will provide you with frequent updates, and also means that if a security issue is reported, it will be addressed quickly. From my perspective, it is much better to pay for active support on all software and hardware than to simply take an unprecedented risk. The software may look good on the surface, but could be very insecure without you knowing about it. The Mossack Fonseca breach highlights not only a need to keep systems up to date from the security perspective, but also the need to invest in information security as a whole.