
Continue reading Northern Rehab Hosts Coat Drive at DeKalb County Online.
This is the fourth installment in a new series we started last month. You can access previous posts here.
Today’s question comes from Michela in Pordenone, Italy:
Plugins are necessary for enhanced functionality of each WP site but the more plugins we add the higher the risk to potential threats. How can we limit this risk and what can we do to prevent in general these kinds of attacks (through the installed plugins)?
This is a great question. According to survey results we published last year, vulnerable plugins are the top way that attackers gain access to WordPress sites. Reducing your plugin security risk is one of the most important aspects of protecting your site. There are a number of things you can do to limit this risk.
Every plugin you install on your website increases your “attack surface”. You are running more code, so your odds of having a security vulnerability exploited go up. Every plugin you add to your site also represents another developer you are relying on to keep you safe. That includes writing secure code, responding quickly to vulnerability reports and keeping your best interests in mind.
If possible we recommend that you limit your plugin downloads to the official WordPress.org plugin directory. A great team of volunteers manages it, alongside a large community of users and security researchers helping out.
If you need to download a plugin from another site, you can use these tips to help determine whether the site is reputable:

The WordPress.org plugin directory makes it really easy to evaluate plugins by providing a nice summary that gives you almost everything you need. Here’s what we suggest you pay attention to:
You should also periodically review your installed plugins to make sure they have maintained their good standing.
We have written at length about the fact that the best way to secure data is to get rid of it. The same concept applies to WordPress plugins: removing plugins reduces your risk.
Security vulnerabilities are constantly being discovered in WordPress plugins. In many cases, the details of the vulnerability will be made public, meaning that the entire world is given the information necessary to exploit the security vulnerability. In fact, the large majority of attacks we see on WordPress sites are attempts to exploit well-known security holes, some many years old. Instead of looking for new vulnerabilities, attackers look for site owners who don’t keep things up to date. Unfortunately, they continue to have success. You can stay ahead of the curve by simply keeping things up to date.
Many plugins like Wordfence include an auto-update feature. You should enable this in as many plugins as you can. For those for which you can’t, you should update to the latest version as soon as possible, especially if it includes a security fix.
Have you ever started a project or hobby and gotten bored with it? That happens to WordPress plugin authors, too. In fact, it happens a lot. Back in May we wrote a post about abandoned plugins and found that, at the time, over 46% of plugins had not been updated in over 2 years.
Does that mean that they include a security vulnerability? Most likely not. What it does mean is that they represent a much higher risk than actively maintained plugins. We recommend that you not run plugins that haven’t been updated in over 2 years.
Another risk to keep an eye on is plugins that have been removed from the WordPress.org plugin directory. There are many reasons why the WordPress plugin team might remove a plugin, including having a security vulnerability that hasn’t been fixed. Since their policy is to not disclose why they removed a plugin, we recommend that you immediately remove plugins from your site that are removed from the WordPress.org directory.
This spring, we added a feature that alerts you when plugins have been abandoned or removed from WordPress.org.
Every now and then an attacker will discover a zero-day vulnerability in a WordPress plugin and start attacking sites. In these cases, if you are unlucky enough to be running the vulnerable plugin, having the latest version installed will not help protect your site. That’s where a web application firewall, or WAF, comes in. Web Application Firewalls examine the traffic hitting your site, filtering out malicious requests.
The Wordfence firewall includes a robust set of protections against the most common attacks on WordPress websites. These include SQL Injection, Cross Site Scripting, Malicious File Uploads, Directory Traversal and many more. In addition, when a new security vulnerability emerges, our security analysts quickly develop code to protect for that specific threat in the form of a “firewall rule.” These firewall rules are deployed in real time to Wordfence Premium customers via the Threat Defense Feed. Free sites receive them 30 days later.
We wrote in depth about about how the Wordfence firewall works earlier in the year.
As a WordPress site owner, managing your plugins is a critical component of keeping your site safe. Understanding the risks and actively managing them is an ongoing activity. By using careful criteria in selecting which plugins to install, keeping your existing plugins updated to the latest versions, and using a robust web-application firewall on your website, you can ensure that you’re doing everything you can to protect your site data from malicious attackers.
How do you choose what plugins to install on your site? How do you evaluate which plugins are safe? We’d love to hear your thoughts in the comments below.
The post Ask Wordfence: How to Limit Security Risks From Plugins appeared first on Wordfence.
The WordPress plugin repository recently removed a plugin known as “Animated Weather Widget by weatherfor.us.” We dug a little deeper, and it appears that the plugin was removed for including JavaScript code that would mine cryptocurrency using the CPU resources of site visitors.
It works as follows:
This allows the plugin owner to earn money by using the CPU resources of visitors to sites using the “Animated weather” plugin.
The following is a screen capture from a debugger showing an iframe that loads from the www.weatherfor.us domain. In this, we show the JavaScript that loads the CoinHive code that actually does the mining.
While researching this post, we found that visiting a site that includes this plugin’s CoinHive Monero mining code generates a huge amount of CPU usage. This becomes audible when your CPU fans all increase their RPMs. I’ve included a short cellphone video below to show the effect.
Two months ago, the Showtime websites showtime.com and showtimeanytime.com were found mining cryptocurrency. It is still unclear whether they were hacked, or if they placed the code there voluntarily. Other websites like The Pirate Bay have added the CoinHive Monero mining code to try to earn additional revenue. Earlier this month, CoinHive mining code was discovered on the UFC website UFC.tv. It is unclear whether they were hacked or if they placed the code on the site themselves.
I reached out to the WordPress.org plugin repository maintainers, and Otto had this to say regarding this plugin:
“Yes, the plugin was removed because the site it connected to, weatherfor.us, started putting hidden mining code in their widgets. The plugin itself was not altered in any way, it was the site which it gets the widget from that had this code added.
Currently, we treat hidden insertion of any undisclosed code as potentially malicious, and crypto-mining is not an exception to this general principle. If a plugin that is unrelated to such activities is modified to include that code, then we will remove the plugin and potentially remove the offending code ourselves, to protect users.
In the same way that plugins are not allowed to, say, insert hidden advertising on sites in a way that benefits the plugin author, plugins are not allowed to insert hidden code in a way that benefits the plugin author. Which is to say that plugins are not allowed to include any form of crypto-mining code which pays back to the plugin author.
That said, a plugin that is explicitly intended for a site admin to include a crypto-miner on their site is allowed, and there’s a few of them in the directory already. The important difference is that these are not hidden, and do not pay the plugin author. The site owner is the one operating the miner, not a plugin author doing it on their behalf.”
What has become clear to me during the past two years is that WordPress plugin authors experiment with a wide range of business models. This leads to plugin authors embedding code that may produce spam on websites, selling their plugins to shady individuals, and in this case, using web browser resources to earn income.
Perhaps if we provided clear guidance and mentoring within the community for plugin authors on how to earn a living from their plugins, this issue would not be as prevalent. I can’t help but think of the Apple App Store and similar models, where a clear business model with clear guidance has created a healthy ecosystem and funding to root out bad actors.
Have you experimented with putting CoinHive mining code on your site? Or have you visited a site that was mining? What was your experience? I’d also like to learn more about our community’s views on plugin business models. I’ll be around to read and reply to your comments.
~Mark Maunder – Wordfence Founder & CEO
The post WordPress Plugin Banned for Crypto Mining appeared first on Wordfence.