Security flaws in 100+ Jenkins plugins put enterprise networks at risk

NCC Group researcher finds security flaws impacting more than 100 Jenkins plugins.
Written by Catalin Cimpanu, Contributor

A security researcher has found and reported security flaws in more than 100 different Jenkins plugins over the last 18 months, and despite efforts to notify developers, many of these plugins have not received a fix.

The Jenkins team has issued ten security advisories about these vulnerabilities in the last 18 months, warning developers to uninstall vulnerable extensions [1, 2, 3, 4, 5, 6, 7, 8, 9, 10].

What is Jenkins?

NCC Group Security Consultant Viktor Gazdag is credited with discovering all the vulnerabilities, all of which impact plugins for Jenkins, a common web-based application used by developer teams.

Jenkins, which is coded in Java, works as a continuous integration/deployment system that allows dev teams to run automated tests and execute various operations based on test results, including deploying new apps and code to production servers.

Because of its useful testing and automation features, Jenkins is wildly popular --in the enterprise sector, especially-- with nearly 79,000 instances, according to Shodan, a search engine for discovering internet-connected systems.

Vulnerabilities impact plugins, not Jenkins

Just like with any modern web utility, Jenkins' standard feature set can be extended via plugins, and like with most open-source projects, the vast majority of Jenkins plugins have been created by third-party developers.

Unfortunately, similar to what happens with most open-source projects nowadays, developers can't provide support for their code indefinitely, and some of these plugins have been abandoned, with no one left to provide support.

Now, Gazdag is warning owners of Jenkins systems that some of these abandoned plugins may end up putting corporate systems at risk, due to unpatched security flaws, some of which are extremely dangerous.

The most common vulnerabilities

The NCC Group researcher said that some of the most common security flaw he found was that many Jenkins plugins stored passwords in cleartext inside their configuration files, rather than use the main Jenkins credentials.xml file, which automatically encrypts all data stored inside it.

For example, if a plugin designed to interconnect Jenkins systems with third-party technology, like a database, a message broker (MQ) server, or a cloud provider, failed to encrypt the password inside its config file, an attacker who managed to retrieve this information would be granted easy access to those systems as well.

Furthermore, Gazdag also found CSRF (Cross-Site Request Forgery) flaws that allowed threat actors to use plugins' "connection test" functions to send credentials to an attacker's server, and SSRF (Server-Side Request Forgery) flaws that allowed threat actors to port-scan and map companies' internal networks, or brute-force login credentials.

In the past, Jenkins systems have been targeted by cryptocurrency-mining botnets, but many of the vulnerabilities Gazdag discovered may not be suitable for automated attacks.

Instead, these flaws are ideal for reconnaissance operations and targeted attacks, which many of the companies that use Jenkins systems usually try to avoid with a higher priority than a low-importance crypto-mining malware infection.

Last year, security researchers from CyberArk also found two vulnerabilities that let anonymous users become Jenkins admins.

Data leaks: The most common sources

More vulnerability reports:

Editorial standards