Vulnerabilities within third-party software might be your greatest risk, because you can’t control or influence the code. And once the the fix is out, the cat’s out of the bag. It becomes a “known vulnerability”. Known to the manufacturer/developer, known to its customers and most significantly, known to attackers.
The vulnerability, located in the platform’s REST API, allows unauthenticated attackers to modify the content of any post or page within a WordPress site. The flaw was fixed in WordPress 4.7.2, released on Jan. 26, but the WordPress team did not publicly disclose the vulnerability’s existence until a week later, to allow enough time for a large number of users to deploy the update.
“This vulnerability has resulted in a kind of feeding frenzy where attackers are competing with each other to deface vulnerable WordPress websites,” Mark Maunder, the CEO of Feedjit, said in a blog post Thursday. “During the past 48 hours we have seen over 800,000 attacks exploiting this specific vulnerability across the WordPress sites we monitor.”
There is one obvious reason WordPress sites were vulnerable: the WordPress core code itself contained the vulnerability.
But there is another, less obvious reason for the vulnerability: in this case, the vulnerability was within the REST API, which is a new WP module and not in use / not needed by the vast majority of self-hosted WordPress sites.
Two simple principles that would have protected you from this vulnerability
1. KEEP UP-TO-DATE WITH PATCHING—it’s such a simple thing, but falling behind on patching is one of the leading causes of exposure to vulnerabilities.
If keeping up with patching is overwhelming, consider hiring a managed IT partner that will monitor for vulnerabilities (as well as performance, availability and more) and patch your systems as well as be ready to act upon any issues that may arise from patching or otherwise.
2. DISABLE UNUSED/UNNEEDED FUNCTIONALITY—this is a critical best practice.
FOR EXAMPLE, If you need to fire up an IIS web server, turn off every service/module you don’t need. You can always turn them on as needed.
In the case of the WordPress REST API, which is mostly for communicating with EXTERNAL sites and services, you should leave this disabled until which time it is needed. By then, most of the kinks and vulnerabilities should be worked out, which is a good general rule of thumb; that is, as a product/feature becomes more mature, it becomes better, more secure.