It's not a decision. If you were running a vulnerable version for any amount of time then revoking and reissuing keys and Certs after you patch is the only way to ensure someone doesn't have your private key material. You must patch, revoke AND reissue. If you are a public site and don't do this then you are placing your future client data at risk. On Wednesday, April 9, 2014, Steve Holdoway wrote:

On Wed, 2014-04-09 at 13:21 +1200, Dean Pemberton wrote:

[snip]

http://filippo.io/Heartbleed provides a quick and dirty tester, if you want to optimize ssl usage, then https://www.ssllabs.com/ssltest is far more thorough.

Most of my sites are CentOS 6 or Amazon linux. With both of these, a

yum update openssl\*

followed by restarting your web server implements the fix.

You still have the decision as to whether to revoke and replace the current cert though...

Steve -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz javascript:; http://list.waikato.ac.nz/mailman/listinfo/nznog

Do I really want to tell some random stranger "here's a potentially vulnerable site you can look at"?

The code for the site tool is available at https://github.com/FiloSottile/Heartbleed if you wanted to run it yourself (and check it's not sending it somewhere) Or a chrome addon to do the same. https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafd... Brad

Python version, for those who don't trust online tests.

Might want to have a look at this perhaps: http://seclists.org/nmap-dev/2014/q2/22 On 10/04/2014, at 9:04 am, Mark Goldfinch wrote:

Greetings all,

On 9 April 2014 22:13, Phil Regnauld wrote: Python version, for those who don't trust online tests.

Has anyone come across a heartbleed scanning tool which will allow one to scan v4/v6 CIDR netblocks?

Generically I'm thinking the process for resolution is:

1) Analyse 2) Plan 3) Act 4) Verify

In either steps #1 or #4 such a tool would be useful in identifying or verifying the problem is indeed resolved.

I'm not above getting into the code and making one myself, but would prefer to utilise someone else's work if it already exists!

Thanks, -- Mark Goldfinch Systems Team Leader, Modica Group Tel: +64 4 498 6000 mark.goldfinch(a)modicagroup.com www.modicagroup.com

Trusted Customer Engagement - communicate, connect and transact with your audience via mobile and internet channels

IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

The bug effects 1.0.1, so any appliance that pre-dates (Feb 2012) this version is unlikely to be a problem. That may reduce the number of devices/vendors you need to check. For example Ubuntu 10.04 LTS with openssl 0.9.8 should not affected by this bug. On Thu, Apr 10, 2014 at 9:33 AM, Scott Howard wrote:

What about binaries that might have OpenSSL statically linked? Even if you update the system libraries you could still be vulnerable.

Or the appliance (or out-of-band management card, print server, etc, etc) that you can't login to in order to be able to tell what version of the libraries it's using.

Or the system you did update the libraries on, but forgot to restart the webserver to pickup the change?

The best answer is normally going to be to do both - check the system itself to make sure it doesn't have an impacted version installed, but also check the individual services to make sure they are not impacted and/or have been fixed.

Scott

On Wed, Apr 9, 2014 at 2:19 PM, Eliezer Croitoru wrote:

...

On 04/09/2014 04:21 AM, Dean Pemberton wrote:

...

We have tree basic messages for website owners:

1. Establish if your site's servers are vulnerable. 2. Patch the vulnerable servers. 3. Revoke/reissue keys and certificates.

Isn't it very simple to just verify that you have or doesn't have the infected library and decide on the certificate revocation and reissuing?

Why to even test the issue if it was tested and validated to affect only on specific version of libs?

So I think the test tools are just for the fun and to run couple more code lines which describes the result of the test that was conducted on lots of versions of openssl already.

(just thinking out loud) Eliezer _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

There are snort signatures available to determine active exploitation. http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/ Th On 10 April 2014 10:33, Jasper Bryant-Greene wrote:

On 10/04/2014, at 9:33 am, Scott Howard wrote:

...

Or the system you did update the libraries on, but forgot to restart the webserver to pickup the change?

Don’t forget to restart things other than web servers! The bug is exploitable through SMTP, IMAP, POP3, XMPP, etc as well...

-Jasper _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On Thu 10 Apr 2014 19:38:01 NZST +1200, Michael Fincham wrote:

determine what daemons need to be restarted (if you're not using a Debian-alike you can probably work something out with `lsof | grep deleted' that functions similarly).

zypper ps Shows all running processes using deleted files.

Or just reboot the box :)

Yep :) Volker -- Volker Kuhlmann is list0570 with the domain in header. http://volker.top.geek.nz/ Please do not CC list postings to me.

On Thu, 10 Apr 2014 11:39:45 Eliezer Croitoru wrote:

If it's a custom software that is vulnerable I think that the exploit can be blocked using couple iptables u32 rules but I am not sure how to do that.(connection marking and phases of the connection)

Some iptables and wireshark rules from Bugtraq: http://seclists.org/bugtraq/2014/Apr/44 # Log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" # Block rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j DROP # Wireshark rules $ tshark -i interface port 443 -R 'frame[68:1] == 18' $ tshark -i interface port 443 -R 'ssl.record.content_type == 24' -- Jean-Francois Pirus | Technical Manager francois(a)clearfield.com | Mob +64 21 640 779 | DDI +64 9 282 3401 Clearfield Software Ltd | Ph +64 9 358 2081 | www.clearfield.com