34 Comments


  1. Interesting report. My takeaway is if they have this automated tool for WordPress plugins, why not offer it as a service for plugin devs? They already have put in the time to develop it, why not profit from it too? If the cost were within reason for smaller projects, I’d buy. Even better they could offer a litte seal that could be added to plugins.


  2. The only solution is a strict review process.
    There is a a review for plugins published the first time on wp.org, but it is very limited, and since a complete commit history is forbidden(!) on .org, it is very hard to follow all the changes on older plugins. One of the many reasons why I trust GitHub only plugins more. I can read the code better there, there is a real issue tracker, not just a hidden ugly Trac instance, and I can send pull requests to fix those plugins.

  3. Ted Clayton

    We have known all along that plugins are mostly unsophisticated, and could therefore be liabilities.

    But what is the pragmatic, actual record, with respect to various theoretic vulnerabilities of plugins that seemingly could be exploited? Is this in fact occurring?

    Are we indeed taking damage, because of the status of plugins?

    I can’t offer a strong answer to that question. The best I can do is shrug and say; “I sure haven’t heard much about plugin-exploits being a big or widespread problem for WordPress”.

    That question should be front & center in this discussion. We have 10s of thousands of plugins deployed 10s of millions of times. If these codes were actually being used by hostile elements to make merry with WordPress-installations … if they really were handy for the bad guys – would we only now & in this manner be hearing about it?

    Let’s be a little bit real here. Checkmarx has been getting global publicity now for 2 weeks on this story. They did really only minimal research. It has been popular in numerous circles, for years, to flog a trumped-up meme that WordPress is a security-twit … and large numbers of such articles were spun off the Checkmarx report in exactly that manner.

    What is the forensic story on plugins? Are plugins hurting WordPress … or not? It is kinda germane that we have that facet of the situation in view, as we watch these other actors read their lines.


  4. I have documented approximately 428 plugins on .org that have exploitable code since 2011 on my hobby site.

    The vast majority of these are updated/fixed, if they contain SQL/PHP exploits they are generally removed immediately upon notification. I can attest to that.

    These are only plugins that have been reported due a security list with poc’s, the real number of unreported or zero-day is a huge % higher. The reason is simple.. very few people do professional grade security audits on their websites.

    Some fact :

    1. Exploits poc’s are added automatically to exploit tools (wpscan, metasploit. etc, etc). This creates serious “ease of use”.
    2. The reported exploits are scanned en masse by bots, by en masse I mean in the tens of millions of requests and probably more.
    3. WordPress sites are exploited because of some of these plugins, especially File Inclusion and SQL injection.
    4. XSS is by far the most common exploit and is becoming a much more prevalent tactic, it now accounts for most black hat web site activities .

    I also agree with toscho, github is a safer place because the code is easier to read, easy to fork/fix and the social aspect of it creates exposure.


  5. @Steven Zahm – That’s a good question. If they had something like that available, I’m sure it would have been linked to from within the report. But as illustrated in the post, over the years, there have been sites and services based on reviewing code for plugins and or themes and they ended up closing. I wonder if their is better demand for such a service now adays.

    @Thomas Scholz – I’ve been pushing for stricter guidelines since 2009 but then again, I hate seeing more restrictions if it fosters freedom. I don’t want the walls of the repository to grow so large, it keeps everyone out. However, the Apple App store is a good model for what happens when things are strict.

    As far as GitHub is concerned, as I mentioned on twitter and in this post, users have been told and trained to only get plugins from a trusted source and WordPress.org is that trusted source. Now, at an individual level, if I see a plugin hosted on GitHub by a known plugin author, someone I trust, then I’ll download and use it. However, the average joe has been told to stay away from plugins that are not hosted on WordPress.org with the exception of commercial plugins like GravityForms. That is why I said plugins hosted on GitHub only are knocked down a notch on the trustworthy scale. Secondly, I linked to the WPTuts article because it was one of the first that instructed people how to keep a GitHub repository plugin synched with one hosted on the WordPress subversion repository. It’s the best of both worlds for both user and developer.

    On the topic of GitHub only hosted plugins, why introduce that pain of the ass of downloading/upgrading plugins the old fashioned way by uploading zip files. Unless you use a trick that enables automatic upgrades from your GitHub repository.

  6. userabuser

    @Thomas Scholz – If your comment were a nail, you just hit it on the head! The only way to solve all (or very close to all) vulnerabilities with plugins (themes too) is to have a strict review process. Who’s going to foot the bill for that? That’s why Github, or any setup like it, is a better way to maintain repositories of code and have move users and developers, interact and contribute to finding and fixing bugs including vulnerabilities. Trac makes your eyes bleed. WP.org repo needs a format similar to Github or BitBucket.


  7. @Ted Clayton – I’ve reached out to Checkmarx to see if they are willing to participate in either a Google Hangout with me or a recorded Skype call so we can learn more about their process of scanning those plugins on the repository.


  8. Here’s a modest proposal: make the DEBUG constant true by default and force plugin authors to fix their notices/warnings instead of sweeping them under the carpet. Errors should be fixed, not hidden. PHP itself is going that route, getting rid of what was likely the single biggest mistake in the language, ever. WP would be well-served by doing the same.


  9. As plugin’s author in a contributive world, just a humble opinion:
    Since 5 years, plugins repository seems to become more a shop or a factory (with customers) and not a exchange platform or a knowledge library (with people working together). I am happy to contribute to WP core debug or improvement via tracs. I will be happy if for free available plugins, users continue to comment and why not suggest patch… But, perhaps the world is changing…
    Best regards,

    Michel

  10. Ted Clayton

    @Jeffro Here are some aspects of this story that Checkmarx might address:

    1.) The method used to select a sample of plugins for the study is unscientific. By selecting “popular” plugins, the sample is unrepresentative in meaningful ways. Although it is mentioned that the findings are applicable (only) to “the most popular plugins”, what was found out about this special sample is then used to argue for policies that would be applied to all plugin developers, and to plugins as a whole and their role in the WordPress ‘ecosystem’.

    The sample-selection method should have been randomized, etc.

    It is true & valid that the popular plugin codes will affect more websites, but it’s not scientifically legitimate to extend what is found out about popular titles, to unpopular examples as well (which in fact comprise the vast majority of all plugins). Basic observations & inferences about the different liabilities & assets of big-name versus no-name plugins have been recognized & discussed for years … we already know these 2 groups aren’t the same animal.

    2.) The study as originally designed & attempted actually failed. It had to be redesigned, in order to be ‘doable’. The technical inappropriateness of the original approach and the fact that it had to be abandoned (‘Oops – That won’t work!’), gives reason to question Checkmarx’ grasp of this field.

    What is the problem? How did the study fail? As reported at TechNewsWorld:

    Six months ago, [Checkmarx] started scanning just the top 50 WordPress plug-ins.

    “We were overwhelmed by the sheer amount of results,” [founder and CTO] Siman said.

    So the researchers limited themselves to the five most critical vulnerabilities — SQL injection, cross-site scripting, cross-site request forgery, file inclusion and pass reversal.

    “Once we limited ourselves to those vulnerabilities, the results were more meaningful — yet shocking,” Siman said. “We found that 30 percent of the top 50 plug-ins were found to be vulnerable to at least one of the vulnerabilities.”

    Automated security-auditing algorithms & programs have been around for a long time. Folks do continue to invent & patent new specific formulations, but the general idea & field is well-known and of long-standing.

    Allowed to work ‘freely’ (as hackers do), such programs tend to churn out ‘overwhelming’ results. Sure-enough. It’s a foible related to the ‘garbage-in, garbage-out’ phenomenon.

    3.) Checkmarx cannot deliver on their promise. They can neither identify the full range of exploits to which plugin-codes might be subject, nor are they physically capable of performing an in-depth analysis of even the mere 50 top WordPress plugins, much less the inventory of 25,000 titles. They are unable to serve as inspector of the ongoing stream of new plugin-submissions from developers great & small (beyond a misleadingly-superficial degree).

    They can only succeed, eg, by artificially restricting their audit-targets to 6 specified vulnerabilities. They can offer assurances only that code is free of ‘this’ or ‘that’ particular vulnerability … not that the code is free of vulnerabilities & immune to exploitation.

    Checkmarx cannot logistically meet the role they suggest for themselves. Nobody can … and we’ve known this for a long time. It’s a fundamental “combinatorial” problem. There is ‘no end’ of ways that code can be exploited.

    ‘If it was really that simple’, automated security-auditing would long-since have been a cut & dried done-deal. Vulnerabilities would now be a footnote in the history of computer programming.

    The problem is fundamentally similar to that of plugging or denying opportunities to terrorists. That we have our ‘junk’ inspected at the airport does not prevent the bad guys from selecting ‘no end’ of other avenues of attack.


  11. I spoke with Dave earlier today who manages the cloud operations for Checkmarx to talk about the WordPress plugin report. They are interested in sharing more data and answering the many questions people have raised since it was published. I’ll be in contact with them next week to view a demo and possibly get those questions answered. They also hinted at making a scanner available as per the requests of many but they are working together to determine the best way to go about it.


  12. Having a review process is too complex given the sheer amount of code committed. Code automation (Checkmarx) may catch some low hanging fruit but in reality it’s not a solution and actual code auditing is expensive, time consuming and well..no one likes doing it.

    Also a lot of exploits come from bundled scripts (timthumb, jplayer, flash players, etc.) So you are not just liable for a plugins code but a complete 3rd party library ..ya that’s not going to happen.

    Malware prefers quantity over quality, that’s why the top 50 plugins are attacked more often, it’s simply a matter of download numbers. In my stats on wpsecure the popularity of plugins are a non-issue exploit wise. Some plugins have under 1k downloads while other have over 1 million.

    The reality is that websites are audited and not plugins because no one has truck loads of cash lying around to manually audit and find poc’s in hundreds if not thousands of plugins, let alone try and patch them (you can’t even patch a plugin using trac..). Where is the return on that investment?

    Educate the end- users, no one, including WordPress, is going to hold your hand.

    Also I am not particularly interested in any company or person who automates code review, you must provide an actual poc (proof of concept) to be taken seriously.


  13. It’s obvious from looking at my server logs that there are plenty of plugins with vulnerabilities, as evidenced by the constant 404 errors from plugin probing. I have put measures in place to quickly ban IP addresses probing for plugins I don’t have installed, which helps but is not a total solution.

    I wonder if there is something we could do as a community where we voluntarily offer stats of what plugins get probed so that users and plugin creators can get notified when probing for a plugin goes over some threshold? Yes, the horse is already out of the barn at that point, but when the bad guys discover and begin to exploit vulnerabilities this could provide a warning system.


  14. Agree with wycks, without proof of concept the report is about bad coding styles and not about exploits.
    For example there might be an unescaped sql statement which the automatic tool might flag, but if the path to get to that code is available only to the admin of the site then it is not an exploit.

    Not even sure that a different review process will help because in the end of the day it takes an expert to find exploits. githuib might be nicer for use then trac but having 1M developers forking and pulling a specific code doesn’t improve the security of the code if none of them are security experts. If you just needed better version control tools to improve security then by now microsoft etc would not have had any security problems.


  15. I don’t think these results will surprise anyone experienced in security who has glanced through the plugin repository.

    The solution IMHO is education. There should be more promotion of blog posts teaching security basics. Most developers creating insecure code just don’t realise they’re doing it.


  16. This report isn’t one bit surprising to me . It seems that almost every WP plugin I’ve read is vulnerable. This needs to be fixed, so my company started a service where we will scan a plugin or theme for free and try to get the fixed code into the wordpres repo.

    I read your daily plugin posts and sometimes I decide to read the code of the plugin and they usually are vulnerable to being hacked.


  17. Thanks for your notes and comments. We (Checkmarx) are diligently working with industry experts such as Jeff (WP Tavern – Jeffro) to best reveal more extensive results, examples and insight to Checkmarx automated scanning of WP Plugins. As noted by earlier comments, the results are broad and deep, a course of responsible disclosure and tactics is required. Checkmarx engineers researched this topic thoroughly prior to release of the report; our intention is to help secure the internet experience. We hope to release further data in the coming week.


  18. Today I had the chance to participate in a WebEx session with Checkmarx to get a better look at the results of their report. I saw how their scanner works and how it reports different vulnerabilities. In one example, a particular plugin had over 150 SQL Injection vulnerabilities in its code base. A Google search later showed about 182 thousand sites using that plugin. Put 2 and 2 together and you’ve got trouble.

    I’m trying to work with Checkmarx and get the appropriate people involved to see if a partnership can be formed between WordPress.org and Checkmarx. I believe once the right people get to see for themselves just how large of a problem this is, that some sort of action will be taken. There is also the issue of just how to go about releasing their work to the public. If they make the scanner available to the public, then it’s possible that plugins will be scanned and once all of the vulnerabilities are found, will Google search websites using those plugins and begin their hack fest. This wouldn’t make Checkmarx look good too the public. However, going that way may wake up a lot of people and finally demand that something be done about it. Having a secure core is great but why not hold plugins and themes to the same scrutiny.


  19. @Jeffro – Sounds interesting. An automated system to let developers know when their code is detected as malicious could be a really useful learning resource. You couldn’t use it to auto-remove plugins from the repository as there is bound to be many false positives, but just alerting developers to the potential presence of bad code could be enough to solve many of the issues.


  20. @Ryan Hellyer – They did talk about False Positives but they were hoping that by releasing their scanner or tool that developers could contribute to detecting false positives and over time, they would decrease.

    I think a scanner or something like it that a plugin must go through before being accepted into the repository would be the best means of implementation. It would kill two birds with one stone. First, education. And 2, less plugins getting into the repo that are filled with vulnerabilities.


  21. @Jeffro -It is not possible to make a scanner which can reliably scan a plugin, so that wouldn’t work. Something which plugin reviewers use to point me in the direction of security flaws would be a handy tool for them though I imagine.

    The main use I see would be in alerting plugin developers that they may have problematic code. You couldn’t automatically block it based on that though as there will always be perfectly good reasons for doing some things which the scanner may fire off warnings on.


  22. @Ryan Hellyer – What are you talking about? Checkmarx creating an automated tool that scanned the plugins in their report. Doesn’t that prove it’s possible? The scanning would not be done by the plugin author but by the plugin review team. Any code that comes up as an SQL injection point or other type of vulnerability would all be publishing in a report. The plugin author gets the report with the details on which code is causing the flags to be drawn and the plugin is not accepted into the repo until it’s scanned and comes up with a result of 0. No guarantee that everything will be found but damn, it has to be a better situation than what we have now.


  23. @Jeffro -I’ve seen this discussed many times before (on WP Hackers I think) and the consensus has been that it is a bad idea. The problem is that you would presumably end up blocking a bunch of legitimate plugins. There is no way to reliably detect bad code that I’m aware of, you can just take a guess, which is presumably what the Checkmarx scanner is doing.

    I guess you could block everything, and then when someone needs to bypass the scanner for some reason then you could apply for an exemption from the plugin repository team I suppose.

  24. Ted Clayton

    It really is true that scanners of this nature have been around for decades. There are many Patents pertaining to this Art. Indeed, the art has been known & patented for so long, so many times, that patents have for years been expiring, allowing others to then roll formerly-protected art into modified products, and then patenting the ‘new’ art.

    The limitations & foibles of these scanners became well-known, decades ago. Most ongoing art involves attempts to dodge/hide these essential shortcomings.

    If scanners could actually do what is claimed for them, there would be no vulnerabilities. Anywhere. The phenomena of errors & oversights & weaknesses would be simply extinct.
    =====

    Notice that Checkmarx studied the most-popular plugins, and found lots of issues … they did not study dorky plugins, but we tacitly assume – without even looking – that dorkware would be even worse. On this partial finding, we then tend to ask: “Shouldn’t we make standards that all plugin authors have to meet, and establish vetting to ensure these codes are up to snuff”?

    Accomplished programmers would have no problem, getting over a steeper learning-curve and a higher barrier-to-entry. But casual authors and their to-diss plugins would be excluded, rejected and culled, in large numbers.

    For some, getting rid of the low-skill authors & their plugins would be acceptable. “Hey – we gotta clean this mess up”! For others, it would even be desirable; a way to ‘deal with’ unwanted competition.

    But the bottom line on crudnik coders & plugins is … WordPress themselves are obviously protecting the plugin-rabble; has been for years, and show no signs of changing that policy. Any plugin-enhancement solution that incidentally grinds the plugin riff-raff under the wheels of Progress will be unacceptable to WordPress.

    Any suggestions for addressing issues with plugins must make-nice with plugin-hillbillies.

    It is a matter of top strategic importance, that Honey Boo-Boo herself can take a glance at the plugin-scene and snort; “Fiddle. Even I can do that“.

    Plugin-management ideas cannot reject — or even noticeably inconvenience — the inexpert. WordPress HQ won’t have it.


  25. @Ryan Hellyer – I’ve seen those discussions. I guess that’s why it hasn’t been done yet already, it’s a bad idea. At the same time, if even half of what I saw during the scanner demo today was accurate, it’s a depressing state of affairs for plugin security on the WordPress.org repository. I mean, we assumed that the repo contained all sorts of plugins rife with insecure code but to have one plugin with over 150 SQL injection points is shocking to me, even without knowing much about security.


  26. @Jeffro -It’s been like this as long as I’ve been around the community.

    An important thing to remember though, is that just because something has an “SQL injection vulnerability” that doesn’t necessarily mean that it will be present on all or even most sites. The most common examples of dangerous code I see only affect situations in which users have elevated permissions. The best example of this is in multisite where developers often assume that administrators are trusted users. However in a multisite environment where unrestricted site registrations are allowed, those users are most definitely not trustworthy. However, the number of sites which allow unrestricted site registrations is small and (I would hope) their developers should know to security audit everything they’re running on their network. So just because something is an “insecure WordPress plugin”, that doesn’t necessarily mean it will ever cause any problems for the majority of users.

    (I have no idea if the stats Checkmarx is reporting includes users with elevated permissions or not)


  27. @Jeffro What are you talking about? Checkmarx creating an automated tool that scanned the plugins in their report. Doesn’t that prove it’s possible?

    Nope.I already said this but I will be blunt this time, unless you provide an actual poc, no one cares about automated scanning, period.

    Providing a poc has been a standard for decades because it’s the only thing that actually provides proof.

    For example here is the poc for the DDOS 3.5.2 update: https://vndh.net/note:wordpress-351-denial-service


  28. @wycks – You and Ryan both bring up good points. A plugin could be detected to have a bunch of flaws but if you can’t do anything malicious with them, no big deal, right? Or if you can’t prove that what the scanner is detecting is actually a flaw with a POC then it’s borderline meaningless.


  29. On a more positive note I think a scanner could be an educational tool for developers, for example if they are not using input sanitization (built into wordpress or otherwise) it could warn them, or user role based encapsulation.

    It’s possible a plugin reviewer could use this but the amount of time and the vastness of the repository is rather daunting without funding.


  30. In addition for false positives there is also the issue of false sense of security. Just because the scanner said that a code is valid doesn’t mean it is secure.
    For example any code that doesn’t strip tags from input in multisite environment is insecure, but I don’t think there is any way to automatically detect that.
    Different example, I doubt that an automatic tool could have discovered that W3CT and supercache expose private/security info to the public net.

    I think that you have to assume that all plugins are insecure untill you audit them. There might be even a situation in which some plugins are declared secure but a combination of them is insecure

  31. DJ

    “Checkmarx…published a security vulnerability report on the top 50 plugins on the WordPress plugin repository…[and] concluded that more than 20% of the 50 most popular WordPress plugins were vulnerable to common web attacks…”

    Best place to download plugins? “For starters, only download plugins from reputable sources. The most notable is the WordPress plugin repository.”

    Hmm.


  32. Thanks for the eye-opening article. I’m part of a security startup called Prevoty, and we’re new to the WordPress community. We’re really digging the discussion here. With so many third-party themes/plugin vulnerabilities and a constantly shifting ecosystem, we’re prompted to look at creative ways to fill in the gaps.

    Not long ago we released our SmartFilter WordPress plugin, which acts as a preview layer to sanitize all input and protect your site from code injections and cross-site scripting (XSS). Because it doesn’t rely on past signatures, it’s able to understand content in a more modern way and prevent zero-day exploits. We’re then able to give precise analytics on how many rule breaks, violations and injections we handled for you. (You can even live test some of SmartFilter’s functionality with blocks of dirty or malicious code on Prevoty’s website.)

    We’re love to have some WordPress aficionados give SmartFilter a whirl and share valuable feedback. Check it out at wordpress.org/plugins/smartfilter. Please let us know what you think!

Comments are closed.