CVE-2019-19521 and PFSense

achtgm

See https://www.openwall.com/lists/oss-security/2019/12/04/5

Seems 2.4.4_3 is affected. Any ETA on the update?

Gertjan

Seems ?

pfSense is a firewall, so no smtpd, raduisd, ldapd listening on any outside NIC.

All you get is

Even if an attacker were able to bypass sshd's authentication with an
invalid user such as "-schallenge", sshd would eventually reject it.

So, they list sshd - to conclude that it's a no-go.
( and "sshd" should only be accessible on a trusted LAN - from the other possible LAN's (OPTx) interfaces no one should be able to access ssh 22 anyway )

su ? Need to get past sshd first.

JeGr

Where does it list "pfsense" or FreeBSD as vulnerable? The CVE talks about OpenBSD, not FreeBSD. I'd be careful not to mix up upstreams as you don't know which fix what system has included and which it hasn't.
Besides that all those services besides sshd and su aren't installed per default on pfSense and sshd isn't enabled by default (and not even from WAN). As pfSense UI doesn't use one of those auth methods listed as default there might only be some local auth expoitation possible (if the appropriate packages are used) and exploited from the inside. There's nothing screaming remote exploitable or only limited without a local user even.

Gertjan

@JeGr said in CVE-2019-19521 and PFSense:

The CVE talks about OpenBSD, not FreeBSD.

Hummm. Pretty good point ...

tm_an

I tested the SSH proof-of-concept from the CVE against our firewall:

ssh -v -F /dev/null -o PreferredAuthentications=keyboard-interactive -o KbdInteractiveDevices=bsdauth -l -sresponse:passwd <IP-OF-OUR-FIREWALL> -p 22022

which returned immediately. According to the researcher's article, a vulnerable system would wait for the challenge, so it seems pfSense is not affected.

Gertjan

For the last decade or so, this method :

@tm_an said in CVE-2019-19521 and PFSense:

PreferredAuthentications=keyboard-interactive

exists during the first, initial ssh login, when the admin takes 'control' of the system.
Subsequent ssh access would/should be setup using public key method :

This goes for any BSD/Linux/... system.

This

@tm_an said in CVE-2019-19521 and PFSense:

-p 22022

port can be found with a port scan in a second or so.
So, "22" is as good as any other port.

tm_an

While I agree that changing the SSH port does not add any severe limits to a dedicated attacker, it does prevent the sheer mass of default port scans/script kiddie attacks to succeed. So it has some value IMHO. It's not available from the internet though, so it really does not matter. I also agree "Public Key Only" should be configured.

But the command was to check if the system as is is suspectible to the specific attack mentioned in the CVE. That SSH can, and should, be hardened is an entirely different matter ;-)

Cheers,
Tobias

Gertjan

This is pfSense : The sheer mass has access to your LAN interface

More general : I've a couple of dedicated mail/web/fool-around servers on the net, which I consider as the real "mass", for many years now. They all have SSH on port 22. And fail2ban (pfSense has the same facility build in) to deal out "one week" penalties.

Btw : more or less fake, but works pretty well just up until now : de activated IPv4 - use only IPv6. You'll experience the silence ... ^^

KIds could use this

for ip is 1 to 4294967296
   do ...

This

for ip is 1 to 340282366920938463463374607431768211456
   do ....

needs more reflection.