Broken cryptography example - MalCare, Blogvault, and WPRemote for WordPress

Rsearch of the MalCare WordPress plugin, which is currently active on more than 300,000 websites exposed a vulnerability that use of broken cryptography for authenticating API requests:

The requests from MalCare's remote servers to connected WordPress sites are authenticated by comparing a shared secret stored as plaintext in the WordPress database to the one provided by MalCare's remote application.

This exposes the WordPress to an attack with the following sequence:

• An attacker gains access to the shared secret in WordPress, using an SQL injection, compromised database access or vulnerable plugins.
• The attacker constructs requests representing themselves as MalCare and sends command to the WordPress sites
• The attacker can create unauthorized admin users, upload arbitrary files, installi/remove plugins and clean up any logs indicating malicious activity.

The same vulnerability exists in the WPRemote (20,000 installations) and Blogvault (100,000 installations) plugins, as they share the same code.

Arguments pro and con

As a point of discussion, it's correct that exploiting broken authentication requires a pre-condition of another vulnerability existing on the system. This is exactly the argument that MalCare responded with when they were informed about the vulnerability months in advance of the public announcement.

And yes, there are many other services that operate with the same shared secret approach to exchanging messages. And it may be fine for some services, if the risk profile of the applications is low enough.

But the risk balance in the context of MalCare is quite poor, because of the permissions and abilities that are given to MalCare

Nevertheless, the implementation exposes both the WordPress site as well as MalCare to additonal risk:

• The number of Wordpress vulnerabilities is huge, the largest in all CMS systems simply because of the wide range of third party plugins available.
• There is a risk from a disgruntled employee who can 'leak' the secret and still have plausible deniability for any maliciou actions.

Alternative implementation

Instead of using a shared secret an assymetric key signing mechanism is a much better implementation. In that implementation the WordPress site will just have the public key of the service like MalCare which is not a secret at all. Any requests received from MalCare will be signed by the private key of MalCare and verified by the public key stored in the WordPress site.

That way, MalCare needs just to keep the confidentiality of their private key, for which there are good practices already defined - either in Vault like applications or in secure parameter stores or a KMS systems provided by the hosting provider.