WordPress Loginizer Plugin has released a security fix for a vulnerability that could allow a programmer to modify a database through an Unauthenticated SQL Injection exploit.
This sort of exploit, also called a Blind SQL Injection, depends on entering information into an input in order to trigger an error response. In this case the information is a username.
The Loginizer WordPress plugin didn’t have an approach to sterilize the info, which implies it didn’t have a way to make up for a mistaken information. This caused the plugin to make 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 specialist who found the vulnerability published a walkthrough of the Loginizer exploit, showing how an error response can be utilized to reach areas of the plugin that relate with it’s functionality. It is there that the programmer 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.”
The issue with Loginizer isn’t restricted to the SQL injection vulnerability. This isn’t only one issue, it’s two issues.
The second exploit is known as Stored Cross Site Scripting (Stored XSS) vulnerability. This is an especially terrible version of XSS vulnerability.
With this sort of exploit a hacker can typically directly inject malicious files and afterward misuse the WordPress site and/or users. In general, a malicious file can be served to site visitor’s browser.
A changelog is a log of all the changes that a software engineer makes to a product. When you update a plugin, WordPress offers you the chance 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.
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.
Speaking the truth about what the update is about, the way in which Loginizer does, is an indication of a decent plugin developer.
WordPress triggered a forced auto update. Most websites running this plugin, up to 89%, should have had their plugin successfully updated.
It is strongly suggested that all WordPress publishers who utilize the Loginizer security plugin to check which version of the plugin they are utilizing and to udpate it quickly if it has not effectively done already.
We at CodeLedge, are Sweden’s best WordPress Development Services provider. We are the experts at making a website fast and easy to load. Feel free to talk with us at firstname.lastname@example.org or get a quote from here.