Critical OpenSSL Vuln

wes allen

Not good:

Heartbleed Bug

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

yzT

critical but not difficult to patch, in fact, within hours many patches were available from vendors

wes allen

But, full remediation might mean revoking and reissuing certs, since you can't tell if your private keys were compromised or not.

Critical crypto bug exposes Yahoo Mail, other passwords Russian roulette-style | Ars Technica

YFZblu

yzT wrote: »

critical but not difficult to patch, in fact, within hours many patches were available from vendors

I feel so many emotions when I read this post - Aside from this issue, generally speaking, people don't avoid patching because they believe it to be difficult. They avoid patching because they aren't thoughtful or simply don't care enough.

Cert Poor

Hope more web server admins implement forward secrecy while patching OpenSSL to 1.01g as well as re-doing the private key/cert. Might as well go all the way.

docrice

The problem with Heartbleed is that if your traffic was compromised, there are no logs to indicate so. If an organization is determined vulnerable, the consideration for potentially revoking existing certificates, getting new ones issued and installed into servers/load balancers, and ultimately navigating through any change-control processes can be daunting on tight timelines when critical security issues are involved.

Add to the fact that some browsers don't do CRL checking so revoked certs, if re-used in the wild, may be blindly accepted. OCSP hopefully works well in place of that.

http://vimeo.com/91425662

The general advice that's been given is for the next few days while hopefully everyone who's providing SSL-based services (and actually affected by Heartbleed) gets their act together and patches, be wary of logging on and authenticating unless you're sure they're fixed. I'm not sure how ones goes about determining that without actively scanning the service or reading an announcement from them declaring that they're not in a vulnerable state.

mikeybikes

Use Heartbleed OpenSSL extension testing tool, CVE-2014-0160 to determine if you have any external facing services that are vulnerable.

Anything that is vulnerable, apply patches, re-issue certs, and change passwords.

Kind of a pain in the butt. We had a couple load balancers that were vulnerable, but that's it. Those have been patched and certificates re-issued.

lsud00d

Thanks for all of the information y'all. I didn't expect my current customer to have any OpenSSL products/implementations but just to be sure I checked all of the publicly available web applications and all came out fine via the link provided by @mikeybikes. Thinking through the other technologies in use, again I don't think any are utilized OpenSSL but I'll continue to prod/scan.

docrice

You can also use the Qualys SSL Labs server test:

https://www.ssllabs.com/ssltest/

lsud00d

Thanks @docrice, I'll check with that tool as well.

I liked the one @mikeybikes linked because it supported ports other than standard 443 for SSL

SweenMachine

UGHHHHHHHHHHHHHHHHHHHH

I'd like to say this has made my night a disaster. We had to change our security system on our medical records system.

OF COURSE they setup the thin clients and touchscreens to be so locked down, that you have to manually put the new certificate into IE...

UGHHHHHHH so many calls haha

-scott

gorebrush

I'm off work at the moment, but I can see an absolute storm of poo coming our way if my thinking is correct

(Not back in until Saturday)

5ekurity

Are there any technical details out there with regards to 'how' this is exploited? Our IDS is supposedly configured to alert on this, but I have my doubts that it will actually work.

--chris--

SweenMachine wrote: »

UGHHHHHHHHHHHHHHHHHHHH

I'd like to say this has made my night a disaster. We had to change our security system on our medical records system.

OF COURSE they setup the thin clients and touchscreens to be so locked down, that you have to manually put the new certificate into IE...

UGHHHHHHH so many calls haha

-scott

Those feels, I know them all. Zeros w/ touchscreens and angry nurses.

Qord

Sans put on nice webcast last night, and it looks like there will be another tonight.
https://www.sans.org/webcasts/openssl-heartbleed-vulnerability-98105
Edit: Better link

5ekurity

Qord wrote: »

Sans put on nice webcast last night, and it looks like there will be another tonight.
https://www.sans.org/webcasts/openssl-heartbleed-vulnerability-98105
Edit: Better link

Awesome, thanks for the link!

Also, there is an NSE script for NMAP out there that will detect vulnerable systems.

https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse

Here's a good article from The Register:

http://www.theregister.co.uk/2014/04/09/heartbleed_explained/

JDMurray

When you add the ssl-heartbleed.nse script file to your Nmap scripts folder make sure to run the nmap –script-updatedb command to update the scripts database, making ssl-heartbleed.nse a native script. After that you can use a command line like: nmap -n -PN -p 443 --script=ssl-heartbleed <host name | IP address> to check for Heartbleed vulnerabilities.

lsud00d

Edit: I figured it out.

YFZblu

docrice wrote: »

The problem with Heartbleed is that if your traffic was compromised, there are no logs to indicate so. If an organization is determined vulnerable, the consideration for potentially revoking existing certificates, getting new ones issued and installed into servers/load balancers, and ultimately navigating through any change-control processes can be daunting on tight timelines when critical security issues are involved.

Add to the fact that some browsers don't do CRL checking so revoked certs, if re-used in the wild, may be blindly accepted. OCSP hopefully works well in place of that.

OpenSSL Heartbeat (Heartbleed) Vulnerability (CVE-2014-0160) and its High-Level Mechanics on Vimeo

The general advice that's been given is for the next few days while hopefully everyone who's providing SSL-based services (and actually affected by Heartbleed) gets their act together and patches, be wary of logging on and authenticating unless you're sure they're fixed. I'm not sure how ones goes about determining that without actively scanning the service or reading an announcement from them declaring that they're not in a vulnerable state.

+1 for the video by Dr. Ramzan - His Sourcefire Chalk Talks were life savers when I entered the field.

DevilWAH

Always make it simple

Heartbleed bug explained by XKCD in a way anyone can understand

Qord

More Sans webcast:
https://www.sans.org/webcasts/heartbleed-vulnerability-2-98130

Tonight's webcast, 5:30 pm:
https://www.sans.org/webcasts/side-heartbleed-client-vulnerabilities-98135

NovaHax

Me and one of my colleagues exploited this on Friday after it was released. It is scary how easy it is to do. And how much revealing info is in the memory leaked. I would send credentials to a web-app over a "secure" TLS connection...and less than a minute later, he could tell me what credentials I sent.

As a security guy...this problem seriously concerns me. However, as a pentester...it excites me because this will probably go un-patched internally for a while. Easy wins right there.