Slashdot Mirror
WordPress Sites Under Attack From New Zero-Day In WP Mobile Detector Plugin (softpedia.com)
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.
Jimmie Walker
This isn't really news, Wordpress plugins are notoriously insecure. It would be more surprising if someone found one that wasn't rife with vulnerabilities. Fortunately, 10,000 sites is a tiny user base compared to a lot of plugins.
Over 2000 installations! Jesus F. Christ! Just think of the damage this could do.
> 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 allowed admins to upload images. It was the upload that got them into trouble. Upload often gets people in trouble because doing it securely is more difficult than it first appears.
Top ways scripts get owned (avoid these things or be very careful, maybe get an expert to spend a few minutes reviewing these parts of the code):
Uploading files
Running external programs (imagemagick, etc)
Sending email
DOWNLOADING files, often download.php is written for videos.
Of the above, the email one has two pretty easy ways to avoid most hacks. A) Let the user choose WHERE to send the email to, OR something in the body of the email (sent to the webmaster). Never let them enter both a To address and any part of the message. B) Use well-vetted modules, don't pope directly to sendmail.
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 fuck is the upload directory("cache" ???) accessible in any way to outsiders? the readable directory, if it needed such, should only have contained the converted images - and even then it would have been better to have them served through something else than just a fucking directory.
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.
"The team at Plugin Vulnerabilities has discovered that the plugin features an arbitrary file upload vulnerability in the "/wp-content/plugins/wp-mobile-detector/resize.php" file.
This file handles image uploads, and according to the researchers who discovered the security bug, it lacks basic input filtering, allowing an attacker to pass a malicious file that gets uploaded to the plugin's /cache directory.
Using this vulnerability, attackers can upload PHP-based backdoors on WordPress sites, something that should have been almost impossible in 2016, after almost two decades of PHP coding and basic lessons in file upload security."
world was created 5 seconds before this post as it is.
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.
Love sees no species.
> 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 prefer to not have shitty code, in a plugin or anywhere else. After 20 years of professional programming, I've become a bit picky actually. There's not much truly high-quality code written, but we can avoid really crappy code.
> you're also attacking the core functionality of the plugin, so is the story here "plugin built to solve problems in foolish way was designed poorly" ?
Maybe people who don't know much, don't know much. :)
I'm kinda kidding there. People who own web sites sometimes ask for this kind of functionallity. This plugin gave them what they asked for. Maybe allowing the web browser to do it's job and render the page appropriately for the device would have given them what they actually wanted, but the plugin gave them what they asked for, I suppose.
> 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 browser handle that.
Kinda like the people who fill the pot holes in the streets.
With 20 million+ WordPress sites out there and some are even useful and successful, the call to get rid of the platform can only be called hyperbololic drama queening. However, someone stole my wallet three days ago and all my money inside it. I also know others this has happened to over the years I have been alive. I stand before you asking for your help in making wallets and money obsolete. It's just too big of a risk for humanity to allow those two items to co-exists. Better to banish both. Stand with me?
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, the screen resolution, user's font size preferences, etc. My html declared what should be on the page, not how many pixels wide it should be.
The WML and WAP stage was the exception - WML isn't html. It was a different language for feature phones. Smart phones, including the early iphones, could handle the same html that worked on the desktop, on AOL, on WebTV, and on Playstation. (If you used width attributes, which were legal for a only a few months before being deprecated, your html would be problematic everywhere. Even on a "standard" 1024x768 desktop the window wasn't always full size.
So yeah, the year or two of WML and WAP was the time it made sense to have a device-specific web site.
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.
Why doesn't PHP (and other web scripting languages) require the execute bit on those scripts? Surely this would make is considerably harder to inject a script.
Anyone know the reason for this because I can't be the first person to think this?!
The password is "dinamit" not "dinamit,". That's a quite important distinction. Broken XIX-century colonial style needs to die.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
I'm aware that WML wasn't HTML (and indeed, that WAP as a whole effectively replaced everything above the basic transport layer with a stack of its own). Hence working with mobile devices as they were then wasn't just a simple matter of theme switching (and it all became moot quite quickly when the overhyped and underdelivering WAP mostly flopped).
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 apparent that some sites weren't well-suited to phone use. Yes, I know that post-iPhone smartphones support HTML natively, but a lot of mid-to-late noughties site layouts assumed a large-ish screen and didn't look good on phones.
That is, it's more 2009 than 1999.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
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.
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.