WordPress Moderators Censoring / Not Caring About Important Security Issues

I’m not the only one having this problem.

No, you’re not. But you are in a very small minority. As Jan Dembowski said:

This is not effecting all WordPress users; it is effecting you and you can fix it on your site yourself. That’s the use case for why something goes into a plugin.

A lot of WordPress users use XML-RPC and there have been improvements to the interface. You can leave it off if you choose.

I have been running various WordPress sites for seven years and have never encountered this issue. A quick poll of my WP friends indicate that they never have, either.

Yes, if you Google something, you will come up with thousands or even millions of results, but each result does not represent someone having that same issue.

My server has been under attack quite a bit recently. After spending a lot of time investigating why the php5-fpm process was using so much CPU, I determined that several attackers have been targeting an installation of WordPress on my server.

That is your problem right there: attackers targeting your WP installation.

The attacks come from a single IP address. I can ban these IP addresses which fixes the problem

And there is your solution.

I have, over the years I have been active in these forums, seen a lot of similar arguments: “I’m having an issue and it’s all the fault of WordPress, when is someone going to fix this rotten piece of software, since everyone is suffering from it?” In almost all of those cases, it is not the fault of WordPress, but a server issue, or a WP configuration issue, or even a PEBKAC error (lots of these for me). WordPress undergoes a lot of beta testing, and is live on millions of sites, so if this were a major security issue, believe me, it would be fixed.

Can someone please explain to me why Mr Jan Dembowski thinks it’s OK to close valid threads?

I’ve saved a copy before it gets deleted since some people here are obviously oversensitive.

It’s not a matter of being oversensitive. It’s about remembering what these forums are for: solving issues that people have with WordPress. Endless ranting because the WordPress team is not going to remove a feature that is used by millions of WordPress users just because a couple of asshats are exploiting it to target your site is simply not productive. It’s not part of the culture on these forums.

I know this is open source software

Yes, it is, which means that 1) it comes to you completely free of charge, and 2) you are free to modify it according to your own needs. But that does not mean you have a right to expect the WordPress team to modify the software to serve your exact needs. That’s not how open source software works.

I know this is frustrating for you. But the problem is not within the WordPress software, as you yourself have pointed out.

I’m not sure how many times I’m going to have to say this, but this issue is a WordPress issue. Sure, I can work around it by DISABLING the entire feature, but that doesn’t fix the problem. By default, WordPress is open to this attack. A bot or exploiter could DOS any installation of WordPress using this attack, and it wouldn’t be very complicated to do so.

I had a user install WordPress recently. Within a few days, his xml-rpc was being hit with the same pingback attack. No one knew about it except for me, the server admin. That is how quickly a new installation was under attack. Consider yourself lucky that your installations aren’t under attack yet. Or maybe they are, you just haven’t noticed it or care about server load. I can guarantee that once you are under attack and have noticed you’re under attack, your opinion will probably change.

A lot of people probably don’t even realize they have this problem, so I’m betting a lot more users actually have this problem more than you think. It takes a good server administrator to notice this problem. It’s not as obvious as you think.

Please explain to me how this is not a WordPress issue without reiterating there is a plugin to DISABLE not FIX this issue.

Just because WordPress has millions of installations doesn’t mean it doesn’t have security issues. Sure, you could say this isn’t a security issue, but it is, and it’s a tough one to spot when you’re being attacked. Your installation isn’t being attacked right now, but that doesn’t mean it won’t be in the future, and when it is, are you still going to suggest it isn’t a security issue? Typically, security involves mitigating problems before they even happen. Instead, WordPress wants to take the easy way out and just have the entire feature disabled.

There was no need to lock the original thread. I just wanted to use it as a record of how many times I’m having to tell users to install the disable xml-rpc pingback plugin to work around this issue. Others were commenting they had the same issue, so I’d prefer it if people could have a voice in a relevant topic.

The number of users affected by this problem are unknown. It took me a few months to discover how this attack was affecting my sever, and as such, it will probably take others a while too. I never asked for the feature to be removed. I asked that WordPress properly secure this feature against attacks.

I’m not sure how many times I’m going to have to say this, but this issue is a WordPress issue.

Probably until it actually *is* a WordPress issue, because right now it’s not.

By default, WordPress is open to this attack. A bot or exploiter could DOS any installation of WordPress using this attack, and it wouldn’t be very complicated to do so.

Please do some research on DOS and DDOS. Every single type of site is open to this attack, even just a single static HTML file is open to this attack. Briefly, this type of attack simply involves directing a botnet at a specific file and viewing it so frequently that the “lines” to it get clogged or sever resources basically burn to the ground (sometimes both).

https://en.wikipedia.org/wiki/Denial-of-service_attack

It’s not unique to WordPress, this type of attack *predates* WordPress.

Here’s an advisory about two DOS tools from the world-wide center for coordinating information about Internet security at Carnegie Mellon University in 1997, 5 years before the first version of WordPress was released: https://www.cert.org/historical/advisories/ca-1997-28.cfm

There were more incidents in the years prior, but digital records of that period are of course harder to come by.

Here’s an interesting read from Protonmail who just last year experienced one of the largest DDOS attacks in Europe: https://protonmail.com/blog/ddos-protection-guide/

Of note to this context, Protonmail is an email provider. They do not use WordPress.

I had a user install WordPress recently. Within a few days, his xml-rpc was being hit with the same pingback attack. No one knew about it except for me, the server admin. That is how quickly a new installation was under attack.

That’s very unfortunate for your user. I’ve been managing WordPress sites for the past 12 years and have one had 1 hit by DDOS which was mitigated by trivial mod_security rules and basic IP blocking, it wasn’t too severe of an attempt.

I suspect they were already on someone’s radar, and I hope the hosting provider was able to mitigate it quickly. If not, it might be time to consider a new hosting provider.

It takes a good server administrator to notice this problem.

If you’re actually being hit by a real DDOS, your site goes offline period, and it usually takes the rest of the server with it. It doesn’t take “a good server administrator” to notice, everyone notices. Perhaps you aren’t actually being attacked. Perhaps you’re just seeing normal bot activity.

———-

So, the point we seem to be at here is that you’re convinced we aren’t reading what you write, and to be totally honest, I’m beginning to be convinced that you aren’t reading what we write.

Sure, you’re quoting back when we say to use a plugin, block the attacker’s IP, or remove the file they’re attacking, but you don’t seem to be reading *why* we say that.

Very briefly, DDOS is not a WordPress-specific problem, anything can be hit by a DDOS. To briefly mitigate a mild DDOS attempt, simply block the attacker’s IP or temporarily remove what they’re targeting. Mitigating what the industry would consider to be a real DDOS attack is much more involved, see the Protonmail post linked to earlier.

Just a quick note with regards to “Not Caring About Important Security Issues,” we clearly do care, otherwise we wouldn’t be putting so much time into trying to help you understand this.

Yes, bots are always trying to attack and exploit servers. I’m not questioning that. I didn’t say it was a DDOS. I said it’s a localized DOS.

My point is that the WordPress code responsible for handling pingback requests should not be putting a high load on my server due to bogus requests. It should be doing nothing if the requests are bogus instead of initializing the database and taking up additional resources every time the request is received to the point it slows my server to a crawl.

I don’t know of any other software that processes bogus requests AND slows the server to a crawl by using too many resources to filter these requests.

How do expect WordPress to identify “bogus” requests within the realm of the XML-RPC protocol specifications?

https://xmlrpc.scripting.com/spec.html

Here’s an idea:

Perhaps an encryption key hash should be sent with every pingback POST request that is unique to every installation of WordPress. If the encryption key hash sent doesn’t match what is stored in a text file, the database and logic doesn’t even need to begin processing the request. This should not be very resource intensive since reading a file from the file system is much quicker and efficient than making calls to the database and performing logic on the request. This would render this attack useless, as it wouldn’t affect system resources.

Interesting idea. What would prevent the key hash from being spoofed?

I don’t think it matters if it is spoofed. It has to match the unique hash for that particular install of WordPress. Have it be some kind of md5 hash, and the chances that an attacker will guess this hash would be slim to none. A legit user of the pingback functionality will be presented with their hash that needs to be sent with every pingback request. It would simply be a variable containing the correct hash. That way, attackers would probably never guess it correctly, and if the variable isn’t included in the request, the request isn’t processed either.

Just a thought.

So, my first impression would be that a botnet with a sharp controller would have spoofed how the hash is stored and transmitted. A static hash wouldn’t be too hard, considering that every single line of WordPress’s code is available to the public.

However, it may knock the less-capable botnet controllers out for a bit, at least until someone posts a how-to on their message boards.

Similar functionality is already baked into the REST API and it can be handled in a dynamic far-more-difficult-to-spoof way, so whenever that fully replaces XML-RPC, we’ll be in good shape.

For now though, so we don’t take up any more of your time here, why don’t you propose that to the developers? File it similar to a bug, but set the kind as Enhancement: https://make.www.ads-software.com/core/handbook/testing/reporting-bugs/

I suppose the big question once it gets to them will be if it’s worth pursuing or better to continue focussing efforts on replacing XML-RPC with the REST API.

Storing the hash in a file on the server may not be the best decision either, so maybe it could be stored in the database, but the function to look it up should be simple and quick. It does this before doing anything else. A single select statement on MySQL should be quite quick…

That, or it could be stored in a flat file, but make sure the file isn’t readable by the world (chmod it to 700 or something)

My idea is that the hash is known only to the server and a legit user. Bots will have no idea what the hash is, as it will be different for every WordPress installation. They’d have to spend a lot of time guessing, and they most likely would never succeed.

I will file an enhance request. Thank you for taking the time to understand what I’m trying to say. It’s not that WordPress should be invulnerable to attacks, it’s that WordPress should not allow attacks to consume a lot of resources on the server while processing the attacks.

My idea is that the hash is known only to the server and a legit user. Bots will have no idea what the hash is, as it will be different for every WordPress installation.

Right, what I mean is what’s to stop a botnet from spoofing its own WordPress installation with its own hash?

They don’t have to spoof a specific WordPress site, they’d just have to spoof *being* a WordPress site.

it’s that WordPress should not allow attacks to consume a lot of resources on the server while processing the attacks.

Processing takes resources unfortunately, it’s why DDOS are so successful. A legitimate request is processed the same way an attack is. The trick is in coming up with new ways to identify what it is.

But that spoofed hash would only be valid for their installation of WordPress. The real WordPress installation they attack would be using a differently randomly generated HASH that was generated and saved during installation. Their request didn’t send the right hash for that install, so it’s dropped.

Ok, the sending site needs to send the hash belonging to the receiving site?

How does the sending site get that hash?