SonicWall false positive for Default Credentials brute force

SonicWall devices may see false positives for SSH Brute Force Logins With Default Credentials Reporting (oid 1.3.6.1.4.1.25623.1.0.103239) and others because of their response on SSH.

Instead of following standard SSH responses, sonic wall returns with their own messages first when trying to login. Therefore, the scanner thinks it was possible to login to SSH.

image001

1 Like

Thanks @PBSH for reporting that and it’ll help in case anyone else runs into it :slight_smile:

If someone is able to help me with improving the NVT to prevent these false positives, you’re welcome! :slight_smile:

The check if a login was successful is done via SSH functionality provided by the scanner so a improvement on VT side isn’t possible at all.

Okay, so in order to resolve this issue, this needs to be done in the Git repository? I’ll look if I can make a Pull Request, or does Greenbone has a resolution for this issue scheduled already?

2 Likes

Yes, any improvement would need to be done in the ssh_userauth() function of the scanner (as used in the ssh_login() function of ssh_func.inc) below as this is the one which is reporting the successful login to the VT in question even if it seems that the login wasn’t successful.

Currently i’m not aware of any schedule for this issue, thanks a lot for your interest / considering to provide a pull request.

3 Likes