'cerber_authenticate' method creates a potential security hole for other plugins

Miscellaneous
1

The ‘cerber_authenticate’ method in cerber_load.php is hooked as last in line with PHP_INT_MAX priority, but has the issue that does NOT check if the $user passed to it is a WP_Error. The problem with that is the following - other plugins might have already flagged the login as bad and WP_Error-ed it. WPCerber in it’s current implementation blatantly ignores that and logs the user in as long as the user and password are valid. Example use case with a security hole :

The Melapress Login Security plugin blocks at user level for failed login attempts (which is different from WPCerber’s own IP level blocking). After the user exceeds the allowed number of login attempts, Melapress WP_Error’s the $user for that. Yet - WPCerber logs the user in ignoring that as long the credentials are valid. This opens the road for brute force attacks when the user name is known and the attacker succeeds to avoid the IP blocking in some way.

The solution is : WPCerber should check if the $user parameter is an instance of WP_Error at the start of ‘cerber_authenticate’ and just pass it on, if so, without authenticationg the user.

2

TL;DR: There’s no security hole. Plugin developers can use a different filter, and we’ll consider updating WP Cerber.

Aren’t you a bit concerned that this hole didn’t exist until another plugin was activated? I mean, WP Cerber continues to work flawlessly, but the issue is that the other plugin isn’t functioning as it should, due to WP Cerber’s specific architecture. To me, the title of this topic sounds a little clickbaity. There’s no security hole. At least not in WP Cerber.:blush:Anyway, thanks for bringing this issue to our attention.

Regarding the authenticate filter. This design decision is based on our 9 years of developing WP Cerber, which have shown that a significant amount of invalid data often passes through filter parameters. This usually happens because unskilled developers are trying to implement something sellable. It’s easy for an inexperienced programmers to hook into a WordPress filter and accidentally return invalid data to another filter in the chain. Ultimately, WP Cerber gets the blame because it’s a sophisticated and well-supported plugin. Customers come to us for help, not to those programmers, because the latter can’t offer professional support.

Another point is that, for many years, WP Cerber has been the only plugin on most websites handling user authentication and protecting WordPress against brute force attacks. Plugin conflicts like you’ve described have been incredibly rare, mainly because this area of expertise was once accessible only to a select few developers.

The issue with the authentication filter poses no more risk than the inability to use some features from other plugins. This is just a typical plugin conflict that led to unexpected results.

What’s the solution in this case? Learn WordPress hooks. There is another hook wp_authenticate_user which can be used instead of one that is occupied by WP Cerber.

That’s a false statement. This doesn’t open any roads for brute force attacks. It is WP Cerber that has successfully protected and continues to protect websites around the word from millions of brute force attempts and other cyber threats over the past decade, even when the username is known. We’ve collected tons of data on how these attacks are mounted, and trust me, WordPress sites don’t get hacked just because “the attacker succeeds in avoiding IP blocking.” At least, not when WP Cerber is in place.

So, let’s get back to the main point: should we update our authentication filter? I think yes. However, we need to do it in a way that benefits both our customers and us by directing customers to the plugin that generates that WP_Error, rather than our support team.

3

Hi,
Thanks for your reply. If you felt offended in some way or you think I’m implying WPCerber is a bad plugin - this is certainly not the case. If so - I wouldn’t be using it at first place :-). I can’t say what you mean by ‘clickbaity’ either - I came here as the only place I found available for free users to report a potential issue and I’m trying to help imporve the plugin (primarily for my sake :-), but also for you and the other users). Now, was I concerned when and how the issue showed up ? Here’s an exempt of my ticket to the other guys (Melapress), which I submitted BEFORE posting here:
…
What I think is a possible mitigation for such cases it to add an additional check on ‘wp_authenticate_user’ which is called in ‘wp_authenticate_email_password’ and ‘wp_authenticate_username_password’. Since plugins that are not malicious, but just buggy or not well written will use those to login users (WPCerber also does) - using this filler will enable you to re-block the login on time, when necessary. For plugins that are malicious there’s hardly something that can be done anyway.
…

So that’s that, but let’s come back to the real matter and try to be constructive. I still stand on my original opinion that this is an issue that needs adressing on your side (I won’t call it a security hole :slight_smile: ). I understand your reasoning, but to put it straight - this way you effectively disable all of the others non malicious, well written security oriented plugins that DO use the ‘authenticate’ hook and block users form logging in for reasons different than wrong credentials (I truly believe Melapress is such a plugin). I don’t think a simple check if a $user is an instance of WP_Error will hamper the effectivenes or performance of WP_Cerber in any way. I definitely think it is a good pattern. The worst thing can happen is that users will not be able to login due to a faulty or malicious plugin doing something stupid or bad, but honestly - so what ?! If you see a potential way that this check can DO a login of users that shouldn’t then - ok, I’ll fully agree, but if it is just about the false negatives - no issue imo.

As of the brute forces - I get the feeling you are looking from a standpoint where WPCerber is the only security plugin on a system AND is fully configured the way you would configure it. But that’s not the real life to put it mildly. Simple case is again … my setup. I have WPCerber configured to prevent brute forces (and quite thight so), but I also rely on Melapress’s mechanism. What if a user with similar setup decides Melapress is enough and disables the WPCerber bruteforce protection for performnace, let’s say - is it an open door or not then ? And I don’t accept the “They should not use ‘authenticate’” because … why not ?

4

Not at all. Quite often, I run into people dropping bold statements about WP Cerber features without bothering to dive into the details. I guess that kind of criticism just confirms we’re doing something that matters. But I still can’t get used to it. Probably because it’s my baby.

This increases probability of fixing the issue. :wink:

So, I get your point, and I tend to agree with much of what you’re saying. These days, setups often involve multiple plugins working together, and WP Cerber isn’t always the sole line of defense. Back in the day, though, it was often the only protection against brute force attacks for many sites, which naturally shaped how it evolved. That’s not the case anymore, of course, but I see where you’re coming from.

Anyway, we’re already planning an update to the authenticate filter in the next release. I appreciate your input, feedback from real-world setups like yours is always great to have.

Happy New Year!

1 Like
5

Implemented in WP Cerber 9.6.6

1 Like