Presented by Teererai Marange

Background Open SSL Hearbeat extension Heartbleed vulnerability Description of work Methodology Summary of results Vulnerable population Patching behavior Impact on certificate ecosystem Exposing attacks Impact of large scale notification

Conclusion Lessons learned Criticisms Questions and answers

Popular implementation of SSL/TLS protocols. Used to facilitate secure connections for web, , VPN and messaging services. Project initiated in code execution vulnerabilities and 6 information leak vulnerabilities discovered so far.

Motivation: Session management in Datagram TLS. Allows either end-point of connection to detect whether its peer is still present. Support indicated during TLS handshake protocol. Following this, either endpoint confirms connectivity sending a heartbeatRequest

Other endpoint confirms presence by sending heartbeatResponse message.

Example

Implementation of hearbeat assumed that the peer sending HeartbeatRequest would be honest about payload length value!!! Suppose I send a payload of length 1 and say that the actual length is 16 bytes. Then the server would return the 1 byte payload plus 15bytes of its own(supposedly private memory). Thus peer could acquire up to bytes of private memory.

Example

Potency of this vulnerability Compromised confidentiality and Access control as anyone could acquire private cryptographic data and private user data. Easy to understand and exploit. Popularity of HTTPS and TLS resulting in more affected services.

Compares payload length field to actual length of payload. Discards heartbeatRequest message if payload length>actual length of payload.

Modified Zmap to perform vulnerability scan Sending heartbeatRequest with length field set to 0 and no payload and no padding. Non-vulnerable servers reject message. Vulnerable servers respond with a message with padding only. Vulnerability scans performed against Alexa top 1million sites 1% samples of public non-reserved ipv4 address space.

At least 44 of Alexa top 100 remained unpatched at disclosure time. 5 Alexa top 100 sites still unpatched 22 hours post disclosure. Broader impact. Codenomicon estimated that 66% of HTTPS enabled sites affected at disclosure time. 45% of Alexa top 1 million supported HTTPS. Of these 24-55% were vulnerable at disclosure time. This value had dropped to 11% 48 hours post discolosure.

Public ipv4 address space(from 48 hours after disclosure) 11.4% supported HTTPS of which 5.9% were vulnerable. 10 ASes accounted for over 50% of vulnerable hosts. Other devices and products 74 distinct sets of devices and software packages.

Other areas of impact Mail servers Tor project Bitcoin clients Android Wireless networks.

10.1% of vulnerable hosts 48 hours post disclosure replaced their certificates in the month following disclosure vs 73% who patched. Of those that replaced their certificate 19% revoked the old one!!! 14% used the same private key!!!! 23% of all HTTPS sites in Alexa top 1million replaced certificates and only 4% revoked the old one between april 9 and april 30.

10.1% of vulnerable hosts 48 hours post disclosure replaced their certificates in the month following disclosure vs 73% who patched. Of those that replaced their certificate 19% revoked the old one!!! 14% used the same private key!!!! 23% of all HTTPS sites in Alexa top 1million replaced certificates and only 4% revoked the old one between april 9 and april 30.

Predisclosure No evidence of attacks prior to disclosure based on observations between January and April Post disclosure

The vast majority of scan attacks originated from the Amazon address space(4267 out of 5948) and were used by popular heartbleed scan services Filipino.io and ssllabs.com Most attacks targeted less than 10 sites(vertical rather than horizontal). Attacks were also centered on dense address spaces for example Amazon.

hosts were randomly split into 2 groups Group A to be notified on April 28, 2014 Group B to be notified on May 7, Each group notification included information on vulnerability, link to recovery guide and list of vulnerable hosts. Regular scans of each group performed every 8 hours in order to track patching behavior.

hosts were randomly split into 2 groups Group A to be notified on April 28, 2014 Group B to be notified on May 7, Each group notification included information on vulnerability, link to recovery guide and list of vulnerable hosts. Regular scans of each group performed every 8 hours in order to track patching behavior.

HTTPS administration: Educating server operators Certification revocation and replacement behavior suggests a superficial understanding of the protocol. Importance of forward secrecy. Need for more scalable certificate revocation protocols. Support for critical open source projects. Heartbeat originally for DTLS. Why was it enabled everywhere in the first place. “Standard implementations could rely on TCP for equivalent session management”. Code review would also have helped.

Vulnerability disclosure: Largely uncoordinated and poorly organized. Many major operating system vendors not notified prior to disclosure. A plan must be put in place for future events of this scale and importance. Notification and patching. Positive effect of notification is clear from this study. Detection of vulnerable systems on a large scale is easier than most researchers think. Research needed to look into protocols that allow machine to machine notification and automated patching accordingly.

Scans of all forms exclude hosts that previously requested removal from their daily HTTPS scans Potential bias in sample?? Ethics. Server is not given notification to not be scanned prior to initial scans. False negatives due to bug in heartbleed scanner. Impact lowered by subsequent scan in May. Estimated between 6.5%-10.5%

Predisclosure affected patching behavior. Data does not tell us about patching sequence. Some server operators disabled the extension before patching. Author appears to assume that all server operators had the goal of patching as soon as possible. What about leaving servers vulnerable for research purposes? What if server operators are weary of bugs in the patch itself?

Small sample size in determining effect of language barrier on patching rate. 75 responses received. 88% of which were in English and other Common languages. Data does not tell us about patching sequence. Some server operators disabled the extension before patching. Author appears to assume that all server operators had the goal of patching as soon as possible. What about leaving servers vulnerable for research purposes? What if server operators are weary of bugs in the patch itself?