When Patching Fails to Hit the Mark
Two separate vulnerability reports serve to illustrate that even best practice processes can fall short in the real world.
Two recent different cases of potentially large numbers of vulnerabilities in popular enterprise products illustrate the challenges faced by the industry.
More than 100 different Jenkins plugins have had security flaws identified in them over the last 18 months, according to researchers, and in spite of the developers being contacted, many remain open to exploit. Jenkins is a web-based application, popular with enterprise developer teams for running automated tests pre-deployment.
The Jenkins team has issued a string of security advisories about affected extensions (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), all discovered by NCC Group Security Consultant Viktor Gazdag. The underlying problem will be familiar to many open source software engineers - abandoned third-party plugins that no longer receive support. The result is a growing number of legacy plugins that no longer receive security patches, so quietly accumulate unpatched security flaws over time.
Some of the vulnerabilities are particularly unpleasant however, according to Gazdag’s research, with the most common security flaw being passwords stored in cleartext inside configuration files, rather than in the main - encrypted - Jenkins credentials.xml file.
Gazdag also found CSRF (Cross-Site Request Forgery) flaws that allowed attackers to use plugins' "connection test" functions to potentially send credentials to a server controlled by the attacker.
Meanwhile, a variety of SAP exploits dubbed 10KBLAZE has been posted online, which could theoretically impact 90% out of an estimated total of 1,000,000 SAP production systems - although this figure is somewhat sensationalist for several reasons. Most importantly, the underlying vulnerabilities have been patched by SAP, but if systems are not correctly configured then the updates may not have been applied, a situation that applies to large numbers of systems, according to researchers at Onapsis Research Labs.
The results of misconfiguration in this case are quite severe, as vulnerable SAP systems could potentially be remotely exploited by unauthenticated attackers, resulting in data exfiltration and/or data deletion.
The Onapsis’ Research Labs research said in a statement that it: "became aware of the release of these new exploits on April 23rd. The exploits can be leveraged to abuse a critical configuration issue in SAP NetWeaver installations (including S4/HANA) that, if not corrected as recommended by SAP, could lead to a full system compromise by attackers, without even requiring a valid SAP user ID and password." The full Onapsis' threat report [PDF] is here.
The report drew swift response from SAP, which is keen to point out that patches have been issued: “SAP is aware of recent reports about vulnerabilities in SAP Gateway and Message Server, however these have been patched by SAP a few years ago. Security notes 821875, 1408081 and 1421005 released in 2009 and 2013 will protect the customer from these exploits. As always, we strongly advise our customers to apply these security notes immediately and ensure secure configuration of their SAP landscape.”
However, even if Onapsis is only partially correct about the number of misconfigured SAP systems, that still implies there are thousands of potentially vulnerable systems, in spite of SAP’s best efforts.
Indeed, the underlying issues behind these two headlines - degraded support for legacy applications, and misconfiguration and/or lack of patching - continue to be major issues for the security industry as a whole. The process of identifying and reporting vulnerabilities responsibly, the vendor then patching (or attempting to work with third party developers in order to patch) has still resulted in sub-optimal security - in spite of best efforts to the contrary. As security pundits have pointed out before, maybe patching doesn’t work - but what alternative is there in the real world?