'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
10

I ran into the same issue here. I see this happen when I attempt to SSH using the anonymous user:

~ ssh anonymous@nas

Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.

Permission denied, please try again.

Connection to nas closed.

So it does appear like the login is successful before you get booted out. There are a couple of ways to remedy this:

Method 1 - False Positive:

Mark this as a false positive in Greenbone.

Method 2 - Expire anonymous user:

Per this post, you can run synouser to modify certain user properties. I was able to use this to expire the anonymous account.

Login to the NAS via SSH and switch to the root user. Here are the commands:

~ which synouser
/usr/syno/sbin/synouser

~ synouser --get anonymous
User Name   : [anonymous]
User Type   : [AUTH_LOCAL]
User uid    : [21]
Primary gid : [21]
Fullname    : []
User Dir    : [/nonexist]
User Shell  : [/usr/bin/nologin]
Expired     : [false]
User Mail   : []
Alloc Size  : [102]
Member Of   : [1]
(21) ftp

Notice the Expired attribute. Here are the operations that can be performed with synouser.

~ synouser --help
Copyright (c) 2003-2022 Synology Inc. All rights reserved.

Usage: synouser
	--help
	--rebuild {all|(domain Force{0|1})|(ldap Force{0|1})}
	--enum {local|domain|ldap|all|domain_used}
	--enumpre {local|domain|all|domain_used} prefix Caseless{0|1}
	--enumsub {local|domain|all|domain_used} substr Caseless{0|1}
	--enum_admin {local|domain|ldap|all}
	--get username
	--getuid UID
	--add [username pwd "full name" expired{0|1} mail privilege]
	--modify username "full name" expired{0|1} mail
	--rename old_username new_username
	--setpw username newpasswd
	--del username1 username2 ...
	--login username pwd
	--dbopen2 username
	--filesetpw
	--create_homes {domain|ldap}

Looking at the documentation of the command, we need to modify the user.

~ synouser  --modify anonymous "" 1 ""

~ synouser --get anonymous
User Name   : [anonymous]
User Type   : [AUTH_LOCAL]
User uid    : [21]
Primary gid : [21]
Fullname    : []
User Dir    : [/nonexist]
User Shell  : [/usr/bin/nologin]
Expired     : [true]
User Mail   : []
Alloc Size  : [103]
Member Of   : [1]
(21) ftp

Now we’ve expired the user and SSH logins fail:

~ ssh anonymous@nas
Your account has expired; please contact your system administrator
Connection closed by 192.168.1.1 port 22

Personally this is what I’ve done as I would never allow FTP access to my NAS, let alone anonymous FTP access.

It goes without saying that if you rely on anonymous FTP access to your NAS, that will no longer work.

The only question that remains is: will this change stick after DSM updates? That remains to be seen as I do not have any pending updates to apply.

Method 3 - Update sshd_config:

In /etc/ssh/sshd_config, uncomment the following line:

#PermitEmptyPasswords no

So it should look like this:

PermitEmptyPasswords no

Restart the SSH service. This is for DSM 7 at the time of writing. Find the appropriate command for your DSM version or reboot your NAS.

synosystemctl restart sshd.service

This should also disallow anonymous logins going forward.

I’ve also read that DSM updates overwrite the sshd_config files so you might have to repeat these steps after a DSM update.

2 Likes