Do the OpenSSH 7.9 CVEs apply to pfSense?

[senseivita]

I was playing around on Shodan.io and I could resist entering my gateway's IP address on the search box; it only detects the ports for the HTTP & SSH services so pretty good considering that firewall doesn't block anything at all, it NATs full cone via tunnel all traffic to the local firewall (and completely unencrypted)

Anyway, it found these CVE warnings:

Honestly I'd be more worried about my IP address getting blacklisted – as it turns out it already is, at the ASN level – than if the gateway gets compromised but I am curious so I had to come find out if pfSense is affected by it. It does say it's pretty much a wild guess just on the version alone. :) Should I start clutching my pearls and looking around bewildered? :O

[johnpoz]

@skilledinept said in Do the OpenSSH 7.9 CVEs apply to pfSense?:

it NATs full cone via tunnel all traffic to the local firewall

So where you actually talking to pfsense ssh there, or were you talking to the firewall behind pfsense ssh?

But all of those issues look more like client issues, and possible man in the middle attacks on your client.. Are you using ssh pfsense as client to talk to something that could be a mitm to where your wanting to talk to?

[stephenw10]

2.5.2 uses 7.9p1 anyway:

[2.5.2-RELEASE][admin@pfsense.fire.box]/root: ssh -V
OpenSSH_7.9p1, OpenSSL 1.1.1k-freebsd  25 Mar 2021

2.6 uses the updated OpenSSL version:

[2.6.0-RC][admin@4220.stevew.lan]/root: ssh -V
OpenSSH_7.9p1, OpenSSL 1.1.1l-freebsd  24 Aug 2021

[johnpoz]

@stephenw10 while yes its 7.9p1 - still in the 7.9 base, and if you connect via ssh to the server - your only going to see the 7.9 banner

debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9

That is what I show when connect from my pc to 21.05.2

But yes its 7.9p1

[21.05.2-RELEASE][admin@sg4860.local.lan]/var/db: ssh -V
OpenSSH_7.9p1, OpenSSL 1.1.1k-freebsd  25 Mar 2021

Kind of would of hoped that new pfsense would of updated to the 8.8 version ;) But don't think its actually in the freebsd base yet.

From a quick looky see on that first CVE, looks like 7.9p1 is not vun anyway.. So its a misrepresentation of issue, which never ever happens with scanning software ;) hehehe

From here
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234965

This should of been taken care of in freebsd 12, and pfsense is currently on 12.2..

And again - all those seem to be related to scp, if your client version is that, etc. so if you were being mitm using that version as client, you could have some issues..

edit: side note.. I wouldn't have ssh open to the public in the first place, not unless you could lock down the source IPs. And don't think I have ever used pfsense ssh in client mode.. The only thing that can ssh to my pfsense, is my pc on my admin lan ;) So when used correctly I don't think really any of the typical cve that come out for ssh are of real concern, if ssh is used sanely ;) Not saying ssh shouldn't be kept up to date, or securely configured as best as possible. Just saying more than likely any cve shouldn't/couldn't really apply in the first place.

edit2: just because guess I am in a rambling mood. If you want really bad support for ssh, look to stuff like switches and or iot devices where the version is quite often ancient, and doesn't even support modern ciphers or algorithms and no way to update them.. Ran into a issue with my unifi APs the other day.. they use dropbear, but its OLD 2017 version, and I lost access to even ssh to them because securecrt finally deprecated use of old host keys. So I had to modify the session options to still allow for the old host keys ssh-rsa

edit3: look at this old shit my switch does, and there is no way to fix it..

Unable to negotiate with 192.168.9.99 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

[senseivita]

So where you actually talking to pfsense ssh there, or were you talking to the firewall behind pfsense ssh?

Both the gateway (named cloudfront) and firewall are pfSense, same version too. SSH and the tunnel server are the only two ports/protos not forwarded, even the web UI for cloudfront is forwarded to the local firewall where it goes through all of filters, (rules, NAT, geographic, reputation, signatures) passed to HAProxy on another system then back out the gateway.

@stephenw10 I connected to the local instance in verbose and I saw it read p1 too. It was out of curiosity though, not concern--to see how readily is info like this available to scanner.

SSH was/is open in case of lockouts so I don't have to deal with the OpenStack console but now that I think about it since it (cloudfront) is (1) already passing everything there's little chance of breaking things that I don't need to adjust and (2) DNS exits through the tunnel only meaning nothing works if it's broken for any reason which wouldn't be a quick fix so I'm following @johnpoz example and closing it down--or maybe forward it to HAProxy and do that TLS+SNI+SSH thing.

BTW, if you think your switch is old... I have a Cisco 7975 phone to which no system released in at least the last 5 years connects without warnings+options and even further unsupported is this Polycom CX700, it doesn't open SSH but it does need to find a CA via DNS/LDAP (and thus the AD domain via DHCP) where the best possible pkey can be a 2048bit RSA key and watchout for the resulting chain so it's not too long in an already very-prone-to-error Microsoft PKI.

This was fun. :) Thank you to both for answering.

[johnpoz]

@skilledinept said in Do the OpenSSH 7.9 CVEs apply to pfSense?:

-to see how readily is info like this available to scanner.

you could turn off the banner, Not sure if pfsense allows for that in the gui? But if your allowed to talk to the ssh and try and negotiate a connection to "auth" you would still be able to get info like what algos and ciphers are possible.

You could edit the sshd conf directly, but that would just get reverted on update, etc.

Security scanners can be very useful - and fun even. But a lot of what they report really needs to be taken with a grain of salt, if not a whole freaking tablespoon of it ;)

But it did do its job - it got you curious, and looking into, and now you prob make for a more secure setup even if what it had reported wasn't really valid ;)