Ben Greenbaum: Re: SSHD-1 Logging Vulnerability
>> [users getting out of sync and passwords getting logged] >Not always. I can think of one Windows SSH client off the top of my head >that will prompt for the username and password seperately - SecureCRT. I'm >sure there are others as well that I'm just not thinking of right now... Well, that and it's easy to just brainfart and type a password in when putty or some other silly client askes me who to log in as. Really all a moot point as long as the daemon logs using authpriv. Your system should be set up to log that stuff to a file only root can read. At that point only root can see when the user gets out of sync, and heck, if they want to they can trojan the daemon to see what they want anyway, assuming passwords are being used. If you arbitrarily syslog stuff like that to world readable files you're running a big risk. The daemon needs to do it's part by logging it to the authpriv facility so you can separate it, and after that you need to make sure you set up syslog right. -Bob cc: Subject: Ben Greenbaum: Re: SSHD-1 Logging Vulnerability >> [users getting out of sync and passwords getting logged] >Not always. I can think of one Windows SSH client off the top of my head >that will prompt for the username and password seperately - SecureCRT. I'm >sure there are others as well that I'm just not thinking of right now... Well, that and even I sometimes just brainfart and type my password in when putty or some other silly client askes me who to log in as. Really all a moot point as long as the daemon logs using authpriv and your system is set up log that stuff to a root-readable only file. At that point only root can see when the user gets out of sync, and heck, if they want to they can trojan the daemon to see what they want anyway. If you arbitrarily syslog stuff like that to world readable files you're running a big risk. The daemon needs to do it's part by logging it to the authpriv facility so you can separate it, and after that you need to make sure you set up syslog right. -Bob
Re: SSHD-1 Logging Vulnerability
On Sun, 11 Feb 2001, Markus Friedl wrote:
> On Fri, Feb 09, 2001 at 06:23:07PM +0100, Florian Weimer wrote:
> > > + log_msg("Rhosts authentication failed for '%.100s', remote '%.100s',
>host '%.200s'.",
> > > user, client_user, get_canonical_hostname());
> >
> > I don't think this patch is a good idea. If a user accidentally
> > enters his password in place of his user name, the password will show
> > up in the log. That's probably the reason while logging is available
> > only in the debug mode. It should be sufficient to log the IP address
> > of the client trying to authenticate.
>
> While I understand you concern, I am not sure whether this
> applies to SSH clients, since they are usually very
> different from telnet clients. You enter the usename when you
> start the client, so it's hard to get out of sync, e.g. I
> have never seen a user enter
> $ ssh -l mypasswd host
> This even applies to Windows SSH vs. telnet clients.
>
> -markus
>
I hate to keep this thread going, but this isn't entirely true. There's
no reason an ssh client can't prompt you for a username AND password if
the username isn't given upon program execution. In fact this is the case
for putty (windows ssh client), if you don't enter in a username for a
host, then it prompt you for one, ala telnet. This is how I run putty
actually, it's convenient when you have multiple accounts on the same
machine. Now I'm not saying don't log the username because of this one
client, but there may be more that I'm not aware of.
--
Steve GrecniProgrammer
Build your world. http://STEEM.com
Re: SSHD-1 Logging Vulnerability
> While I understand you concern, I am not sure whether this > applies to SSH clients, since they are usually very > different from telnet clients. You enter the usename when you > start the client, so it's hard to get out of sync, e.g. I > have never seen a user enter > $ ssh -l mypasswd host > This even applies to Windows SSH vs. telnet clients. Not always. I can think of one Windows SSH client off the top of my head that will prompt for the username and password seperately - SecureCRT. I'm sure there are others as well that I'm just not thinking of right now... Ben Greenbaum Director of Site Content SecurityFocus http://www.securityfocus.com
Re: SSHD-1 Logging Vulnerability
Markus Friedl <[EMAIL PROTECTED]> writes: [Logging user names harmful or not?] > While I understand you concern, I am not sure whether this > applies to SSH clients, since they are usually very > different from telnet clients. You enter the usename when you > start the client, so it's hard to get out of sync, e.g. I > have never seen a user enter > $ ssh -l mypasswd host Yes, this is certainly correct for the traditional command line clients. > This even applies to Windows SSH vs. telnet clients. IIRC, Teraterm has a combined dialog box for entering password and user name, and I think you can confuse one with the other. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Re: SSHD-1 Logging Vulnerability
On Fri, Feb 09, 2001 at 06:23:07PM +0100, Florian Weimer wrote:
> > + log_msg("Rhosts authentication failed for '%.100s', remote '%.100s',
>host '%.200s'.",
> > user, client_user, get_canonical_hostname());
>
> I don't think this patch is a good idea. If a user accidentally
> enters his password in place of his user name, the password will show
> up in the log. That's probably the reason while logging is available
> only in the debug mode. It should be sufficient to log the IP address
> of the client trying to authenticate.
While I understand you concern, I am not sure whether this
applies to SSH clients, since they are usually very
different from telnet clients. You enter the usename when you
start the client, so it's hard to get out of sync, e.g. I
have never seen a user enter
$ ssh -l mypasswd host
This even applies to Windows SSH vs. telnet clients.
-markus
Re: SSHD-1 Logging Vulnerability
jose nazario <[EMAIL PROTECTED]> writes:
> - debug("Rhosts authentication failed for '%.100s', remote '%.100s', host
>'%.200s'.",
> + log_msg("Rhosts authentication failed for '%.100s', remote '%.100s', host
>'%.200s'.",
> user, client_user, get_canonical_hostname());
I don't think this patch is a good idea. If a user accidentally
enters his password in place of his user name, the password will show
up in the log. That's probably the reason while logging is available
only in the debug mode. It should be sufficient to log the IP address
of the client trying to authenticate.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
SSHD-1 Logging Vulnerability
Crimelabs, Inc. www.crimelabs.net
Security Note
Crimelabs Security Note CLABS200101
Title: SSH-1 Brute Force Password Vulnerability
Date: 5 February, 2001
Vendors: Any supported by SSH-1
Versions: At least ssh-1.2.27 and 1.2.30
Not Affected: OpenSSH
Severity: Medium to High
Author: Jose Nazario <[EMAIL PROTECTED]>
Website: http://www.crimelabs.net/
Vendor Status: Contacted 1 February, 2001
Vendor Reply: Fixed in CVS, more below
Introduction
There exists a very simple, but potentially damaging, vulnerability in
the SSH version 1 daemon related to the brute forcing of passwords in
accounts. By default the daemon does not log up to four unsuccessful
attempts at guessing a password or a username/password combination. This
allows for the undetected brute forcing of passwords or account/password
combinations. An exploit is included. A source code patch to ssh-1.2.30 is
also included.
This is unrelated to, but similar to, the problem noted by the
J.J.F./Hackers Team at http://www.jjf.org/advisory/SshdJJFen.txt, which
noted the failure of the ssh version 2 daemon to not log IP addresses upon
connections, leading to an untracable brute force attack.
Impact
Depending on the rules in place at the site, if root logins are allowed
(and they are by default) this could lead to a root account compromise if
given enough time or a good enough dictionary in relation to the password.
While this can readily be done for other login protocols, including
telnet, ftp, and the like, they log failed password attempts, unlike sshd.
As such, it becomes possible to hide one's intentions as an attempt is
made to brute force accounts.
It is for this reason that we mark the risk factor as "Medium to High".
Crimelabs dissuades allowing ssh root logins for many reasons, including
this one. The main argument against it is a lack of accounting on the
system, which would be facilitated by 'su' logs. Additional reasons
include bypassing the limitations placed on users by 'su' locally, and
conformance to traditional UNIX login standards for telnet and rlogin,
which disallow root logins.
The Problem Code
Examination of the code reveals this occurs because the message that would
otherwise log this message is wrapped around a debug routine:
(file sshd.c from sources 1.2.30, one example)
2673- {
2674- /* Log failures if attempted more than once. */
2675: debug("Password authentication failed for user %.100s from %.100s.",
2676- user, get_canonical_hostname());
2677- }
Patch and Workaround
The following patch should be applied to sshd.c (this is for the 1.2.30
sources), the daemon rebuilt and reinstalled.
Better yet, upgrade to OpenSSH (http://www.openssh.com/). Thanks to
everyone on the OpenSSH team for a better product.
The following patch against ssh-1.2.30 code fixes the logging issue for
password authentication, RSA authentication, RhostsRSA authentication, and
TIS authentication. Kerberos4 appears to still not be logged as a failed
password authentication, but Kerberos5 does. Not having a Kerberos
infrastructure to test this on, I am unable evaluate this portion of the
code.
$ diff -Naur ssh-1.2.30/sshd.c.orig ssh-1.2.30/sshd.c
--- ssh-1.2.30/sshd.c.orig Wed Jan 31 12:11:08 2001
+++ ssh-1.2.30/sshd.c Wed Jan 31 12:57:36 2001
@@ -2408,7 +2408,7 @@
remote_user_name = client_user;
break;
}
- debug("Rhosts authentication failed for '%.100s', remote '%.100s', host
'%.200s'.",
+ log_msg("Rhosts authentication failed for '%.100s', remote '%.100s', host
+'%.200s'.",
user, client_user, get_canonical_hostname());
xfree(client_user);
break;
@@ -2469,7 +2469,7 @@
mpz_clear(&client_host_key_n);
break;
}
- debug("RhostsRSA authentication failed for '%.100s', remote '%.100s', host
'%.200s'.",
+ log_msg("RhostsRSA authentication failed for '%.100s', remote '%.100s',
+host '%.200s'.",
user, client_user, get_canonical_hostname());
xfree(client_user);
mpz_clear(&client_host_key_e);
@@ -2500,7 +2500,7 @@
break;
}
mpz_clear(&n);
-debug("RSA authentication for %.100s failed.", user);
+log_msg("RSA authentication for %.100s failed.", user);
}
break;
@@ -2633,7 +2633,7 @@
authenticated = 1;
break;
} else {
- debug("TIS authentication for %.100s failed",user);
+ log_msg("TIS authentication for %.100s failed",user);
memset(password, 0, strlen(password));
xfree(password);
break;
@@ -2672,7 +2672,7 @@
if (password_attempts > 0)
