{00428858.1}

Emerging Risk: April 2014, “Heartbleed” Vulnerability in OpenSSL

Executive Summary There is growing media coverage regarding the “Heartbleed” vulnerability. It will arise in Credit Unions that make use of open SSL. This vulnerability will be mitigated in part by Credit Unions who use Microsoft Internet Information Services. Credit Unions more likely to be exposed to this vulnerability make use of Linux which is widespread. Credit Unions that are not as likely to be exposed to this vulnerability are Credit Unions who may be behind on their patch management. As the vulnerability was introduced into the code in 2012 those who have done more recent updates to their firewalls, routers or anything with a GUI interface protected by SSL will have a greater likelihood of being exposed to this vulnerability. Our guideline lays out the technical details of the vulnerability along with suggested tools and mitigation steps for you to address this vulnerability.

OpenSSL Vulnerability OpenSSL is a library used by about 65% to 70% of servers on the internet to provide encrypted connections, indicated by the closed padlock icon in your web browser.

A vulnerability was published on April 7, 2014 that allows an attacker reading the complete memory of a server affected by this vulnerability, just by connecting to the server and exploiting this vulnerability. The vulnerability is present in the so called Heartbeat function of TLS (Transport Layer Security), intended to keep alive SSL connections for a certain period of inactivity.

Among the data at risk are:

• The primary, secret server keys of the server’s X.509 certificate resulting in a risk that the certificate has been compromised

• All session keys and cookies

• Any data hosted by the server or accessible through the server, including user credentials and sensitive personal data, financial data or internal documents

• All third party usernames and passwords on remote systems The attack leaves no trace behind. Once a server’s certificate keys have been obtained, an attacker could decrypt all traffic to this server: past, present, and future. Future traffic would be secure only after the server certificate is revoked and replaced with a new certificate.

The affected versions of OpenSSL (v. 1.0.1 through v.1.0.1f) have been in the wild since March 14, 2012.

Management should handle this as an emergency action project and take the following initial steps for all systems using SSL/TLS encryption, including web servers, mail servers, VPN services and more:

• For in house services, the IT department should follow the advice given further down in this document immediately.

• For outsourced services, the vendor should be contacted immediately and asked to verify if they ever used software or operating systems affected by the Heartbleed vulnerability.

For services that are found to be affected, full disclosure of all data accessible must be assumed and may be reportable to regulators. For the future protection of data on affected servers and services, please refer to the advice given further down in this document.

Affected software, operating system and devices • Apache, nginx and other open source web servers, accounting for about 66% of web servers on the

internet. Note that Microsoft’s Internet Information Services (IIS) is not affected by this issue.

• Many email servers (SMTP, POP and IMAP protocols). While Outlook/ Exchange are not directly affected, upstream email providers used to provide services such as SPAM filtering may be affected.

• Virtual private networks (SSL VPNs), if they are based on a username/password authentication. VPNs that require a client side certificate before the TLS handshake are not affected in practice.

• Network appliances (virtual appliances, routers, switches, Network Attached Storage, SAN’s and load balancers) – basically everything offering SSL encrypted communication or an “https” type web interface may be affected.

• Many client software products, including web browsers, email clients, VPN clients, chat clients and FTP over SSL.

• Android based phones, tablets and other devices running Android 4.1 or 4.1.1, this includes many Smart-TVs and other consumer electronics.

• Affected server/ desktop operating systems, including recent releases of most popular Linux distributions (i.e. RedHat, Suse, Ubuntu, Linux Mint, Debian, Fedora and CentOS), VMWare, ESX, FreeBSD 10.0 and recent OpenBSD releases. Note that Apple products are not affected as they use a much older version of OpenSSL.

Two possible attack directions With this vulnerability clients and servers can attack each other. Exposure of a public facing server is obvious: if a client can initiate a TLS handshake to the server, it could also attack the server.

Conversely, a server could also attack connecting client. While securing servers and infrastructure should be top priority, the potential for a malicious server attacking a client should not be ignored. If a server certificate has been compromised, an attacker could impersonate the server and use it for phishing attacks that could have disastrous consequences.

Special Circumstances Mitigating the Vulnerability The following special circumstances which would render the attack impossible or prevent compromise of the TLS encryption may be present in some environments:

• If OpenSSL has been compiled without support of the Heartbeat function (by setting the compiler switch “-DOPENSSL_NO_HEARTBEATS”). There is no way to disable Heartbeat functionality at runtime of OpenSSL.

• If Perfect Forwarding Security (PFS) is enabled, the keys and other data on the server may still be disclosed, but individual encrypted communication sessions would still be secure.

• If the TLS session is established after client certificates, hardware tokens or other authentication mechanisms have been verified, the attack would be limited to legitimate users connecting to the service, rendering it impractical for an attacker. This maybe the case in some “closed user group” scenarios, but not in public-facing servers.

• If the system is using an older installation of OpenSSL (0.9.8 and 1.0.0), that is not affected by this vulnerability.

How to verify internal services • PRA Group can perform a Nessus scan on the service in question.

• Download the test script from one of these sites and execute the test locally: o PERL script: (best as this does the actual memory dump)

� https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl o Go script:

� https://github.com/FiloSottile/Heartbleed

• Use one of the following test services (these may be over-loaded due to volumes): o http://filippo.io/Heartbleed/ o http://possible.lv/tools/hb/

How to verify external/ outsourced services for the presence of Heartbleed The test methods noted above should also work on outsourced services. However, it would offer no assurance about the historical presence of the Heartbleed vulnerability, which could still affect present and future TLS sessions. The only practical recourse is to request a statement from the vendor about the presence or absence of the vulnerability since March 2012.

Mitigation of the Heartbleed vulnerability, if present • Patch OpenSSL or apply a workaround:

o Patch affected systems to OpenSSL 1.0.1g. For most Linux distributions, FreeBSD and OpenBSD, the patches have been committed to the official repositories. Just executing your usual update command would deploy the patched version of OpenSSL.

o If patching is not feasible, OpenSSL may be recompiled without Heartbeat support. o If OpenSSL is embedded in another product, i.e. as the secure web interface for a network

device, an update should be obtained from the vendor or the service needs to be disabled o For Android devices, no practical solution may exist if the vendor no longer releases updates for

your device

• The current server keys need to be revoked and a new certificate obtained from the Certificate Authority

• Change all passwords used by the service

• Invalidate all session keys and cookies

• Evaluate the actual content handled by the vulnerable servers/ services that could have been leaked, and take action accordingly

• Evaluate any other information that might have been revealed, like memory addresses and security measures

The mitigation process is similar for insourced and outsourced services. For outsourced services, coordination of the individual steps between the vendor and the organization is critical.

If an organisation has two-factor authentication, authentication codes are likely set to change at fixed intervals: this variation helps to mitigate the risk posed by the Heartbleed vulnerability.

Please contact PRA Group if further clarification or support on this matter is required.

Additional Reading • http://heartbleed.com/

• https://www.openssl.org/news/secadv_20140407.txt

Special Credits: A special thanks to Condenomicon Ltd of Finland for the documentation at heartbleed.com, which was used in part in this bulletin.

About the Author

Stephan Muhs, CISA, CISSP, CRISC – Information Tech nology Auditor Stephan Muhs is an IT Auditor with a specialization in network and systems security assessment at PRA Group. Stephan has worked in Europe and Canada for professional services companies serving clients from various industries, including financial services, logistics, manufacturing, utilities and non-profit, including small and large, multi-national organizations. He has over 15 years of international experience in network, data communication, and systems security, as well as over 20 years of direct IT experience and more than 10 years of senior management experience. He is a Certified Information System Auditor (CISA), Certified Information Systems Security Professional (CISSP) and Certified in Risk and Information Systems Control (CRISC) and has experience in Windows, Unix and Linux systems administration, security architecture, IS operations and change management. Furthermore, his audit experience includes completing internal and external vulnerability assessments, information systems audits, security and privacy audits, IT risks and controls review, operational audits, ethical hacking and PCI-DSS compliance scans. His management experience includes management of complex, diversified projects and senior management at a boutique IT-security company.

Disclaimer

This document is intended for informational purposes. While every effort is made to ensure that the information contained herein is reliable, P. Reimer & Associates Ltd. (“PRA Group”) does not warrant the accuracy, completeness or currency of such information. You should consult with PRA Group or other professional advisors to determine how the information contained in this document applies to your particular situation prior to making any decision or taking any action based upon such information. In no event shall PRA Group or its directors, officers, employees or agents be liable for any loss, damage or expense directly or indirectly arising out of or in connection with the use of, or reliance upon, the information contained in this document.