MalCare uses broken cryptography to authenticate API requests from its remote servers to connected WordPress sites.
Requests are authentication by comparing a shared secret stored as plaintext in the WordPress database to the one provided by MalCare’s remote application.
This can allow attackers to completely take over the site because they can impersonate MalCare’s remote application and perform any implemented action, including, but not limited to:
- Creating malicious admin users.
- Uploading random files to the site.
- Installing/Removing plugins.
This is exploitable if any of the below pre-conditions are given:
- The site has one of the never-ending read-SQLi vulnerabilities in any plugin, theme, or WordPress Core. This recently happened with WooCommerce Stripe keys.
- The site’s database is compromised at the hosting level.
- Other methods that allow reading or updating WordPress options (wp_options), such as this wildly exploited Elementor vulnerability.
MalCare has received the full details of this vulnerability three months before this public release, and despite us offering (free) help, they subtly dismissed it because “supposedly” this is the industry standard for API authentication.
Note: WPUmbrella had the same conceptual vulnerability and fixed it within days.
Furthermore, concerns were raised, because the vulnerability requires a pre-condition that on its own, would be a vulnerability.
While this is true, the irony should be obvious here:
- MalCare, being a Malware Scanner, is only “useful” if your site has been infected with Malware.
- All Malware can read data from the database and steal the shared secret.
- Instead of infecting sites with “actual” Malware, hackers can steal the API key and then remove the Malware.
- ==> MalCare gives any Malware an undetectable, indefinite backdoor that can be used to reinfect sites repeatedly.