Heartbleed OpenSSL: SAP BI Platform and Tomcat testing

[former_member18062]

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:

Official Heartbleed site	Heartbleed Bug
CVE-2014-0160	CVE -CVE-2014-0160
OpenSSL Advisory	https://www.openssl.org/news/secadv_20140407.txt
Apache Tomcat Bugzilla  BugID:56363	Bug 56363 OpenSSL security advisory - Heartbleed bug
Tomcat SSL how to	Apache Tomcat 6.0 (6.0.39) - SSL Configuration HOW-TO
SAP BI Platform KBA	http://service.sap.com/sap/support/notes/2003582

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.

[denis_konovalov]

Excellent !!!

[Former Member]

Great Blog Brian!

[AndrewK]

Great Info!!

[petr_solberg]

Hi Brian,

I agree with the others, really excellent article.

You said,

     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.

What I would like to understand, is, how the vulnerability was introduced to OpenSSL in  December 2011. Was it a code error, or was it premeditated.

Will Heartbleed mean that the good work going on in the open area, is devalued and corporates will shy away from open software ?

OpenSSL's website describes itself as:

     The OpenSSL Project is a collaborative effort to develop a robust

     commercial-grade, full-featured, and Open Source toolkit implementing

     the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1)

     protocols as well as a full-strength general purpose cryptography library.

     The project is managed by a worldwide community of volunteers that use the

     Internet to communicate, plan, and develop the OpenSSL toolkit and its

      related  documentation. 

This experience begs the question, would an investment in a commercial solution have been safer ?

Best regards,

Andy.

[denis_konovalov]

Andy,

The question about "how" this happen is truly interesting one. A number of interesting possibilities comes to mind - from NSA planting this bug (and NSA been using this vulnerability all these years) to simple bug in the code, like any other.... :wink: , internet is full of possible answers. Peak one you like best :grin:

As to the "open source" vs. "commercial" solutions -- I do not thing anyone has the correct answer to this. It depends....

[former_member18062]

Hi Andy,

Some really great questions that I dont have all the answers to, but I can tell you what I've learned from my research on the internet:

• According to the OpenSSL changelog, you can search the changelog for the term "heart" and pinpoint the developer who introduced this flaw (Robin Seggleman).
  https://www.openssl.org/news/changelog.html
  
  Here is a good news article that might answer some of those questions:
  http://www.businessinsider.com/robin-seggelmann-regrets-introducing-heartbleed-error-2014-4

• OpenSource vs. Commercial:
  Opensource software is developed by a community of freelance developers.  Although a single person may have coded the flaw, this code goes through (theoretically) checks and balances / code review by the community.  I dont really believe that this is a black eye for OpenSource software since even publicly traded companies (RSA) has reported simiar flaws with their encryption in the past.

I suppose its possible that some organizations and government agencies had discovered the flaw years ago and used it to their advantage without reporting it, but we would never know. :wink:

[petr_solberg]

Hi Brian and Denis,

thank you for the feedback and answers.

Andy.

[Former Member]

As always thanks for keeping us posted Brian.

Alok

[former_member182521]

Thanks for Sharing Brian

[Former Member]

Thanks a lot for sharing!

[former_member186487]

Very nice article.

The note 2003582 mentioend above states that -

SAP will provide updated Tomcat in the future patches.

Any idea, which patch will include this or it is already out with BI 4.1 SP3?

Please advice.

Thank you,

SS

[denis_konovalov]

it is not clear when tomcat with updated/fixed native library will be provided.
"As is" the tomcat SAP provides is safe (as per above), so there is no rush to get new version :wink:
and I imagine it will depend on when Tomcat.org actually has fixed version available.

[sbastien_francal2]

Thanks for your great post Brian!

[former_member18062]

Hi Surendra,

This was not available at the time that 4.1 SP03 was released.  I suspect this will be included in an upcoming SP.

Since writing this blog, Apache has released their own official binaries which you can download here:

Index of /dist/tomcat/tomcat-connectors/native/1.1.30/binaries

As Denis noted, patching is not critical unless you are using the APR.

[Toby_Johnston]

Thanks for the info BT!

[Former Member]

And just to make it more entertaining... Thank you XKCD!

[former_member18062]

Always nice to see complexity explained simply.
Thanks Patrick!

[Former Member]

Great! Thx a lot!