full-disclosure - Re: OpenSSH User Enumeration Time-Based Attack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51DF847F.9090104@ocip.de>
Date: Fri, 12 Jul 2013 06:22:23 +0200
From: Florian Reinholz <reinholz@...p.de>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: OpenSSH User Enumeration Time-Based Attack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11.07.2013 17:41, Jann Horn wrote:
> On Wed, Jul 10, 2013 at 03:38:59PM +0200, Curesec Research Team
> wrote:
>> By testing several OpenSSH installations we figured there is a
>> delay of time when it comes to cracking users (not) existing on a
>> system. A normal Brute-force-Attack tests for the correct user
>> and password combination, usually without knowledge if the user
>> on the system exists.
> 
> FYI, the openssh guys have known this for quite a while and they
> don't treat it as an issue worth fixing. They don't want to
> introduce extra anti-timing code just to prevent user enumeration
> from working.
> 
> You can also see a measurable difference when you try logging in
> with random public RSA keys – around 100% difference over
> localhost, over the internet it's much lower, but with a few
> attempts, you can still get good data. Well, for systems that have
> password auth enabled, your approach seems a lot more reliable.
> 
> By the way: If you can hog the CPU for seconds by sending a few
> kilobytes of data, isn't that a DoS issue?
> 
> 
> 
> _______________________________________________ Full-Disclosure -
> We believe in it. Charter:
> http://lists.grok.org.uk/full-disclosure-charter.html Hosted and
> sponsored by Secunia - http://secunia.com/
> 

Agree. Tested the approach against various systems, virtual and real,
using different endpoints, and it does not reveal anything useful.

I dont think that "int(time.time()) [...] if timeRes > 20:" is very
efficient or even an accurate way for user estimation.
It never took more than 3s to refuse the login attempt, regardless the
users exists or not. Even "DenyUsers" did not change anything.

Anyways, using a more accurate timing it might be possible to reveal
something useful...

- -Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13-SpecialBuild (MingW32)
Comment: Protect messages and files using GnuPG and OpenSSL!
Comment: The GnuPG-Pack: http://home.arcor.de/rose-indorf
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iD8DBQFR34R/yzosym+CqfMRAlR9AKC1NHl74knXpufksEiBdaPyRYbaRgCgjPw3
jtFrF6BbS0MoR0JoXPfqKOw=
=VK4t
-----END PGP SIGNATURE-----


Download attachment "smime.p7s" of type "application/pkcs7-signature" (4297 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/