10 ms·
OpenSSH user enumeration
- jarfil 8y agoUsernames are not a secret, passwords are a secret.
- asveikau 8y agoI 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.
- mrkoot 8y agoExactly - 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 this using the PoC against some of my own systems (the ones that have PasswordAuthentication still enabled) and it works for those.
- mrkoot 8y ago...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_username_enumeration/e4e05n2/ https://www.reddit.com/r/blackhat/comments/97ywnm/openssh_us... [1] https://github.com/mkj/dropbear/blob/master/svr-auth.c#L175-L188 https://github.com/mkj/dropbear/blob/master/svr-auth.c#L175-... [2] https://www.shodan.io/search?query=SSH-2.0-dropbear https://www.shodan.io/search?query=SSH-2.0-dropbear [3] https://www.shodan.io/search?query=SSH-2.0-OpenSSH https://www.shodan.io/search?query=SSH-2.0-OpenSSH
- mrkoot 8y agoVendor confirmed the issue, noting that it exists in "probably all versions" of Dropbear (i.e., v2018.76 and earlier) and that a patch will follow in the next couple of days: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2018q3/002109.html http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2018q3/002...
- mackal 8y agoThey are useful though. If you check a bunch of usernames from a person leak and find matches, you got a password to try.
- thaumaturgy 8y agoA correct sshd_config includes: PasswordAuthentication no
- mrkoot 8y ago+1. But just to be sure: that does not prevent testing for usernames and hence enumerating software by testing for known/common service account usernames (e.g. "_tor" on OpenBSD and "debian-tor" on Debian-based OSs). (No claim was made to the contrary; just mentioning this to prevent anyone from thinking otherwise.)
- jwilk 8y agoTo disable logging in with password you also need: ChallengeResponseAuthentication no
- flas9sd 8y agofor a longer explanation see https://blog.tankywoo.com/linux/2013/09/14/ssh-passwordauthentication-vs-challengeresponseauthentication.html https://blog.tankywoo.com/linux/2013/09/14/ssh-passwordauthe... Though, if you're using TOTP via a PAM module, you'll want it
- mwpmaybe 8y agoI got a chill up my spine when I read this but fortunately it looks like this is the default on Ubuntu 16.04 and 18.04 (at least).
- jwilk 8y agoApparently Debian disabled it in 2005: openssh (1:4.1p1-1) experimental; urgency=low […] * Disable ChallengeResponseAuthentication in new installations, returning to PasswordAuthentication by default, since it now supports PAM and apparently works better with a non-threaded sshd (closes: #247521). […] -- Colin Watson <cjwatson@debian.org> Tue, 31 May 2005 01:33:33 +0100 https://bugs.debian.org/247521 https://bugs.debian.org/247521
- ddtaylor 8y agoAre you willing to send me a list of all your usernames on all your systems?
- mirimir 8y agoSure. It's root and user, on everything :)
- ddtaylor 8y agoDoes that mean that `wc -l /etc/passwd` is just two?
- daurnimator 8y agoNo. There will be plenty of system user. But they do not have SSH access permitted.
- tjoff 8y agoIt doesn't matter if ssh access is permitted.
- mirimir 8y agoSo how is an attacker going to access the machine?
- tjoff 8y agoIf 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.
- mirimir 8y agoNothing crucial should be directly accessible from the Internet.
- mirimir 8y agoDoes 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.
- mrkoot 8y agoYes. Large corporate networks often still have (some) production systems that allow password-based authentication. I don't know how widespread it still is, but I still encounter it frequently at clients (which may be a skewed sample). Just to be sure: PasswordAuthentication does not need to be enabled for the PoC to work, and username testing can also be used for software enumeration by testing for common/default non-SSH users, .g. "_tor", "debian-tor", etc. (I apologize for repeating here what I also stated in other comments in this thread, but this aspect should not be overlooked.)
- jakobdabo 8y agoCan 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 8y ago1. 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.
- est 8y agoyeah but what if some user names are known to have a weak secret?
- deleted 8y ago[deleted]
- xorcist 8y agoIncidents happens when several things which are innocent on their own suddenly interact in unforeseen ways.
- e12e 8y agoAs 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.
- acdha 8y agoHow 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.
- e12e 8y agoMaybe knowing software a is likely running and managed by user b helps constructing a targeted attack.
- acdha 8y agoPerhaps 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.
- e12e 8y agoFwiw 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).
- IshKebab 8y agoAbsolute nonsense. Usernames can be sensitive information in many situations.
- sebcat 8y agoPoC in subsequent email: http://seclists.org/oss-sec/2018/q3/125 http://seclists.org/oss-sec/2018/q3/125
- tptacek 8y agoIf you're a startup and this matters to you, you're doing it very wrong.
- ronnier 8y agoSorry, can you explain what you mean by this? I didn’t follow.
- oxymoron 8y agoI 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 8y agoFWIW, 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.
- elyrly 8y agolow security impact, best practice as others has mentioned
- throwawaymath 8y agoThis 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 8y agoStop 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.
- gabrielblack 8y agohttps://github.com/gbonacini/opensshenum https://github.com/gbonacini/opensshenum