Caleb

@solwininfotech,

Your plugin has been changed, yes. But not entirely for the better.

Your new code now has multiple new problems.

Putting a big

if (!is_wp_error($user) && is_object($user)) {

bracket around all your code and totally eliminating the get_user_by() (never actually translating the $username string) call might seem like a good idea, but not in reality.

All that bracket does is to protect YOURSELF from getting into the situation WordFence was in. That someone upstream passes YOU values that are not what you think. But it adds new issues.

Problem 1. The Authentication process starts by WordPress sending

(null, $username, $userpassword)

NULL.. As in, the first filter function will not have a WP_User at all as a parameter, but a ‘null’. The filter is responsible for filtering on $username/$userpassword and checking or looking up the username, when no $user structure has been found yet.
Or in the case, that the $username is for example a banned/illegal name, a filter might not try to look up the $username at all, but will simply return WP_User_Error.

A WP_User object is not found until the first filter translates the $username into a WP_User object. Then if the user and $userpassword is accepted by that particular filter, the filter passes a WP_User (rather than a WP_User_Error/WP_Error) as a return value.

Given that you are bracketing your entire function, that simply means that if you are first to be called from wp_authenticate(), you become a pass-though. Doing nothing at all. You never look up or otherwise check the $username.

This particular issue you are somewhat protected from, since WordPress initially inserts 3-4 internal ‘authenticate’ filters, which most likely would have translated $username before you ever get called. Why it might have appeared to work, when you tested it. But that is not an assumption that is really safe to make, since you are supposed to be able to handle NULL.

Problem 2. You are now returning NULL.

If there is a next filter in the chain AFTER you, like here WordFence, they might save the overall filter-result from your return value, because they are also responsible for accepting NULL as a first parameter. The next filter might then translate/validate/invalidate $username and return a correct value. But if you are alone or last in a filter-chain, you would be returning NULL to wp_authenticate() as the final filtering result..

NULL is not a valid return value from any ‘authenticate’ filter. No more valid than the earlier value of ‘false’.

wp_authenticate() in fact checks for NULL explicitly, and considers it a failure of the filter process that should not happen. It reacts by failing the whole login process, and declaring the login invalid.

The way WordPress works by default, is that it’s internal “scheduling” process, called “WP-Cron” gets called during normal user visits. It will wake up when a user visit a page, and suddenly start doing various maintenance things, while that user waits to see their page. 🙂
That works OK for things that complete in split seconds, but you sure would not want a user to get caught by suddenly running a long “WordFence Scan”, while they wait to see your page.

To prevent that from happening, WordFence does not merely use Wp-Cron, but starts it’s various tasks by instead “calling back” to the server to create it’s own “visit”, where things like the file-scan can happen in peace and quiet, leaving your normal users to go about their own business.

THAT then means that your site has to be able to call itself to accomplish various tasks. If it tries to “call home”, but the call cannot go through, tasks start failing.

Your diagnostics output state directly, that this cannot happen because of an issue with your hosting setup.

“Failed to connect to (domain here) port 80: No route to host“.

Your site’s server cannot figure out how to find itself. It cannot translate your domain-name into a “route” (path through the networks) back to it’s own IP address. It is usually caused by a local configuration issue, which I have seen on some server/hosting setups.

It for example can happen, if your server is behind a NAT (Network Address Translation) where it has a different IP-address internally from what it is known as on the global Internet).
That can make it seem alive to the external world, so you get visitors from outside, but when you try to use the external IP address (what your domain-name translates to) to call the server from itself, it fails because the server does not know that this IP address is actually itself. It essentially knows only it’s internal address.

There are various configuration changes that can fix that, including fixing routing, adding IP to interface directly, adding your host-domain-name to the local /etc/hosts file – but pointing to the loopback interface instead, …, …
BUT, unless you have root access to your server all those methods are unavailable to you directly. If you are on a shared hosting setup, you can NEVER have root access. Your hosting company would have to fix their setup.

On a VPS or Dedicated server, where you are in 100% control and have root-access, the simplest methods is usually to just add a line to the /etc/hosts file, pointing your domain/server name to loopback (127.0.0.1), since that affects only the local server. It usually fixes it, assuming that your web-server is listening on Loopback.

Starting scans remotely should theoretically work around this by making the WordFence server(s) call your site instead. It is a workaround for the call-back problem, but for scans only. If that does not happen, I guess that is another problem.

I am seeing repeated accesses by GoogleBot with this WordFence parameter as well:

/?wordfence_logHuman=1&hid=xxxxxx

For that one there is no excuse of “redirect” like for the previous incident linked above. the LogHuman test comes out attached to page headers, and gets caught by GoogleBot and others on some of their accesses. Probably for Google on some of the test-site accesses.

It is another case of side-effects from WordFence injecting Javascript based links into random pages just for internal purposes.

It is a decidedly bad idea to modify a site’s page code with goofy links/parameters that should not be there. I prefer to control my own page content and links, thank you very much.

It is not a vulnerability or a new type of attack.. It is a parameter your local WordFence use to call itself, that under normal conditions should NOT become visible to the outside.
Unfortunately there are conditions where WordFence panics and spews it out into page code using Javascript, where visitors, Google, and other bots can find the link.

In either case, the parameter is there by accident, not an attack it itself. When someone OTHER THAN your own server calls with it, it means that they have found and called the query link, but calling it is not a security risk. It is part of slightly abnormal “normal business”. 🙂
Mostly a nuisance with Google Search Console when GoogleBot finds it, since they now are thinking your site uses query args it does not.

Given the Epoch timestamps you show, these links were caught/seen/called on

Saturday, August 19, 2017 4:10:09.600 AM GMT-06:00 DST
and
Saturday, August 19, 2017 6:24:14.490 AM GMT-06:00 DST

so these particular ones obviously just recently happened.

I think you are seeing another unfortunate side-effect of this case, which you might wanna read through:

https://wordpress.org/support/topic/syncattackdata-query-parameters/

Most likely the permission settings for your system is blocking it.

Go to the WordFence -> Tools -> Diagnostics tab and look at the top items there to confirm that they are all marked as OK regarding writing to filesystem and configurations.
If they are not all marked with OK or check marks, your file-system need a permission adjustment.

The root-cause (what ultimately started the failure) is not in WordFence, but in the User-Blocker plugin. Poor coding can cause User-Blocker to at times pass on values that should not exist in the authentication path.

@solwininfotech’s answer from earlier of simply passing you on to the next layer in the filter chain was wrong. They did not actually look at the problem before throwing it “over the fence” to WordFence.

Their code has an obvious flaw. 2 minutes or less of looking at their code should tell them where it can go haywire.

You have hit one of the unfortunate side-effects of having multiple plugins trying to manipulate the same thing.

That said, I would suggest a tiny future improvement in WordFence, where it validates whether other plugins might pass them unexpected/invalid values. That would prevent the PHP errors from being reported in WordFence.
That would not fix the root-flaw, though. That must come from User-Blocker.