Categories
Uncategorized

Loginizer Plugin Gets Forced Security Update for Vulnerabilities Affecting 1 Million Users

WordPress.org has pushed out a forced security update for the Loginizer plugin, which is active on more than 1 million websites. The plugin offers brute force protection in its free version, along with other security features like two-factor auth, reCAPTCHA, and PasswordLess login in its commercial upgrade.
Last week security researcher Slavco Mihajloski discovered an unauthenticated SQL injection vulnerability, and an XSS vulnerability, that he disclosed to the plugin’s authors. Loginizer version 1.6.4 was released on October 16, 2020, with patches for the two issues, summarized on the plugin’s blog:
1) [Security Fix] : A properly crafted username used to login could lead to SQL injection. This has been fixed by using the prepare function in PHP which prepares the SQL query for safe execution.
2) [Security Fix] : If the IP HTTP header was modified to have a null byte it could lead to stored XSS. This has been fixed by properly sanitizing the IP HTTP header before using the same.
Loginizer did not disclose the vulnerability until today in order to give users the time to upgrade. Given the severity of the vulnerability, the plugins team at WordPress.org pushed out the security update to all sites running Loginizer on WordPress 3.7+.
In July, 2020, Loginizer was acquired by Softaculous, so the company was also able to automatically upgrade any WordPress installations with Loginizer that had been created using Softaculous. This effort, combined with the updates from WordPress.org, covered a large portion of Loginizer’s user base.
Any #WordPress install with @loginizer probably isn’t using another WAF solution. As you can notice from the graph 600k+500k active installs were updated upside down, so … Preauth SQLi in it, reported by me. Update! Crunching write up 🙂 https://t.co/gkEVWun9wt pic.twitter.com/XWXVMYO1ED
The automatic update took some of the plugin’s users by surprise, since they had not initiated it themselves and had not activated automatic updates for plugins. After several users posted on the plugin’s support forum, plugin team member Samuel Wood said that “WordPress.org has the ability to turn on auto-updates for security issues in plugins” and has used this capability many times.
Mihajloski published a more detailed proof-of-concept on his blog earlier today. He also highlighted some concerns regarding the systems WordPress has in place that allowed this kind of of severe vulnerability to slip through the cracks. He claims the issue could have easily been prevented by the plugin review team since the plugin wasn’t using the prepare function for safe execution of SQL queries. Mihajloski also recommended recurring code audits for plugins in the official directory.
“When a plugin gets into the repository, it must be reviewed, but when is it reviewed again?” Mihajloski said. “Everyone starts with 0 active installs, but what happens on 1k, 10k, 50k, 100k, 500k, 1mil+ active installs?”
Mihajloski was at puzzled how such a glaring security issue could remain in the plugin’s code so long, given that it is a security plugin with an active install count that is more than many well known CMS’s. The plugin also recently changed hands when it was acquired by Softaculus and had been audited by multiple security organizations, including WPSec and Dewhurst Security.
Mihajloski also recommends that WordPress improve the transparency around security, as some site owners and closed communities may not be comfortable with having their assets administered by unknown people at WordPress.org.
“WordPress.org in general is transparent, but there isn’t any statement or document about who, how and when decides about and performs automatic updates,” Mihajloski said. “It is kind of [like] holding all your eggs in one basket.
“I think those are the crucial points that WP.org should focus on and everything will came into place in a short time: complete WordPress tech documentation for security warnings, a guide for disclosure of the bugs (from researchers, but also from a vendor aspect), and recurring code audits for popular plugins.”
“WordPress.org has the ability to turn on auto-updates [ for ] plugins”
Where is that explained to the average user, and where can it be toggled off?
While I appreciate the security reasoning behind this functionality, its in essence a hardcoded backdoor. Plugins can be updated against the will of the site owner.
Report
It’s in the documentation.
https://wordpress.org/support/article/configuring-automatic-background-updates/#plugin-theme-updates-via-filter
Report
Thanks Otto 🙂
I had actually read the documentation not that long ago, which is rare for me brother! Even with a re-read just now, it doesn’t feel like it clearly states what this filters purpose is, when it why/when it would be used.
There is no distinction between normal updates (major/minor) and security updates.
Even the filter is just called ‘auto_update_plugin’, which someone might turn off (but would want critical security updates), or leave on for said critical security updates (but worry that plugins will auto update for major/minor releases).
By default, automatic background updates only happen for plugins and themes in special cases
It my opinion that ‘special cases’ needs some form of definition. As a site owner, if an external web service wants to update files on my server, I want to know under what circumstances.
Report
That is true, and I didn’t create this functionality in the first place, however we have used it extremely responsibly and only turned the flag on for very extreme cases, such as this one. But, you can turn it off if you so choose. It’s your site. It defaults to on for security updates only. And we’re really picky about security updates. We even require authors to backport for major versions, the same as WordPress itself does. It’s basically a full release process. Not easy to do, and fully transparent to all release personnel. I can’t sneak in something evil without dozens of people noticing.
But, if you prefer to do it yourself, then I will happily tell you how to turn it off via filters. It’s documented. It may not be the best documentation, and that is a fair point. Improvements are welcome.
Report
Anytime you do an update, there is a risk that the update will screw up the website. It can conflict with the theme you are using or other plugins.
I am against any FORCED update. I am there to do updates, not any automatic way. So in case there is a screwup/conflict…I am there to fix things.
I am sorry but there is never a reason for any plugin author, Automattic, the Tooth Fairy or even Santa Claus to essentially tresspass into my property (my website). I usually update within an hour or less whenever there is a core, theme or plugins update.
Report
“I am against any FORCED update.”
It sounds as if you’re not doing so already, so make sure you switch it off using the instructions at https://wordpress.org/support/article/configuring-automatic-background-updates/#plugin-theme-updates-via-filter.
Report
100% automatic updates are turned off. I have a plugin call WP Disable Automatic Updates by Daniele De Rosa.
I follow @WordPress on twitter, and enough members of the WordPress Community that I will get over 100 tweets on my feed “hey, WordPress xxx version is out”.
Just for this “forced” update, I removed Loginizer and found a similar plugin.
Report
Your email address will not be published. Required fields are marked *









This site uses Akismet to reduce spam. Learn how your comment data is processed.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.


WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…read more →
Proudly powered by WordPress.

source

Leave a Reply

Your email address will not be published. Required fields are marked *