Shulou(Shulou.com)05/31 Report--

This article mainly introduces the example analysis of Jenkins plug-in vulnerabilities, the article is very detailed, has a certain reference value, interested friends must read it!

Jenkins is a widely used open source automation server that allows DevOps developers to build, test, and deploy software efficiently and reliably.

In order to take full advantage of Jenkins's modular architecture, developers use plug-ins to extend its core functionality. So far, there are more than 1600 community-contributed plug-ins in Jenkins's plug-in index. Some of these plug-ins store unencrypted plain text credentials. In the case of data leakage, cyber criminals can access this information without the user's knowledge.

We will focus on the following information disclosure vulnerabilities and the corresponding plug-ins affected:

At the time of this writing, vulnerabilities in the Port Allocator, testlink, and caliper-ci plug-ins have not yet been fixed. The current version of the eggplant plug-in is deprecated.

Access to stored credentials

The Jenkins plug-in vulnerability can be exploited to obtain user credentials. When user credentials with extended read privileges or access to the primary file system are compromised, attackers can also access other integration services, especially if users use the same password for different platforms or services.

Plug-in configurations are typically stored in $jenkins_home root in the form of a XML file, which defines the structure and settings of each plug-in. Usually the configuration of the plug-in is saved as part of the working configuration file, such as $jenkins_home/job s/new job/config.xml. If credentials are part of the plug-in configuration, they should be stored in encrypted form, while this is not the case for Gogs, Port Allocator, Caliper CI, TestLink, and eggPlant plug-ins.

Credentials are stored in unencrypted plain text:

The correct way to store credentials is to delegate them to a third-party credential provider, and then reference the plug-in by CredentialSid in the configuration file.

If the user can read the configuration file, they can only view the CredentialSid reference, and the actual credentials are stored in the reference.

The credential plug-in included in the default recommended plug-in list is used to store encrypted credentials. The details of the credential store are described below.

This plug-in stores encrypted credentials in $jenkins_home/credentials.xml.

In the above example, the password store is encoded with base64. By using the base64 decoder, we can observe that some non-printable characters are encoded.

In fact, encrypted passwords and encrypted metadata are encoded using base64.

The key used for decryption is hard-coded in Jenkins. Different installations of Jenkins will result in different key. The key is encrypted and stored in the $jenkins_home/secrets/hudson.util.secret file. The hudson.util.secret file is encrypted through aes with a key derived from the master key, which varies from one jenkins installation to another.

This means that protecting the $jenkins_home/secrets directory is critical to prevent the stored credentials from being disclosed. Executing a job or build on master may affect the overall security of Jenkins, such as installing plug-ins, creating new jobs, reading and deleting credentials, and other private data. Jobs running on master can also grant lower access and allow them to print data using the shell command.

Safety recommendation

Credentials stored in plain text can pose a direct threat. However, administrators should also keep in mind that users who have access to the $jenkins_home/secrets directory can also access the stored credentials. $jenkins\ u home/hudson.util.secret and $jenkins\ u home/secrets/master.key are files used to decrypt saved passwords, and their exposure can cause an attacker to decrypt stored passwords.

Like all DevOps tools, Jenkins should consider security. In its default settings, Jenkins does not perform security checks. Therefore, Jenkins recommends that users implement best practices, including user authentication and mandatory access control, rather than building on the primary node of a large system.

If the job must run on the primary node, Jenkins recommends using the Job restrictions plug-in, which can restrict job execution or node configuration based on user permissions.

The above is all the contents of the article "sample Analysis of Jenkins plug-in vulnerabilities". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.