Responsible Disclosure : Security Misconfiguration leading to HPE's Jenkins exposed to internet without authentication

Introduction

In the world of DevOps and CI/CD, Jenkins holds a special place as a versatile automation tool. However, like any software, it's not immune to security vulnerabilities or misconfiguration. In this blog post, we'll explore a recent Jenkins security misconfiguration issue I discovered and reported to HPE Security Response on 5th May 2023. Now that the issue is resolved, I'm sharing the technical details of the discovery.

Disclaimer: Rest assured, no information has been disclosed to any third party, and no actions have been taken that could potentially harm the organization. It's important to clarify that no scanning of HPE assets has occurred. In adherence to the responsible disclosure process, I promptly reported the identified issue and maintained complete confidentiality for over 150+ days before sharing this disclosure. This publication strictly refrains from revealing any information related to HPE, their users, customers, or any associated entities. This is work from my personal time and not related to any of my current or past employer.

A Focus on CICD Security and Jenkins

My research work in CICD security led me to closely examine Jenkins, a critical component in many development pipelines. For a deep dive into Jenkins Attack Surfaces, you can refer to my GitHub repository [here](https://github.com/dibsy/Recipies-Of-A-Jenkins-Hacker).

Identifying Exposed Jenkins Controllers

The challenge at hand was identifying publicly exposed Jenkins controllers efficiently. To avoid extensive scanning efforts, I turned to Shodan, a specialized search engine for internet-connected devices. It helped me spot exposed Jenkins controllers quickly.

During a thorough analysis of numerous results using a custom analysis tool I developed ( https://github.com/dibsy/jenkills ), I came across multiple exposed instances associated with various organizations, including one within HPE.

Unearthing the Jenkins API Quirk

A significant hurdle emerged when trying to determine these controllers belonged to which organizations. Reverse IP lookups typically pointed to AWS / Azure where many Jenkins infrastructures are hosted as organizations prefer to use Cloud for CICD build environments. The other option would have been going into individual builds and investigating organization emails / internal urls.

My breakthrough came when I discovered a feature of the Jenkins API: "http://jenkins-server/api/json". This endpoint provides a ton of information about the Jenkins controller including a "url" key associated with a FQDN which points to the same IP. Sometimes this key can hold the value of the host IP. You can also find a generic response here https://github.com/dibsy/Recipies-Of-A-Jenkins-Hacker/tree/main/enumeration . Please note the below response is from a test environment and does not belong to impacted org's Jenkins controller

Root Cause Analysis

Upon attempting to access the website via the discovered FQDN ( xxx.xxx.xxx.hpe.com:8443 ), I encountered certificate errors, indicating authentication issues. Many organizations rely on this method for secure access to their applications using from browser using a client certificate authentication.

The issue likely stems from an initial design expectation that only successful authentication to the Jenkins controller would be allowed based on the Fully Qualified Domain Name (FQDN) of the controller. In such a design, a valid client certificate would facilitate authentication, while any other attempt would trigger a negotiation error, safeguarding the system.

However, the problem arose due to the absence of any restrictions when attempting to access the controller via its IP address. This oversight allowed Shodan to detect the exposed controller in the first place, revealing an unintended exposure.