Don't let RabbitMQ vulnerabilities expose your CI pipelines
RabbitMQ is an open source message broker that exchanges asynchronous messages between publishers and consumers. The messages can be a human-readable JSON, a simple string or a list of values that can be converted into a JSON string.
In March of 2019, the Jenkins Security Advisory reported multiple vulnerabilities were found in . If your continuous integration pipelines rely on RabbitMQ, you’ll want to make sure your environment is hardened against any of the 1.1.9 version’s vulnerabilities.
Plugin configurations
Before you connect the plugin to the broker, Jenkins users are required to provide values for the following categories:
- name
- host
- port
- username
- password
The name is used to label the designated configuration on the build step. Default values are assigned to the host and port. You must create a unique username and the password is masked with asterisks.
After you complete these tasks, press the “Connection Test” button to ensure the values are properly used.
After a successful test, you can configure the build step with the following steps:
- RabbitMQ Name
- Exchange name
- Routing key
- Data
- Convert to JSON
Message routing
Rabbit-MQ Publisher doesn’t directly publish on RabbitMQ. Instead, a message is published to an exchange on the RabbitMQ exchange server — Windows, Linux or Ubuntu. The exchange decides how the message should be routed to queues.
Data can contain environment variables and build parameters. Once properly checked, data can then be converted to JSON format.
Plugin vulnerabilities
The first vulnerability was that passwords weren’t encrypted. They were stored in plain text in the plugin’s global configuration file on the Jenkins Master.
An attacker with low or no privileges could access the configuration file and view the passwords, and could also use the exposed password to change the values for the default host and port. New plugin versions encrypt all passwords before storage in a configuration file.
The second vulnerability was that the plugin’s missing permission check allowed any user to connect to Rabbit MQ. Users with Overall/Read access were vulnerable to, for example, Jenkins to initiate a Rabbit MQ connection to an attacker-specified host and port with an attacker-specified username and password.
This form validation method did not require POST requests, which resulted in a cross-site request forgery vulnerability. Fortunately, new versions include fixes. If you haven’t updated your Jenkins plugins and the older publisher is still active, the time to update is now.