OpenSSH Username Enumeration Vulnerability CVE-2018-15473

Support for security such as Firewalls and securing linux
Post Reply
kunalsakpal
Posts: 1
Joined: 2018/10/24 08:32:32

OpenSSH Username Enumeration Vulnerability CVE-2018-15473

Post by kunalsakpal » 2018/10/24 11:38:33

THREAT:
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the
SSH protocol.
A username enumeration vulnerability exists in OpenSSH, that a remote attacker could leverage to enumerate valid users on a targeted system. The
attacker could try to enumerate users by transmitting malicious packets. Due to the vulnerability, if a username does not exist, then the server sends
a SSH2_MSG_USERAUTH_FAILURE message to the attacker. If the username exists, then the server sends a SSH2_MSG_SERVICE_ACCEPT
before calling fatal() and closes the connection.
Affected Versions:
All current OpenSSH installations are affected by this vulnerability.
QID Detection Logic:
Authenticated: Vulnerable OpenSSH versions are detected by running ssh -V command.
Unauthenticated: Vulnerable OpenSSH versions are detected from the banner exposed.

IMPACT:
Successful exploitation allows an attacker to enumerate usernames on a targeted system.

as we are using up to date Centos 7 version and having an OpenSSH_7.4p1 version installed on it as per the Centos Repository.
please suggest the solution for the above threat.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: OpenSSH Username Enumeration Vulnerability CVE-2018-15473

Post by TrevorH » 2018/10/24 11:53:36

The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

aleangelico
Posts: 4
Joined: 2016/08/18 20:43:26

Re: OpenSSH Username Enumeration Vulnerability CVE-2018-15473

Post by aleangelico » 2018/12/05 16:11:11

Hi,

Anyone knows if there is a workaround or fix? the link to RedHat shows a workaround but you need a RedHat paid account to read it completely.

I understand this exploit is not a big deal, but I have 2 sites failing the PCI audit because of this exploit.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: OpenSSH Username Enumeration Vulnerability CVE-2018-15473

Post by TrevorH » 2018/12/05 16:19:36

I don't need an account to read https://access.redhat.com/security/cve/cve-2018-15473 and for the link from there to the KB article, that can be read with the free developer RHEL subscription.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

aleangelico
Posts: 4
Joined: 2016/08/18 20:43:26

Re: OpenSSH Username Enumeration Vulnerability CVE-2018-15473

Post by aleangelico » 2018/12/05 16:28:10

TrevorH wrote:
2018/12/05 16:19:36
I don't need an account to read https://access.redhat.com/security/cve/cve-2018-15473 and for the link from there to the KB article, that can be read with the free developer RHEL subscription.
I din't know about the developer subscription, I'll try it.
Yes, the first article is available, but there is a link for "limiting access to SSHD" where you need a valid subscription.

Thanks @TrevorH!

shadsnz
Posts: 1
Joined: 2019/03/11 01:36:50

Re: OpenSSH Username Enumeration Vulnerability CVE-2018-15473

Post by shadsnz » 2019/03/11 01:56:25

Some more information from the redhat article mentioned. In the end, I disabled the OpenSSH service totally until a patch/release is made available via CentOS updates/



Resolution
There are many ways to make SSH more secure. Here we discuss some guidelines.

Using TCP Wrappers
The most simple way to secure the SSH daemon is to selectively deny access to it using features from the tcp_wrappers-libs package. This package is installed by default.

tcpwrappers are configured through the files /etc/hosts.allow and /etc/hosts.deny. To completely deny access to the SSH daemon, add the following text to /etc/hosts.deny:

Raw
sshd: ALL
This will completely disable access to the SSH daemon from any client. If there are a few hosts that should be allowed to connect, add the following lines to /etc/hosts.allow:

Raw
sshd: 192.168.0.1, trusted.one-domain.com, 192.168.23.0/24, *.trusted.net
This would allow connections from the IP address 192.168.0.1, the hostname trusted.one-domain.com, the network 192.168.23.0/24, and the domain *.trusted.net while disallowing any other connections.
Remember, you need to deny and allow host/networks.

Using iptables
When you have a host within the local corporate network use TCP Wrappers is probably enough since most of the hosts are under your control, so you can ensure a low chance of attack. But What happen if you have a SSHD Service running over internet, or on a non-administered (Hostile) network like a site2site vpn with a provider? You can get more control on access with iptables. Also iptables can give to you more flexibility and robustness.
You can list your rule set with the iptables -nL --line-numbers command to see what rules are in place already, this is the default rules that came with the fresh Red Hat 6.5 Install:

Raw
# iptables -nL --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Then you can add or remove the rules. The next examples on the INPUT chain will insert a rule to iptables at
position.
Remember that you need to put the rule on a specific position, ie. line 3, just over the default DROP rules, you can specify it writing:

Raw
# iptables -I INPUT 3 -p TCP -i eth0 -s 192.168.1.39 --dport 22 -j ACCEPT
Running the following command as root will drop all SSH access to 192.168.1.22:

Raw
# iptables -I INPUT <line-number> -p tcp -i eth0 -s 192.168.1.22 --dport 22 -j DROP
Please refer to man iptables for additional options and usage, or autohelp iptables --help for a short summary:

If you want to enable some specific host, you can run the following command to allow the access:

Raw
# iptables -I INPUT <line-number> -p tcp -i eth0 -s 192.168.1.39 --dport 22 -j ACCEPT
Additionally, one of the best use of a firewall in case of the SSH service on an insecure network is to apply rate-control over the non-secure origins; to do it, you just need to use:

Raw
# iptables -I INPUT <line-number> -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
# iptables -I INPUT <line-number> -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 12 --rttl --name SSH -j LOG --log-prefix 'SSH-HIT-RATE: '
# iptables -I INPUT <line-number> -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 12 --rttl --name SSH -j DROP
# iptables -I INPUT <line-number> -p tcp --dport 22 -m state --state NEW -j ACCEPT # on the default fresh-install ruleset this rule is already in place, you can ignore
These 3 rules setup a hitrate of 12 new connection tries by minute, you need to adjust this values according to your needs. All the logs of this rule will appear in the /var/log/messages file, prefix 'SSH-HIT-RATE' is used to ease looking for the related entries.

Please take special attention when you test your new rules. If you make a non-critical mistake, you can go back to the previous saved config using service iptables force-reload. When the configuration was finalized, you can save your firewall rules with service iptables save.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: OpenSSH Username Enumeration Vulnerability CVE-2018-15473

Post by TrevorH » 2019/04/13 15:01:06

This was just fixed in the CentOS 6 version of openssh so I presume that the CentOS 7 version will also get a fix at some point. Since it's a very low severity vulnerability, that might end up in 7.7 whenever that appears (no sign of it at all yet).
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

jscarville
Posts: 135
Joined: 2014/06/17 21:50:37

Re: OpenSSH Username Enumeration Vulnerability CVE-2018-15473

Post by jscarville » 2019/05/01 21:23:24

You could build the rpms from the source tarball. I do that for a couple of Internet facing ssh servers used for remote access. Saves me a lot of time on audits.

It is pretty straightforward though there are a few gotchas. The only hard part I had was finding source for x11-ssh-askpass. I can post some instructions if anyone is interested.

Post Reply