Re: User enumeration in Dropbear 2018.76 and earlier
On Mon 20/8/2018, at 11:55 pm, Matt Johnston wrote: > > I can confirm Dropbear has the same problem, probably all versions. I should > have a patch in the next couple of days. > > This allows someone to remotely know whether a particular username exists or > not on a server. In some circumstances that could be a problem, though by > itself it doesn't allow exploitation of a server. This should be fixed by https://secure.ucc.asn.au/hg/dropbear/rev/5d2d1021ca00 , a CVE number is CVE-2018-15599 Cheers, Matt
Re: User enumeration in Dropbear 2018.76 and earlier
On Mon 20/8/2018, at 5:50 pm, Matthijs R. Koot wrote:
>
> The user enumeration issue in OpenSSH [0] also exists in Dropbear 2018.76
> and earlier; at least going back to w/v2013.58 (didn't test with earlier
> versions yet). It is specifically related to this code in svr-auth.c [1]:
> [0] http://seclists.org/oss-sec/2018/q3/124
> [1] https://github.com/mkj/dropbear/blob/master/svr-auth.c#L175-L188
Hi Matthijs,
I can confirm Dropbear has the same problem, probably all versions. I should
have a patch in the next couple of days.
This allows someone to remotely know whether a particular username exists or
not on a server. In some circumstances that could be a problem, though by
itself it doesn't allow exploitation of a server.
Some background, OpenSSH and Dropbear don't share authentication code but they
both took a similar approach to handling authentication request packets. The
SSH_MSG_USERAUTH message structure varies depending on the "method" field [ZZ],
so the subsequent fields only get read after the username has been handled -
that needs to be handled carefully. I might have looked at the OpenSSH auth
code when first implementing Dropbear's, though it doesn't really look familar
now.
Cheers,
Matt
[ZZ] https://tools.ietf.org/html/rfc4252#section-7
eg
byte SSH_MSG_USERAUTH_REQUEST
stringuser name
stringservice name
stringmethod name ("publickey", "password" etc)
method specific fields
User enumeration in Dropbear 2018.76 and earlier
Hi all,
The user enumeration issue in OpenSSH [0] also exists in Dropbear 2018.76
and earlier; at least going back to w/v2013.58 (didn't test with earlier
versions yet). It is specifically related to this code in svr-auth.c [1]:
- 8< - 8< - 8< - 8< -
#if DROPBEAR_SVR_PUBKEY_AUTH
/* user wants to try pubkey auth */
if (methodlen == AUTH_METHOD_PUBKEY_LEN &&
strncmp(methodname, AUTH_METHOD_PUBKEY,
AUTH_METHOD_PUBKEY_LEN) == 0) {
if (valid_user) {
svr_auth_pubkey();
} else {
/* pubkey has no failure delay */
send_msg_userauth_failure(0, 0);
}
goto out;
}
#endif
- 8< - 8< - 8< - 8< -
The PoC released for OpenSSH [2] also works against Dropbear - which seems
remarkable because both have an entirely different code base and the issue
is not due to SSH specs.
Because the issue can be abused to test both for SSH and non-SSH users, it
can be abused to enumerate installed services/software by testing for
default/known service users.
To test an SSH service on 127.0.0.1:22022 for user 'admin', the PoC can be
executed as follows:
$ python ssh-check-username.py --port 22022 127.0.0.1 admin
Credits to /u/dbzjegrw8o6n0 for posting an initial observation at
/r/blackhat [3], which triggered a colleague and me to look into it.
Friendly regards,
Matthijs Koot (Secura BV, the Netherlands)
[0] http://seclists.org/oss-sec/2018/q3/124
[1] https://github.com/mkj/dropbear/blob/master/svr-auth.c#L175-L188
[2] https://bugfuzz.com/stuff/ssh-check-username.py
[3]
https://www.reddit.com/r/blackhat/comments/97ywnm/openssh_username_enumeration/e4e05n2/
