OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq Archives: Re: S/Key & OPIE Database Vulnerability

Re: S/Key & OPIE Database Vulnerability

Subject: Re: S/Key & OPIE Database Vulnerability
From: Evil Pete (shipleyDIS.ORG)
Date: Mon Jan 24 2000 - 20:47:24 CST

I disagree, by reading the skeykeys/opiekeys file you can gain
insight on all users. While, as you point out, this can be obtained
via login probes, the skey-login program will provide false data as well.

 eg:
        fbsd# telnet www.dis.org
        Trying 216.240.45.60...
        Connected to kizmiaz.dis.org.
        Escape character is '^]'.

        login: fooberry

        S/Key MD5 65 fd681a7be2a92421
        S/Key Password:

thus an advantage to keeping this data a system secret.

In addition by viewing the skeykeys file you can also learn more about
account usage (last skey login etc..) which can be useful in compromising
a system while avoiding detection.

Also, in the relm of security you do not want to expose any system information
unless it is necessary. thus (imo) /etc/*.conf should not be publicly readable
unless required by the service. All system information should be on a
"need to know basis"

>This "security advisory" seems to result from a fundamental
>misunderstanding of how S/Key works. The point of S/Key is that it is
>fully intended to work even when all the information in the skeykeys or
>opiekeys file is publicly known, and in fact all of the same information
>can be obtained merely by sniffing the network or looking over the
>shoulder of the S/Key user.
>
>Here's an example of an opiekeys line:
>
>stevev 0498 ca0693 8c979c12f4a3578e Jul 25,1996 11:00:48
>
>Respectively the fields are the user name, the sequence number, the
>64-bit number decoded from their most recent challenge response, and the
>date.
>
>Only the sequence number, challenge word, and 64-bit number are used in
>the S/Key algorithm. The sequence number and challenge word are
>presented to the user in the S/Key challenge; the 64-bit number can be
>decoded trivially from from the user's six-word response.
>
>The security of S/Key depends on the privacy of the user's secret (which
>you should note is not stored in any form in the keys file), that the
>sequence of possible challenge responses is used in backwards order, and
>that the function used to generate the sequence is not feasibly
>invertible (because of the use of a cryptographic hash function to
>generate successive terms of the sequence).
>
>Since the all of a user's information kept in the skeykeys/opiekeys file
>is exposed every time the user logs in, there is no real security
>benefit to making the file unreadable. An S/Key user who chooses an
>easily-guessed secret will still be susceptible to dictionary attack
>whether or not his public information can be obtained from the file.

This archive was generated by hypermail 2b27 : Tue Jan 25 2000 - 14:37:42 CST