Re: Hardware tokens for remote access authentication

[Vin McLellan <vin () TheWorld com>]

Vin McLellan (me) wrote:

> In 1998, even Marcus' FWTK and the TIS Gauntlet were found to have a 
> flawed random-number generator, which threatened the integrity of those 
> C/R authenticators which had relied upon it.)

Marcus Ranum <mjr () ranum com> replied:

> This may strike you as surprising, but I've never heard of such a thing.
> Can you post a reference??

See Kevin Kadow's April '99 post to Bugtraq, "FWTK, Gauntlet 'random seed' 
security problem," at: 
<http://www.securityfocus.com/archive/1/19990416203627.15201.qmail>.
Kevin announced:


> >   A 'random seed' problem in lib/rand.c affects all local 
> > challenge-response authentication on FWTK and Gauntlet. Many services 
> > have support available for this authentication service, including 
> > versions of ssh, ftp and telnet.

<snip>

> > The problem...affects all the 'random challenge' authentication methods 
> > in Unix platform releases both FWTK and of Gauntlet, though 4.x. The 
> > affected challenge-response methods include Cryptocard, SNK (Axent) and 
> > md5 authentication, as well as RADIUS CHAP.
> >
> > Simply put, if you know the response to any one challenge (from sniffing 
> > the cleartext exchange, shoulder surfing, etc.), you can predict when the 
> > authsrv will generate that same challenge again and possibly manipulate 
> > it into repeating the challenge within minutes.

I asked Kevin about this a year or so later. He said that there had been a 
patch issued for Gauntlet, but after 17 months the FWTK.org had still not 
issued the patch he had submitted.  (Dunno the currrent status of this bug 
in FWTK.  Is Kevin still on this list? Maybe he or Joe Yao can give you an 
update?)

The problem, according to Kevin's report on Bugtraq:

> > The random number routine in the FWTK library 'seeds' (initializes) the 
> > Unix random number generator using only time and process id information, 
> > making the sequence of challenges trivially easy to predict. This 
> > weakness is similar to the 1995 Netscape 'random seed' security problem, 
> > and a real fix is likely to be machine-dependent.

Marcus, unfamiliar with Kevin's bug report, expressed skepticism:

> Random numbers used for challenge-response do not need to be
> cryptographically strong, for practical purposes, if the challenge is
> attached to a unique stream. There's a theoretical attack, I suppose,
> where you could figure out what the next challenge would be, but you'd
> still need the correct response within the life of the system. Since the
> auth server would lock an account after failed attempts, you'd need
> some fancy theoretical footwork to pull off an attack. Did anyone ever
> actually do it? That's the question!

Kevin offered exploit code.  His attack on the authentication server 
apparently corrupts and then purposely manipulates the RNG's "unique stream."

Kevin's experiences with TIS and NAI around this bug report, he has said, 
have made him a fervent advocate of "full disclosure" lists.  I disagree 
with Kevin about the balance of rectitude in the "full disclosure" debate, 
but he is a very sharp guy.

I remember arguing with him on one of the newsgroups four years ago about 
the relative importance of hash collisions in the classic 64-bit SecurID 
token output.  He argued that it was a cryptanalytic vulnerability, and I 
disagreed. Kevin was right -- as was demonstrated in the research published 
last year by Biryukov, Lano, and Preneel 
<https://www.cosic.esat.kuleuven.ac.be/pressReleases/ashf.pdf> and extended 
earlier this year by Contini and Yin: 
<<http://eprint.iacr.org/2003/205/>http://eprint.iacr.org/2003/205/>.

(Three years ago, RSA -- as it has every few years -- commissioned a de 
nova review of the SecurID crypto by an independent cryptographer of 
international stature.  The report RSA got back warned of a similar 
cryptanalytic attack vector on the SecurID's Brainard hash.  Although RSA 
was about to launch a new AES-based SecurID with a 128-bit secret, the 
company also decided -- for the first time in 15 years -- to quietly 
upgrade crypto in the classic 64-bit SecurID.)

> To Vin's FUD about how hard it is to get it right: that's just
> utter bull byproduct. In truth, authentication systems (especially token
> based ones) don't get attacked in practice.

Q.E.D.  Crypto is demonstrably hard to get right; and when it is wrong, 
most people (even InfoSec professionals, even cryptographers) often can't 
easily recognize that they have a problem.  Examples are embarrassingly 
abundant.

I frankly don't know of any token-protected systems or networks that have 
been successfully attacked -- but in 20 years I've seen a number of 
potentially effective attacks proposed, and then systemically 
blocked.  (Some were publicly demonstrated. Some were known only among the 
product's development team. Still others were -- or are -- known only to 
the customer who reported a problem, and the vendor engineers who fixed 
it.)  A lot of problems get quietly and effectively fixed -- with the 
general public, and most customers, none the wiser...(hopes the vendor, 
many vendors;-)

(I'll bypass discussion of the "disclosure" conundrum: When is a risk a 
threat, and who sets the priorities for mitigation?  At various times, I've 
argued all sides of those issues.)

Would real-world attacks on token-based authentication systems necessarily 
become public knowledge?  Would we know if Kadow's exploit was used in an 
attack during the period after his Bugtraq post, when some large number of 
FWTK sites were apparently left vulnerable for some period of time? If the 
attacker was a pro intent on merely stealing secrets, probably not.

Marcus argued that attacks on an authentication server are unlikely:

> Because they are a pain
> in the a** and because it's easier to just break some sucker's account
> who is still using a password. It's like the old joke about the 2 guys
> trying to outrun a bear that's chasing them, "I don't need to outrun
> the bear; I just need to outrun YOU."

Remember Courtney's First Law? "Nothing useful can be said about the 
security of a mechanism except in the context of a specific application and 
a specific environment."

I subscribe to the bear-chase model, of course. Professionally, we all 
do!  But the baseline really depends on your particular threat profile, 
doesn't it?  Are you a target of opportunity or a target of choice? Is your 
potential attacker a script kiddie, a surfing hacker, or a dedicated paid 
professional with a specific assignment.

William Hugh Murray has an mnemonic for the cost of an IT attack: 
WAIST.  Some mix of Work, Access, Indifference to attack, Special 
knowledge, and/or Time will crack any security system, he argues -- but if 
an attacker is blessed by an over-endowment of any one of them, that 
probably decreases, for the attacker,  the importance of all the others.

The potential targets of an attack on an OTP system are the token, the 
network, the server, and the people.  I suspect that new attacks will 
continue to be developed against all four elements. Ignoring any one of 
them could be dangerous.  Vendors of security products are expected, by 
most of their customers, to stay out in front of the emerging threats. I 
know that RSA -- and probably its competitors -- has designed unannounced 
defenses into its product line that should help protect its customers from 
a variety of new and hopefully-rare attacks on the SecurID, the ACE/Server, 
and the network they rely upon.  Now if we could only figure out how to 
better inoculate our people against the range of current and future 
social-engineering threats that target them.

Suerte,
        _Vin

       -----------------------------------------------------------------
        "Trust is only dangerous when you have to rely on it."

                 * Vin McLellan + The Privacy Guild *
                 Chelsea, MA. USA vin () theworld com


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards