Patching/Upgrading OpenSSL

ingmthompson · Apr 9, 2014, 8:51 PM

@Satras:

@ingenieurmt:

my network is simply not interesting enough to warrant targeting,

No Offend, but this Attitude makes you a prime Target. People believeing they are save cause they are not interresting enough.

I'd prefer to keep my own counsel on what my attitude may or may not constitute, if you don't mind.

keychain · Apr 9, 2014, 8:54 PM

hm.. should I stay up for an hour more or two?

doktornotor · Apr 9, 2014, 8:57 PM

BBcan177 · Apr 9, 2014, 9:14 PM

Snort has released some rules to help detect this vulnerability. If they work?

Just an FYI

http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.html

fragged · Apr 9, 2014, 9:22 PM

Requires a Snort subscription of course to get the rule now, not after 30 days when it hits the free rules set.

Reading the article, it seems like the actual rules are released in the post also :)

BBcan177 · Apr 9, 2014, 9:24 PM

The rules are listed on their website.

Copy and paste them into the local rules… ;)

I'm sure that's why they posted them like that. I have a paid subscription so its already in my ruleset.

dgcom · Apr 9, 2014, 9:55 PM

Have you tested it? Not working for me. Its like snort ignoring custom rules… :(

karlfife · Apr 9, 2014, 9:57 PM

Is the server side (listener side) of site-to-site OpenVPN configured with a pre-shared key vulnerable to the heartbleed exploit? I don't know if the PSK is functionally similar to a TLS authentication key.

The good news is that most (not all) of our server listener ports have a WAN rule restricting connections to those ports to static IPv4 addresses. The bad news is the 'not all' part.

Questions:
1. Are IP-agnostic site-to-site OpenVPN listeners (configured with PSK) vulnerable to heartbleed?
2. If the answer to #1 is "yes, vulnerable", and if the aforementioned unrestricted listeners are configured to be limited to ONE connection, and if the connection has been nailed up the entire time, would that prevent a drive-by from exploiting the vulnerability?
3. If the answer to #1 is "yes, vulnerable" and the answer to #2 is 'No, vulnerable', is the post-update remedy to simply re-key the vulnerable server and client? In other words would the SINGLE vulnerable server listener expose ALL of the PSK's bound to ALL of the server instances, or just the one? (simplifying re-keying)

Thanks in advance for the rapid response to the vulnerability!

BBcan177 · Apr 9, 2014, 10:14 PM

@dgcom:

Have you tested it? Not working for me. Its like snort ignoring custom rules… :(

I compared the rules and they are the same on the blog as in the posted VRT ruleset.

In Snort:WAN Rules:custom.rules

Did you upgrade to the latest snort version? I am still on the previous release. (Not sure if that matters)

As a test, I copied two of the rules and changes the rule sid (so I wouldn't have duplicates) and they saved no problem.

EDIT: Maybe now is a good idea to pay the $29.00 for a Snort VRT membership?

hans-d · Apr 9, 2014, 10:16 PM

Tested the posted rules, and ran http://filippo.io/Heartbleed/ to test. Alert (and ip block) appeared referencing the rule…

dgcom · Apr 9, 2014, 10:25 PM

(Yes, running latest snort package).

For me, custom rules did not work, but they are already included for free in emerging-current_events.rules and those are catching it.

jimp · Apr 9, 2014, 10:33 PM

@karlfife:

Is the server side (listener side) of site-to-site OpenVPN configured with a pre-shared key vulnerable to the heartbleed exploit? I don't know if the PSK is functionally similar to a TLS authentication key.

The good news is that most (not all) of our server listener ports have a WAN rule restricting connections to those ports to static IPv4 addresses. The bad news is the 'not all' part.

Questions:
1. Are IP-agnostic site-to-site OpenVPN listeners (configured with PSK) vulnerable to heartbleed?
2. If the answer to #1 is "yes, vulnerable", and if the aforementioned unrestricted listeners are configured to be limited to ONE connection, and if the connection has been nailed up the entire time, would that prevent a drive-by from exploiting the vulnerability?
3. If the answer to #1 is "yes, vulnerable" and the answer to #2 is 'No, vulnerable', is the post-update remedy to simply re-key the vulnerable server and client? In other words would the SINGLE vulnerable server listener expose ALL of the PSK's bound to ALL of the server instances, or just the one? (simplifying re-keying)

Thanks in advance for the rapid response to the vulnerability!

PSK is not vulnerable. This was specific to SSL/TLS.

hans-d · Apr 9, 2014, 10:43 PM

Also some snort rules http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/, slightly different from the the snort team.

dgcom · Apr 9, 2014, 10:46 PM

Did some more testing, but could not make rules from here to work in custom rules.
However, updated emerging-current_events.rules works pretty well.

Anyone, who has snort installed should get free ETOpen rules updated and check emerging-current_events.rules on WAN interface.

fatsailor · Apr 9, 2014, 11:38 PM

@jimp:

freebsd-update won't work on pfSense, and would break things if it did. At least for now. Might change in the future.

OpenVPN and lighttpd don't need rebuilt, they are not statically linked to OpenSSL.

Just wait for a firmware update, it'll be coming soon.

That's my plan- wait. It appears that at least the FBSD p1 patch to 10.0 stuffed things up a bit. They updated the shared libs, but not the headers. Now anyone compiling ports has issues…...

Since freebsd-update can potentially break things, I for one would argue you need to take it out of the distro. You don't want a cowboy (like myself) going crazy updating and breaking things.

I'd love to see it in the distro, but I realize that such a mechanism creates a major can of worms in trying to maintain configuration management.

pvoigt · Apr 9, 2014, 11:59 PM

@fatsailor:

That's my plan- wait. It appears that at least the FBSD p1 patch to 10.0 stuffed things up a bit. They updated the shared libs, but not the headers. Now anyone compiling ports has issues…...

Hm, I have yesterday installed p1 on FreeBSD 10.0-RELEASE. And today I have upgraded e.g. port www/apache22. I did not have any problems when building and installing. And Apache is still working. Do you have any reference for your "Now anyone compiling ports has issues…..". Or have I just been favoured by fortune :)

Regards,
Peter

fatsailor · Apr 10, 2014, 1:24 AM

@pvoigt:

Hm, I have yesterday installed p1 on FreeBSD 10.0-RELEASE. And today I have upgraded e.g. port www/apache22. I did not have any problems when building and installing. And Apache is still working. Do you have any reference for your "Now anyone compiling ports has issues…..". Or have I just been favoured by fortune :)

Regards,
Peter

There was a post on the FreeBSD forums about a mismatch between the libraries and the headers when configuring 'curl':

checking for OpenSSL headers version… 0.9.8 - 0x0090819fL
checking for OpenSSL library version... 1.0.1
checking for OpenSSL headers and library versions matching... no
configure: WARNING: OpenSSL headers and library versions do not match.

I didn't see any headers in p1 (but then I just did a simple grep). It's likely that apache's configure doesn't check for consistency between the headers and the libraries.

zandr · Apr 10, 2014, 2:09 AM

Returning to the original thread, has the 2.1.2 build gone off the rails?

Darkk · Apr 10, 2014, 2:45 AM

@zandr:

Returning to the original thread, has the 2.1.2 build gone off the rails?

Say it aint so!

BBcan177 · Apr 10, 2014, 4:50 AM

http://packetstormsecurity.com/news/view/23941/Everything-You-Need-To-Know-About-The-Heartbleed-SSL-Bug.html