Re: OpenSSH User Enumeration Time-Based Attack

[Grandma Eubanks <tborland1 () gmail com>]

So, I've been toying with this on many systems. Every lan system would do
the same thing you describe. Unfortunately, I haven't been able to test lan
sucessfully yet.
Then I had several remote systems that would take 2 minutes to respond to a
valid user (root and another valid user as given by some people to help me
test) while non-valid took about 5-8 seconds. But this did not work on all
remote OpenSSH systems....

MUCH better analysis for successful conditions is needed. However, as I do
not really have massive need for this yet, I have not done that nor willing
to give enough time to do it just yet.

So I've just uploaded and give this script out to anyone wanting to test
this themselves and see who's interested in finding out exact
conditions/versions. It is also in Python and Paramiko.
It's a good idea to use defaults of linear checking before playing with the
multiproc system. If you are doing testing uncomment this line:
#print("Time until response: %s" % str(timeRes))

***If you do not like 'colorful' language or that I call out the lack of
research by the posters, please do not pursue getting this script***

http://code.google.com/p/multiproc-openssh-username-bruteforce/source/browse/ssh_user_enum.py

I will review and accept change requests and know there are certain issues
(like static chunksize). I just didn't want to take longer than an hour on
something I'll hardly be using.
All test results (with appropriate ssh versions) are warmly welcomed as
well so exact conditions can be tracked down.


On Thu, Jul 11, 2013 at 11:22 PM, Florian Reinholz <reinholz () ocip de> wrote:

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