View
290
Download
1
Category
Tags:
Preview:
Citation preview
Introduction
• Heartbleed is a security bug disclosed in April 2014 in the OpenSSLcryptography library, which is a widely used for the implementation ofthe Transport Layer Security (TLS) protocol.
• Heartbleed may be exploited regardless of whether the party using avulnerable OpenSSL instance for TLS is a server or a client.
• It results from improper input validation (due to a missing boundscheck) in the implementation of the TLS heartbeat extension, thusthe bug's name derives from "heartbeat”.
• The vulnerability is classified as a buffer over-read, a situation wheremore data can be read than should be allowed.
OpenSSL
• OpenSSL is an open-source implementation of the SSL and TLSprotocols. The core library, written in the C programming language,implements basic cryptographic functions and provides various utilityfunctions.
• The OpenSSL project was founded in 1998 to invent a free set ofencryption tools for the code used on the Internet. As of 2014 twothirds of all webservers use it.
Heartbeat Extension
• The Heartbeat Extension provides a new protocol for TLS/DTLSallowing the usage of keep-alive functionality without performing arenegotiation.
• TLS is based on reliable protocols, but there is no feature available tokeep the connection alive without continuous data transfer.
• The Heartbeat Extension overcomes these limitations.
• The user can use the new HeartbeatRequest message, which has tobe answered by the peer with a HeartbeartResponse immediately.
Heartbeat Hello Extension
• A peer cannot only indicate that its implementation supportsHeartbeats, it can also choose whether it is willing to receiveHeartbeatRequest messages and respond with HeartbeatResponsemessages or only willing to send HeartbeatRequest messages.
• The former is indicated by using peer_allowed_to_send as theHeartbeatMode; the latter is indicated by usingpeer_not_allowed_to_send as the Heartbeat mode.
• This decision can be changed with every renegotiation.
The Heartbeat Protocol
• The Heartbeat protocol is a new protocol running on top of theRecord Layer. The protocol itself consists of two message types:HeartbeatRequest and HeartbeatResponse.
• A HeartbeatRequest message can arrive almost at any time during thelifetime of a connection.
• There must not be more than one HeartbeatRequest message in flightat a time. A HeartbeatRequest message is considered to be in flightuntil the corresponding HeartbeatResponse message is received, oruntil the retransmit timer expires.
Heartbeat Request / Response Message
• The Heartbeat protocol messages consist of their type and anarbitrary payload and padding.
• struct {HeartbeatMessageType type;uint16 payload_length;opaque payload[HeartbeatMessage.payload_length];opaque padding[padding_length];} HeartbeatMessage;
Heartbeat Request / Response Message
• The total length of a HeartbeatMessage must not exceed 2^14 Bytes.
• type : The message type; either heartbeat_request orheartbeat_response.
• payload_length : The length of the payload.
• payload : The payload consists of arbitrary content.
• Padding : It can be any random content and the sender of thismessage must use at least 16 Bytes of padding.
Working
• When a HeartbeatRequest message is received and sending aHeartbeatResponse is not prohibited, the receiver must send acorresponding HeartbeatResponse message carrying an exact copy ofthe payload of the received HeartbeatRequest.
• If a received HeartbeatResponse message does not contain theexpected payload, the message must be discarded. If it does containthe expected payload, the retransmission timer must be stopped.
The Heartbleed Attack
• We had discussed earlier in the introduction part that this attack wasmade possible because of the improper input validation of the TLSHeartbeat extension. The vulnerability lies in the payload variable.
• Ideally the code must check the payload data length with the actuallength of data sent in the Heartbeat request, but it isn’t checking it.
• So if the payload exceeds the standard length in the request, theserver may return more data in response than what it should ideallyreturn.
The Heartbleed Attack
• This is a case of Buffer Overflow (BoF). Look at the following vulnerable code:
The Heartbleed Attack
• The rrec contains all the incoming request data. The code reads thedata. The first byte is to check if it’s a Heartbeat protocol and thenanother 2 bytes determine the length of the Heartbeat payload.
• Ideally the length of the payload must be equal to the payload_lengthsent in the Heartbeat request. But as discussed, the code is notchecking actual length sent in the Heartbeat request.
The Heartbleed Attack
• So the code copies the amount of data requested by incomingrequests to the outgoing server response and possibly more thanrequested in some cases.
• This may leak valuable information to attackers, such as session IDs,tokens, keys, etc.
What can be leaked ?
• As said earlier, much sensitive information from the server’s memorycan be sent in through the response.
• Some of them are session-related information such as session ID,different tokens, keys, and some other sensitive internal informationsuch as queries, internal data, etc.
• The next image shows a real example of what we can receive in theresponses.
Solution
• This vulnerability lies in the OpenSSL version 1.0.1f and 1.0.2 – beta1.
• Affected users should upgrade to OpenSSL 1.0.1g.
• Users unable to immediately upgrade can alternatively recompileOpenSSL with -DOPENSSL_NO_HEARTBEATS.
• OpenSSL version 1.0.2 will be fixed in 1.0.2 – beta2.
To check whether your website is safe visit
1) https://lastpass.com/heartbleed/
2) https://filippo.io/Heartbleed/
References
1. RFC 6520 - https://tools.ietf.org/html/rfc6520
2. www.heartbleed.com
3. Infosec Institute - http://resources.infosecinstitute.com/exploiting-heartbleed/
4. https://xkcd.com/1354/
5. https://www.openssl.org/news/secadv_20140407.txt
6. https://lastpass.com/heartbleed/
Recommended