
OpenSSH user enumeration - hamstah
http://www.openwall.com/lists/oss-security/2018/08/15/5
======
sebcat
PoC in subsequent email: [http://seclists.org/oss-
sec/2018/q3/125](http://seclists.org/oss-sec/2018/q3/125)

------
gabrielblack
[https://github.com/gbonacini/opensshenum](https://github.com/gbonacini/opensshenum)

------
jarfil
Usernames are not a secret, passwords are a secret.

~~~
mirimir
Does anyone still use password authentication on servers that actually matter?
I mean, I'm just a hobbyist, and I switched to keys several years ago.
Basically, I just use root and user, because anything else unnecessarily adds
information.

~~~
jakobdabo
Can somebody please explain to me why exactly using good passwords and
allowing root login is bad security? Every SSH security tutorial mentions
those but they never mention the reasons.

If somebody hacked into my password manager and managed to steal the root
user's password then they could do the same with my private key. Where is the
difference?

Also, if somebody hacked into a non-root administrative account, they can just
use sudo to elevate. What makes disabling root login more secure?

~~~
Borealid
1\. A "good" key safe for the forseeable future would have around 256
effective security bits. To get a key that strong, your password would have to
be (speaking VERY generously here) 40 characters long and truly random.

2\. When using _real_ password authentication, connecting to a compromised
server results in a disclosure of your password. When using challenge-response
authentication, it does not. Note that correctly-configured OpenSSH uses
challenge-response even for password-based methods. Incorrectly configured SSH
will send passwords over the wire.

~~~
jwilk
> Incorrectly configured SSH will send passwords over the wire.

What do you mean?

~~~
pests
Real password based vs challenge response.

With real password when you type your password into the ssh password prompt it
then sends that password to the server.

Challenge response is a method in which you usually encrypt or hash random
server provided data. You send the hash. The server knows your password and
can hash the data with it too. The hashes are compared not the password. In
this method the password never leaves your machine. Replay attacks are
prevented due to the server sending different data for you to hash on
different login attempts.

~~~
e12e
Note also that requiring a password for sudo might have some issues, as the
password is sent over the ssh connection as you type. I'm not sure what the
state of the art is wrt counting and guessing characters - or if mossh makes
the problem worse - or helps. For the general idea, see:

[http://www.securiteam.com/securitynews/5KP0O0A3PU.html](http://www.securiteam.com/securitynews/5KP0O0A3PU.html)

Does anyone know of recent work on passively attacking interactive ssh in
order to guess what's being typed? I could see machine learning helping here,
given the ability to observe enough sessions to form a training set...

~~~
e12e
Of course, with Pam for sudo authentication you could use otp, u2f with or in
place of a password.

------
elyrly
low security impact, best practice as others has mentioned

~~~
throwawaymath
This is typical of Qualys security advisories. They frequently find unintended
software behavior which can be arguably called vulnerabilities but which can’t
directly compromise software. It’s good they find these kinds of things, but I
wish more people focused on the basic fact that their security advisories
frequently only impact servers which aren’t adhering to best practices. It’s
not good that OpenSSH allows user enumeration, but you’ve committed a critical
error in system administration if that minor bug gives an attacker any
leverage at all.

If you strictly use public key authentication and don’t expose your SSH server
to the public internet, this is a non-issue. Furthermore there’s no defensible
reason not to do that - it’s very straightforward to firewall SSH access
behind a private network, and VPNs exist precisely for this reason. Access to
the network and access to machines _within_ the network should be strictly
decomposed. If you allow SSH access from the public internet _and_ have a VPN,
you have to worry about two (privileged) points of failure, not one. Put
everything behind a public-key authenticated VPN and SSH vulnerabilities are
obviated, with the exception of insider threats in the organization.

------
cyphunk
Stop letting attackers route to you. Put your ssh server behind an onion. Do
the same if you have POP/IMAP and other servers that have no reason for being
accessible through transparent routing.

------
tptacek
If you're a startup and this matters to you, you're doing it very wrong.

~~~
ronnier
Sorry, can you explain what you mean by this? I didn’t follow.

~~~
oxymoron
I think he’s saying:

a) Why are you using bleeding edge software in production, and especially so
unreleased versions of OpenSSH?

b) Why are your SSH servers exposed to public traffic?

c) User enumeration is useful for finding accounts with weak passwords. Why do
you have personal accounts on prod servers? Why do you have _any_ accounts not
using public key authentication at all?

~~~
exikyut
FWIW, regarding a),

> _We believe that this issue warrants a CVE; it affects all operating
> systems, all OpenSSH versions (we went back as far as OpenSSH 2.3.0,
> released in November 2000), and is easier to exploit than previous OpenSSH
> username enumerations..._

As for b) and c), I 100% agree.

In fact: if you're using KVM-based virtualization, and you have VNC or serial
access to your node (GCP gives you serial access, via web UI or an SSH-based
proxy), you could completely _disable_ standard network-based login. (Writing
an admin tool that connects to the serial console, gets a usable shell, and
enables your sshd for when you need it, is an exercise for the inspired
sysadmin. :P)

But this fun little trick is going to break a lot of stuff.

~~~
e12e
Just remember (at least for non ephemeral systems): always have two ways in.
That way if one path is down (fiber cable cut, serial disconnected, cloud
admin panel down for maintenance, ssh authorized_keys file has wrong
permissions, ssh/ssl cert(s) expired... ) - you can still get in via the other
path.

~~~
exikyut
A very good idea.

Perhaps a valuable resource would have a disposable proxy in front of it; then
one way in (or even no ways in!) might be viable.

