WordPress Sites Under Attack From New Zero-Day In WP Mobile Detector Plugin (softpedia.com) 50
An anonymous reader writes: A large number of websites have been infected with SEO spam thanks to a new zero-day in the WP Mobile Detector plugin that was installed on over 10,000 websites. The zero-day was used in real-world attacks since May 26, but only surfaced to light on May 29 when researchers notified the plugin's developer. Seeing that the developer was slow to react, security researchers informed Automattic, who had the plugin delisted from WordPress.org's Plugin Directory on May 31. In the meantime, security firm Sucuri says it detected numerous attacks with this zero-day, which was caused by a lack of input filtering in an image upload field that allowed attackers to upload PHP backdoors on the victim's servers with incredible ease and without any tricky workarounds. The backdoor's password is "dinamit," the Russian word for dynamite.
Developer (Score:2)
Well, yeah (Score:2, Insightful)
Re: (Score:2, Interesting)
Try telling that to a Business head who praises how great Wordpress is and how its the only platform they consider to use. I tell all potential customers to stay away from Wordpress and if I'm asked to work with it I tell them I'm not interested in the job *.
I've administered enough cPanel servers to know the extent and damage of wild Wordpress exploits and quite frankly cannot for the life of me understand why it gets chosen as a preferred platform of use.
* Yes I like money. No I don't deal with cheapskate
"Build into" meaning "can't update"? (Score:2)
> Given that a lot of plugins do things that a developer can build into wordpress,
It almost sounds like you're suggesting editing the core Wordpress code, meaning you can no longer update easily to get security fixes. That would, of course, be a very bad idea, especially with Wordpress since it's so dead simple to write a plugin, but write it correctly.
This particular plugin was supposed to switch themes based on whether it's a mobile device or not. Putting aside the 1999 mentality of that, it also all
Re: (Score:2)
something like that should be a core functionality of wordpress and if it wasn't, should be done with css pretty much.
doing it like .. say, slashdot, is an idiots way.
Yep. Slashdot classic is good at 3.5" (Score:2)
> doing it like .. say, slashdot, is an idiots way.
Yeah funny thing is, Slashdot does it both very well and the silly way. mobile.slashdot.org is rather annoying, meaning it was a waste of time for them to build it. On the other hand, if click "use Classic" you find that the old 1990s Slashdot works pretty darn well - regardless of which device. Classic works fine on my little phone, my tablet, my giant desktop screen - mostly because it doesn't presume any particular size or resolution. It lets the
People who don't know, don't know (Score:2)
> So then /you're/ suggesting just write a plugin, which also avoids someone else's shitty plugin's problems.
Yes, I'm saying that if you want to modify Wordpress behavior, that's best done via plugin. From a security point of view, that allows you to upgrade Wordpress as normal. Obviously there are also lots of other benefits to modules, such as plugins, over "wall of code". Excellent support for modules/plugins is a main reason that Wordpress, Apache, and many others are so popular.
Yes, obviously I pre
Re: (Score:2)
This particular plugin was supposed to switch themes based on whether it's a mobile device or not. Putting aside the 1999 mentality of that
1999? Seriously? IIRC back then even regular, non-smart phones were only just starting to become truly mass market, every-man-and-his-dog items, and the mobile Internet- if you can call it that- consisted of a few devices supporting WAP [wikipedia.org], which was meant to be the next big thing but wasn't. Probably because paying per-minute charges to view an extremely limited few lines of content at a time and having to redesign your entire website to support it didn't appeal to many people.
I think you meant 2009 to 2012
WML not HTML. Aol WebTV Playstation, netbook HTML (Score:2)
Think about the difference between HTML and PDF. We already had Postscript, HTML was invented to do something differently.
I watched people build AOL versions of their sites, and WebTV versions, Playstation versions, 800x600 and 1024x768 versions. Designing for a specific size, they may as wellbhave been using Postscript (pdf). Mine never needed any of that because it was built using html as it was intended to be used; the BROWSER'S job is to layout the page appropriately for the size of the window,
Re: (Score:2)
This theme switcher is essentially a continuation of the "mobile version of our site" tactic which became common in the early smartphone era when it became appa
Doing it wrong in 2009 (Score:2)
People did that in 2009 (and 2016), just as they used the deprecated "height" and "width" attributes. Those who did so were doing it wrong. Making a device-specific site was best practice only with wml. "Best viewed in Internet Explorer" or "best viewed on iPad" means you're doing it wrong.
Re: (Score:2)
Kinda like the people who fill the pot holes in the streets.
Whoa (Score:3)
Re: (Score:3)
There's really no danger until there's over 9000 installations.
Re: (Score:2)
Re: (Score:2)
actually it has quite a lot to do with php. first, executing uploaded scripts just willy nilly. that's one, and kind of a php/script thing compared to something else it(whole frigging) could have been written in.
second, the plugin having rights to make more executable/runnable scripts/executables.
third, kind of a php/scripting thing, for example had it been written in java, javascript(gasp) or c++ or whatever where you could/would do image resizing in memory without external scripts and such.
third, why the
Re: (Score:1)
really this I guess is just guessing but the BIGGEST FUCKING PHP THING in it would be to execute .php files from all places if you point a GET to it. and that my friend is pretty much a "php thing". suppose it would contain java .class files in there? or .js for node or whatever? or even .sh? it should get just served up from the "cache" - NOT EXECUTED.
If you send a GET request to a random .py or .pl file, if it's inside of the document root, it gets executed too. It's not just a PHP thing no matter how much you want that to be true. Of course a .class or .sh file won't execute, there is no handler registered in the web server to execute those types of files.
Re: (Score:3)
This has nothing to do with PHP itself. The issue here is a failure to sanitize input and properly check file write-out locations.
It's typical amateur hour crap that you find with any language.
Can Them All (Score:1)
Why don't web server scripts require exec bit? (Score:2)
Anyone know the reason for this because I can't be the first person to think this?!
Re: (Score:2)
Re: (Score:2)
This doesn't help anything because the script they inject the code into already has the execute bit set.
Re: (Score:2)
This doesn't help anything because the script they inject the code into already has the execute bit set.
Erm... no!
They're not uploading the script using SFTP or anything that might preserve file permissions; they're uploading using an existing, insecure, PHP script on the server. That will only allow for the file content and the file name to be preserved, so unless the PHP script explicitly set the file as executable, then it wouldn't be executable. The problem is, right now, it doesn't need to be executable in order to execute!
Re: (Score:2)
Erm.... yes!
They inject code right into the script that already has the execute bit set. It's not uncommon, I've seen it myself.
Re: (Score:2)
They inject code right into the script that already has the execute bit set. It's not uncommon, I've seen it myself.
Looking at this specific example, WP Mobile Detector flaw [pluginvuln...lities.com], I can't see how that would be possible.
Just to recap (mostly for my own benefit to make sure I'm not going mad!), this flaw works by sending a URL to a vulnerable website. The vulnerable website then uses file_get_contents() [php.net] to read the file... it is assuming the file is local, but actually it's a URL to somewhere else. If the server is configured with allow_url_fopen [php.net] then file_get_contents() will perform the necessary HTTP GET to retrieve the con
Bad quoting (Score:2)
The password is "dinamit" not "dinamit,". That's a quite important distinction. Broken XIX-century colonial style needs to die.
Removing the Plugin Helps No One Who Has It (Score:2)
It just makes it no longer appear in the repository. No one gets notified the plugin is insecure, or that it has been removed from the repository at all. It just remains in 100,000 WordPress installations, unmaintained, forever.