Heartbleed OpenSSL: SAP BI Platform and Tomcat testing

See also my previous blog: Installing SAP BI 4.1 SP01 on Red Hat Enterprise Linux 6.x Step-by-step

The Heartbleed Bug has generated a lot of discussion. In this Blog, I will go over what I know about Heartbleed based on my personal experience. Be advised that this blog is for informational use only and SAP BI Support has authored a KBA (pertaining to the BI Platform) will be continually updated with all of the knowledge we have around this topic.

Resources:

Summary of the Heartbleed Bug:

The Heartbleed Bug is a serious vulnerability in certain versions of the OpenSSL cryptographic software library.  The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by vulnerable versions of OpenSSL.  An attacker could then obtain encryption keys which will allow decryption of past and future traffic to protected sites.

Affected OpenSSL versions:

• Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

Status of different versions:

•     OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
•     OpenSSL 1.0.1g is NOT vulnerable
•     OpenSSL 1.0.0 branch is NOT vulnerable
•     OpenSSL 0.9.8 branch is NOT vulnerable

SAP BI Platform SSL:

Here is a breakdown of where SSL is leveraged in the BI platform:

	Streamwork integration: XI3.1 and BI4.x includes redistributes OpenSSL 0.9.8 which is unaffected by heartbleed.  in addition, this library is used only in situations where outbound connections with SAP Streamwork is leveraged.
	Server to Server SSL (Corba) In situations were Corba SSL is enabled, the platform is utilizing an RSA implementation which is unaffected by heartbleed to provide secure SSL functions.  This configuration is documented in the admin guide http://help.sap.com/businessobject/product_guides/sbo41/en/sbo41sp3_bip_admin_en.pdf
	Tomcat SSL The default build of Tomcat does not have APR/SSL enabled Tomcat can use two different implementations of SSL: The JSSE implementation provided as part of the Java runtime (since 1.4) The APR implementation, which uses the OpenSSL engine by default. According to Apache.org (via bugzillaID:56363): “The binary builds of Tomcat Native 1.1.24 – 1.1.29 have been compiled with an OpenSSL version vulnerable to Heartbleed, and are thus probably vulnerable.” SAP provides a Tomcat binary release which integrates an OpenSSL library directly into Tomcat (APR/Native).  This is disabled by default

How can I tell if my Tomcat version is affected?

Since Tomcat can use these 2 SSL methods mentioned above (JSSE and APR), only the APR implementation may include this affected version of OpenSSL.  For BI Platform, the out-of-the Box method to setup SSL on Tomcat leverages JSSE  (JSSE is unaffected by heartbleed).  While it is possible to enable APR and exploit the bundled tomcat, it is quite a few extra steps to enable APR and configure SSL.

Q: Where can I find this affected APR Binary?:

A: Check the Tomcat Native version (windows only). Cross reference this with:
Bug 56363 OpenSSL security advisory – Heartbleed bug:

*Note: for *nix systems, run ->”openssl version” and upgrade openssl as necessary.

Although you may have an affected binary, it doesn’t yet indicate that you’re using it. 
Read on….

Q: So how do I know if my Tomcat SSL uses JSSE or APR?
A: Check your Tomcat logs and also SSL connector configuration:

Chances are that if you’re using the Out-of the box tomcat provided by SAP BI, you’re probably using JSSE.

Check your logs/stderr.log and determine which ProtocolHandler is running your SSL port.

Example:

INFO: Initializing ProtocolHandler [“http-bio-8443”]

From Apache.org reference: Apache Tomcat 7 Configuration Reference (7.0.53) – The HTTP Connector:

“The BIO and NIO connectors use the JSSE SSL whereas the APR/native connector uses OpenSSL. Therefore, in addition to using different attributes to configure SSL, the APR/native connector also requires keys and certificates to be provided in a different format.”

Also its important to note that if the following message is found in stderr.log, Tomcat is not configured to load the native APR by default:

INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Windows\SysWOW64\;C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\

How do I just test my Java Application server to be sure?

There are a few ways to do this.  Most of the utilities are developed or derived by: https://github.com/FiloSottile

*Note: I express no warranties about the reliability of these 3rd parties.

*Note: Only do this on a TEST system.

1) Compile and run Heartbleed checker tool

This method is a a bit more complicated.

Prerequisites:

• Install go 1.2 Downloads – go – The Go Programming Language – Google Project Hosting
• Install git Git – Downloading Package
• Configure your GOPATH variable http://golang.org/doc/code.html#GOPATH
• Optional – Configure git for proxy servers git config –global http.proxy http://<login_internet>:<password_internet>@aproxy:aport

Install
Documented here: FiloSottile/Heartbleed · GitHub

go get github.com/FiloSottile/Heartbleed
go install github.com/FiloSottile/Heartbleed

If that all worked properly, you should now have a Heartbleed.exe in your /go/bin folder.

Run

so far, so good…. 

How do I purposely exploit Tomcat so I know this tool is working?

You’re basically asking:  How do I enable the affected APR and configure SSL with OpenSSL? 
Here is what you would have to do:

1. Enable Tomcat APR.
   Ensure that Tomcat is actually loading the affected APR binary.  Locate the tcnative-1.dll (this should be in /tomcat/bin) and add this location is in your java.library.path
   
2. Configure SSL using the APR implementation:
   Edit the server.xml

   <Connector port=”8443″ protocol=”org.apache.coyote.http11.Http11AprProtocol” SSLEnabled=”true” maxThreads=”150″ scheme=”https” secure=”true” SSLCertificateFile=”C:/SSL/servercert.pem” SSLCertificateKeyFile=”C:/SSL/privkey.pem” SSLPassword=”password” clientAuth=”false” sslProtocol=”TLS” />

   *Notice you have to provide additional parameters (SSLCertificateFile, SSLCertificateKeyFile, SSLPassword) that were not required with JSSE (JSSE requires keystore and keystorepass).

3. Start Tomcat, check your logs:
   You should now see:

   INFO: Loaded APR based Apache Tomcat Native library 1.1.24 using APR version 1.4.6.
   INFO: OpenSSL successfully initialized (OpenSSL 1.0.1c 10 May 2012)

4. Retest Tomcat using Heartbleed
   
   

What to do if <insert application server here> is Vulnerable?

• Keep up to date with the information on Heartbleed Bug

• For Tomcat, stay tuned to this bugzilla track: Bug 56363 OpenSSL security advisory – Heartbleed bug. For APR users, a link to v1.130 APR is provided.  Just copy+paste and restart tomcat.  For Linux users, simply ‘yum update openssl‘.

  Alternatively just use the default JSSE.

• For other App servers, contact your specific Application Server vendor
  

I enjoyed testing and hope you find it informative.