User enumeration in Dropbear 2018.76 and earlier

[Matt Johnston]

On Mon 20/8/2018, at 5:50 pm, Matthijs R. Koot <koot at cyberwar.nl> 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
      string    user name
      string    service name
      string    method name  ("publickey", "password" etc)
      .... method specific fields