4

As well as being CEO of penetration testing specialists High-Tech Bridge, Ilia Kolochenko is also perhaps unsurprisingly a white hat hacker of some repute. Equally unsurprising is the fact that he has warned that security vulnerabilities in leading CMS platforms such as Drupal, Joomla and WordPress are effectively leaving the security door wide open for hackers to walk through.

Kolochenko refers to the threat posed by old plugins, passwords and extensions as being the 'Achilles heel of popular CMS' and for good reason. High-Tech Bridge regularly tests popular CMSs via the ImmuniWeb online penetration testing service and equally regularly, sadly, discovers vulnerabilities therein. It follows a strategy of responsible disclosure, which I'm all in favour of, whereby any vulnerabilities are reported to the vendor with immediate effect but no public disclosure (other than a broad statement without exploitable details) is made for three weeks. This gives the vendor ample time to do something about it, and should encourage those who are a bit slow off the mark to focus attention on a fix. All without alerting the bad guys as to how to create code to exploit the hole.

This is obviously a good thing for all of us, with many Joomla and WordPress vulnerabilities coming to light this way, and being patched before any damage can be done. Unfortunately, black as well as white hat hackers do the research and it's always something of an ongoing race to find the holes first. The difference being that the black hats are increasingly after the more critical vulnerabilities that can be kept quiet and exploited in a zero-day manner. Meanwhile, all too often, the white hats are left with less critical stuff which (while still being worth catching) has less of an impact on the overall security posture of a platform.

Reading between the lines, the truth of the matter is that the vast majority of holes in the CMS code base, whichever platform you look at, have been found and fixed over the years. Kolochenko actually reckons that 99% of exploitable vulnerabilities in core CMS code fall into this category. So, CMS usage is pretty safe now then? Well, yes, but not 100% so and admins are partly to blame here. Weak passwords and password reuse are right up there at the top of the insecurity tree, along with social engineering attacks against CMS administrators. The compromise crown has to be placed upon the head of XSS vulnerabilities in plugins, made effective because of both the previous weaknesses.

"The main weakness in modern CMSs sites today" Kolochenko argues can be found "in the plugins written and supported by third-parties." He explains that it's not WordPress itself that is vulnerable but rather the WordPress plugins "which are often produced by new coders with little experience in security." Yet this serves us up with something of a catch 22 situation as we realise the potential for insecurity via plugins but have little choice but to use them thanks to a lack of required, often quite site specific, functionality that the CMS platform itself has by default. "By exploiting XSS and SQLi flaws in the plugins, the attacker can get at the admin password same as if he were exploiting these vulnerabilities in the core code of the web application" Kolochenko says, continuing "the problem for the internet is that there are so many millions of WordPress and Joomla websites produced and operated by very small companies or individuals with no training or understanding in security." He has a point, with WordPress itself admitting it has more than 33,000 available plugins with a combined total of 747,619,967 downloads. Sod's Law dictates that a number of these will fall into the Kolochenko risk category. These plugin security flaws, through no real fault of WordPress itself, will make the entire WordPress installation insecure.

So, be on your guard when it comes to choosing and maintaining your passwords. Be on your guard when it comes to choosing what plugins you use, and apply as much security due diligence in this area as you would when choosing the CMS platform in the first place. Be on your guard when it comes to social engineering, and ensure that you are up to speed on the latest phishing tactics in order to avoid falling victim. All of these things come at either no cost or a very low cost to your budget. If you have the money to throw at the problem, then consider using the services of a penetration testing consultancy or an online service such as ImmuniWeb.

As Editorial Director and Managing Analyst with IT Security Thing I am putting more than two decades of consulting experience into providing opinionated insight regarding the security threat landscape for IT security professionals. As an Editorial Fellow with Dennis Publishing, I bring more than two decades of writing experience across the technology industry into publications such as Alphr, IT Pro and (in good old fashioned print) PC Pro. I also write for SC Magazine UK and Infosecurity, as well as The Times and Sunday Times newspapers. Along the way I have been honoured with a Technology Journalist of the Year award, and three Information Security Journalist of the Year awards. Most humbling, though, was the Enigma Award for 'lifetime contribution to IT security journalism' bestowed on me in 2011.

2
Contributors
1
Reply
28
Views
2 Years
Discussion Span
Last Post by iamthwee
2

Too true, even the commercial plugins can suffer from exploits. For example, recently I was using a theme which has the 'revolution slider' and there was a big security exploit with it.

http://blog.sucuri.net/2014/09/slider-revolution-plugin-critical-vulnerability-being-exploited.html

This resulted in someone hijacking my mail server and sending hundreds of thousands of spam mails.

My advice would be, wordpress is great, so you wouldn't want to write your own cms, stay vigilent and update wordpress whenever you can, stay away as much as possible from the free plugins that haven't been fully tested on the wordpress sites.

Generally a good rule of thumb is to see how many times the plugin has been downloaded etc.

Of course the ideal solution would be to write your own cms but again, if you don't know what you're doing you run the same risks...

Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.