Malicious Code in Previously Trusted WordPress Plugins: A New Reality
In case you missed it, three widely-used WordPress plugins were recently found to have malicious code included with recent updates. Display Widgets, Fast Secure Contact Form and SI CAPTCHA Anti-Spam were each removed from the official WordPress Plugin Repository due to SEO spam discovered by users.
One thing each plugin has in common was that they were all previously trusted and generally considered secure. More recently, they were sold by their original authors to a new developer, who used these popular plugins to spread payday loan spam posts. In fact, security plugin company Wordfence recently reported that up to 9 plugins have been found with malicious code added through various means.
While many web designers and developers have become more proactive in securing their sites against typical threats like brute force attacks, etc. – malicious plugins appear to be a whole new ballgame. We’re used to defending against security holes, but not authors who are intentionally trying to propagate malware. And in the case of the plugins mentioned above, immediately updating to the latest version was the worst thing we could have done since that was how the code was installed.
The question now becomes, what can be done to prevent this from happening again?
A Matter of Trust
The team in charge of vetting WordPress plugins in the repository has a really difficult job. There are currently over 52,000 free plugins available and it’s darn near impossible to continually scrutinize each one for security. Why, just think of the sheer amount of updates to those plugins that occur on a daily basis. It’s undoubtedly difficult enough to vet just the new plugins that come in – never mind checking out each and every subsequent update that is released.
Still, we’ll often just trust that whatever we download to our sites is safe. There are always worries about outdated code that would allow a hacker to do some damage – but how many of us ever thought to question the motives of the author themselves?
In the open source community, there is a great deal of good will. Code is shared and improved on a regular basis. There are so many outstanding people who give their time and talents to make the web a better place. While this spirit of giving is a wonderful thing, it also leads to some complacency on our part. We don’t stop to think that someone out there may not really be looking to do us a favor.
Even worse, in this case the attacker took code that had been trusted for years by scores of users and turned into something else entirely. And the truth is that only hardcore WordPress news junkies had any idea what was going on after the fact.
Sadly, it seems to be a reasonable assumption that the vast majority of folks using these plugins have absolutely no idea that they were removed from the repository. If they do notice it’s missing, they may not know why. That’s got to change.
Finding a Way to Warn Users
The issue of a malcontent purchasing a previously-trusted plugin and turning it into a tool of destruction is (hopefully) not a common occurrence. But plugins are routinely removed from the repository and the average user probably will never hear about it.
While the team responsible for the repository has some ideas (here and here, for example) on keeping users better informed, I think it needs to go even further. In my view, security issues like this should be displayed on the WordPress plugin management page within each installation. This is the same area that tells us when a plugin requires an update, and it makes sense that a message could be placed in that same area – perhaps with a link to a more detailed explanation.
It’s understandable that there is concern about just blurting out major security holes or malicious code. That information could certainly be used for the wrong reasons as well. But how does that balance out with the risk of essentially telling no one about the issue?
True, these particular plugins were spewing SEO spam – not necessarily a matter of life and death. But what if something out there starts deleting database tables or spreading ransomware?
We’ve reached a tipping point. There must be a way to disseminate this type of security information to sites that have these plugins installed.
It’s truly a shame that someone took advantage of the trusting nature of the WordPress community. But maybe it’s the wakeup call that we needed to realize that malicious attacks come from both the inside and outside of a WordPress install.
I don’t envy the people who have to make decisions on how best to let users know what’s going on. It seems like no matter what path they choose, there are serious risks involved. But it feels like some sort of action is needed.
If the new reality is that what we install on our websites isn’t always going to be on the up and up, then we need to be informed of any found dangers. For me, this all started with the Display Widgets plugin, which I had installed on a few sites. The Wordfence plugin alerted me to the fact that it was removed from the plugin repository. From there, I had to do some research to find a forum post that explained the situation (and it was not easy to find since the plugin page had been removed).
I work with WordPress on a daily basis and write about it quite often. If I had a hard time finding information regarding this incident – how is the average site owner supposed to find out? It’s a situation that seems untenable for the future.
The post Malicious Code in Previously Trusted WordPress Plugins: A New Reality appeared first on Speckyboy Web Design Magazine.