Weak GSSAPIKexAlgorithms ciphers detected

[negregg]

Hello,

We are getting dinged by security for weak GSSAPIKexAlgorithms by Nessus. Our hosts are running gsi-openssh-server.x86_64 version 7.4p1-7.el7 on CentOS7.

The same host running openssh does not show these weak gss algorithms. The following nmap output shows the comparison.

openssh output:

# nmap --script ssh2-enum-algos -sV -p 1122 localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2022-06-23 14:04 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000033s latency).
Other addresses for localhost (not scanned): 127.0.0.1
PORT     STATE SERVICE VERSION
1122/tcp open  ssh     OpenSSH 7.4 (protocol 2.0)
| ssh2-enum-algos:
|   kex_algorithms (9)
|       curve25519-sha256
|       curve25519-sha256@libssh.org
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
|       diffie-hellman-group16-sha512
|       diffie-hellman-group18-sha512
|       diffie-hellman-group14-sha256

gsissh output:

# nmap --script ssh2-enum-algos -sV -p 22 localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2022-06-23 14:05 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000034s latency).
Other addresses for localhost (not scanned): 127.0.0.1
PORT   STATE SERVICE VERSION
22/tcp open  ssh     (protocol 2.0)
| ssh2-enum-algos:
|   kex_algorithms (15)
|       gss-gex-sha1-vz8J1E9PzLr8b1K+0remTg==
|       gss-group1-sha1-vz8J1E9PzLr8b1K+0remTg==
|       gss-group14-sha1-vz8J1E9PzLr8b1K+0remTg==
|       gss-gex-sha1-dZuIebMjgUqaxvbF7hDbAw==
|       gss-group1-sha1-dZuIebMjgUqaxvbF7hDbAw==
|       gss-group14-sha1-dZuIebMjgUqaxvbF7hDbAw==
|       curve25519-sha256
|       curve25519-sha256@libssh.org
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
|       diffie-hellman-group16-sha512
|       diffie-hellman-group18-sha512
|       diffie-hellman-group14-sha256

The configs between the two are essentially the same. Any suggestions on how to mitigate this "issue". We need to have all the gss-*-sha1 exchanges disabled.

Thanks in advance!

[fscheiner]

@negregg: Assuming you are using GSI-OpenSSH due to GSI, if you want to continue using GSI for authentication for this exact version of GSI-OpenSSH you're out of luck. This because newer GSS KEX algorithms based on SHA256 (and also SHA512) were only included since (GSI-)OpenSSH 8.0p1 (see https://github.com/openssh-gsskex/openssh-gsskex/commit/8571f49c7d6675a7a7731cf9347fd1aa4a405242). So to get rid of this "issue", you'd have to deactivate all available GSS KEX algorithms there, effectly disabling GSI authentication (which is based on GSS).

As an alternative you can manually compile the GSI-OpenSSH 8.7p1 w/HPN 15.2 from Fedora 35 we include in the GCT sources. This version is patched to still be able to be built on CentOS 7 and supports the newer SHA256 based GSS KEX algorithms. After compilation and installation you can limit the accepted GSS KEX algorithms to SHA256 based ones with the configuration variable GSSAPIKexAlgorithms="[...]" (see sshd_config(5) for details).

Mini Howto

1. Start by downloading and extracting https://repo.gridcf.org/gct6/sources/gct-6.2.1653033972.tar.gz (latest (i.e. GCT v6.2.20220524) source installer tarball)
2. Install build dependencies:

   $ sudo yum -y -d1 install \
   gcc gcc-c++ make autoconf automake libtool \
   libtool-ltdl-devel openssl openssl-devel git \
   'perl(Test)' 'perl(Test::More)' 'perl(File::Spec)' \
   'perl(URI)' file sudo bison patch curl \
   pam pam-devel libedit libedit-devel

3. Inside the GCT sources directory issue ./configure --prefix=/opt/ --disable-gram5 --disable-gridftp
4. If that went through w/o problems, issue make -j and afterwards finally install with sudo make -j install.

[negregg]

@fscheiner Thanks for the excellent details!

One quick follow up, how come with OpenSSH_7.4p1 (none GSI Version) we are not seeing this detected with nmap even though we have GSI auth enabled?

# sshd -T|grep -i gss
gssapiauthentication yes
gssapicleanupcredentials no
gssapikeyexchange yes
gssapistrictacceptorcheck yes
gssapistorecredentialsonrekey no
gssapikexalgorithms gss-gex-sha1-,gss-group1-sha1-,gss-group14-sha1-
gssapienablek5users no

# gsisshd -T|grep -i gss
gssapiauthentication yes
gssapicleanupcredentials yes
gssapikeyexchange yes
gssapistrictacceptorcheck yes
gssapistorecredentialsonrekey no
gssapikexalgorithms gss-gex-sha1-,gss-group1-sha1-,gss-group14-sha1-
gssapienablek5users no

[fscheiner]

@negregg: Well, that's a good question. I don't know how nmap figures that out or if OpenSSH and GSI-OpenSSH advertise the available KEX algorithms differently. Assuming that the "normal" OpenSSH from CentOS has support for Kerberos (through GSS), I'd expect it to use the same GSS KEX algorithms than the GSI version.

[negregg]

Thanks @fscheiner. I am just going to report back that these KEX algorithms are required for GSI-OpenSSH to operate. Thanks for all your research.

[fscheiner]

@negregg Sure, you're welcome.