The matter of heartbleed

Presented by Teererai Marange

Durumeric, Z., Kasten, J., Adrian, D., Halderman, J. A. et al.

Outline

BackgroundOpen SSLHearbeat extensionHeartbleed vulnerability

Description of workMethodologySummary of results

Vulnerable populationPatching behavior Impact on certificate ecosystemExposing attacks Impact of large scale notification

Outline

ConclusionLessons learnedCriticismsQuestions and answers

Background: OpenSSL

Popular implementation of SSL/TLS protocols. Used to facilitate secure connections for web, email, VPN and messaging services.

Project initiated in 1998. 8 code execution vulnerabilities and 6 information leak vulnerabilities discovered so far.

Background: Heartbeat extension

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

Background: Heartbeat protocol

Other endpoint confirms presence by sending heartbeatResponse message.

Background: Heartbeat protocol

Example

Background: Heartbleed vulnerability

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 65536 bytes of private memory.

Background: Heartbleed vulnerability

Example

Background: Heartbleed vulnerability

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.

Background: Heartbleed patch

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

payload length>actual length of payload.

Key timeline dates

Methodology: Estimating Vulnerable population

Modified Zmap to perform vulnerability scanSending 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 sites1% samples of public non-reserved ipv4 address space.

Results: Estimating Vulnerable population

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.

Results: Estimating Vulnerable population

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 products74 distinct sets of devices and software packages.

Results: Estimating Vulnerable population

Other areas of impactMail serversTor projectBitcoin clientsAndroid Wireless networks.

Results: Patching behavior

Results: Patching behavior comparison to Debian weak keys

Results: Certificate ecosystem10.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.

Results: Certificate ecosystem10.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.

Results: Attack scene Predisclosure

No evidence of attacks prior to disclosure based on observations between January and April 7 2014.

Post disclosure

Results: Attack scene 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.comMost attacks targeted less than 10 sites(vertical rather than horizontal). Attacks were also centered on dense address spaces for example Amazon.

Methodology: Notification 152805 hosts were randomly split into 2 groups

Group A to be notified on April 28, 2014Group B to be notified on May 7, 2014.

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.

Methodology: Notification 152805 hosts were randomly split into 2 groups

Group A to be notified on April 28, 2014Group B to be notified on May 7, 2014.

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.

Results: Notification

Results: Notification

Conclusion: Lessons learned

HTTPS administration: Educating server operatorsCertification 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.

Conclusion: Lessons learned

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.

CriticismsScans 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%

CriticismsPredisclosure 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?

CriticismsSmall 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?