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, , 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 disclosureAlexa Top SitesThe Internet (IPv4) Pre-48 hoursAt least 44 of Alexa top 100 Between 24 – 55% of Alexa 1 million N/A Post-48 hours11.5% of Alexa top 1 million5.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 s 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?