WordPress Loginizer Plugin has issued a security patch for a vulnerability that could allow a hacker to modify a database through an Unauthenticated SQL Injection exploit.
This kind of exploit, also known as a Blind SQL Injection, relies on entering data into an input in order to trigger an error response. In this case the input is a username.
The Loginizer WordPress plugin didn’t have a way to sanitize the input, which means it didn’t have a way to compensate for an erroneous input. This caused the plugin to create an error situation.
According to the WPScan description of the Loginizer exploit:
“The vulnerability was triggered within the brute force protection functionality, which was enabled by default when the plugin was first installed. When a user attempts to login with an unknown username, the attempt is logged in the backend database, where the username, as well as other parameters, are not properly validated before being placed within the SQL query.”
The security researcher who discovered the vulnerability published a walkthrough of the Loginizer exploit, showing how an error response can be used to reach areas of the plugin that relate to it’s functionality. It is there that the hacker can see vulnerable to a SQL injection.
The researcher described it like this:
…via function definition we see how raw $username reaches the plugin functionality… Also in this function there are calls towards DB with not sanitized DB parameters… and we see the places that are vulnerable of SQLi based on user login data.”
The walkthrough continues with the proof of concept and concludes:
…And that is it, more than easy and detailed about SQLi + XSS via $username.”
Stored XSS Vulnerability
The problem with Loginizer isn’t limited to the SQL injection vulnerability. This isn’t just one issue, it’s two issues.
The second exploit is called a Stored Cross Site Scripting (Stored XSS) vulnerability. This is a particularly bad version of an XSS vulnerability.
With this kind of exploit a hacker can typically directly inject malicious files and then exploit the WordPress site and/or users. In general, a malicious file can be served to site visitors browser.
Loginizer Changelog
A changelog is a log of all the changes that a software developer makes to a software. When you update a plugin, WordPress gives you the opportunity to click and see a description of what those changes are. Those descriptions are from the changelog. All WordPress plugin developers have a running changelog in the WordPress plugin repository and also often on their website.
According to the official Loginizer changelog, this issue affects versions prior to the latest, which is Loginizer version 1.6.4.
The Loginizer plugin changelog describes the two patches like this:
“[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.
[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 should be commended for be forthright about describing the issue in their changelog.
Screenshot of Loginizer Plugin Changelog
Some plugin publishers try to hide that an update is a security fix by using technical jargon and not mentioning that there is a security fix.
Being honest about what the update is about, the way Loginizer does, is a sign of a good plugin developer.
WordPress Auto Update
WordPress triggered a forced auto update. Most sites running this plugin, up to 89%, should have had their plugin successfully updated.
It is highly recommended that all WordPress publishers who use the Loginizer security plugin to check which version of the plugin they are using and to udpate it immediately if it has not already done so.
