OpenSSL leaks server-Keys / The Heartbleed Bug

Server NGINX
1

A missing bounds check in the handling of the TLS heartbeat extension
can be used to reveal up to 64k of memory to a connected client or
server.

https://www.openssl.org/news/secadv_20140407.txt
http://heartbleed.com/
http://www.reddit.com/r/netsec/comments/22gym6/diagnosis_of_the_openssl_heartbleed_bug/

regards,

mex

Posted at Nginx Forum:

2

Guide to Nginx + SSL + SPDY has been updated with some infos, links and
tests
regarding heartbleed

https://www.mare-system.de/guide-to-nginx-ssl-spdy-hsts/#heartbleed

regards,

mex

Posted at Nginx Forum:

3

I see this on Linux-Plug list:

"If your operating system uses OpenSSL 1.0.1 its servers are vulnerable.

CentOS and pulled his patch here:

http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html

If you have servers with Ubuntu 12.04 LTS you should take a look at this
discussion:

http://serverfault.com/questions/587574/apache-2-is-still-vulnerable-to-heartbleed-after-update-reboot"

2014-04-08 17:18 GMT-05:00 mex [email protected]:

mex

Posted at Nginx Forum:
Re: OpenSSL leaks server-Keys / The Heartbleed Bug

nginx mailing list
[email protected]
nginx Info Page

–
Un abrazo!

Ral Hugo http://twitter.com/raulhugo

Miembro Asociadohttp://apesol.org.pe http://apesol.org.pe/SysAdmin
Cel.
#961-710-096 Linux Registered User #482081 - http://counter.li.org/
http://counter.li.org/P Antes de imprimir este e-mail piense bien si
es
necesario hacerlo

4

There is not much to learn from a gujide that what has alrfeady been
said
on http://heartbleed.com.

More specifically, there is nothing related to nginx nor SPDY…
Heartbleed is related to OpenSSL and the solution is either to update
your
OpenSSL version/package with the official/your distro repository one and
restart OpenSSL-related processes to load the fixed library or recompile
your current library removing the support of the heartbeat capability.
On a side note, people having no use of heartbeat and having a fixed
version orf OpenSSL are advised to disable this capability to make the
trackdown of vulnerable versions easier in the near future in the
eventuality of a coordinated action to detect them and alert
administrators
responsible for the affected systems.

I suspect your are attempting to bring traffic to your website at all
costs with a pointless and misleading article… I despise that.

B. R.

5

Also it’s worth to look at the recent nginx blog post regarding
heartbleed:

NGINX and the Heartbleed vulnerability | NGINX

thanx for the link maxim, has been incorporated

regards,

mex

Posted at Nginx Forum:

6

“Answering the Critical Question: Can You Get Private SSL Keys Using
Heartbleed?”
@
http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed

wbr, Valentin V. Bartenev

7

On 4/9/14 2:18 AM, mex wrote:

Guide to Nginx + SSL + SPDY has been updated with some infos, links and
tests
regarding heartbleed

https://www.mare-system.de/guide-to-nginx-ssl-spdy-hsts/#heartbleed

Also it’s worth to look at the recent nginx blog post regarding
heartbleed:

–
Maxim K.

8

Hello,

On 4/11/14, 12:11 PM, Valentin V. Bartenev wrote:

“Answering the Critical Question: Can You Get Private SSL Keys Using
Heartbleed?”
@
http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed

Thanks for the link. On a quick read it seems their conclusion is that
while it is extremely unlikely that your private key(s) was/were
stolen using nginx, you should still re-key and revoke. While
comforting, not really of any great practical help.

Nice that CloudFlare (and no doubt others) received significant advance
warning while the rest of us were left vulnerable. Just sayin…

–
Jim O.

“Never argue with a fool, onlookers may not be able to tell the
difference.” - Mark Twain

9

Am 11.04.2014 18:34 schrieb Jim O.:

Thanks for the link. On a quick read it seems their conclusion is
that while it is extremely unlikely that your private key(s)
was/were stolen using nginx, you should still re-key and revoke. While
comforting, not really of any great practical help.

Adding info from

it looks like for tests so far only freebsd/apache2 is a combo where
private key data could leak.

Nice that CloudFlare (and no doubt others) received significant
advance warning while the rest of us were left vulnerable. Just
sayin…

Really… those with deep pockets get warning “in advance”. Blah.

10

Fyi. if you are running a ssl tunnel like stunnel with openssl 0.9.x,
this
attack is logged as “SSL3_GET_RECORD:wrong version number” as opposed to
no
nginx/openssl logging.

If you have logging going back 2 years and you are seeing these log
entries
now, you may be able to detect attacks from before 7-4-2014.

Here we have many stunnels with openssl 0.9.x and found the first
attacks
at: 2014.04.08 22:19:14 (CET) in more then 2 years of logging.

Posted at Nginx Forum:

11

Hi,

Thanks for the link. On a quick read it seems their conclusion is that
while it is extremely unlikely that your private key(s) was/were
stolen using nginx, you should still re-key and revoke. While
comforting, not really of any great practical help.

They updated the post, their initial analysis was wrong.

Also see:
http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge

Nice that CloudFlare (and no doubt others) received significant advance
warning while the rest of us were left vulnerable. Just sayin…

They had no choice. They couldn’t notify a lot of people about this, it
would have been leaked to exploit kits and black hats before OpenSSL
provided the bugfix. That would have been a lot worse.

Regards,

Lukas

12

Hello!

On Mon, Apr 14, 2014 at 03:03:54PM -0400, itpp2012 wrote:

Fyi. if you are running a ssl tunnel like stunnel with openssl 0.9.x, this
attack is logged as “SSL3_GET_RECORD:wrong version number” as opposed to no
nginx/openssl logging.

If you have logging going back 2 years and you are seeing these log entries
now, you may be able to detect attacks from before 7-4-2014.

Here we have many stunnels with openssl 0.9.x and found the first attacks
at: 2014.04.08 22:19:14 (CET) in more then 2 years of logging.

I suspect that this is just a particular script to exploit the
vulnerability, which doesn’t care much about being correct and
is seen this way due to incorrect handshake. Proper exploitation
shouldn’t be detectable this way.

And yes, it’s seen on more or less any 0.9.x OpenSSL
installation, including nginx:

2014/04/15 04:02:57 [info] 48738#0: *2785200 SSL_do_handshake() failed
(SSL: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number)
while SSL handshaking, client: 182.118.48.115, server: 0.0.0.0:443

–
Maxim D.
http://nginx.org/