A researcher has discovered vulnerabilities in more than 100 plugins designed for the Jenkins open source software development automation server and many of them have yet to be patched.
NCC Group Security Consultant Viktor Gazdag has manually tested hundreds of plugins that extend Jenkins’ functionality and identified vulnerabilities in over 100 of them. The flaws are mostly related to storing passwords in plain text, and cross-site request forgery (CSRF) issues with missing permission checks that can allow hackers to steal credentials and launch server-side request forgery (CSRF) attacks.
“Although Jenkins encrypts the passwords in the credentials.xml file, some of the plugin developers made use of other ways to store the credentials in the plugin’s own .xml file or in the job’s config.xml file. In the majority of cases these solutions did not involve any encryption. In addition, sometimes the web form where the user submits the credentials revealed the password or the secret token and did not use the correct Jelly form control,” Gazdag explained in a blog post published on Thursday.
“This could be problematic because the default installation (either it was a Docker container image or was installed by a package manager) had the default permission, which was world-readable on the credentials.xml, the plugin’s own global configuration xml file and for each of the jobs’ config.xml. It is worth mentioning that a lot of Jenkins hacking tutorials only mention the credentials.xml file and do not discuss the other two files. Not to mention that the workspace folder could temporarily store some juicy information as well,” he added.
As for the CSRF issues, they are related to functions in the plugins that allow users to test credentials and connect to a server. The CSRF flaws are introduced due to the fact that plugin developers have failed to enforce POST requests, which prevent attacks by using a CSRF token.
The vulnerabilities and the affected plugins are described by Jenkins developers across several advisories published in the past two years, including an advisory released in early April that describes the flaws found in roughly 60 plugins. The advisories show that the security holes found by Gazdag have been assigned “low” and “medium” severity ratings.
The impacted plugins interact with a wide range of services, including Twitter, AWS, VMware and Azure. In most cases, these plugins have been created by third-party developers that have no affiliation to the vendor whose software is used by the plugin.
In some cases, the developers of the affected plugins appear to have released patches since Jenkins developers released advisories, but many remain vulnerable.
Jenkins developers have released advisories for unpatched vulnerabilities to allow administrators to decide for themselves if they still want to use the insecure plugins.
“The Jenkins security team triages incoming reports both to Jira and our non-public mailing list. Once we’ve determined it is a plugin not maintained by any Jenkins security team members, we try to inform the plugin maintainer about the issue, offering our help in developing, reviewing, and publishing any fixes. Sometimes the affected plugin is unmaintained, or maintainers don’t respond in a timely manner to the notifications or the followup emails we send,” explained Daniel Beck, a Jenkins core maintainer and head of the Jenkins security team.
