In an uncommon move, WordPress developers earlier this month automatically pushed an important security update for the popular Loginizer plug-in to roughly 1 million people, which caught some unsuspecting users off-guard in the process.
The decision, which was made to ensure a significant vulnerability didn't wreak havoc, is one all software and app developers wrestle with themselves when establishing patching policies: under what circumstances should software updates be taken out of the hands of users? And should potential backlash factor into the decision making?
Citing the plug-in’s author, the WPScan WordPress Vulnerability Database reported that the forced update successfully patched 89 percent of the WordPress sites that use Loginizer, a plugin that helps fight brute-force attacks.
Even users who had not enabled the auto upgrade feature on WordPress were nevertheless updated to version 1.6.4, which fixed a SQL injection vulnerability (discovered by researcher Slavco Mihajloski) and cross-site scripting flaw. Experts said the pushed patch was a prudent move, despite some users expressing confusion or displeasure via Twitter and on WordPress's support page.
Chloe Chamberland, a threat analyst at Wordfence, cited several key factors that should be considered when deciding whether or not to force an update. These include “the criticality of the vulnerability, how easily the vulnerability can be exploited, permissions required to exploit the vulnerability, and potential impact that an update could cause.”
The Loginizer patch made sense, said Chamberland, because the vulnerability was “trivial to exploit,” and the plug-in has a large user base. “A simple apostrophe in the username entered into Loginizer led to an unauthenticated SQL injection attack which could be used to inject stored cross-site scripting in an admin view, which could then be used for site takeover. We were surprised that it took this long to find this vulnerability.”
“I think users should be grateful to WordPress for taking care of their website security,” agreed Ilia Kolochenko, founder and CEO of ImmuniWeb. “Given the critical risk of the vulnerability and the ease of exploitation, unpatched plug-ins are a major risk not only for careless website owners but for the integrity of their website visitors, whose confidential data and PII may be stolen and then sold or exploited.”
“Furthermore, attackers can likewise install a sophisticated malware on the compromised website and infect visitors’ computers or mobile devices with a ransomware.”
According to Mike Puglia, chief strategy officer at Kaseya, website operators generally can’t be trusted to apply software updates in a timely manner, “especially when alerts pop up out of the blue that disrupt their workflow. More often than not, users put off installing updates – some of which are critical to their systems – because they don’t want to be inconvenienced.” This places users of these websites in danger of a serious cyberattack.
Kolochenko went so far as to say such forced updates should be made on a regular basis for its WordPress's popular plugins.
Of course, there are potential pitfalls to such a strategy.
“The most disastrous possibility would be if the supply chain was compromised and automatic updates could be used to push malicious code,” said Ram Gall, Wordfence QA engineer and threat analyst. “While this would be catastrophic, there are processes in place to prevent this. The WordPress plugin’s team reviews the patch prior to pushing a forced update to determine potential impact and verify a patch isn’t introducing a new vulnerability.”
There’s also the less extreme, yet more likely scenario, “where the update hasn’t been sufficiently tested and introduces bugs or incompatibilities,” Gall added. “This could potentially bring down a website or introduce further vulnerabilities, and the patch might not always fully correct the original vulnerability, leading to a false sense of security.”
Puglia agreed that there’s always the potential of an update breaking something. However, “most vendors rigorously test their patches and updates to anticipate common issues and preemptively address them in order to minimize disruption to end users.” Even if a small number of users are temporarily inconvenienced, “vendors and IT admins have a duty to ensure the security of the greatest number of users” by pushing the update through.
The risk of disruption resulting from the Loginizer update was low, Gall said, “since the patch effectively updated the plugin to use prepared statements – a best practice – via a core WordPress function. In other words, the patch was relatively simple and was unlikely to introduce any bugs.”
Logically speaking then, if risk of breaking a website is much lower than the risk of a bug being exploited, then a forced update should be deemed acceptable, argued Chamberland. "What is worse? A broken site that can be fixed by disabling a plug-in but is secure from compromise, or a site that is vulnerable to [a compromise] that could cost a lot of time and money to resolve?”
For that matter, there are ways developers can further reduce the risk of an update going wrong or being received poorly by the user community.
“WordPress should make sure that its terms of service and EULA contain clauses that expressly allow them such unrequested updates in a clear and conspicuous manner,” recommended Kolochenko, who warned there could be potential civil damages or even criminal hacking charges if an update did cause problems.
Gall also emphasized the importance of code review and testing. Developers keeping security patches separate from feature updates also helps, he said, “since feature updates… are far more likely to suffer from incompatibilities or unforeseen issues.”
Effective communication is especially key, experts concur, especially if something does go awry.
“It could be as simple as a mechanism to email administrators informing them why an update is being pushed. Likewise, a mechanism to monitor any issues caused by updates would be useful,” said Gall.
Additionally, “Be transparent so users understand the significance of the update and how it directly affects them,” said Puglia. “The more information you can share upfront, the more likely users will embrace the need for the update.”
Robert Capps, vice president, market innovation at NuData Security, said another good communication practice is to "author and publish protocols for how such events will be handled in the future." Moreover, "organizations should also look to notify clients as soon as possible about impact, and assist customers with resolution of problems stemming from forced security patches and upgrades on supported applications."
Puglia also suggested that software developers give users a deadline to install the updates themselves before commencing the involuntary push. “This approach gives users the option to perform updates when it’s convenient for them, with the safety net that if they forget to do so by a certain time that the update will happen automatically. When it comes to deploying the automated push, it’s helpful to time the updates during off hours to lessen the impact and disruption on users.”