Upload
aron-harvey
View
223
Download
0
Tags:
Embed Size (px)
Citation preview
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.