Firewall Wizards mailing list archives

Re: Hardware tokens for remote access authentication


From: "Marcus J. Ranum" <mjr () ranum com>
Date: Mon, 12 Jul 2004 19:33:15 -0400

Vin McLellan wrote:
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>.

        Wow!!! This says something interesting about the value of full
        disclosure, when you consider that the one person who most
        likely should have seen this - didn't. ;)   It also is interesting that
        the report is '99 against code from '94. So much for the "many
        eyes" theory of open source. ;)

        Kadow's attack is heavily reliant on shell-level access to the
        auth server. Anyone who gave shell-level access to their auth
        server has already voided the warranty. ;) You're not supposed
        to do that!!!  Kadow's at least intellectually honest enough to
        mention in his writeup that normal FWTK/Gauntlet configuration
        practice is to only allow connections to authsrv on the loopback
        port, which completely defeats the attack unless the attacker
        is ON the machine. That's how it was designed to be run, and
        that's how it was configured in Gauntlet. In other words, the
        attack would never work against a system that had not already
        been misconfigured to the point of stupidity.

        Your posting, Vin, doesn't mention these inconvenient facts as
        they are described in Kadow's own paper. That makes it sound
        a lot like you're just blowing FUD to me.  I understand your
        desire to relentlessly market SDI's products (you took a couple
        more chances to throw in a plug here and there in your response..)
        but I don't think it's proper to do it at the expense of other
        systems, by selectively choosing parts of someone else's
        paper that subtly change the message and distort its meaning
        just so you can make your point. That's not proper.

        The _actual_ URL (the one Vin gave is wrong) is
        http://www.securityfocus.com/archive/1/13322
        and I suggest that anyone who is interested in this topic
        give it a read - compare Vin's selective editing with what
        Kadow really has to say. SHAME ON YOU, VIN!

        I'm also not particularly impressed with hype and FUD
        blowing "security researchers" who write a paper that
        reads basically, "If the system is configured correctly
        or in the default configuration as it comes from the vendor
        this attack won't work" - who then goes on for 5 pages
        about the theoretical ramifications of how serious the
        attack would be, if the system were set up wrong. Duh!
        You also need to be in the path where you can sniff
        valid challenge/response pairs, in order to mate the
        correct challenge with the right 56-bit DES generated
        response. Well, if you can do that, since fwtk didn't
        do user-land crypto, you can just as easily cut to the
        chase and do an IP splice attack. That was a known
        problem in the system that we ignored in 1994 because
        "that'd be too hard" (or so we thought, then!) ;)

        All that said, the PRNG seeding *IS* bad. The intent of
        the system was to be 'good enough' to raise the bar
        to the point where the bad guys would attack a weaker
        part of the system - most likely the endpoint(s).

        If you're willing to think about the problem for a few
        minutes and not be impressed by FUD from a vendor
        shill, you'll realize that moderately good authentication
        raises the bar to the point where the other weaknesses
        of the system become more significant. In fact, I'd argue
        that plain-ole-passwords over SSH/SSL have probably
        raised the bar to the point where the hackers are just
        now having to re-invent transitive trust attacks (hello, kiddiez!)
        The value of authentication systems like an SNK or
        S/Key or SecurID has relatively little to do with their
        cryptographic strength or complexity, and a lot to do
        with the fact that hackers don't have keystroke loggers
        for brains - yet. I'd go so far as to say that the ONLY
        value of those systems is that they, for the time being,
        push authentication computation into a non-networked
        system. You can accomplish that with a palm pilot or
        darned near anything, and you'll have a system that
        the hackers aren't going to compromise.

        Unless you give them shell access to it. Duh!

mjr.

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


Current thread: