Heartbleed Bug - Revision history

Brennan at 13:56, 28 May 2014

2014-05-28T13:56:41Z

Tgondrom: add the notion that compromised passwords need to be changed after upgrade of openssl

2014-05-12T16:15:53Z

add the notion that compromised passwords need to be changed after upgrade of openssl

Neal Mueller at 23:45, 10 April 2014

2014-04-10T23:45:45Z

Andylew at 22:59, 10 April 2014

2014-04-10T22:59:05Z

Andylew: Added remarks and link to Matt Sullivan's explanation of using Heartbleed for session hijacking attacks

2014-04-10T22:57:45Z

Added remarks and link to Matt Sullivan's explanation of using Heartbleed for session hijacking attacks

Neal Mueller at 20:37, 10 April 2014

2014-04-10T20:37:20Z

Neal Mueller at 20:36, 10 April 2014

2014-04-10T20:36:27Z

Neal Mueller at 19:03, 10 April 2014

2014-04-10T19:03:29Z

Neal Mueller at 19:03, 10 April 2014

2014-04-10T19:03:21Z

Neal Mueller at 19:02, 10 April 2014

2014-04-10T19:02:51Z

← Older revision		Revision as of 13:56, 28 May 2014
Line 95:		Line 95:

	Test a website's vulnerability here [http://filippo.io/Heartbleed/]		Test a website's vulnerability here [http://filippo.io/Heartbleed/]
		+
		+	Firefox Plug-in for user to test website for vulnerability Red=Bad, Green=Good [https://addons.mozilla.org/en-US/firefox/addon/heartbleed-checker/]

	Blog post from Michael Coates [[http://blog.shapesecurity.com/heartbleed-bug-places-encrypted-user-data-and-webservers-at-risk]]		Blog post from Michael Coates [[http://blog.shapesecurity.com/heartbleed-bug-places-encrypted-user-data-and-webservers-at-risk]]

← Older revision		Revision as of 16:15, 12 May 2014
Line 75:		Line 75:

	Implement Perfect Forward Secrecy. This additional layer of security protects encrypted data from several potential attacks by using a per session random keys.		Implement Perfect Forward Secrecy. This additional layer of security protects encrypted data from several potential attacks by using a per session random keys.
		+
		+	Change passwords: If the compromised OpenSSL library had been used to protect login and password information (e.g. like in many cases using SSL for account login pages), this information should be considered compromised. That means that after the library has been upgraded all compromised passwords should be changed. The best way to do this is to inform the users that their password might have been compromised due to this vulnerability and that they should change their password, combined with system of one-time forced change of password after login.

	'''What should users do?'''		'''What should users do?'''

← Older revision		Revision as of 23:45, 10 April 2014
Line 82:		Line 82:
	According to Errata Security [http://blog.erratasec.com/2014/04/yes-you-might-have-to-change-your.html#.U0blvq1dWv0], "The only passwords you need to change would be ones that you entered in the last couple of days. Personally, I haven't entered any passwords over the last couple days, so I don't need to change any passwords."		According to Errata Security [http://blog.erratasec.com/2014/04/yes-you-might-have-to-change-your.html#.U0blvq1dWv0], "The only passwords you need to change would be ones that you entered in the last couple of days. Personally, I haven't entered any passwords over the last couple days, so I don't need to change any passwords."

		+
		+	= Exploit POCs =
		+
		+	A list of Heartbeat exploit POCs is provided here.[https://blog.bugcrowd.com/heartbleed-exploit-yet/]

@@ Line 30: / Line 30: @@
 == Session Hijacking with Heartbleed ==
-Matt Sullivan published an interesting article about leveraging Heartbleed for [[Session_hijacking_attack|session hijacking attacks]], including a walkthrough on JIRA [https://www.mattslifebytes.com/?p=533 here].
+Matt Sullivan published [https://www.mattslifebytes.com/?p=533 an interesting article] about leveraging Heartbleed for [[Session_hijacking_attack|session hijacking attacks]], including a walkthrough on JIRA [https://www.mattslifebytes.com/?p=533 here].
 = Explanation of the Bug =

← Older revision		Revision as of 22:57, 10 April 2014
Line 29:		Line 29:
	According to Codenomicon [http://heartbleed.com/], "There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed."		According to Codenomicon [http://heartbleed.com/], "There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed."

		+	== Session Hijacking with Heartbleed ==
		+	Matt Sullivan published an interesting article about leveraging Heartbleed for [[Session_hijacking_attack\|session hijacking attacks]], including a walkthrough on JIRA [https://www.mattslifebytes.com/?p=533 here].

	= Explanation of the Bug =		= Explanation of the Bug =

@@ Line 44: / Line 44: @@
 Below is the revised code from Github.[http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=731f431497f463f3a2a97236fe0187b11c44aead]
-hbtype = *p++;
+    hbtype = *p++;
-n2s(p, payload);
+    n2s(p, payload);
-if (1 + 2 + payload + 16 > s->s3->rrec.length)
+    if (1 + 2 + payload + 16 > s->s3->rrec.length)
      return 0; /* silently discard per RFC 6520 sec. 4 */
-pl = p;
+    pl = p;

← Older revision		Revision as of 20:36, 10 April 2014
Line 28:		Line 28:

	According to Codenomicon [http://heartbleed.com/], "There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed."		According to Codenomicon [http://heartbleed.com/], "There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed."
		+
		+
		+	= Explanation of the Bug =
		+
		+	This serious flaw (CVE-2014-0160) is a missing bounds check before a memcpy() call that uses non-sanitized user input as the length parameter. An attacker can trick OpenSSL into allocating a 64KB buffer, copy more bytes than is necessary into the buffer, send that buffer back, and thus leak the contents of the victim's memory, 64KB at a time.
		+
		+	TheRegister's explanation [http://www.theregister.co.uk/2014/04/09/heartbleed_explained/]
		+	OpenSSL Github Fix [http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902]
		+
		+
		+	= The Fix =
		+
		+	The patch in OpenSSL 1.0.1g is essentially a bounds check, using the correct record length in the SSL3 structure (s3->rrec) that described the incoming HeartbeatMessage.
		+
		+	Below is the revised code from Github.[http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=731f431497f463f3a2a97236fe0187b11c44aead]
		+
		+	hbtype = *p++;
		+	n2s(p, payload);
		+	if (1 + 2 + payload + 16 > s->s3->rrec.length)
		+	return 0; /* silently discard per RFC 6520 sec. 4 */
		+	pl = p;

← Older revision		Revision as of 19:03, 10 April 2014
Line 2:		Line 2:

	Heartbleed is a catastrophic bug in OpenSSL, announced in April 2014.		Heartbleed is a catastrophic bug in OpenSSL, announced in April 2014.
		+
		+

	[[File:Heartbleed.png]]		[[File:Heartbleed.png]]

@@ Line 1: / Line 1: @@
 = Introduction =
 Heartbleed is a catastrophic bug in OpenSSL, announced in April 2014.
 = About the Name =

← Older revision		Revision as of 19:02, 10 April 2014
Line 1:		Line 1:
−	[[File:~~http://www.clickondetroit.com/image/view/-/25397200/medRes/1/-/maxh/360/maxw/640/-/14inmduz/-/~~Heartbleed~~-security-flaw-jpg~~.~~jpg~~]]	+	[[File:Heartbleed.png]]

	= Introduction =		= Introduction =