Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Security Communications Privacy The Internet Technology

Backdoor Found In WordPress Plugin With More Than 200,000 Installations (bleepingcomputer.com) 84

According to Bleeping Computer, a WordPress plug that goes by the name Display Widgets has been used to install a backdoor on WordPress sites across the internet for the past two and a half months. While the WordPress.org team removed the plugin from the official WordPress Plugins repository, the plugin managed to be installed on more than 200,000 sites at the time of its removal. The good news is that the backdoor code was only found between Display Widgets version 2.6.1 (released June 30) and version 2.6.3 (released September 2), so it's unlikely everyone who installed the plugin is affected. WordPress.org staff members reportedly removed the plugin three times before for similar violations. Bleeping Computer has compiled a history of events in its report, put together with data aggregated from three different investigations by David Law, White Fir Design, and Wordfence. The report adds: The original Display Widgets is a plugin that allowed WordPress site owners to control which, how, and when WordPress widgets appear on their sites. Stephanie Wells of Strategy11 developed the plugin, but after switching her focus to a premium version of the plugin, she decided to sell the open source version to a new developer who would have had the time to cater to its userbase. A month after buying the plugin in May, its new owner released a first new version -- v2.6.0 -- on June 21.

Backdoor Found In WordPress Plugin With More Than 200,000 Installations

Comments Filter:
  • I have pretty much given up at the idea of any somewhat ok CMS. They all are terrible, insecure, or take 6 months to figure out how they work for experienced programmers with clients who want things done yesterday. Drupal was such a nightmare that I never bothered to learn.

    It seems easier to write your own code than to use such a system.

    Wordpress is a joke. Easy to use but inpractical and a great example why you need an I.T. department to monitor and keep things upgraded.

    • by Khyber ( 864651 )

      Try Kirby CMS.

    • Agreed.

      I built my own lightweight framework that I use for my clients projects.

    • by Dynedain ( 141758 ) <slashdot2.anthonymclin@com> on Wednesday September 13, 2017 @09:13PM (#55192607) Homepage

      I think it's a tradeoff. Do you need blogs, commenting, authentication, permission systems, easily updatable content by non-technical users, etc? For example, rolling your own authentication system is easy. Rolling your own that isn't vulnerable to DDOS and SQL-injection attacks is a really hard problem that people have already solved within most frameworks or CMS systems. In this case, a CMS might be worthwhile. However, ff you just need a couple of static pages that don't require regular changes, then skip it. But if the client can't be bothered to spend the money and time for regular maintenance and security patches, then they should just be directed to a WYSIWYG end-to-end system that offers the whole thing as a managed service.

      • by Billly Gates ( 198444 ) on Wednesday September 13, 2017 @09:27PM (#55192681) Journal

        I think it's a tradeoff. Do you need blogs, commenting, authentication, permission systems, easily updatable content by non-technical users, etc? For example, rolling your own authentication system is easy. Rolling your own that isn't vulnerable to DDOS and SQL-injection attacks is a really hard problem that people have already solved within most frameworks or CMS systems. In this case, a CMS might be worthwhile. However, ff you just need a couple of static pages that don't require regular changes, then skip it. But if the client can't be bothered to spend the money and time for regular maintenance and security patches, then they should just be directed to a WYSIWYG end-to-end system that offers the whole thing as a managed service.

        There is Django and several frameworks that are easy to learn and fairly secure if you know what you are doing. How many sites need all these things CMS provides? If they do then a complex monster like SharePoint might be useful but these are small unless you work for a fortune 500 company.

        The people who use Wordpress are small business owners and most customers who want something cheap to setup and forget. Wordpress is defective by design as it doesn't auto update and have all the plugins auto update and be 100% compatible with itself. The whole thing is defective by design as 75% of the people who use do not have an I.T. department unlike those who work with these monster CMS packages and even if they do have an I.T. guy or two they never will check Wordpress as the boss might be pissed if the update breaks something etc.

        • some people with word press don't get shell / ssh to the server. So the small business who does not want to pay for that (added costs at some hosts)

          And they need to make edits without waiting for some managed service to make even the very small changes.

        • by Anonymous Coward

          HTML is also quite cheap and simple to setup, and simpler if it can be exported from a document editor (especially if that document editor can meaningfully handle multiple pages). If someone happens to have a decent website hosting service (one which updates software and keeps unrequested features disabled), that very simple solution is pretty unlikely to cause security problems.

          If the website is mainly to promote a small business and provide contact information, with maybe an occasional blog post, chances

        • by Tablizer ( 95088 )

          How many sites need all these things CMS provides?

          Typically you use only a small subset, but the hard part is knowing what you'll need in the future. WordPress's large catalog means you are fairly likely to find a plugin close to new feature requests. It's the network effect in action. PHB's and marketers will often see something on a trendy site and go into me-too mode.

          • How many sites need all these things CMS provides?

            Typically you use only a small subset, but the hard part is knowing what you'll need in the future. WordPress's large catalog means you are fairly likely to find a plugin close to new feature requests. It's the network effect in action. PHB's and marketers will often see something on a trendy site and go into me-too mode.

            Nope PHBs do not care beyond the next quarter and right this minute. Technical debt is not debt as IT is a cost center etc. Just whip something up quick or they will wonder why they are paying you if another guy can get the job done quicker etc. Then when they want more (most of the case not) you can worry about that problem.

            I have not seen anyone say hey can you spend a full year or 6 months on the ultimate end all to be all which we will use for a decade with a long term strategy etc. HA! Most of the time

      • by Dracos ( 107777 )

        Has it been 6 weeks since the last WordPress exploit was reported? That shit runs like clockwork.

        WordPress is not a CMS, it's a blog script playing dress-up. It was lousy code when it was first vomited forth in 2004, and having not changed much since, is utterly horrendous code now.

        I say things like that often, and from experience I know that the only defenses of WordPress that ever get offered are argumentum ad populum canards, "it's so easy" (you chose it for yourself, not based on client needs), and "I

        • by 404 Clue Not Found ( 763556 ) * on Wednesday September 13, 2017 @09:51PM (#55192779)

          It's not 1980 anymore and coding is commonplace, and with it, bad code. Still, writing bad code is job that pays the bills for a lot of people who couldn't do better. Wordpress is the fast food of web development... cheap and crappy, but available everywhere and easy to hire/fire for. For most of its uses (blogs and small biz sites), the cost of a Wordpress hack and the subsequent cost to fix it or even re-create the whole thing again from scratch is probably still several times cheaper than hiring a "proper" web developer to do it the right way from scratch and with modern security best practices.

          So your Wordpress site gets hacked and replaced with ISIS spam or whatever, ok, you fix it and move on. One would hope that valuable customer information is stored in a separate system, usually managed by a payment provider or Mailchimp and such. The visible website is just an information portal.

          There's a market for enterprise-level security (which still gets hacked), a market for managed small-biz websites (squarespace, wix, etc.), a huge market for Wordpress, etc.

          Most people would rather choose convenience and cheapness than perfect security...

          • by Billly Gates ( 198444 ) on Wednesday September 13, 2017 @10:10PM (#55192827) Journal

            Outside of silicon valley not everyone knows code. That is the problem. People read a book or remember doing a hello world in HTML with Netscape back in the day and assume it is easy and uncomplicated and do not understand what is at stake and how the whole computing stack from the application layer down to the network and physical work and interact. Just because some sweet .com sites work like magic means it was easy and simple to develop.

            There is a market for those who buy template sites from hosts. They should stick with that if they do not know what they are doing or want to pay someone to develp and maintain.

          • by Dracos ( 107777 )

            The vast majority of people who deploy WordPress sites don't know a damn thing about development. They charge an unsuspecting rube $1200 or more to spend an afternoon configuring plugins and spending $50 on a theme. They don't know anything about code, server management, or anything actual developers would know.

      • by AC-x ( 735297 ) on Wednesday September 13, 2017 @11:49PM (#55193091)

        [Avoiding] SQL-injection attacks is a really hard problem

        NO! Avoiding SQL-injection vulnerabilities is a basic part of website coding and extremely easy to do [owasp.org], there is no excuse.

        • Mod parent up!

          If you can't write a database-backed app that always uses prepared statements for every single insert, update and where clauses, in this day and age, you have no business releasing it, even internally. This is basic DB-related knowledge. It is trivial to prevent, with any effort at all.

          • I replied to parent, but there is a trick with MySQL--you can call the parameratized api call, but most MySQL drivers will convert this into raw SQL. In Wordpress, the internal api call to use a parameratized query will do this--on the wire and on the database, it is as if you never did this from a security point of view. I know as my company makes a product that can add a security layer to Wordpress between it and the database, and only for a few rare plugins did we have to support parameratized calls to

            • by AC-x ( 735297 )

              For anyone following up this part of the thread, see my reply here [slashdot.org]

              • The fact that the debate in this thread is happening proves my point. Yes, people should be trained to do paramertized queries. But SQL-injection is just one of many potential security flaws that takes time to learn, understand, and ensure you follow best practices to avoid the security risk. Well-supported frameworks most likely have already gone through those growing pains and have the benefit of many-eyes. Something your roll-it-myself solution most likely would not have.

                • I don't disagree with using frameworks, but you specifically claimed that parameterized queries are still vulnerable to SQL injection. That's a very big accusation with huge implications, did you mean to make that claim or did you actually mean something else?

                  Even if you are using a framework if you're working on an even slightly serious project you'll likely need to make your own db calls sooner or later...

                  • Re-read the thread and who the authors are of the various comments. I never said anything about parameterized queries being subject to SQL injection.

        • Parameteritized queries against MySQL are often converted into non-parameratized queries for performance reasons. This is the DEFAULT behavior of most MySQL drivers. Most programmers don't even know it is happening behind the scenes, and the protection they thought they have is lost.

          • by DarkOx ( 621550 )

            Most programmers don't even know it is happening behind the scenes, and the protection they thought they have is lost

            Some of the protection they thought they had is lost. Most the bugs at the driver layer are pretty well shaken out because they are so widely used and well tested. While its not impossible, Its still pretty unlikely.

          • by AC-x ( 735297 )

            I'm going to need a citation for that, because PHP's MySQL driver doesn't behave in that way and I can't imagine anyone else's MySQL driver being worse.

            Not to mention a Google search reveals nothing and it would be a pretty common complaint if parameratized queries regularly broke when dealing with the ' character.

    • It seems easier to write your own code than to use such a system.

      I've been down that road, but managers kept asking for additional features that were readily available in existing CMS's or their pluggins. I spent a lot of time re-inventing the wheel and was always behind.

      I'd like to see more "generative" systems that generate static HTML from a CMS and uploaded automatically and periodically via a one-way FTP connection. (The internal draft may be dynamic.) It's harder to hack static HTML. I know generative

      • The flaws in Wordpress are often over-stated. Sometimes you'll get a headline about a horrible Wordpress flaw, like this one that hurt over a million installations [slashdot.org]. Then you dig in, and actually you needed a rarely used feature to be enabled, and even then, it didn't allow you to inject SQL, at best it allowed you to see more images in your query than you should have. So the actual damage was very minimal.

        I do like your idea of a statically generated site. That is a good way to avoid security flaws in man
        • by Tablizer ( 95088 )

          If you only put public-intended material on your Internet site, then there are no secrets there to steal. (Disable versioning also, relying on only off-server backups.) Vandalism would be the worse case, assuming you don't leave some loose FTP or network path back to your internal systems.

          • Even vandalism is not possible with the particular vulnerability I linked to. The headlines were all hyperbole. 'Security' companies try to make any exploit they find seem as bad as possible to raise the profile of their company. That's why you see exploits with logos, too [wikipedia.org].
      • 'd like to see more "generative" systems that generate static HTML from a CMS and uploaded automatically and periodically via a one-way FTP connection

        This is what Jekyll does and it's supported by GitHub pages. It's very easy to set up so that a post-push git hook regenerates the site and sets the permissions so that the web server process can read it but can't write anything in that directory. The down side is that you don't get any dynamic content (comments and so on). I've never been quite motivated enough to write a comment system that stores everything in an append-only log and has write access to precisely that one file, so if it's compromised y

        • I've never been quite motivated enough to write a comment system that stores everything in an append-only log and has write access to precisely that one file, so if it's compromised you can always just roll back to the last pre-compromised state.

          It probably makes more sense just to embed someone else's comment system at that point, even if you're hosting it, only separately from your main site.

      • I'd like to see more "generative" systems that generate static HTML from a CMS and uploaded automatically and periodically via a one-way FTP connection. (The internal draft may be dynamic.) It's harder to hack static HTML. I know generative CMS's exist, but they never caught on for some reason.

        Actually I'll bet this would be rather easy to do with wget or curl or something.

        • by Tablizer ( 95088 )

          Wget usually uses FTP, doesn't it? Either way the concept is similar: on a timer or special request, new and changed files are uploaded and obsolete ones deleted via a preset process that checks date stamps. The system has to make sure they stay in sync with the internal (staging) version. Maybe once a week a total refresh is done to cover any gaps.

          As somebody pointed out, certain dynamic features like blogs and discussion groups probably won't be timely enough this way, but if it's only a small portion o

          • wget downloads over http. It might have ftp options too, I don't know. Once you build your website in Wordpress, and say you have it running on port 8000, you can run something like this:

            wget -r -np -k http://localhost:8000/ [localhost]

            It will recursively download all the files statically into a directory in your current directory. Then you can upload that to AWS or wherever. You could even make it a cron job, so it updates every hour or something.

            If the client insisted on using Wordpress dynamically from the
            • by Tablizer ( 95088 )

              For non-trivial sites, you probably don't want to re-generate the entire site each time. Also, that may not remove old content properly. Typically a site has images and PDF's also. Some kind of file "delta management" is in order to only mirror what was added, changed, or deleted since the last pass. Delta-based replication is hard to be easy, efficient, and reliable at the same time.

              • If it's static, it's trivial :)

                Once it's 'downloaded' locally, then only uploading the changed shouldn't be too hard using rsync (or similar). There are probably other tools you can use too. I'm going to experiment more with this later, but this is a good idea, thanks for brainstorming it with me. I wouldn't have thought of it if you hadn't suggested it!
                • by Tablizer ( 95088 )

                  Sites for medium or large orgs can have several thousands of files. I don't see how a simple tool can scan & compare those in a timely manner. Managers like to see some changes show up pretty quick. There may need to be a "quick mode" and a slower but more thorough clean-up mode/process, like a nightly batch.

                  • Sites for medium or large orgs can have several thousands of files.

                    Several thousand files is nothing on a modern CPU, and you know it. Even diff -rq [directory] will quickly scan through a hundred thousand files.

                    • by Tablizer ( 95088 )

                      But you have to transfer that info from source to the destination server. The CPU is not the bottleneck.

                      Take server A and server B with only an SFTP connection between them. How do you know what is different between them, in terms of the web content folder tree?

                      I agree most of the time we only need to send a "delta set" of changes, but there should be a consistency check at least once a week because bleep can happen. If we over-complicate the info exchange between the servers, then we have the security prob

                    • rsync does that quickly and well (faster than sftp), and it will do incremental updates, too.
                    • by Tablizer ( 95088 )

                      I'm skeptical, it's a lot of info about files that needs to transfer.

                    • *shrug* It's kind of the problem that every web company everywhere faces. In the worst case, you could keep a local copy, write a script to check for changes against your new revision, then upload anything that changed.

                      I'm willing to bet AWS has some support for something like this too, but I'll have to verify later when I have time to play around with this problem.
                    • by Tablizer ( 95088 )

                      *shrug* It's kind of the problem that every web company everywhere faces.

                      No, most use dynamic CMS's, the very things we were looking to avoid in this thread. Some CMS's do have dynamic replication built in, but somebody had to build them in, and it only partly solves the security problems we were trying to avoid by going static-file.

                      In the worst case, you could keep a local copy, write a script to check for changes against your new revision, then upload anything that changed.

                      Worse case? We want timely file

                    • We're talking about uploading a bunch of static files here, it's not rocket science. Despite the potential for problems, it's still better than running Wordpress straight. Obviously it would be better if this capability were built directly into Wordpress, but obviously it's not (unless you disagree with that point).

                      Anyway I'll be experimenting with this because I think it's such a good idea. It should work with large data sets, and the code required to implement it should be short.
                    • by Tablizer ( 95088 )

                      It's not a one-shot upload, you have to keep them in sync with the expected files, and not leave old stuff floating around for Google to keep listing. The boss won't care about how much safer you are over WordPress if his/her Big Important Page is not up or missing updates.

                      Sure, one can slap scripts together to get it 99% in sync, but 99% is not always good enough. Reliable replication over limited bandwidth is not a trivial problem.

                    • but 99% is not always good enough.

                      Yes it is lol, don't kid yourself. We're talking about systems built on Wordpress here.

      • There's plenty of frameworks and libraries to do that. Also, if you separate your content authoring servers from your content publishing servers, you usually get that (Drupal, WordPress, and many others CMS platforms can easily be setup this way. AEM for example (very very expensive) works that way by default). This only protects against certain types of attacks of course. For example, there's no way to inject SQL through a Wordpress flaw if your public-facing publishing server only has read-access to the d

    • by jbn-o ( 555068 ) <mail@digitalcitizen.info> on Wednesday September 13, 2017 @10:23PM (#55192861) Homepage

      This situation doesn't back up your point at all. Technical considerations about features and what's easy to learn versus hard to learn are remarkably subjective. What's objectively clear is that Sharepoint (a proprietary CMS) doesn't allow users to inspect what it's doing, alter the code, or share improved versions. Any problems with Sharepoint have to be fixed by the proprietor (Microsoft), and a backdoor in Sharepoint may well not be viewed as something that needs to be "fixed" from the proprietor's point of view.

      WordPress, by contrast, respects a user's freedom to run, inspect, share, and modify. Site owners can decide how much time and effort they want to put into keeping their WordPress install secure. If they find a problem, improvements can be vetted, shared, and completely understood. The limits of review and improvement are the site owner's to choose and site owners retain the freedom to fully control their site (so long as they host on free software systems). Even bad free software (for any definition of "bad") is better than nonfree software because users have software freedom. Writing one's own code would grant one the freedoms only Microsoft gets with Sharepoint.

      It's not fair to WordPress to conflate a WordPress plugin with WordPress itself ("Wordpress is a joke") or being horribly vague about what is so bad about various free CMSes. WordPress can't take responsibility for what others put in their WordPress plugins. They can only delist the malware plugins and describe why users shouldn't run that plugin downloaded from another source.

      Finally, your point fails to describe how this particular WordPress plugin is critical to useful WordPress sites. This matters to WordPress' main audience—nontechnical users—who might want to know why they should not want particular functionality the plugin ostensibly delivers, or how to get comparable functionality another way. Lots of users aren't technical and won't know why they shouldn't install a bunch of plugins, or how to vet the plugins they find provide genuinely necessary functionality (including not blindly accepting every upgrade but vetting the changes along the way). I don't like malware either, but it's not fair to conflate software freedom with non-freedom (as if nonfree software was inevitable or just as reasonable a choice, an alternative), or to blame one party (WordPress in this case) for another' choices, and objections are far more useful when they are specific.

      • It's not fair to WordPress to conflate a WordPress plugin with WordPress itself

        The difference between Wordpress and other CMSes (like Drupal) is that their official repo [wordpress.org] has repeatedly served malware.

    • Drupal was such a nightmare that I never bothered to learn.

      What version? I've been using it a long time, and it's come a long way, although it's always been pretty spectacularly easy to come up with a simple site. What's tough is migration between major versions, if you use many modules.

    • It's not a CMS issue. It's a shit code issue. The more accessible you make software, or a programming language, the lower the barrier of entry is, and the more programmers get involved, no matter how crap their skills are. Wordpress is one of, if not the, single most popular blogging software available because it's so easy to set up and extend.

      And as can be expected, it has a ridiculous number of half-assed poorly written plugins that by all rights should never have seen the light of day. If they did so

    • I've been impressed with Grav as of late. No database to worry about, all done in flat files using Markdown. Very nifty and nowhere near as insecure as Wordpress

  • Old domain names are often bought to be used by spammers, as I understand the domain names have a good reputation behind them and can be used to exploit reputation based spam filtering.
    Same here with old WordPress plugins being bought and used to install backdoors in people's sites. One can assume that a tried-and-true plugin would be implicitly trusted which makes this case more unsettling.
    I'm sure the WordPress team will be looking at ways to avoid a repeat, but I wonder: could WordPress site owners co
    • by raymorris ( 2726007 ) on Wednesday September 13, 2017 @10:48PM (#55192923) Journal

      > Could WordPress site owners could do more to protect themselves?

      Here are three suggestions.

      1. Do not have plugins installed that you don't use. A large percentage of Wordpress hacks that I have investigated involve plugins that are no longer in use. The only software that is guaranteed to not make you vulnerable is software you have not installed.

      1b. As a corollary, if most of the features of Wordpress are things you are not going to use, do not install WordPress. Smaller, simpler code we'll have fewer vulnerabilities.

      2. Hacks, either built-in back doors or simple vulnerabilities, tend to use certain PHP functions such as which can execute external commands, such as exec() and popen(). These can be disabled in php.ini. Disabling these functions will prevent hackers from using them, and they tend to indicate poor quality code anyway. If disabling these function stops the script from running, it *may* have been a poor quality script to begin with.

      3. Tools are available to scan PHP code looking for suspect portions. These tools can also look for functions such as exec() or popen which should be looked at to see if they may be either venerable or back doors.

      Somebody may say that they use a exec or popen either to retrieve web Resources with wget or to run the imagemagick binaries. It's a better idea to use PHP's built in HTTP functions and to use the imagemagick API via the imagemagick extension. The imagemagick binaries are the UI, the USER interface,to imagemagick. Applications should use the application programming interface or API, not the UI.

      • by Anonymous Coward

        Working as a systems monitor at a webhost for ~2 years, about half of the accounts that we suspended were mismanaged WordPress installs. Of those, perhaps 3/4 were people attempting to do SEO "blogs" on overcrowded shared servers (with shared IPs, good luck with that). Most common issues were... database abuse trying to wrangle million pages of "content", network/worker process abuse trying to ingest "content" from the greater internet, and search engines suddenly attempting to index said "content". Comment

  • by Anonymous Coward

    Bait and switch behavior when a company builds a good reputation for trustworthy software then sell it to an untrustworthy company to exploit that trust are a real problem: LavaSoft Adaware did the same thing!

    > Stephanie Wells of Strategy11 developed the plugin, but after switching her focus to a premium version of the plugin, she decided to sell the open source version to a new developer who would have had the time to cater to its userbase.

    LavaSoft Adaware used to be a trusted antimalware program but it

  • ... for their disaster response site after their massive data breach?

    Why, yes, yes, they did!

    https://krebsonsecurity.com/20... [krebsonsecurity.com]

    At what point do they declare the foot completely blown off and stop shooting?

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...