Usernames are not a secret, passwords are a secret.
Absolute nonsense. Usernames can be sensitive information in many situations.
OpenSSH user enumeration
71–80 of 89 posts
Re: OpenSSH user enumeration
#72Earlier quoted context omitted.
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…
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 Does anyone know of recent work on passively attacking interactive ssh in order…
Of course, with Pam for sudo authentication you could use otp, u2f with or in place of a password.
Re: OpenSSH user enumeration
#73Earlier quoted context omitted.
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…
Just to add to @borealid's comment: a password that encodes 96+bits of entropy is effectively a shared symmetric key (OK, technically a secret). Point being - it needs to be managed like a key: it's inconvenient to type, hard to remember, should be stored encrypted at rest, preferably in an hsm. Gnupg agent/ssh agent and the various key agents for desktops all do this, and generally support hsm as well. There's also…
One other nice thing about keys is that you can restrict them to a specific command. If you have users who are running well defined tasks that can be a great way to avoid handing out full accounts.
Re: OpenSSH user enumeration
#74Usernames are not a secret, passwords are a secret.
As others have noted - this allows user enumeration. Which can be very useful: Does a system appear to run one of the many horribly insecure "enterprise" backup solutions? Or some other horrible, ancient system? Does $person from orgchart appear to have a $user? (target for spear phising, compromise of laptop). Information hinting at distribution (eg: Ubuntu). Is there a jboss user? Etc.
How much of a difference does this really make? Most attacks which I’ve seen simply launched the attack immediately so if you have enterprise software using the vendor’s configuration you’re screwed anyway, and both options are quickly blocked by fail2ban after splatting off the public key-only setup of any security conscious server.
Re: OpenSSH user enumeration
#75Earlier quoted context omitted.
As others have noted - this allows user enumeration. Which can be very useful: Does a system appear to run one of the many horribly insecure "enterprise" backup solutions? Or some other horrible, ancient system? Does $person from orgchart appear to have a $user? (target for spear phising, compromise of laptop). Information hinting at distribution (eg: Ubuntu). Is there a jboss user? Etc.
How much of a difference does this really make? Most attacks which I’ve seen simply launched the attack immediately so if you have enterprise software using the vendor’s configuration you’re screwed anyway, and both options are quickly blocked by fail2ban after splatting off the public key-only setup of any security conscious server.
Maybe knowing software a is likely running and managed by user b helps constructing a targeted attack.
Re: OpenSSH user enumeration
#76Earlier quoted context omitted.
How much of a difference does this really make? Most attacks which I’ve seen simply launched the attack immediately so if you have enterprise software using the vendor’s configuration you’re screwed anyway, and both options are quickly blocked by fail2ban after splatting off the public key-only setup of any security conscious server.
Maybe knowing software a is likely running and managed by user b helps constructing a targeted attack.
Perhaps but it’s a limited change from what’s already possible. Spending time on basic best practice stuff securing those accounts will pay a lot more dividends in more scenarios than adding a minor impediment to finding them.
Re: OpenSSH user enumeration
#77Earlier quoted context omitted.
I don't know, judging by my SSH logs it seems a lot of the automated malicious login attempts are looking for common software used to deploy code. Knowing that a target machine has a username used by some popular software might be valuable information in an attack. But on the subject of passwords, best practice for SSH for a long time has been to disable password based login entirely and rely on keys.
Exactly - it also works for non-SSH accounts, thus allowing software enumeration by testing for default/common/known default service users. For instance, an OpenBSD box running Tor may have a user "_tor", a Debian-based box (e.g. Ubuntu) may have a user "debian-tor", and so on (depending on how Tor was installed, in my case via pkg_add & apt-get; usernames might vary for different OS/repo versions). I have tested thi…
...and apparently the same issue exists in Dropbear up until current version (2018.76 / Feb 2018), which has an entirely different code base. A comment on /r/blackhat [0] led a colleague and me to look at Dropbear's sources, and it happens to have logic that is sufficiently similar [1] for the same PoC to work; tests against v2018.76 and a couple of earlier versions (e.g. v2013.58) are successful.
Shodan shows some 66k services identifying as SSH-2.0-dropbear [2], as opposed to some 15k identifying as SSH-2.0-OpenSSH [3].
Issue has been reported to the vendor today.
[0] https://www.reddit.com/r/blackhat/comments/97ywnm/openssh_us...
[1] https://github.com/mkj/dropbear/blob/master/svr-auth.c#L175-...
Re: OpenSSH user enumeration
#78Re: OpenSSH user enumeration
#79Earlier quoted context omitted.
Maybe knowing software a is likely running and managed by user b helps constructing a targeted attack.
Perhaps but it’s a limited change from what’s already possible. Spending time on basic best practice stuff securing those accounts will pay a lot more dividends in more scenarios than adding a minor impediment to finding them.
Fwiw I mostly agree - reading /etc/passwd shouldn't be able to help compromise your system. But it's also an error for sshd or any daemon to allow the enumeration of your list of users. I mean when we get to read /etc/passwd via httpd we call it an exploit... (even if we don't get shadow too).
Re: OpenSSH user enumeration
#80Earlier quoted context omitted.
It doesn't matter if ssh access is permitted.
So how is an attacker going to access the machine?
If a certain account is present then the attacker might know a certain service is running and then target that.
Might also reveal the purpose of the machine (oh, this is probably the build server) or who is managing it.