A chain of high-severity vulnerabilities in Jenkins, the open-source automation server program that supports the software development lifecycle, and its Update Center, has been mitigated by the Jenkins project team.
The Aqua Nautilus Research team first discovered and reported the flaws in how Jenkins processed available plug-ins, and explained how adversaries could exploit those through cross-site scripting and remote code execution attacks.
The research team, which dubbed the vulnerabilities CorePlague, explained that attackers could exploit the flaws even if the Jenkins server was not directly reachable by the threat actors. Self-hosted Jenkins servers were also vulnerable, they added.
Adversaries could compromise multiple Jenkins servers by planting an infected plug-in in the software's Update Center, which Jenkins servers use by default to obtain plug-ins.
Once the Jenkins team approved a plug-in — usually just a procedural step — developers could upload upgrades to the original plug-in without any further involvement from the Jenkins team. So a threat actor could upload a benign plug-in, then upload a malicious version of it as an update without additional approval.
Here's how CorePlague works — and key takeaways for your application security team.
How attackers could poison a Jenkins plug-in
Here are the steps in the attack, as outlined by the Aqua Nautilus research team:
- After gaining access to the Update Center with a benign plug-in uploaded in an HPI file, the attacker would modify the file with an XSS payload inside the Jenkins version attribute and upload it to the Jenkins artifact registry.
- The Update Center would then fetch the plug-in and store the payload in a JSON file of available plug-ins.
- Jenkins servers accessing the Update Center would then pull down the JSON file from the center and their administrators would open the Available Plugin Manager page. That executes the XSS payload.
Raffi Erganian, co-founder of vulnerability management tool vendor Vulnera, explained the severity of CorePlague in a LinkedIn posting, noting that the vulnerability is triggered without any additional action from the victim, and the exploitation does not require the manipulated plug-in to be installed.
"Jenkins servers typically have a wealth of sensitive data, from SSH credentials, to passwords and keys to cloud providers. They're often used to build/push code and orchestrate software deployments. Ironically, given the amount of sensitive data, they're also rarely updated because of their criticality to business operations."
—Raffi Erganian
More extensive plug-in review processes may be impractical
A more robust review process for plug-ins might be a way to avoid the kind of security issues posed by CorePlague, but that's not always practical in the open-source software world, said Karlo Zanki, reverse engineer at ReversingLabs.
"In the ideal world, every piece of software published to any kind of public repository should be reviewed rigorously. But that is often not doable nor scalable by the maintainers of such repositories. They simply don't have the resources to perform such a review."
—Karlo Zanki
For example, developers publish more than 10,000 versions of different packages published in the repositories for Python, PyPI, and npm daily, Zanki said. "There is no way such a large amount of packages could be reviewed in adequate time."
Zanki urged consumers of extensions and packages to make security reviews of software packages and components they intend to use a priority, given the state of software supply chain chain security. "If they don't have the required resources, they should seek appropriate assistance," he said.
Lessons learned from CorePlague
The Jenkins team released a patch for the public Jenkins Update Center on February 15, which mitigates some risks associated with this vulnerability since it is the first component involved, The Aqua research team noted:
"This is particularly significant since most Jenkins users rely on the public Jenkins Update Center for the list of the available Jenkins plug-ins. This means that if you rely on the public Jenkins Update Center to get plug-ins, your Jenkins server will be vulnerable but probably not exploitable. Thus, there is no immediate need to update it."
However, the research team added, "if you use self-hosted or customized Update Centers, you are at risk."
They also found that while Jenkins installs that are older than 400 days are immediately exploitable, Jenkins Servers under 400 days old were vulnerable to the vulnerabilities but could not be exploited immediately. But if those servers were not updated and remained out-of-date, they could be exploited in the future.
That underscores the importance of maintaining a regular update schedule for all components of the environment, which can help to prevent known and unknown vulnerabilities from being exploited, they added:
"Our research highlights the importance of defense-in-depth strategies for securing environments. It is critical to have multiple layers of protection in place to safeguard the environment and its components from vulnerabilities."
If you implement different security measures, even if one component is compromised, the other layers of protection can mitigate the damage and prevent an attacker from escalating their attack, the researchers explained.
The surge in supply chain attacks in recent years warrants a comprehensive approach to application security, Zanki said:
"Any piece of software that gets installed into the development environment, regardless of if it is dedicated software or an extension/plug-in of some kind, should undergo a security review before being cleared for usage."
Article Link: Jenkins patches high-severity XSS vulnerabilities: Lessons learned from CorePlague