own3mall

That’s not really all that helpful. I’ve done all of the above, and I still can’t figure out why the SQL queries are wrong. Without my fix, the site is completely broken, and I’ve cleaned out as much as I can, and WordFence finds no issues other than my modified file (which I modified myself to fix the SQL issues)…

Thanks, I am not using that plugin, so it could be our theme (salient-child).

I’m running a full scan now on the entire server using ClamAV, but I’m pretty sure the issue is just localized to this installation. I have already followed the guide for the most part, as WordFence does restore the files with the original once it detects changes.

The problem is, how are these changes being made in the first place? It keeps happening.

I’m not sure. I’ll have to think about it a bit more.

The pingbacks system is too open and easily abused, so should it have been included as a feature in the first place? I don’t see much use for it. I can see perhaps someone wanting this feature, but it just opens too many opportunities for abuse.

In my case though, I had pingbacks disabled in the control panel.

Under Discussion settings, there are two settings.

Attempt to notify any blogs linked to from the article
Allow link notifications from other blogs (pingbacks and trackbacks) on new articles

Both of these are unchecked (disabled). Yet, when I was being attacked, even with these settings disabled, my server load was off the charts. Perhaps we could store these settings in a file so they are easily retrieved quickly? If these settings are disabled, we don’t process the request at all? Currently, it seems that with these settings unchecked, there’s still some kind of logic / database initialization going on which isn’t very efficient.

The Disable XML-RPC Pingbacks Plugin removes this logic entirely, but why doesn’t disabling the settings have the same effect? It doesn’t need to remove the function, it merely needs to not process the requests which is inefficient for the server.

With that being said, has anyone come up with an iptables rule to rate limit specifically pingback requests? If not, maybe this is what I’ll work on next.

Since the pingbacks system has no way to prevent abuse, maybe pingbacks should be disabled by default when WordPress is first installed?

Another possible solution would be to the write a file when a pingback request is received with the name of {IP_ADDRESS}.txt which contains a timestamp. {IP_ADDRESS} being the IP address from the client sending the request (PHP can grab this easily). When a pingback request is received, we check to see if the file exists, and if it does, we check to see if the current timestamp is greater than the old timestamp + 60 seconds. If it’s not, we discard this request because not enough time has passed. If it is, we process the post back and write the new timestamp to the file. If the file doesn’t exist, we create the file with the current timestamp and process the request. Then, WordPress could run a “cron” like function like it does for updating WordPress to delete these files to cleanup every once in a while. This will limit a source to one pingback request per minute, which seems more than fair. Thoughts on this potential solution? Seriously, file system operations are very fast and so are timestamp operations, so I could see this working. This would also prevent a single attacker or multiple attackers from having a noticeable impact on the server.

There’s gotta be someway to prevent the abuse from hammering the server.

EDIT: Also, would it be possible to unlock the old forum thread and merge the majority of the posts in this thread to it? I think it’s an ongoing issue that needs to be discussed or addressed. At the very least, post a link in that closed thread to here? And maybe this post needs to move? Just thinking out loud here.

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.

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)

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.

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.