Zakir Durumeric, James Kasten,David Adrian, J. Alex Halderman, Michael Bailey, Frank Li, Nicholas Weaver, Johanna Amann, Jethro Beekman,

Mathias Payer, Vern Paxson

THE MATTER OF HEARTBLEED

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 100Between 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?