IBM WebSphere Message Broker And Integration Bus Both Vulnerable To POODLE

Posted on | by admin

[fusion_text]Shortly after its announcement that WebSphere MQ could be exposed to the POODLE vulnerability, IBM issued a similar warning for its IBM WebSphere Message Broker and IBM Integration Bus (IIB) products. POODLE is short for Padding Oracle On Downgraded Legacy Encryption and it exploits an opening in SSLv3. Because SSLv3 is enabled by default in IBM WebSphere Message Broker and IBM Integration Bus, hardening against POODLE is critical. (See TxMQ’s coverage of the WebSphere MQ vulnerability here.)
OpenSSL could allow a remote attacker to bypass security restrictions. When configured with “no-ssl3” as a build option, servers could accept and complete an SSL 3.0 handshake, which could then be exploited to perform unauthorized actions.

Affected Products

The specific list of affected products includes:

  • IBM WebSphere Message Broker V7.0 and V8.0
  • IBM Integration Bus V9.0
  • IBM WebSphere Message Broker Hypervisor Edition V8.0
  • IBM Integration Bus Hypervisor Edition V9.0
  • IBM SOA Policy Pattern for Red Hat Enterprise Linux Server

Workarounds

The most important action is to disable SSLv3 and switch to TLS protocol on Message Broker and IIB servers and clients. Product-specific instructions, with direct links to the more detailed instructions in the IBM Knowledge Center, are listed below.

Inbound Connections

The attack vector is around inbound. The outbound connections may stop working if the server disallows SSLv3.
Inbound HTTP connections using the Broker-wide listener: Instructions found here.
mqsichangeproperties broker name -b httplistener -o HTTPSConnector -n sslProtocol -v TLS
Inbound HTTP connections using the integration server listener will by default use TLS (as the integration server listener defaults to TLS). If however it has been modified to match the broker-wide listener, use these instructions to make the necessary changes to use TLS.
mqsichangeproperties broker name -e integration_server_name -o HTTPSConnector -n sslProtocol -v TLS
Inbound SOAP connections using the non-default broker-wide listener: Instructions found here.
mqsichangeproperties broker name -b httplistener -o HTTPSConnector -n sslProtocol -v TLS
Inbound SOAP connections using the integration server listener (the default choice) will by default use TLS (as the integration server listener defaults to TLS). If however it has been modified to match the broker-wide listener, use these instructions to make the necessary changes to use TLS.
mqsichangeproperties broker name -e integration_server_name -o HTTPSConnector -n sslProtocol -v TLS
TCPIP Server inbound: Instructions found here.
mqsichangeproperties MYBROKER -c TCPIPServer -o myTCPIPServerService -n SSLProtocol  -v TLS
WebAdmin inbound: Instructions found here.
mqsichangeproperties brokerName -b webadmin -o HTTPSConnector -n sslProtocol -v TLS
ODBC (DataDirect) OpenSSL as configured in odbc.ini: The ODBC Oracle Wire Protocol driver allows for the EncryptionMethod connect option to be set to a value of 5, which means only use TLS1 or higher. Setting EncryptionMethod=5 for the Oracle Wire Protocol driver will avoid POODLE. This functionality has been available since 6.1 version of the Oracle WP driver. The providers of DataDirect drivers are working on similar functionality to all other ODBC drivers that support SSL and upgrading the version of OpenSSL used within the drivers to pick up the enhancement to SSL negotiation.
The client-based ODBC drivers (DB2 Client and Informix Client) rely on the SSL implementation within the database’s client libraries. See client libraries to learn about possible exposure to POODLE.

Outbound Connections

Once the servers are changed to use TLS, it’s important to update the outbound settings with the following commands. Note that in all the following instructions, TLS can be substituted for SSL_TLS or SSL_TLSv2 if needed.
For HTTP connections: Instructions found here.
Then in the SSL tab of the Request node(s) select TLS for the Protocol.
For SOAP connections that have been modified to use the non-default SSLv3 protocol: Instructions found here.
Then in the SSL tab of the Request node(s) select TLS for the Protocol.
TCPIP Client: Instructions found here.
mqsichangeproperties MYBROKER -c TCPIPClient -o myTCPIPClientService -n SSLProtocol -v TLS
JMS Nodes: Some information found here. Follow instructions as provided by your JMS Provider.
Follow instructions as provided by your JMS Provider.
CICS Nodes: Instructions found here.
the CICS nodes use TLS by default, so no change needed.

Security Providers

WSTrust: Set the environment variable MQSI_STS_SSL_PROTOCOL to “TLS”
TFIM: Set the environment variable MQSI_TFIM_SSL_PROTOCOL to “TLS”
Click here for IBM’s full CVE-2014-3566 bulletin.
TxMQ is an IBM Premier Business Partner and “MQ” is part of our name. For additional information about this vulnerability and all WebSphere-related matters, contact president Chuck Fried: 716-636-0070 x222, mailto:[email protected].
TxMQ recently introduced its MQ Capacity Planner – a new solution developed for performance-metrics analysis of enterprise-wide WebSphere MQ (now IBM MQ) infrastructure. TxMQ’s innovative technology enables MQ administrators to measure usage and capacity of an entire MQ infrastructure with one comprehensive tool.
(Photo by greg westfall under Creative Commons license.)
[/fusion_text]