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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Apr 2006 12:47:43 +0100
From: <c0redump@...ers.org.uk>
To: <bugtraq@...urityfocus.com>, "Brett Glass" <brett@...iat.org>
Subject: Re: Strengthen OpenSSH security?


Hi.

Previous versions of OpenSSH were vulnerable to timing attacks.  I'm not 
aware of what version you're running but I'd put my money on that.  I too 
watch the kiddies attempting brute force attempts on our SSHD, however, up 
until now, these have been pretty dumb tools based on a word list as far as 
I can see.

http://www.security.nnov.ru/docs4475.html may be of some interest to you, 
also, google "OpenSSH timing attacks".

- c0redump

----- Original Message ----- 
From: Brett Glass
To: bugtraq@...urityfocus.com
Sent: Tuesday, April 18, 2006 5:31 AM
Subject: Strengthen OpenSSH security?


I'm sure that most folks with hosts that expose an OpenSSH daemon
to the Internet have been getting the usual probes and password
guessing attempts and have been taking appropriate actions (e.g.
setting AllowUsers and using strong passwords) to protect
yourselves. But today, on one of my servers, I noticed a new trend:
the attackers are getting smarter. Apparently, they can tell the
difference between a user ID which is not named in an AllowUsers
directive -- or which does not exist at all -- from one for which
they just haven't guessed the correct password. I've now watched as
some attackers (but not all... yet) tried various user IDs, noted
which ones existed and were in AllowUsers, and focused password
guessing attacks on just those user IDs.

It seems to me that sshd should not tip its hand by returning
different responses when a user ID can be used for logins than when
it can't -- allowing an attacker to focus password guessing attacks
on user IDs with which it would have a chance of gaining access.
For those folks out there who are more familiar with OpenSSH than I
am: How hard would it be to make the responses indistinguishable?

--Brett Glass 




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ