Security Bulletin: IBM UrbanCode Deploy Agents Don't Verify Server Identity (CVE-2016-0271)

Summary

Mutual authentication in IBM UrbanCode Deploy ensures that unknown agents cannot connect to the server over JMS. However, if a trusted agent is compromised, it can impersonate the server and send work to other agents. Agents do not verify the identity of the server over either HTTP or JMS, and the server does not guarantee that agents receive only messages that were intended for them.

Vulnerability Details

CVEID: CVE-2016-0271**
DESCRIPTION:** IBM UrbanCode Deploy could allow a local privileged user to impersonate other users and obtain root privileges on other agents.
CVSS Base Score: 8.2
CVSS Temporal Score: See <https://exchange.xforce.ibmcloud.com/vulnerabilities/111051&gt; for the current score
CVSS Environmental Score*: Undefined
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H)

Affected Products and Versions

IBM UrbanCode Deploy 6.0, 6.0.1, 6.0.1.1, 6.0.1.2, 6.0.1.3, 6.0.1.4, 6.0.1.5, 6.0.1.6, 6.0.1.7, 6.0.1.8, 6.0.1.9, 6.0.1.10, 6.0.1.11, 6.0.1.12, 6.0.1.13, 6.1, 6.1.0.1, 6.1.0.2, 6.1.0.3, 6.1.0.4, 6.1.1, 6.1.1.1, 6.1.1.2, 6.1.1.3, 6.1.1.4, 6.1.1.5, 6.1.1.6, 6.1.1.7, 6.1.1.8, 6.1.2, 6.1.3, 6.1.3.1, 6.1.3.2, 6.2.0.0, 6.2.0.1, 6.2.0.2, and 6.2.1 on all supported platforms.

Even when you are using a non-vulnerable version of IBM UrbanCode Deploy, some agent actions might not verify the identity of the server correctly if you are using a vulnerable plug-in. The plug-in must be updated to the latest version. See the following table for information about plug-in versions. If a plug-in is not listed, it is not vulnerable.

| Vulnerable Versions| Fixed Versions
—|—|—
Artifactory Source Config| 4 and earlier| 5 and later
Cloud Foundry| 15 and earlier| 16 and later
Docker Source Config| 4 and earlier| 5 and later
File System (Versioned) Source Config| 4 and earlier| 5 and later
Git Source Config| 4 and earlier| 5 and later
IBM AnthillPro Source Config| 2 and earlier| 3 and later
IBM Cognos| 2 and earlier| 3 and later
IBM MobileFirst Platform (formerly Worklight)| 7 and earlier| 8 and later
IBM Rational Asset Manager Source Config| 3 and earlier| 4 and later
IBM Rational ClearCase Source Config| 4 and earlier| 5 and later
IBM Rational Team Concert SCM Source Config| 3 and earlier| 4 and later
IBM UrbanCode Build Source Config| 2 and earlier| 3 and later
IBM UrbanCode Deploy Applications| 69 and earlier| 70 and later
IBM UrbanCode Deploy Components| 66 and earlier| 67 and later
IBM UrbanCode Deploy Configuration Templates| 7 and earlier| 8 and later
IBM UrbanCode Deploy Environments| 71 and earlier| 72 and later
IBM UrbanCode Deploy Process|

1

| 2 and later
IBM UrbanCode Deploy Resources| 68 and earlier| 69 and later
IBM UrbanCode Deploy System| 61 and earlier| 62 and later
IBM UrbanCode Deploy Versions| 62 and earlier| 63 and later
Maven Source Config| 4 and earlier| 5 and later
Microsoft TFS (Team Foundation Server) Source Config| 5 and earlier| 6 and later
Microsoft TFS SCM (Team Foundation Server) Source Config| 3 and earlier| 4 and later
NuGet Source Config| 1 and earlier| 2 and later
Perforce Helix Source Config| 3 and earlier| 4 and later
Subversion Source Config| 8 and earlier| 9 and later
TeamCity Source Config| 5 and earlier| 6 and later
Websphere Application Server - Deployment| 90 and earlier| 91 and later
WinRS Agent Install| 5 and earlier| 6 and later
zOS Utility| 21 and earlier| 22 and later

Remediation/Fixes

For IBM UrbanCode Deploy 6.2 through 6.2.1, upgrade all servers, agents, and relays to IBM UrbanCode Deploy 6.2.1.1, and update plug-ins as indicated previously. For IBM UrbanCode Deploy versions 6.1.0.0 to 6.1.3.2, upgrade the server to IBM UrbanCode Deploy 6.1.3.3. Then, complete the following steps to enable certificate verification on the agents.

Enabling Agent Verification of Server Certificate During HTTPS Communication

Part 1: Creating a Valid Server Certificate

The server is installed with an existing private key and self-signed certificate with the alias server in a keystore in the _server_installation_dir_``/opt/tomcat/conf/tomcat.keystore file. The certificate is presented to agents, relays, and users that connect to the server via HTTPS. Because the certificate that is associated with this key has a generic distinguished name (DN), the key must be replaced so that the agent or relay can properly verify the host name of the server. Complete the following steps.

1. Stop the IBM UrbanCode Deploy server.
2. Go to the _server_installation_dir_``/opt/tomcat/conf directory of the server computer.
3. Generate a private key with the correct host name to use for HTTP communication. The existing key that is used for HTTPS communication is located in the tomcat.keystore file with the alias server. The following example shows a command to create a new key by using the Java keytool utility:

• keytool -genkeypair -alias serverNewCN -keysize 2048 -sigalg SHA256withRSA -keyalg RSA -keystore tomcat.keystore
• In the server.xml file, locate the HTTPS connector. The HTTPS connector has the SSLEnabled="true" property. Add a property to specify which alias in the keystore contains the certificate to use: keyAlias="serverNewCN".
• (Optional) You can create a certificate signing request by using this key, and then use an internal or external certificate authority to sign it. If you are using a certificate authority to sign the certificate, import the certificate of the CA (rather than the certificate of the UrbanCode Deploy server) into the keystore of the agent or agent relay in Part 2.
• Start the server, and upload the latest version of all vulnerable plug-ins (listed previously) to the server.

Part 2: Configuring Agents and Relays to Validate Server Certificates

By default, agents or relays that are upgraded from a pre-6.2.1.1 build accept all certificates, including self-signed certificates, and do not verify that the host name on the certificate is valid. After the server is configured to present a certificate with a valid host name, and the agents and relays are configured to accept that certificate, a property can be enabled on the agents to force them to verify the server host name, and accept trusted certificates only. Complete the following steps.

1. For each agent or relay, import the certificate into the keystore of the JRE that is used to run the agent or relay process. By default, the path to the keystore is $JAVA_HOME/lib/security/cacerts. (If the certificate is signed by a certificate authority that is already trusted by the agents and relays, you can skip this step.)
2. For each agent or relay, either set the UC_TLS_VERIFY_CERTS=yes environment variable on the agent, or add the verify.server.identity=true property to the agent or relay properties file. For an agent, this property file is _agent_installation_directory_``/conf/agent/installed.properties. For a relay, this property file is _relay_installation_directory_``/conf/agentrelay.properties.
3. Restart the agent or relay.

Note: Relays are vulnerable only if they are used to cache version artifacts. If you disabled this feature on relays, then only agents must be configured to validate the certificate of the server.

Workarounds and Mitigations

For versions IBM UrbanCode Deploy earlier than 6.1, upgrading to IBM UrbanCode Deploy 6.0.1.14 enables secure HTTPS communication between the server and the agents, and prevents agents from sending work to other agents via JMS. However, even with these changes, agents can still read instructions that are sent to other agents. Because of this behavior, upgrade to IBM UrbanCode Deploy 6.1.3.3 or IBM UrbanCode Deploy 6.2.1.1 as soon as possible. If it is not possible to upgrade to version 6.1.3.3 or later, complete the following steps to mitigate this issue on earlier versions of the product.

1. Upgrade all servers, agent relays, and agents to IBM UrbanCode Deploy 6.0.1.14.

2. For any plug-ins installed on the server that are listed as vulnerable, download the latest version of the plug-in and upload it to the server.

3. Follow the previous instructions in the Remediation/Fixes section under “Enabling Agent Verification of Server Certificate During HTTPS Communication”.

4. Implement an ActiveMQ access control list to ensure that clients can only read from, not write to, the agent queues. Instructions for using simple passwords or LDAP for the access control list are available in the attached text file.
SimpleAuthACLInstructions.txt