New Wordpress Vulnerabilities: CVE-2016–10033d and CVE-2017–8295
Two days ago, security researcher David Golunski announced a severe Wordpress vulnerability: one that allowed arbitrary code execution on the targeted server.
As discussed in the announcement, Wordpress had an injection vulnerability in its use of the PHPMailer library. In version 4.7.1, this vulnerability was fixed.
But that doesn’t mean the problem has been solved. Many Wordpress installations do not have automatic updates enabled. And many hosting providers do not maintain their customers’ installations, or require them to be updated. Therefore, many users are still vulnerable today.
And yesterday, Mr. Gollunski announced a second vulnerability, that hasn’t been fixed. This one, if successfully exploited, can give an attacker full administrative access to the Wordpress account.
Wordpress is used by about 28% of all websites. In terms of the percentage of the Internet that’s exposed to being compromised, these exploits are among the largest to date.
This situation is a powerful illustration of an uncomfortable truth. Most web security solutions have not kept up with the current threat environment.
First of all, conventional signature-based analysis is obsolete. New zero-day exploits are always being discovered, sometimes (as we see here) with enormous scope. But many conventional security products can’t detect them until patches are developed, tested, and installed. Meanwhile, users remain vulnerable.
Here at Reblaze, the opposite is true. Our customers were never exposed to these vulnerabilities. The Reblaze cloud web security platform protected against these exploits (along with countless others), even before they were discovered.
That’s because Reblaze doesn’t rely only on signature recognition. It does look for known attack signatures, but it also incorporates many other methods of threat recognition.
For example, code injection attacks (such as the first Wordpress exploit above) are blocked with Reblaze’s application whitelisting. This is a strictly-defined ruleset which defines the allowed headers, HTTP methods, resources, content-types, encoding, languages, forms, input fields, etc. within an application. By its nature, code injection requires inputs that fall outside of the acceptable boundaries — which means Reblaze detects and blocks it, even if that specific exploit has never been seen before.
Different attack vectors are addressed differently within Reblaze. For example the second Wordpress exploit above is defeated not by detecting code injection (which the exploit doesn’t use), but by shutting down the accompanying DoS attack.
Of course, the Internet is always evolving, and new web threats are always arising. Let’s say that a zero-day attack arises which Reblaze does not currently protect against. What then?
Again we see that cloud web security is the best approach. Whenever a new threat is discovered, the cloud allows us to immediately deploy countermeasures across all Reblaze deployments, worldwide. Our customers always have the latest forms of protection, and they don’t have to lift a finger to get it — it’s all done for them, immediately and automatically.
Moreover, the cloud allows us to use powerful technologies such as big data and machine learning. Even as the Internet evolves, Reblaze is always learning and adapting. Would-be attackers must contend not merely with a WAF appliance or whatever — instead, they have the computing capacity of the global cloud working against them, detecting their attacks and defeating them.
For most organizations today, a successful compromise of their web assets (their site, apps, or services) would be a serious blow. These Wordpress exploits remind us that new vulnerabilities are always being found, sometimes at very large scales.
Robust web security is vital. Don’t entrust it to inadequate or obsolete security products.
For more information about Reblaze, contact us at hello@reblaze.com or visit our website at https://www.reblaze.com/.
