[mrkoot]

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 this using the PoC against some of my own systems (the ones that have PasswordAuthentication still enabled) and it works for those.

[mrkoot]

...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-...

[2] https://www.shodan.io/search?query=SSH-2.0-dropbear

[3] https://www.shodan.io/search?query=SSH-2.0-OpenSSH

[mrkoot]

Vendor 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/002...