Slashdot Mirror
Attacks On WordPress Sites Intensify As Hackers Deface Over 1.5 Million Pages (bleepingcomputer.com)
An anonymous reader writes: "Attacks on WordPress sites using a vulnerability in the REST API, patched in WordPress version 4.7.2, have intensified over the past two days, as attackers have now defaced over 1.5 million pages, spread across 39,000 unique domains," reports BleepingComputer. "Initial attacks using the WordPress REST API flaw were reported on Monday by web security firm Sucuri, who said four groups of attackers defaced over 67,000 pages. The number grew to over 100,000 pages the next day, but according to a report from fellow web security firm WordFence, these numbers have skyrocketed today to over 1.5 million pages, as there are now 20 hacking groups involved in a defacement turf war." Making matters worse, over the weekend Google's Search Console service, formerly known as Google Webmaster, was sending out security alerts to people it shouldn't. Google attempted to send security alerts to all WordPress 4.7.0 and 4.7.1 website owners (vulnerable to the REST API flaw), but some emails reached WordPress 4.7.2 owners. Some of which misinterpreted the email and panicked, fearing their site might lose search engine ranking.
I could harsh on PHP until the cows come home, but that would be annoying. So I'll just say that this sort of security problem shows that it's impractical to write anything secure in PHP. Why? Mainly because it adds a layer of complexity atop compiled binary, and it adds source code access once a hacker has got past a certain level, and... oh, it's just all kinds of insecure.
Just why did PHP become so popular, anyway? I really don't see the attraction. Now WordPress would be a wonderful thing, if only they'd ditch the PHP. It would be a little harder to customize and extend, but far from impossible. Worst case, we could supply a scripting language ONLY for custom extensions. Basically a macro language. Python's embeddable.
(No, I don't consider a widely used API to be a custom extension. That's part of the core.)
More opinion: in a production system, scripting languages and macros should be only for custom extensions, and never for core code. There should never be scripts BEHIND an API. If WordPress were written in a compiled language and run as a binary, it would be less easy to hack. But not C. Those damn pointer arithmetic exploits...
Couldn't resist.
I tried WordPress for a while, and I tried some PHP coding. I'm a tad bitter.
Don't worry, a fully autonomous self driving car is just a software problem.
Register it with Google Search Console... the alerts are quite helpful, even if they're somewhat late sometimes
Nope. They won't blame their precious 5$ web hosts. Instead, for some reason I still struggle to grasp, they will instead blame the web coders they didn't hire, who warned them not to use WordPress in the first place, as well as "all versions of PHP itself," regardless of host configuration.
It is absurd how much computing power is wasted on dynamically generating what is effectively static content, like blogs.
A simple blog should not require an SQL database and complex software stacks that are executed whenever someone visits the site.
Instead, consider using a static website generator like Pelican, or one of the many alternatives.
Write articles and blog posts in a simple, human-readable markup language such as Markdown or ReStructuredText.
Manage your documents in git. Run the generator to recreate the HTML and update Atom/RSS feeds.
The resulting website is blazing fast and can be hosted on dirt cheap servers.
More simplicity on the Internet please.
The only secure way to use WordPress is as a static site generator, where the live version is deployed with no dynamic functionality and the administration backend is secured by a layer above WordPress (e.g. HTTP BASIC authentication).
WordPress isn't particularly terrible code, but it is written in a particularly terrible programming language where it's practically impossible to write something secure because things are insecure-by-default and you're expected to defend against all the gotchas explicitly.
I subcontract with marketing companies so I work with some aspect of WordPress development on a daily basis. The standard groupthink from WordPress evangelists is that the security problems are behind us -- that WordPress core hasn't had a serious vulnerability in years, core has a review process, blame your out of date installations and inexperienced plugin developers.
For those not in the know, the REST API is something new to wordpress. Developers could get early access thru a plugin, but the API now comes included with WP4.7. There is so much buzz and excitement, even among wordpress people who have no idea what REST really is, few people questioned it because this meant WordPress can now take over the world.
I for one questioned it. When I saw REST enabled in 4.7 without a control to disable it my literal reaction was "Are you FUCKING kidding me???" I have experience in security. I understand attack surfaces. I have seen what a fiasco xmlrpc.php attacks are to wordpress. And these idiots open REST APIs to the internet by default? Jesus fucking Christ, I really don't think Matt Mullenweg or any of the other idiots running the WordPress show have any ability to learn from history.
Sadly, there is no evidence of other CMS's surpassing WP in popularity. You should get used to WordPress continuing to be the sendmail of php apps.
And web agencies. You got a genuine recipe for disaster. But that's so much fun, all those cheap websites (my company included) which get defaced and hacked to death on a monthly basis, as it cannot be updated timely because they to need every single exotic and never updated plugins. I had to build a presentational website, 15 years ago, and you know what? I did use a static content generator, which I coded myself as it was dead simple! What's is stupid is that as many people told in replies, most of these sites actually needs zero dynamic content and would do as well with a static site generator. But hell, you got to pull the WordPress buzzword to please the corporate people, cause they need cheap flexibility, and buzzwords.
Stupidity is the root of all evil.
The site is already defaced as soon as WordPress is installed.
You've established that WP is not the solution. What do you suggest as a solution for less than tech savvy users who want to create good looking, fast, secure web sites?
My mom always said, "Jim, you're 1 in a million." Given the current population, there are 7000 of me. God help us all!
Wordpress isn't terrible code, but it is terribly well thought through from a security point of view. Think of it like design decisions in Windows XP which lead to most users logging in as Administrators. Wordpress's killer features are its extensibility. This allows a LOT of crap code to come into Wordpress installations due to no fault of its own.
I remember my own Wordpress site turning into a spammachine. I had the entire administration system locked away to only allow access from a local IP address. I had taken all precautions including removing links to administration, changing the default directories, users, including limits on logins, disabling all features like comment posting etc. In the end the theme I installed had a security hole that was exploited which allowed the attacker to modify the theme's code. The theme itself turned into a spam service and my computer eventually crumbled under the load of sending spam when enough people visited the site.
We all ridicule people who rely on security-through-obscurity. Incidents like this should make us take another look at that sentence: While we shouldn't rely on obscurity for protection, we shouldn't forget that it does help. Major platforms like WordPress are lucrative targets for hackers, who will spend a lot of energy searching for weaknesses they can exploit.
Using some lesser-known platform, or even rolling your own, makes you a less interesting target. Sure, you may (will!) have other vulnerabilities, but far fewer people will be hunting for them. This is a not-inconsiderable advantage.
Enjoy life! This is not a dress rehearsal.
But it doesn't scale enough. Nothing does.
I don't know buddy. I've never had problems with ASP or ColdFusion. Tens of thousands of users at a time, and they work just fine.
Since WordPress runs more than a fourth of the entire web (110+ Million Websites), 1.5 Million infected sites isn't all that much. Yes, WP is a mess and could use a redo, but then most legacy systems could, so what gives? WP is popular, is exposed via port 80 all over the planet and thus is a big fat jucy target. I'm glad Automattic (WordPress Corp.) is alive and well and doesn't try to be anything else than the herald of WordPress and it's (small) business arm and does it's dues by keeping up with patches and fixes.
We suffer more in our imagination than in reality. - Seneca
Funny how the URL says 15 million and the article says 1.5 million.
https://it.slashdot.org/story/...
Has Slashdot been defaced too?
The reason I hate WordPress is PHP.
LAMP rules. Get over it. Yes, PHP is awkward (said it myself) and I don't particularly like it that much either. But show me another web PL that does what PHP / LAMP does.
Hello World in PHP is "Hello World." There. Done. Upload a bunch of PHP files on to a LAMP setup, type in the URL in the browser and watch magic happen. No compiling, no appserver to babysit 24/7, no race conditions. Pure simple stupid procedural turing complete web template logic with some nifty utility functions bolted on left right and center, with no order or discipline what-so-ever. But they all work.
LAMP rules, it get's the job done and right now it's also putting money in my pocket. Yes, there are a lot of n00bs and non-programmers doing stuff in PHP and the projects using it have little to no idea how to organise web-dev, let alone a clean model or dev pipeline. And it's really ugly and bizar. But it get's the job done, one hack at a time.
PHP is the language that get's shit done on the web, plain and simple. It's the P in LAMP.
That's why PHP has WordPress, Joomla, Typo3, EZ Publish, Drupal and such and Java has nothing of that magnitude. Go figure.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
So I have five separate personal WordPress sites for testing/hacking/tinkering and casually look after one for a friend. Every single one of mine updated on the day the patch for this problem was fixed.
I got email notifications from each of my sites notifying me they were updated before I heard about the problem. I read the WP blog post about it and thought "shit, that would have been a huge problem if my sites hadn't auto-updated!" and forgot about it completely.
(Incidentally, the next night I had a much, much higher than normal number of brute force login attempts. Not sure if related.)
I'd be very interested to find out why these 1.5m sites did not automatically update. I wonder if they're being manually updated or what the deal is. But if auto-patching worked as it was supposed to this vulnerability would have been mitigated much more quickly.
Don't rely on /readme.html to show you the exact version any more for a recent WP install. They seem to have knocked off the third field, so versions 4.7, 4.7.1 and 4.7.2 all now say "4.7", which might scare someone into thinking they're still on the vulnerable 4.7.
Of course, you can log into your WP admin interface and find the exact version there, plus it's also present as the $wp_version variable in /wp-includes/version.php if you have access to the Web tree filestore.
WP auto-updating does have its risks of course - we've seen WP 4.7 introduce this big vulnerability for example (though I believe you can hold back these "major" updates and do them manually). Plus a lot of admins would prefer a scheduled time/day to update - it seems that by default auto-updating is fairly random w.r.t to its scheduling. Plus you'd want to update dev/UAT first before live in case there is breakage. Also, as far I know, WP auto-updating by default doesn't backup the Web tree/DB first and has no easy way to roll back a failed auto-update because of that (so off to tape backups you go whilst the site can often be down).
Still, WP updating whether its manual, scripted or automatic is still a million light years ahead of Umbraco's updating (which usually can't be upgraded between major releases, so many Umbraco sites get stuck on a particular major release for a very long time, even after support has ended).
In my experience, the answer is "custom code and plugins". If you're running a bog standard Wordpress install with Akismet, FormNinja, Gallery, and a handful of the other top-20 plugins, auto-update is just fine and won't bother you at all. If you have a lot of custom layout code, or specialized plugins that are mission critical but not regularly updated, updating Wordpress can break them, thus breaking the website. Yes, it's stupid. Yes, this situation should not be the case. However, you asked thy people don't enable auto-update. That would, in fact, be why.
As an aside, shameless plug for the super awesome Shield Plugin. It's free, and when properly configured, can prevent nearly all of the major forms of automated attack. I've also used iQ Block Country to nix traffic from most of the usual purveyors of such attacks. Not a dev or an investor, just a super happy user of both.
Now, to go one further, Slashdot seems to be back-and-forth regarding mandatory auto-updating. Wordpress has a flaw, and the response is, "why isn't auto-update just how the thing works?". Microsoft implements this with Windows 10, and the response is, "How dare they tell me when I have to update!". Which is it?
A developer's peers will generally know whether they provide good value or not. When preparing to do a performance review of a developer, ask for feedback about that developer from other developers on the team (and other co-workers they interact with on other teams).
Any web software or web developer who seriously uses the phrase “REST API” possesses by definition an understanding of how the web is meant to work that is 100% complete and 100% wrong. And security is 10,000% more difficult to learn and implement correctly than HTTP is, so why anyone still trusts either one to such know-it-all idiots is entirely beyond me.
You should patch it to /dev/null. It’s the only way to be sure.
Value conversion isn't necessarily the same as validation. If you want validation, then use validation operations. Use the right tool for the job.
Table-ized A.I.