WordPress Loginizer Plugin issued a security patch for a vulnerability that could allow a hacker to modify a database through an exploit called Unauthenticated SQL Injection.
In order to trigger an error response, this sort of exploit, also known as a Blind SQL Injection, relies on entering data into an input. The input is a username in this case.
There was no way for the Loginizer WordPress plugin to sanitise the input, which means that it did not have a way to compensate for the erroneous input. This caused the plugin to create a situation with an error.
According to the Loginizer exploit description of WPScan:
“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.”
A walkthrough of the Loginizer exploit was published by the security researcher who discovered the vulnerability, showing how an error response can be used to reach areas of the plugin that relate to its functionality. The hacker can see that he is vulnerable to an injection of SQL.
Researcher describe 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 sanitize 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 issue with Loginizer is not limited to the vulnerability of the SQL injection. This is not just a single issue, but two issues.
A Stored Cross Site Scripting (Stored XSS) vulnerability is called the second exploit. This is an especially bad version of a vulnerability in XSS.
A hacker can typically directly inject malicious files with this type of exploit and then exploit the WordPress site and/or users. A malicious file can generally serve on the browser of site visitors.
Loginizer Changelog
A change log is a log of all the changes that are made to a software by a software developer. WordPress gives you the chance to click and see a description of what those modifications are when you update a plugin. These are descriptions from the Changelog. In the WordPress plugin repository and also often on its website, all WordPress plugin developers have a running changelog.
This issue affects versions prior to the latest version, which is Loginizer version 1.6.4, according to the official Loginizer change-log.
The change log of the Loginizer plugin describes the two patches in this way:
“[Security Fix] : The SQL injection could result in a properly crafted username used to login. PHP Prepare fixed it using the function that prepares the secure execution of the SQL query.
[Security Fix] : If the IP HTTP header modified to have a null byte it could lead to stored XSS. Fixed by sanizing the HTTP IP header properly before using the same one.”
For describing the problem in their changelog, we should commend loginizer for being forthright.
WordPress Auto Update
WordPress triggered a forced auto update. Most sites running this plugin should have had their plugin updated successfully, up to 89 percent.
We recommend that all WordPress publishers who use the security plugin Loginizer check which version of the plugin they are using and immediately update it if they have not already done so.
You may also like:
Leave A Comment