Open SSL Heartbleed bug

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

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.