Member Login
login help
Contact Us
24x7 CSIRT

CRITICAL Vulnerability In OpenSSL: HeartBleed

Print-friendly copy (pdf)

- - - - - - - - -

April 10, 2014

To: IT Executives and Security Staff

CRITICAL Vulnerability In OpenSSL: HeartBleed

The REN-ISAC [1] wants to stimulate immediate action concerning a
CRITICAL vulnerability in a pervasive piece of software, and make
itself available for questions and assistance in understanding
how to deal with the issue.

OpenSSL is an open-source implementation of the SSL and TLS [2]
protocols. SSL/TLS provides the cryptographic function for almost
all secure Internet communications. One most obvious example is
secure web services. OpenSSL is widely utilized in open-source
and commercial products. The odds are certain that your
enterprise relies on OpenSSL-based services.

The HeartBleed bug in OpenSSL is simple and easily exploited.
A "heartbeat" mechanism in the protocol allows a client to tell
a server "I'm going to send you some data, echo it back to me".
The client's request contains the data and specifies the length
of the data. If the specified length is larger than the length
of the data sent, the server returns an amount of data equal
to the specified length with contents of server process memory
making up the difference. Up to 64KB of memory can be exposed
per request.

The exposed memory is in the OpenSSL service process area
and can contain secret keys used for X.509 certificates, user
names, passwords, web cookies, and even the contents of
user communications.


+ Update vulnerable servers or otherwise mitigate the risk AND
replace the public/private keys and SSL/TLS certificate associated
with the servers. Revoke the earlier (potentially compromised)
SSL/TLS certificate(s). Understand that, although absolutely
necessary, revocation isn't 100% effective because of shortfalls
in client use of revocation [7]. Make sure your certificate
authority is not vulnerable before obtaining new certificates.

+ Evaluate the risks (described below) and evaluate other steps
such as expiring passwords, notifying users, monitoring account
access, etc.

+ Use this opportunity to evaluate improving the configuration,
cipher (e.g. TLS 1.2), and capabilities (e.g. Perfect Forward
Secrecy) of your SSL/TLS services [2], [3], [4], [5], [6].

+ Provide information and guidance for your users.

+ Warn your users about the inevitable phishing to steal user
account information by spoofing password change notifications.

+ If you have questions or seek assistance, contact the REN-ISAC

Is My Enterprise Affected?

Unquestionably yes. Either directly (services that you operate
and provide) or indirectly (services provided to you by other
parties). Most likely both.

What Are The Vulnerable Services?

This list is not comprehensive. Vulnerable services may include:

+ Secure web (https).

+ Network systems including those that allow only administrator
access, e.g. routers, and those that provide user-authenticated
services, e.g. VPN servers.

+ Applications and appliances that employ secure remote connections.

What's At Risk?

#1 Your capability to deliver secure web services. Compromise of
the secret keys associated to X.509 certificates used by the web
server would allow an attacker to intercept and decrypt all
traffic and/or impersonate the server.

#2 User names and passwords used to access vulnerable servers.

#3 Session keys and cookies used in sessions with vulnerable servers.

#4 Content of communications that occurred over vulnerable servers.

#5 Other information exposed in the memory leak that could allow
an attacker to mount additional attacks against the server (likely
becomes irrelevant when you upgrade OpenSSL).

It's IMPORTANT to note that risk to your enterprise not only
involves internal services but includes use of services provided by
other parties, e.g. financial, cloud, federated authentication, etc.

Is This Vulnerability Currently Being Exploited?

Yes. It's very easy to exploit. Tools and how-to information are
easily obtained. Universities have reported observing exploitation
attempts (see Can I Detect Attacks? below).

How Can I Tell If I've Been Compromised?

If you've already been compromised you probably won't be able to
tell. Exploitation of the vulnerability leaves no log information on
the affected server. Your first indication may be in seeing stolen
credentials used in follow-on attacks.

Can I Detect Attacks?

Yes. There are signatures available for intrusion detection systems.

For open-source IDS (Snort, Suricata, Bro):

For commercial IDS, refer to your vendor.

Should I Be Resetting All My Users' Passwords?

Evaluate the risk and tradeoffs. Are you able to determine if
passwords were handled by a vulnerable server? Do you require
periodic password changes thwarting the use of organizational
passwords at external web properties? Do you require two-factor
authentication for business functions?

In the absence of having information about what data might have
been exposed, the most conservative response would be to reset all
user credentials. Don't count on users voluntarily resetting their
passwords. Implement an expiration process. Conduct the process in
stages, e.g. resetting privileged/sensitive accounts immediately,
before addressing all other accounts in staged waves. In many cases,
password change processes and support personnel will not be scaled
to support 100% required changes all at once.

Notify all users of the broader issue concerning services
provided outside your enterprise. Mandate changes for users of
vulnerable external business functions and suggest that users
consider their active personal accounts as well. However, don't
change passwords on external services until you know their
vulnerabilities have been addressed.

Many people may not know their password(s), having lost them to
the "remember password" function in popular web browsers. How does
your organization support users changing or reinstating passwords
if they don't know their current password? Trivia questions? Personal
appearance with picture id in-hand?

End users will be very confused and need lots of support.
Supporting information on web pages will help users and relieve
the burden on help desk and support personnel. Prepare your help
desk for the onslaught.

It's an excellent time to reinforce the best practice of unique
passwords for every account and password wallets to manage the
passwords. Also, if you're not already doing so, to evaluate using
two-factor authentication for business functions.

Do I Need To Consider This A Breach For Notification Purposes?

Evaluate whether to notify users of affected systems to change
their passwords (see Should I Be Resetting All My User's Passwords?).

Concerning a more broad notification of breach, this will be very
hard to determine. Evidence for and determination of the extent of
a successful attack will be indirect, e.g. compromised accounts used
by criminals, subsequent man-in-the-middle attacks on secure web
traffic, or compromised super user accounts being used from odd

Notification concerning a "potential breach" needs to be guided by
local policy and law.

What Systems Are Vulnerable?

System vulnerability and patch information is quickly evolving.
Track at the CERT and SANS web pages:

Can I Test For Vulnerable Systems?

Various tests are available:

Online tests (use at your own risk - you potentially identify
vulnerable servers to unknown persons)

Other Notes

SSH is not vulnerable to this issue as far as we know at this time.




Thanks to the REN-ISAC Technical Advisory Group [8] and members of
the HEISC [9] for assistance in assembling this notification, and to
REN-ISAC members for valuable shared information.


Copy of this Alert is available on the REN-ISAC web site at:

We'd appreciate your input on additional means to protect from the
threat and general feedback concerning this Alert. If you have any
questions, please don't hesitate to e-mail us at


Your REN-ISAC Team
24x7 Watch Desk +1(317)274-7228