False positive (hopefully!) SSH vulnerability report

1

Having left an unprotected VyOS router connected to the Internet (and nothing else!), the Jersey Cyber Security Centre (https://jcsc.je) contacted me the next day to tell me that Shadowserver had reported that its SSH was vulnerable to CVE-2024-6387.

This vulnerability is described as affecting OpenSSH versions 8.5p1 to 9.7p1 (inclusive).

When scanning recent VyOS (my tests were with 1.4.2 & 1.5-stream-2025-Q2), one sees:-

$ sudo nmap -p 22 --version-all -sV 192.168.46.105
Starting Nmap 7.80 ( https://nmap.org ) at 2025-07-12 14:00 BST
Nmap scan report for 192.168.46.105
Host is up (0.030s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 (protocol 2.0)
MAC Address: E6:A7:A0:DF:88:10 (Unknown)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.57 seconds

where 9.2p1 would be within the vulnerable range. However the actual version installed (in 1.5) is:-

vyos@vyos:~$ sudo apt list openssh-server --installed
Listing... Done
openssh-server/now 1:9.2p1-2+deb12u6 amd64 [installed,local]

DSA-5724-1 stated that CVE-2024-6387 has actually been fixed in Debian 12 from version 1:9.2p1-2+deb12u3, meaning that neither 1.5 nor 1.4.2 should actually be vulnerable.

On other (non-VyOS) Debian machines, a scan shows the full version:-

$ sudo nmap -p 22 --version-all -sV redacted.itconsult.net
Starting Nmap 7.80 ( https://nmap.org ) at 2025-07-12 13:16 BST
Nmap scan report for redacted.itconsult.net (x.x.x.x)
Host is up (0.036s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u5 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds

The difference between the two scan results is due to their being “DebianBanner no” in /var/run/sshd/sshd_config on VyOS. Commenting it out as a test causes the full version to be returned.

My suspicion was that if Shadowserver saw the full version, it would not have erroneously flagged the vulnerability.

Is there a reason for having “DebianBanner no” set? If not, perhaps it should be removed. I am happy to log it on vyos.dev if this is thought appropriate.

Best wishes,
Matthew

1 Like
2

Welcome to the world of falsepositives from vulnerability scanners.

Most have shitty detection where they only look at part of the versionnumber and dont understand that for example Debian will backport security fixes while remaning on the same versionnumber (you see that “u5” from the full version string?).

In my world there is no need to expose anything other than the vendor of the product like so: “OpenSSH 9.2p1 (protocol 2.0)”. You would in this case need to have some more than just “OpenSSH” due to how clients can behave based on version detected. This might work aswell “OpenSSH (protocol 2.0)” since its really the protocol who defines how the SSH-client will behave.

I do the same for webservers (“Apache 2.4”) etc.

One could argue if even the vendor should be exposed (like in your case just set “SSH (protocol 2.0)” but my take is that someone who want to hack your system wont just “Oh snap, he got an updated OpenSSH server - lets move to another target”… they will send all the junk anyway and see what sticks no matter of what your server claims to be running.

Reason why the full version shouldnt be exposed is that this might limit the amount of noise the hacker will make (unless they just start with the latest CVE’s and move their way down to the oldest). And a noisy attacker is good to identify them and put their sourceaddresses in blacklist.

1 Like
3

Check git blame.
The original task is âš“ T4205 Disable Debian Version in SSH (DebianBanner->no)

4

Thank you most kindly for the task info…