Patching/Upgrading OpenSSL

BBcan177

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

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

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

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

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!

BBcan177

@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

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

dgcom

(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

@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

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

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

@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

@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

@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

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

Darkk

@zandr:

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

Say it aint so!

BBcan177

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

pvoigt

@fatsailor:

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.

Thanks so far. But could you please provide the URL of this issue. I would like to follow that topic. I have just searched the FreeBSD forum but did not find it.

Peter

fatsailor

@dgcom:

@jimp:

VPN or SSH is best. Letting anyone even touch your GUI port remotely from an arbitrary IP is a bad thing. As this proves, it's not about a password, it's about exploiting the service itself. Custom ports won't hide you for long.

Are you saying VPN or SSH never had any security issues? Don't think so. VPN is also not convenient - does not work from many locations. SSH is better, but theoretically can be exploited as well - with the bug you do not know about (yet).

What is really missing for Web UI is the IP lockout if someone tries to brute force password.

It's really about the size of the attack surface you present to an adversary. The surface of SSH is small and WELL understood. The surface of a web GUI is large and not well understood.

Using an approach like FAIL2BAN to block IP's is useful, but it is far from sufficient protection.

fatsailor

@pvoigt:

@fatsailor:

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.

Thanks so far. But could you please provide the URL of this issue. I would like to follow that topic. I have just searched the FreeBSD forum but did not find it.

Peter

Yes - Finding things at FBSD forums isn't easy.

Here you go - http://forums.freebsd.org/viewtopic.php?f=5&t=45870&start=25

There's been been no further discussion on the topic