[UNIX] OpenSSH and S/Key Information Leakage

From: support@securiteam.com
Date: 11/16/01 

From: support@securiteam.com
To: list@securiteam.com
Subject: [UNIX] OpenSSH and S/Key Information Leakage
Message-Id: <20011116202331.99625138BF@mail.der-keiler.de>
Date: Fri, 16 Nov 2001 21:23:31 +0100 (CET)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  OpenSSH and S/Key Information Leakage
------------------------------------------------------------------------

SUMMARY

Sensitive information leakage vulnerability has been found in combined
OpenSSH and S/Key implementations. The vulnerability allows an attacker to
find out sensitive information on the remote system by simply analyzing
the incoming "welcome" banner sent by the product.

DETAILS

Important Note:
Neither of these information leakage issues is a security bug in itself.
Both S/Key and OpenSSH are secure even with this issue. However, this
information leakage may assist a hostile attacker.

General S/Key information leakage:
As is commonly known, the S/Key (and OPIE) one-time password system will
send the user a challenge string. This string is provided after the
username is entered. The string looks like: otp-md5 98 indi26401

This string will tell you several things:

1) What hash algorithm is being used (in this case, md5). Because some
hash algorithms are weaker then others, this will help an attacker
determine which accounts to attempt to attack.

2) The "indi26401" is a "seed" value. If this seed changes, then it is
clear that the user has changed the passphrase that S/Key uses to generate
one-time passwords.

3) The "98" indicates that S/Key is expecting password #98. By watching
this number, it is possible to determine a user's login frequency. By
watching it at different times in the day, the user's habits can be
determined. Note that in an S/Key enabled system, "su" also uses S/Key
passwords for root, which helps an attacker know when the system
administrators are maintaining the system (and when they are on
vacation...).

OpenSSH & S/Key implementation problems:
There are some bad implementations of S/Key in client programs. OpenSSH
(at least on OpenBSD 2.9) is one such bad implementation. OpenSSH only
provides this challenge string if (1) the user exists and (2) the user is
using one-time-passwords. Otherwise, it simply asks for a password (or
"hangs up" on the remote client if reusable passwords are not allowed).
Obviously, in an environment where one-time-passwords are required,
provides an easy way of finding out usernames.

Note:
This depends very much on the version of the OpenSSH and the versions of
your S/Key library. OpenSSH switched away from creating fake S/Key
challenges, and now depends on the skey/otp/bsdauth/whatever-library to
created fake challenges. With BSD_AUTH it even depends on the
authentication algorithms available in the default class.

With a post-Nov 2000 OpenBSD, skeychallenge() creates fake challenges, so
OpenSSH does not need to care.

Fixes:
 - If S/Key passwords are used at all, "fake" challenge strings should be
printed whenever a real challenge string is not available. OPIE does this
right.

 - Unfortunately, much of the information leakage cannot be helped. It
would be trivial to prevent display of the hash algorithm used, but that
would provide very little security - the real threat is the sequence
number, as it lets an attacker profile a system. The sequence number is
required as it is used when pre-computed password lists are used.

 - OpenSSH and other programs often monitor failed logins. Reviewing your
logs will alert you to this type of activity. However, once alerted, your
options are either very limited - disconnect your system from the network
or allow yourself to continue to be probed! (you might block offenders' IP
addresses, but that will be difficult as offenders usually have a large
number of IPs to come from).

ADDITIONAL INFORMATION

The information has been provided by <mailto:jmaslak@antelope.net> Joel
Maslak and <mailto:markus@openbsd.org> Markus Friedl.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.