One Computer Can Knock Almost Any WordPress Site Offline | Hacker News Reader

One Computer Can Knock Almost Any WordPress Site Offline

securityweek.com

34 pointsthg40 comments

For those that are curious, here is what the famous "load-script.php" returns when you call it with a bunch of params: https://wordpress.com/wp-admin/load-scripts.php?c=0&load%5B%...

That is a subtle way of making a point.

Note however that the file is under 450 KiB, there are images on that site which rival this (generated) file. And the readfile() call is an extraordinarily light call, all it does is, as the name implies, read from disk to STDOUT (the HTTP stream in this case).

It's not about filesize - you're not trying to saturate the site's network pipe, you're trying to tie up all of its processes combining arbitrary JS files so it doesn't have time to respond to legitimate requests.

Note that "load-styles.php" isn't any better https://wordpress.com/wp-admin/load-styles.php?c=0&dir=ltr&l...

That being said, one can only hope that generating those isn't that heavy on the server.

You know how I know WP is a monument to poor design and bad technical debt?

This right here.

This is just clickbait exploitation for Wordpress haters who think Wordpress is a pile of garbage and wished it would just die already and then were hoping this would be empirical damnation but were slightly disappointed that it wasn't because it actually helps expose an issue that will result in a patch that will result in Wordpress living on forever past our deaths. I mean, well that's what someone MIGHT think...not me of course, I mean I LOVE Wordpress.

As I assume that the load-scripts.php file is only used for the admin interface, it seems silly that WordPress didn't want to classify this as a bug and make it only accessible to authorized users.

Does anyone have an idea why this is?

>Does anyone have an idea why this is?

Because it is not.

Solution: add http auth to your /wp-admin directory

This will break things.

Edit: Why the downvotes? Lots of non-admin stuff lives inside wp-admin, "add http auth" is terrible advice.

https://censys.io/ipv4?q=%22wp-admin%2Fadmin-ajax.php%22

Hundreds of thousands of sites with "wp-admin/admin-ajax.php" on their index should more than prove this.

Good point. There may be some things that are needed publicly, which you could whitelist. I've seen the whole directory behind the auth on a handful of sites though. ex] tether.to/wp-admin

recently set up a wordpress site on aws using elastic beanstalk, redis, and cloudfront -- can take quite a beating. if i had the chance to optimize more, it could have handled more... but i was really unimpressed with Wordpress and how it has failed to evolve much over the years.

Can't this be easily cached? It's GET of a unique URL, seems like a perfect solution.

An attacker could permute the load order or add other parameters, breaking any cache above the Wordpress level. This is definitely on WP to solve.

>This is definitely on WP to solve

How do you propose that WP solve DoS attacks against their application?

This script simply doesn't seem particularly slow to me, despite messing with the parameters a bit.

https://wordpress.com/wp-admin/load-scripts.php?c=0&load%5B%...

Perhaps most people here are missing the fact that you can hit literally any part of WP a lot and it will break.

"literally" as in "not literally" as most parts of WP are not vulnerable to this attack.

But they literally are.

i think you need to step away from your computer for a bit and calm down. Someone just found out about this vulnerability and yes there is debate about who is responsible for mitigating the attack vector, but that doesn't mean to get all stressed out about it. You are replying to ever comment that isn't aligned with your opinion at this point.

I'm perfectly calm.

>Someone just found out about this vulnerability

This is grossly misrepresenting the issue. There is no vulnerability, webapps are slow.

>that doesn't mean to get all stressed out about it. You are replying to ever comment that isn't aligned with your opinion at this point.

Not getting stressed out is exactly what I am trying to advocate by calling out people spreading FUD.

Not having this script might slow down the site some, but it would completely prevent this attack. The goal isn't to prevent all DoS attacks, it's to prevent massive force multipliers like this so that DoS attacks are expensive.

>Not having this script might slow down the site some, but it would completely prevent this attack.

Where "this attack" equals repeatedly requesting a script which isn't even particularly slow compared to other part of WP...

>it's to prevent massive force multipliers

This is not a "massive force multiplier". Please spend a tiny bit more time looking into the subject.

exactly, that's how every other adhoc solution does it. however the bigger issue is that since it site under wp-admin, it should require a login to access.

Seems accidental, any reason this could be intentional?

From the same paragraph:

> Since it is also used to improve performance of the wp-login.php page, it can be invoked before any user authorization is required.

is something like this advisable to do to your own site to test or will cloud providers get angry? is it legal to do in general?

i don't see why would it be illegal to do this to your own site. and i don't see why cloud providers would get angry -- you're just giving them money for the bandwidth you use on your account.

when i built out the wordpress aws site i mentioned here i used a locust cluster to simulate high traffic loads in order to test the load balancer in elastic beanstalk... amazon even has a guide on how to set it up.

This will hammer your CPU to the wall too. If it's a cheap cloud provider that is charging you based on the assumption that you're not actually going to use very much CPU and the server you're running on is overprovisioned, they'll get angry. If you're paying for 100% of the specs you're getting, it won't bother them (i.e., AWS, where even the 'overprivisioned' tiny VMs are overprovisioned with specific SLAs for what that means, and you're still welcome to use 100% of that promise).

> i.e., AWS

good points, this is what i was referring to - aws doesn't care.

You might use up your traffic allocation and your provider might shut the server down if it disturbs other tenants.

Get a CDN

One Computer Can Knock Almost Any Site Offline

I also found this click bait title humorous. ONE COMPUTER can launch a car to into space!*

* As long as it's the one controlling all the other computers that control all the systems for Falcon Heavy.

Except that usually DoS attacks are effective because they use a distributed system of many computers (DDoS).

This attack is notable in that it requires only one, this detail is worth mentioning.

You clearly lack any understanding on this subject.

Application layer attacks are not a new thing.

It would be awesome if your replies in this thread were constructive and educational.

You've made a few blanket statements without further clarification or evidence and are coming across as kind of insulting.

I refer you to the Hacker News guidelines on comments : https://news.ycombinator.com/newsguidelines.html

>It would be awesome if your replies in this thread were constructive and educational.

I am aware that my replies have been brief, but WP is not a project I particularly want to defend and sadly nobody is paying me to do so.

>without further clarification or evidence

I would expect that the people making the claim about this serious new vulnerability should be the ones substantiating that claim.

Anyone who's ever ran a wordpress website should immediately know this is bullshit. It all sums up to "wordpress is really slow, this script is not particularly slow, other parts of wordpress are significantly slower".

Then there's the bunch of people telling you to restrict access to wp-admin... This is terrible advice and will break non-admin stuff that lives within wp-admin.

I kinda agree with the WP people that this is not really an exploit. If you call a script that does a few seconds of processing, and keep calling it, yes it will take down the server...

That said it can definitely be mitigated by checking for this kind of request explicitly and not letting the same IP keep requesting the URL (plus caching, etc.) Maybe it's an argument for WP to integrate some of the features of 'firewall' plugins.

> If you call a script that does a few seconds of processing, and keep calling it, yes it will take down the server...

aka, exploiting the script loading behavior...

The thing is, in WordPress, it's not uncommon to end up with a public URL that takes a few seconds to generate if it uses a few plugins or multiple queries on a low-end server. This is really just demonstrating that apache/nginx fall over at some point (usually what goes away first is the MySQL connection).

i think the issue is that since the script sits under wp-admin it is outside of something that administrators can use caching techniques against. Also, if it is under wp-admin, it should require a logon to access.

Reply on news.ycombinator.com