THE MATTER OF HEARTBLEED
Zakir Durumeric, James Kasten,David Adrian, J. Alex Halderman, Michael Bailey, Frank Li, Nicholas
Weaver, Johanna Amann, Jethro Beekman, Mathias Payer, Vern Paxson
Presented By: Sneha Dudaki
WHAT IS HEARTBLEED?
 A bug in the OpenSSL open-source cryptographic library.
 OpenSSL implements SSL and TLS protocols.
 Provides a secure communication channel for most services such as web, email,
VPN, and messaging services.
WHAT IS HEARTBLEED?
 The Heartbleed bug was critical due to three main reasons:
1. Retrieved private cryptographic keys and private user data
2. Easy to exploit
3. More affected services due to HTTPS and TLS protocols being used.
 More specifically, it was a bug in the implementation of the TLS Heartbeat
extension.
 TLS Heartbeat extension uses a well-defined Heartbleed protocol.
THE HEARTBLEED PROTOCOL
 Checks if the host communicating to is online – “heartbeat”.
 Verifies communication connectivity through a Heartbeat request.
 The request contains a payload length field and a payload that you want the
server to echo back.
 Vulnerability: payload length extension attack!
 Allows attackers to access data stored in the protected memory of the server.
WHY IS HEARTBLEED CATASTROPHIC?
 Heartbleed allows attackers to read sensitive information from servers.
 Almost all popular web, mail, messaging, and database servers use
OpenSSL to facilitate TLS connections.
 Invalidates users privacy and confidentiality due to a “leaky” secure
communication channel.
MOTIVATION
 Explore the impact of a “serious” bug on the technical community.
 Gain a better understanding of the coping and response mechanisms
adapted.
 Effective global security policy.
MAIN AREAS EXPLORED
1. Tracking the vulnerable population
2. Monitoring patching behaviour overtime
3. Accessing the impact on the HTTPS certificate ecosystem
4. Exposing attempts to exploit the bug
TRACKING THE VULNERABLE POPULATION
 Vulnerability scans against:
 The Alexa Top 1 Million domains
 1% non-reserved IPv4 address space
 Results:
Time of disclosure
Alexa Top Sites
The Internet (IPv4)
Pre-48 hours
At least 44 of Alexa top 100
Between 24 – 55% of Alexa 1 million
N/A
Post-48 hours
11.5% of Alexa top 1 million
5.9% of all HTTPS hosts
MONITORING PATCHING BEHAVIOUR
OVERTIME
 Detects when services disable the heartbeat extension.
 Pre-disclosure patching: Google, Akamai, and some other sites.
 Popular websites
 5 of Alexa top 100 remained vulnerable after 22 hours.
 93 sites replaced their certificates.
 Internet wide HTTPS
 Slower patching behaviour (Note: 1% scan per day!).
 A drastic drop in vulnerable host % due to quick patch of ASes.
APRIL AND MAY PATCH RATES
IMPACT ON THE HTTPS CERTIFICATE
ECOSYSTEM
 Security community “recommended” to generate new cryptographic keys and
to revoke compromised certificates.
 Certificate replacement
 Alexa sites - 73% patched but only 10.1% replaced.
 19% of the sites that replaced certificates also revoked the original
certificate.
 14% re-used the same private key!
 Certificate revocation
 The number revoked in the following three months after the disclosure was
greater than the previous 3 years.
EXPOSING ATTEMPTS TO EXPLOIT THE
BUG
 Checking network traffic for potential attackers.
 Pre-disclosure activity
 No evidence of any exploit attempt
 Post-disclosure activity
 Examined packet traces from three honeypots.
 Observed 5,948 attempts to exploit the vulnerability from 692 hosts.
 Several types of exploits (will see in the next slide).
 Hosts targeted ports that supported HTTPS.
TYPES OF EXPLOITS
NOTIFICATION SYSTEM
 Authors notified the system operators of vulnerable systems that were not
patched.
 Notification emails were sent out.
 The vulnerable systems were tracked.
 Result:
 A significant positive improvement in vulnerable systems being patched
after the notification.
SUMMARY
 Vulnerability was widespread (websites to embedded devices).
 Sites patched heavily in the first two weeks, and then ceased.
 Very few sites replaced or revoked their certificates.
 No attacks pre-disclosure but a significant increase post-disclosure.
 Lastly, the notification system proved to be impactful.
CRITICISM
 Zmap - the Heartbleed scanner.
 Data aggregation 2 days after public disclosure.
 Daily 1% scans of the IPv4 address space.
ZMAP - THE HEARTBLEED SCANNER
 The Heartbleed scanner contained a bug that caused vulnerable sites to
appear safe (i.e. false negatives).
 A timeout period that set the vulnerability status to false by default.
 Found that false negatives were address-independent (i.e. no correlation
between IP addresses and false negative detection).
ZMAP - THE HEARTBLEED SCANNER
Using data gathered from two scans in the months of April and May they
conclude that:
“ultimately we conclude that the scanner exhibited a false negative rate
between 6.5% and 10.5%, but that these manifest independently of the
particular server scanned. Due to this address-independent behaviour, we can
assume a similar false negative rate for sampled scans”.
Possible solution – set status to unknown or null as default.
DATA AGGREGATION TWO DAYS AFTER PUBLIC
DISCLOSURE
 Impact on popular websites was found after 48 hours by the researchers.
 Aggregated press releases, targeted scans, and quotes from news sites were
used for collecting data in the first 48 hours.
 Report lower bound statistics, with information for some sites missing.
 To what extent is this information truly representative of the actual statistics?
 Not plausible to make such claims or assumptions due to missing information.
DAILY 1% SCANS OF THE IPV4 ADDRESS
SPACE
 The authors estimate that 2 million HTTPS hosts were vulnerable two days
after the disclosure.
 This could possibly be an underestimate due to the 1% sample size.
 Since the IPv4 address space covers most of the Internet, the 1% data
extracted on a particular day will not be representative of another 1%
sample.
 Though scanning large samples (> 1%) may consume more time, it ensures
a more reliable estimate.
QUESTIONS?