RFC6520 defines SSL Heartbeats - What are they?

1. SSL Heartbeats are used to keep a connection alive without the need to constantly renegotiate the SSL session.

2. Used in MTU path discovery

Why is this a problem? Heartbeat requests can be sent WITHOUT authentication to the server.

Open SSL Heartbleed bug

CVE-2014-0160 describes the SSL Heartbleed bug

● Vulnerable versions of OpenSSL do not validate user input for the memory length value.

● Bug was introduced into OpenSSL version 1.0.1 code in March 2012

● Non affected versions; .99 and 1.0.0 forks● Affected version 1.0.1 through 1.0.1f● Patched in 1.0.1g● Introduced to the code in Nov 2011, it was committed to the code on Dec 31,

2011 just before midnight.

What exactly is bleeding?

● The bug allows attackers to grab 64K chunks of memory contents near the SSL heartbeat on a vulnerable host.

● It is random chunks of data in this memory space – ASLR helps in this situation

● Attack can be repeated many times to grab different random chunks of data

● 64k does seem like much - but it is!

Memory disclosure: what exactly can an attacker get?

● 1. Private crypto keys - the keys to the kingdom, or at least the server.

● 2. Usernames and Passwords● 3. Session identifiers● 4. Private data – data payloads● 5. Meta data for the SSL session, programming

structure pointers - may defeat other exploit protections.

Geeky details, the 4 part heartbeat

1. SSL V3 RECORD LENGTH (should be limited to 4 bytes)

2. Heartbeat Message Type (1Byte)

3. HEARTBEAT MESSAGE (should be limited to 2 bytes BUT IT'S NOT)

● When the victim machine replies there is an extra 64k (-1byte) of memory of the server process returned to the attacker.

4. Message Data (variable bytes)

Untraceable and undetectable = No!

● Many news media sites are saying this attack is untraceable. Not exactly true.

● There is no logging of the session beyond normal SSL negotiation.

● The attack is detectable.

So what can I do?● Coordinate with vendors to get vulnerable

devices patched or replaced. At a minimum, revoke and reissue vulnerable certs.

– IT did this late last week for the Juniper VPN concentrator.

● Change passwords - even if a vendor says their product was not vulnerable, they CANNOT guarantee any business partners products were not vulnerable.

● Monitor carefully for any evidence of identity theft.● Prepare for phishing and social engineering

campaigns leveraging Heartbleed into scaring people into divulging credentials.

Server side attacks● But I'm not running a web server so I'm safe.

Yeah right!● But Windows products are not affected so I'm

safe. Not even!● While Windows servers are not directly

affected, many use SSL to link to other servers. ● I checked everything using TCP port 443. I'm

safe right? No.

Client side attacks

● A full accounting of vulnerable clients is not yet known.

● An attacker can redirect traffic to a vulnerable server they control and exploit this vulnerability.– this hasn't been seen yet but it's only a matter of time.

● Be wary of "secure" network clients.● Restrict use of unknown public wireless unless

you know your client is safe.

Safe(r) Browsers

● Firefox, Chrome, and IE (on Windows) use the Microsoft implementation of SSL not OpenSSL.

● Internet Informations Server/Services (IIS) are not vulnerable.

● Yeah Microsoft!● Don't even think about asking about XP.

What else?

● Most Android devices are vulnerable. - No word on Chrome Books yet.

● iOS and Mac OSX are not vulnerable.

-but some 3rd party iOS apps are. ● Most Linux browsers are probably vulnerable.● 3rd party code using OpenSSL could be

vulnerable - this will take time to discover.

What is Information Security doing?

● Continuous monitoring for this vulnerability with both IDS and IPS devices.

● Vulnerability scans. - not as effective since it's a snapshot in time but a good starting point.