Router failing PCI Compliancy due to OpenSSh vulnerability

[jadog]

I have been using the Asus-Merlin firmware on a RT-66U router for a number of years. The current firmware is 384.7. The router sits directly behind a modem and all other switches or networking appliances connect directly to the router at our business. Each quarter I am getting a notice from our credit card company that shows the TrustWave PCI scan is failing with the message "OpenSSH Username Enumeration Vulnerability". The recommended step then indicates that I should upgrade to OpenSSH 7.8 or later. I am attaching the PCI report showing the failed scan.

I have reviewed the configuration on my router and DDNS is NOT enabled and neither is remote wan access (see attached image). Does anybody have a suggestion??

 

[RMerlin]

Their test is flawed, since Asuswrt-Merlin doesn't even have OpenSSH...

 

[CasualObserver]

Have a look at this as it is likely the Dropbear equivalent to reported CVE-2018-15473 openssh vulnerability:

CVE-2018-15599
Name
CVE-2018-15599
Description
The recv_msg_userauth_request function in svr-auth.c in Dropbear through 2018.76 is prone to a user enumeration vulnerability because username validity affects how fields in SSH_MSG_USERAUTH messages are handled, a similar issue to CVE-2018-15473 in an unrelated codebase.

 

[CasualObserver]

The release below had a fix go in for CVE-2018-15599, would make sure that minimum version you are using is release noted here:

384.7_2 (21-Oct-2018)
- FIXED: Namecheap DDNS service not working
- FIXED: CVE-2018-15599 security issue in Dropbear
- FIXED: Potential buffer overrun in httpd

 

[jadog]

Awesome! Thanks you guys. I'll give that a go and report back.

 

[jadog]

I updated the Asus-Merlin firmware to 384.8_2, and when the most recent Aperia scan ran, it still reported a vulnerability in OpenSSH. Can anyone provide how this can be addressed? If there is no path forward here, I'll have to move back to the default ASUS firmware .

 

[AndreiV]

I updated the Asus-Merlin firmware to 384.8_2, and when the most recent Aperia scan ran, it still reported a vulnerability in OpenSSH. Can anyone provide how this can be addressed? If there is no path forward here, I'll have to move back to the default ASUS firmware .

Router failing PCI Compliancy due to OpenSSh vulnerability

How can anyone address something that doesn't exist?

The scan is wrong.

 

[ColinTaylor]

+1 What @AndreiV and RMerlin said.

What router model do you have? RT-66U is not a valid model number. Also, 384.8_2 is not the current release.

The dropbear vulnerability mentioned in post #3 was already fixed in 384.7_2 (21-Oct-2018).

 

[dave14305]

I updated the Asus-Merlin firmware to 384.8_2, and when the most recent Aperia scan ran, it still reported a vulnerability in OpenSSH. Can anyone provide how this can be addressed? If there is no path forward here, I'll have to move back to the default ASUS firmware .

Having SSH open to the WAN and publishing your IP in the screenshot is a bigger Compliance issue than any SSH vulnerability.

 

[ColinTaylor]

Having SSH open to the WAN and publishing your IP in the screenshot is a bigger Compliance issue than any SSH vulnerability.

I was just thinking the same thing.

Confusingly, in his first post he has a screen shot of the router that shows SSH as disabled! So I'm wondering if this "OpenSSH" detection is not his router at all but part of his ISP's infrastructure.

OTOH He seems to be confused over what router and firmware he is running so I'm not sure what to believe at this point.

 

[EmeraldDeer]

I was just thinking the same thing.

Confusingly, in his first post he has a screen shot of the router that shows SSH as disabled! So I'm wondering if this "OpenSSH" detection is not his router at all but part of his ISP's infrastructure.

OTOH He seems to be confused over what router and firmware he is running so I'm not sure what to believe at this point.

Perhaps the audit somehow runs on the LAN as the router administrator rather than from the WAN?

If it is hardcoded to consider OpenSSH but not Dropbear, then any patch level is no good. By the way, I am running 384.10_2 and "ssh -V" returns Dropbear v2018.76 which probably needs patching.

Anyways, Entware has an OpenSSH client package "openssh-client - 7.9p1-4". If it was installed and the PATH modified to use it instead, then maybe the audit would succeed because all it does is run "ssh -V".

 

[L&LD]

Perhaps the audit somehow runs on the LAN as the router administrator rather than from the WAN?

If it is hardcoded to consider OpenSSH but not Dropbear, then any patch level is no good. By the way, I am running 384.10_2 and "ssh -V" returns Dropbear v2018.76 which probably needs patching.

Anyways, Entware has an OpenSSH client package "openssh-client - 7.9p1-4". If it was installed and the PATH modified to use it instead, then maybe the audit would succeed because all it does is run "ssh -V".

I hope that the TrustWave PCI scans are from outside the network when they are trying to find vulnerabilities in it though.

 

[EmeraldDeer]

I hope that the TrustWave PCI scans are from outside the network when they are trying to find vulnerabilities in it though.

It is not even a router, maybe a port forward to an Ubuntu computer.

# telnet 47.75.199.9 22
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8

# telnet router.asus.com 22
SSH-2.0-dropbear_2018.76

 

[john9527]

By the way, I am running 384.10_2 and "ssh -V" returns Dropbear v2018.76 which probably needs patching.

Merlin picked up dropbear 2019.78 in the 384.11 builds.....My fork picked it up for V39E1

 

[L&LD]

It is not even a router, maybe a port forward to an Ubuntu computer.

# telnet 47.75.199.9 22
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8

# telnet router.asus.com 22
SSH-2.0-dropbear_2018.76

Sorry, I don't think I am following you?

 

[EmeraldDeer]

Sorry, I don't think I am following you?

I ran telnet to their router's ssh port just to get the banner like I am assuming the audit does. This also establishes that the audit could have been from the WAN. Since the banner says Ubuntu, it is not an Asus router. Then what is it? I speculate that it is a port forward to an Ubuntu host on their LAN. All they need to do is upgrade Ubuntu on that other computer. Or better yet, turn off port 22 on the WAN and use a router VPN server to get access.

 

[L&LD]

I ran telnet to their router's ssh port just to get the banner like I am assuming the audit does. This also establishes that the audit could have been from the WAN. Since the banner says Ubuntu, it is not an Asus router. Then what is it? I speculate that it is a port forward to an Ubuntu host on their LAN. All they need to do is upgrade Ubuntu on that other computer. Or better yet, turn off port 22 on the WAN and use a router VPN server to get access.

I am duly impressed! You may have solved this for the OP.

 

[RMerlin]

Merlin picked up dropbear 2019.78 in the 384.11 builds.....My fork picked it up for V39E1

The only CVE issue resolved by 2019.78 was already patched in my tree back in October, so there's no emergency for 384.11 - 384.10_2 is still secure on that front.