On Fri, Jun 17, 2005 at 09:59:45AM -0700, Greg Webster wrote: > On Fri, 2005-06-17 at 12:51 -0400, Justin Pryzby wrote: > > On Fri, Jun 17, 2005 at 09:14:04AM -0700, Greg Webster wrote: > > > Package: ssh > > > Version: 1:3.8.1p1-8.sarge.4 > > > Severity: critical > > > File: /usr/sbin/sshd > > > Tags: security > > > Justification: root security hole > > > > > > Due to the delay that is caused by password checking, once ssh > > > determines that the login attempt is for a valid account, attackers can > > > statistically prove the existence of accounts on a ssh-accessible server > > > remotely. This cuts down greatly on the difficulty of a brute-force > > > password-guessing attack. Since user accounts often use worse patterns > > > than (hopefully) root does, it doesn't take much to pick user accounts > > > that are other than standard accounts and attempt to break in. > > You're talking about microsecond delays, right? > > Nope...human-discernable delays. Give it a shot on your system. I can > easily determine just by mentally counting, if an account is valid. I tested it before I sent the email. ssh [EMAIL PROTECTED] (a normal account, but one without RSA access from my usual account); there is about a .1 second delay before I see the Password: prompt, and about a 2 second delay between password prompts when I feed the incorrect password. ssh [EMAIL PROTECTED] (an invalid account); also about a .1 second delay before I see the Password: prompt, and another 2 second delay between prompts when I feed a password (to the invalid account).
> > > I'd strongly suggest either a randomized delay on responses for login > > > attempts on non-existent accounts, or a consistent delay between > > > existing and non-existent accounts, or some other method of hiding this > > > information. > > Didn't this get implemented? I recall hearing about this some time > > ago (~18 months?), probably on one of the Debian lists. > > Don't think so. I've noted this behaviour on 8 internet-facing servers > now, with fully updated ssh packages (the system I sent this from was my > own workstation, which does have the problem, but is behind a few levels > of firewall...I should probably have sent it from one of the affected > machines). > > > > This attack is already in the wild, as shown in logs: > > This doesn't seem to indicate any particular attack. I don't know if > > there's any evidence that its doing anything other than sshing to > > $user:[EMAIL PROTECTED] (Though there is no evidence to support my > > claim, either. It would be interesting to force the use of password > > authentication, rather than challenge-response, to see what password > > is being used. Takers?). > > Definitely would be a good test...I'd like to see someone validate what > I've been seeing. I see lots of the same logfile entries; but I have doubts that it is looking for a valid account, and not just looking for an *opened* account. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
