CVE-2019-19521 and PFSense
-
See https://www.openwall.com/lists/oss-security/2019/12/04/5
Seems 2.4.4_3 is affected. Any ETA on the update?
-
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.
-
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. -
@JeGr said in CVE-2019-19521 and PFSense:
The CVE talks about OpenBSD, not FreeBSD.
Hummm. Pretty good point ...
-
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.
-
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. -
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 -
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.