1. 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

2. 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.

3. 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!

4. 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.

5. 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)

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. What else? ● Most Android devices are vulnerable. - No word on Chrome Books yet. ● iOS and Mac OSX are not vulnerable. -but some 3 rd party iOS apps are. ● Most Linux browsers are probably vulnerable. ● 3rd party code using OpenSSL could be vulnerable - this will take time to discover.

12. 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.