Online Services

Blog

  • When Your Plugins Turn Against You

    When Your Plugins Turn Against You

    When Your Plugins Turn Against You

    Every day we face countless cases of sites getting compromised and infected by an attacker. From there, the sites can be used for various operations like spam campaigns, malware spreading or simply to damage your SEO ranking among other events.

    The threat may not always come from outside though. There are occasions where we are indirectly the ones responsible for the infection and may never find out until we get blacklisted by a search engine, or alerted of malicious code from our users.

    Continue reading When Your Plugins Turn Against You at Sucuri Blog.

  • New in Wordfence 6.3.11: Abandoned and Removed Plugin Alerts

    On Thursday of last week, we released Wordfence 6.3.11 which included a really exciting new feature: we are now alerting you if you are running a plugin that either appears to be abandoned or has been removed from the WordPress.org plugin directory. In this post, we explain how each of these new alerts work and why they’re so important to the security of your website.

    Abandoned Plugins

    At Wordfence, we define a potential abandoned plugin as one that has not been updated by its developers in at least 2 years. In May, we analyzed the plugins in the WordPress.org repo and found that almost half of them hadn’t been updated in over 2 years. Over a third of them had a compatibility tag for a WordPress version dating back to 2014 or earlier.

    abandoned plugin alert

    The alert we send tells you how long it’s been since the developer updated the plugin, as well as whether we found reference to any unpatched security issues with it and whether it has been tested with the current version of WordPress.

    Why Should You Care if a Plugin Hasn’t Been Updated Recently?

    If a developer hasn’t updated a plugin in two or more years, there is a really good chance that the plugin author has actually abandoned the plugin altogether. An author that has abandoned a plugin is very unlikely to fix any security vulnerabilities that users have reported. No plugin is immune to becoming a security vulnerability on a website, even simple plugins with small user bases. Simply put, the older a plugin’s code, the higher the risk of security issues.

    Let’s look at ways that vulnerabilities happen or are discovered:

    1. Many Plugins Use Software Components That Were Written by Someone Else

    One of our favorite examples is the TimThumb vulnerability that was discovered in 2011 by someone we know quite well here at Wordfence. TimThumb was an image-sizing utility that was included in lots of themes and plugins. Once the WordPress community discovered the vulnerability, all of the theme and plugin authors who had used it had to scramble to release a fix of their own for each of their plugins.

    In the case of an abandoned plugin, the authors wouldn’t likely be available apply a quick fix. To this day, we continue to see attacks seeking to exploit this very old vulnerability on sites that we protect.

    2. WordPress Plugins Function in a Very Dynamic Environment

    WordPress.org publishes core WordPress updates constantly, and  PHP, Apache, Nginx and updates to other plugins and themes are posted at least as often, too. This continually changing landscape represents a security risk over time.

    A great example is the ‘add_query_arg()’ and ‘remove_query_arg()’ issue that GoDaddy/Sucuri discovered two years ago. The issue here was with a WordPress function that plugin and theme developers use to interact with WordPress core. To fix the issue, each plugin developer needed to update their code and push updates. Any plugin author who was no longer paying attention would likely miss this and leave the vulnerabilities in their code.

    3. Security Researchers and Attackers Are Constantly Finding Vulnerabilities

    As of this writing, the WPVulndb website has publicly reported five WordPress plugin vulnerabilities in the last week alone.

    When a security researcher discovers a vulnerability, they reach out to the developer, disclose the details and give them a fixed amount of time to release a fix. Once the author releases the fix, the researcher generally publishes their findings publicly.

    However, in cases where the author does not respond, such as with an abandoned plugin, the researcher will sometimes release the details anyway, giving attackers the information they need to exploit it. The worst case scenario is when an attacker is the first to discover a vulnerability, leaving literally all of the sites running that plugin vulnerable to attack before developers get the chance to release a fix.

    What Should You Do if One of Your Plugins Appears to be Abandoned?

    The best option in this situation is to remove the plugin and replace it with a plugin whose author is actively maintaining the code. If a suitable replacement doesn’t exist and you are a software developer, or know someone who is, it might be possible to assess the risk and potentially decide to maintain it yourself going forward if vulnerabilities are reported.

    Plugins Removed from WordPress.org

    Plugins listed in the WordPress.org plugin directory need to follow a set of guidelines. The list of requirements is long, so there are a wide variety of reasons why the WordPress.org team may remove a plugin.

    One common security reason is that a security researcher has discovered a vulnerability, contacted the author without getting a response, and then contacted the WordPress plugin team about the author’s unresponsiveness. The WordPress plugin team will do their best to contact the author, but if they also receive no response, they will subsequently remove the plugin from the plugin directory.

    It’s important to stress that not all of the reasons for removing a plugin represent something that should lead you to stop using the plugin, but many of those reasons are worth taking into consideration when deciding whether to keep a plugin on your website.

    What Should You Do if the WordPress.org Directory Removes One of Your Site’s Plugins?

    Your first course of action should be to try to determine why it was removed. If you’re able to verify that the plugin was removed for a non-security reason, then it might be okay to continue to use it. It’s a judgement call on your part based on all the information you’re able to gather. If you can’t figure out why it was removed, or you confirm that it was removed due to a security vulnerability that hasn’t been fixed, we recommend that you remove the plugin from your website immediately and finding a well-maintained replacement for its functionality.

    Conclusion

    As we’ve written about in the past, vulnerable plugins are the most common way that attackers compromise WordPress websites. It is critical that, as a site owner, you only install (and keep) reputable plugins on your website, and that you keep them up-to-date and remove them if they are abandoned. The new alerts that we added last week should make that task much easier going forward.

    The post New in Wordfence 6.3.11: Abandoned and Removed Plugin Alerts appeared first on Wordfence.

  • Unwanted “Shorte St” Ads in Unpatched Newspaper Theme

    Unwanted “Shorte St” Ads in Unpatched Newspaper Theme

    Unwanted “Shorte St” Ads in Unpatched Newspaper Theme

    Unwanted ads are one of the most common problems that site owners ask us to solve. Recently, we’ve noticed quite a few requests to remove intrusive “shorte st” ads that they never installed on their sites themselves. My colleague Denis Sinegubko of UnmaskParasites helped to investigate this case.

    Shorte[.]st is a service that hijacks links, forcing visitors to view a page containing ads before they can visit the link they clicked on.

    Continue reading Unwanted “Shorte St” Ads in Unpatched Newspaper Theme at Sucuri Blog.

  • Home Router Botnet Resumes Attacks

    Yesterday at 7pm UTC (noon PDT) we saw the volume of brute force attacks on the WordPress sites that we protect more than double from the average for the previous 24 hours. The number of attacking IPs more than tripled.

    The chart below shows the count of attacks per hour from June 12th onward. You can see a very obvious spike followed by about a 10-hour pull-back, and then another surge almost back to the high we saw with the spike.

    Brute Force Attack Spike June 2017

    We dug into the IP addresses behind the attacks to try to figure out who or what is behind the abrupt surge.

    Home Routers Again?

    Back in April, we wrote about a home router botnet that was being used to attack WordPress websites. Many of those attacks were originating from IPs that had a specific port (7547) open and were running a vulnerable version of remote management software called Rompager. We published a list of 28 ISPs with suspicious attack patterns indicating compromised routers and built a tool that checks if your router is vulnerable. In early May we wrote about that same botnet shutting down.

    In the table below we show the top 20 ISPs by number of IP addresses involved in the latest surge and actively attacking. We also show the average number of hourly attacks per IP. Please note the the average is likely understated, as we accumulated attacks during a four-hour window and did not account for IPs that started or stopped attacking in the middle of the time window.

    Comparing that list to the ISPs with the most new attacking IPs yields interesting results. Of the top 20 ISPs involved in attack surge, all 20 of them were on our earlier list of 28. The IPs are also attacking at low volume, which is consistent with what we saw in April. We also spot checked many of the IPs, and did find port 7547 open on some of them.

    While we cannot be 100% certain that the surge in attack volume can be attributed to the home router botnet we wrote about in April or the attacker that was behind it, the data very strongly suggests it is. We will continue to monitor the attacks and report on anything interesting we find here on the blog.

    How Does This Impact You?

    Most site owners should expect to see a significant increase in password-guessing attack volume, if they haven’t already. We have written at length about how to protect against brute force attacks, including the serendipitous Learning Center article that we posted yesterday, Introduction to Brute Force Attacks. In that article, we mention several steps you can immediately take on your websites to harden your defenses against brute force password-guessing attacks as much as possible, which will make your website really, really tough to break into. The harder it is to guess your username and password and break through your site’s defenses, the greater the likelihood that any would-be hacker will simply move on to a much easier target.

    The Wordfence Premium IP Blacklist responded to the attacks beautifully, growing from 1,444 IPs before the attack to 5,592 three hours later. At the time of this writing there are 6,928 IPs on the list and it continues to grow. At the height of the previous botnet attack there were over 10,000 IPs on the blacklist.

    For those of you who aren’t certain that your site security is up to the challenge, you might consider having our security services team audit your site security. It costs $149 and includes a one-year Wordfence Premium subscription.

    The post Home Router Botnet Resumes Attacks appeared first on Wordfence.