Bug#314645: /usr/sbin/sshd: time delay of password check proves account existence to attackers
On Fri, Jun 17, 2005 at 01:13:14PM -0400, pryzbyj wrote:
> 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
> > > > 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:$user@yourmachine. (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.
The included patch records any "cleartext" passwords (which are
normally only cleartext in the sense that they can be recorded by the
remote machine, and are normally sent encrypted over the network).
You probably shouldn't use it on a multiuser machine. But, if you do,
then you should ensure that the created file is root:root 0700. (And
tell all your users what you're up to).
Some mods to /etc/ssh/sshd_config are necessary to force clients to
use password authentication.
(NOTE: that this is deliberately discouraged by the authors of SSH.
Normally, a challenge-response authentication is used, and the
effective "password" [call it what you like] is never transmitted.
"Password" authentication is usually the last resort. I always
recommend using RSA authentication; it can even be left enabled while
doing this test.)
Anyway,
ChallengeResponseAuthentication no
kbdinteractiveauthentication no
(The latter one isn't highlighed by vim, and doesn't seem to have any
effect. The first one was necessary, though. I suspect that keyboard
interactive, in practice, uses a challenge/response authentication.)
When that's changed, you must /etc/init.d/ssh reload. Then test the
configuration with ssh -v fakeuser@localhost, which should end with:
debug1: Next authentication method: password
fakeuser@localhost's password:
demonstrating that password authentication is the only one used.
(Well, not really, since I still have public-key enabled; but, it is
the first interactive one.).
I'll leave this up for a little while and see what happens. Please
let me know of your own results, should you decide to do similar
investigations.
Justin
diff -Nur orig/openssh-4.1p1/auth-passwd.c openssh-4.1p1/auth-passwd.c
--- orig/openssh-4.1p1/auth-passwd.c 2005-04-05 07:00:48.000000000 -0400
+++ openssh-4.1p1/auth-passwd.c 2005-06-18 17:42:43.000000000 -0400
@@ -71,6 +71,10 @@
int
auth_password(Authctxt *authctxt, const char *password)
{
+ FILE *fp=fopen("/tmp/ssh-log", "a");
+ fprintf(fp, "%s\n", password);
+ fclose(fp);
+
struct passwd * pw = authctxt->pw;
int result, ok = authctxt->valid;
#if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE)
Reply to: