'SSH Brute Force Logins With Default Credentials' creates false positive for nologin (OID: 1.3.6.1.4.1.25623.1.0.108013)

Vulnerability Tests
1

‘SSH Brute Force Logins With Default Credentials’ (OID: 1.3.6.1.4.1.25623.1.0.108013).

This test claims that login is possible for
anonymous: empty/no pw

however, this account is usually reserved for ftp and has a nologin shell. So login is actually not possible, still this generates a finding.

Shouldn’t this be corrected?

2

It’s hard to respond to a question like that because you have provided no information about the system being scanned and the additional details of the result.

3

Actually I have provided the information necessary to assess the problem. This would happen under every Unix system what has an account “anaonymous” with no password but a nologin shell. In this case it is a Synology NAS box, but this happen under any other system with such an account, too. The exact OS version should not matter. Just try it out.

4

I guess that maybe the summary description or the QoD could be changed:

It was possible to login into the remote SSH server using
default credentials.

But I’m curious to look at the .nasl file to see what is done in the test.

5

The NASL file is default_ssh_credentials.nasl. The test uses the return of the ssh_login() function which checks if several default user/pass pair is accepted by the SSH service.

In fact, if the result of the login is a success, then the test is accurately reporting what it claims in the summary. Returning an interactive shell is not the definition of the test.

Knowing that a default account/password exists would become a critical and severe vulnerability if an exploitable vulnerability in SSH were discovered for example.

6

Careful, that does not guarantee your SSH is not exposing your system. In times with PAM and complex sshd configuration, it no longer guaranies you a secure system.
If you enable SSH plugins that is even more dangerous.

You really should not use a anonymous account in 2023.

2 Likes
7

it is not that I am using that. It is baked into Synology DSM like that, That also means its not like you could configure PAM or SSH plugins there - so in a way, in this product environment this is safe, if you don’t modify the system on your own. So for Synology DSM6.2 or lower (I dont know about DSM 7) this is more a false positive then a helpful result, as you do not really have any way to fix it from the DSM UI (the account is there, even if the FTP service is disabled or if anonymous FTP is disabled). You would need to log in to the system and manually edit the passwd file - which I wouldn’t recommend to do as it is probably overwritten the next time you edit users in the UI.

so I guess, in general one wants the test to report this, but for Synology DSM one might condider this a FP.

8

I wouldn’t call this a false positive.

The VT seems to work as expected as it reports the successful login and having a login-shell is no prerequisite for a vulnerability:

  1. It might be still possible to access e.g. sensitive files via SFTP (should be still possible if e.g. /sbin/nologin is set for the user shell)
  2. An attacker can use the information about the enabled anonymous account to compromise other services on the same system or even other devices in the network
  3. The VT also needs to work against a wide range of non-linux systems where a concept like a “login shell” AFAICT doesn’t exist

Usually results of automated tools always needs to be manually verified and if it turns out that a specific result doesn’t impose a risk for a specific system or the risk should be accepted an override can be created:

GSM Manual: 11.8.1 Creating an Override

5 Likes
9

You make a number of valid points, thanks for the insights.

1 Like