Jenkins Plugins Reveal Several Zero-Day Bugs

Jenkins, the very popular open-source automation platform used by enterprises worldwide for building, testing, and deploying software, announced last week that it had identified 34 security vulnerabilities affecting 29 plugins. Of the 34 security vulnerabilities, 29 are categorized as zero-day issues

Full details of the announcement can be found in this disclosure by Jenkins on the dozens of zero-day bugs in multiple plugins from Bleeping Computer, but here are the basics:

  • The zero-day vulnerabilities have CVSS scores that range from low to high severity
  • A total of more than 22,000 installs were potentially affected by these vulnerabilities
  • 144,000+ internet-exposed Jenkins servers could be exploited if they run an unpatched plugin

Feel like you have heard about this before?

This announcement further cements that zero-day issues are a problem that will not go away any time soon. As an industry, we are still recovering from the fallout associated with the Log4Shell and SpringShell zero-day issues. Now organizations that utilize Jenkins will have to start a new investigation to see if they are using any vulnerable plugins.

Jenkins Zero-Day Vulnerabilities You Need to Address

The types of issues found in the Jenkins plugins include XSS, Stored XSS, CSRF, missing or incorrect permissions checks, as well as passwords, secrets, API keys, and tokens stored in plain text. These issues are like the starting lineup in the security vulnerability all-star team. The challenge is not only finding out where these issues exist in your applications but which ones should be remediated first.

XSS (Cross-Site Scripting)

XSS (Cross-Site Scripting) is not something that ASPM directly looks for. However, when you utilize ASPM and SAST tools together, you can see the details of the XSS issue and a full context view of the application architecture via the ASPM map. ASPM provides you with every data flow in your application architecture, making remediating XSS issues easier than just SAST information.

Stored XSS

The issue with Stored XSS is that most organizations explicitly trust the data in their database. With ASPM, you can see all the application services connected to the database. This information makes it much easier to understand if you can trust the data in your database. Stored XSS issues would be a higher priority to fix if, after reverse engineering your application with  ASPM, you see that databases are being populated by, say, a third-party connection.

CSRF (Cross-Site Request Forgery)

This OWASP CSRF  provides a complete definition of Cross-Site Request Forgery. While ASPM again does not directly look for CSRF issues, ASPM does give you an in-depth view of how the application works. Hence, remediation and prioritization of CSRF issues are much more manageable. ASPM can help identify misconfigurations in your application architecture that could potentially cause a CSRF exploit.

Missing or incorrect permissions checks

By reverse-engineering the application artifacts, ASPM allows platform users to see if permissions are configured correctly. In addition, ASPM helps identify if permission issues affect more than just one application service.

Passwords in stored text

By reverse-engineering the code, ASPM sees all programmatic flows and information, including hardcoded passwords in compiled code and configuration files.

Secrets in stored plain text

By reverse-engineering the code, ASPM sees all programmatic flows and information, including secrets stored in plain text in compiled code and configuration files.

API keys in stored plain text

By reverse-engineering the code, ASPM sees all programmatic flows and information, including API Keys stored in compiled code and configuration files.

Tokens stored in plain text

By reverse-engineering the code, ASPM sees all programmatic flows and information, including Tokens stored in plain text in compiled code and configuration files.

When good software packages go bad

Organizations utilize many technologies to create applications, including source code, frameworks, libraries, and open-source packages. The problem with zero-day vulnerabilities is that suddenly, an application component deemed secure and compliant is now insecure. There is no way of knowing if an application component “may” become insecure until the release of a zero-day announcement. 

Since the risk is unknown, these newly insecure application components could be used hundreds or thousands of times in your application portfolio.

Why Should I Care?

According to Shodan Data, over 150,000 internet-facing Jenkins Servers are worldwide. That is a huge issue to address and prioritize without a complete application architectural context. Organizations are fighting a daily battle against zero-day type issues. No matter how cutting edge and forward-thinking your application security, architecture, and site reliability teams are, it is tough to protect against the unknown. 

ASPM lets you identify and prioritize which zero-day issues to fix first because it provides you with complete application architectural insight and context. ASPM is your bleeding-edge technology to help with mitigating zero-day issues.

 

Did you find this blog helpful or interesting?

Click the social media button of your choice to share the blog with you friends and colleagues.

See a Live Demo of the Bionic Platform