Re: SecurID White Paper - A Comment

[vin () shore net (Vin McLellan)]

        Any user community, and the vendor of any security product, is
vastly served by talented critics, crackers, and customers who bang on a
product relentlessly; analyze it in detail; and then sound trumpets to
announce its weaknesses: real, theoretical, and mythical.

        Give us only the Grace to sort by these categories -- and a grip on
context that can keep these reports in some earthly perspective -- and the
typical sysadmin will require no more than her allotted budget for Maloxx
and Pepcid AC.  'Course, that's sometimes easier said than done;-)

        Authentication products -- one-time password (OTP) tokens in
particular; and the popular ACE/SecurID system in specific -- have had the
benefit of several articulate Cassandras over the past year.  In the IDS
community, Mike Neuman <mcn () EnGarde com>, reputed to have created the first
of the current generation of automated TCP session-hijack devices at Sandia
a few years back, regularly scorches token authentication systems as
generically insecure.  Mr. Neuman argues, as he did again last week in a
post to multiple mailing lists:

> It's trivial for an intruder to monitor the network, waiting for a user to
> legitimately authenticate themselves. Once authenticated, the intruder can
> hijack that user's connection and assume his credentials."

        Session hijacking -- aka "active sniffing" or "TCP splicing" -- is
"the most serious flaw in one-time password systems,"  proclaims Mr.
Neuman.

        (What Neuman means, I presume, is that TCP splicing can subvert the
integrity and continuity, "hijack," any unencrypted TCP session... even one
which has been initiated with strong authentication. Even with total
control of the comm link, a bad guy can only block or snatch a two-factor
OTP; he can never create one, and the best will timeout quickly.

        (But then, the validity or integrity of two-factor authentication
-- a token "held;" plus a password "known" -- is not really an issue for
Mr. Neuman.  He simply declares OTPs irrelevant if the TCP session they
initialized can be taken over; the valid user cut off; and the bad guy left
in control of an authenticated session with all the user's privileges. It's
a intriguing POV... particularly from a vendor who sells a commercial
session-hijack tool, IP-Watcher, to a hopefully restricted clientele.)

        Over in the Firewalls community, Frank Willoughby <frankw () in net>
of Fortified Networks -- bane of Firewall vendors rash enough to market
products which do not yet offer user-to-firewall encryption -- has echoed
Mr. Neuman, with a slightly more narrow focus.  Last week, in a post to
BoS, he declared:

|> Using SecurID (or Digital Pathways, S/Key, etc) is *lethal* if you are
|> planning on using it to authenticate users from the Internet who wish to
|> access a system on your internal network which is protected by the
|> firewall."

        Both Neuman and Willoughby are bright guys and respected security
mavens, but don't they sound like armchair generals who want to abolish the
infantry because it can't defend against high-altitude bombing? Perhaps
because they seek to challenge a still-pervasive illusion about the
integrity of TCP/IP network connections, they tend to generalize a bit and
toss the proverbial baby with the bathwater. They don't bother to
acknowledge the limited purpose and function, or any independent value, of
strong user authentication.  (Encryption without strong authentication is
also problematic, to say the least.)

        But then, Prophets with a Revelation are like that: single-minded;-)

        These guys, and others who use similar rhetoric, sometimes get so
caught up in their jeremiads that they ignore basic tradecraft. In Compsec,
security is never absolute; both threats and defenses are always relative.
Prudent CIOs invest in defenses against likely and serious threats -- not
all known threats. We live with all manner of vulnerabilities which never
become serious threats, like Unix viruses. Others -- like the risk of
eavesdroppers snooping on network traffic -- become all but accepted; and
relatively few sites feel the potential for loss justifies the solution
(encryption.)

        For any given environment, an assessment of current risks, and the
need to invest in new security tech, are both CIO judgment calls. The cost
of additional security is weighed against the perceived vulnerability and
value of the data or system assets at risk.  Firewalls without
user/firewall crypto is not silly; two-factor authentication without crypto
is not lethal.  Each, properly configured, offers an effective tool to
block an array of known and dangerous threats.  At issue is whether the
threat of TCP session hijacking now poses a danger of a magnitude which
demands that a prudent administrator invest in link or application-level
cryptography.  For a growing number of sites and environments, the answer
is clearly "yes."

        Yet, professionals who decide that this threat does not yet justify
the expenditure necessary to block it do not deserve to be scorned as
fools. Risk-analysis is Security 101.  How much insurance, at what cost? To
protect against what scope of potential loss?

        Properly forging TCP packets, the essential skill for tcp-splicing,
is still beyond the wannabes on Alt.2600.  And to tap a telephone line --
the typical OTP app is a dial-in phone connection, through a communications
server -- requires a wholly different level of criminal commitment than
"sniffing" on a local LAN or Internet link to which one is already
connected. At least in the US, wiretapping is a federal felony, punishable
by serious jail time.)

        That said, I should point out that _all_ vendors of two-factor
authentication systems "strongly recommend" encryption today as the natural
complement to their OTP products for high-security installations.

        The function of a security device is to raise the cost of an attack
upon it -- in terms of time, money, equipment, specialized knowledge, and
risk of criminal penalties -- so that it is no longer (compared to
alternatives) an attractive or likely avenue of attack.  As a class, OTP
tokens do that for user authentication. Protecting the continuity,
security, and confidentiality of a  TCP network connection is a different
task, which in many secure environments will (sooner rather than later)
doubtless require an additional investment in crypto.

        Even crypto won't bring on Nirvana.  No security tool should be
purchased with any illusion that it offers Total Security, of course;
anyone who claims to sell TS is a bandit, and anyone who accepts such a
claim is a fool.  Such illusions can be dangerous, even (rarely;-)
"lethal."

        No recent buyer of any of the six or seven commercial two-factor
OTP systems is likely to be unaware of the distinction between user
authentication and network integrity. Up until three years ago, however,
almost everyone presumed that a TCP session had internal integrity --
although we always knew that unencrypted network traffic promised no more
confidentiality than a postcard.

        Cheap and omnipresent PC-based sniffers, often configured as
"password grabbers," were then, as now, seen by CERT as the dominant threat
to secure remote access over networks.  The security community and their
managers responded by investing in OTP tokens to both validate a remote
users identity to a high degree of certainty and to foil the pesky sniffer
threat.  (CERT even went proactive and recommended a switch to OTPs two
years ago!) But to the extent that anyone trusts a network, or trusts it to
safeguard valuable data unencrypted, many of us assumed a confidence in the
integrity of the TCP/IP infrastructure that was, in hindsight, rash.

        It was a comfortable illusion that survived even the abundant
evidence of e-mail and source forgeries. Not everyone has yet escaped it --
despite the energy and enthusiasm with which Neuman, Willoughby, and many,
many, others (me among them,) have beat the drums of warning.

        The fundamental truth about the Vulnerable Network, circa 1996: The
delay in providing full network encryption has left the Internet not only a
"party line" (vulnerable to sundry eavesdroppers with low-tech "sniffers,")
it has also left us wholly dependent upon a TCP/IP infrastructure which can
not guarantee even the integrity or continuity of an ongoing user/host
connection.

        Like Isaiah and Obadiah, dismal Prophets of yore, Neuman and
Willoughby took to their pulpits last week to comment on the publication of
a "white paper" entitled "Weaknesses in SecurID," by "PeiterZ"
<ftp://ftp.secnet.com/pub/papers/securid.ps>.  This document reports on
recent research into the ACE/SecurID protocol by PieterZ and a group of
loosely-associated TCP hackers including "Mudge," "*Hobbit," and the
moderator of the SDAdmin mailing list, Adam Shostack.  Such a report was
widely anticipated because Mudge, the author of a devastating critique of
the freeware s/key OTP protocol last year, had promised a similar
deconstruction of SDTI's ACE/SecurID for this year.

        For a ten-page "white paper" from the hacker elite, the PieterZ
Paper was rather disappointing (or reassuring, as the case may be;-)  In a
widely cross-posted comment, Mike Neuman harrumped:

> I appreciate the conclusion of the paper which finally does proclaim that
> SecurID (and other one-time password tokens) are extremely vulnerable.
> The vulnerabilities described seem to be overly esoteric, however."

        Neuman complained that the over-arching reality of network
insecurity -- session hijacking -- went "unmentioned" in the hackers' white
paper. (Actually, it is mentioned, but only in passing... as if such an
attack was too lacking in finesse, too basic and blunt, for such elite
protocol mavens to waste time or text discussing;-)

        SDTI, the vendor of the ACE/SecurID system, has posted a
substantive commentary on the PieterZ Paper and it's allegations,
suggestions, and conclusions on their web site. (Look for Network Security
Bulletin 2-897 at <http://www.securid.com>.  The document, unsigned, is an
analysis by Jim Kotanchik, SDTI's director of engineering.)

        With the lethargy of summer behind us, I also expect the issues
raised will enjoy a full and energetic discussion on Adam Shoshack's
SDAdmin mailing list. (Enroll with an "subscribe sdadmin" message to
<majordomo () bbnplanet com>)  I look forward to participating.

        As the author of the SecurID FAQ, however, I'm surprised to find
myself in agreement with Mike Neuman's summary judgment. "Overly esoteric"
is just about right.  This is a relatively harmless and fruitless
exploration of the ACE protocol by some very smart guys who deduce or
propose several potential attacks on the ACE system. Attacks which are
blocked by various security features (documented or undocumented) in the
current versions of SDTI's ACE/Server... or which seem extremely unlikely
to succeed outside a software lab or a DefCon fantasy fest.

        (My favorite PieterZ threat scenario is the suggestion that an
attacker could time a phone call to a valid user -- then in the process of
typing in a SecurID Passcode -- so as to interrupt his typing _precisely
between the second-to-last and last digit of the Passcode_ in order to
stall the user and delay the keystroke for the last digit of his SecurID
Passcode.)

        There is also, however, an impressive analysis of the ACE
client/server protocol which uncovers a exotic vulnerability in the
protocol's use of SDTI's F2 hash which could have been a real problem for
the ACE/SecurID user community six months ago -- before SDTI fixed it with
an undocumented tweak buried in both v1.3 and v2.2 upgrades to the
ACE/Server.  (ACE/Server 1.3 and 2.2 were free "mandatory upgrades,"
flagged for security concerns.)

        I've elsewhere credited Mudge with another intriguing idea,
unattributed by PieterZ, for an unspecified attack which would physically
or logically split a network into two sections and then isolate a working
authentication server from its backup (slave,) in order to mimic to one
what a valid user sends to the other.

        Many of these threat scenarios have the problems endemic to
theoretical attacks. They presume an uncommonly fragile network
infrastructure (with, for instance, no redundancy in vital comm links.)
They often presume an attacker has free reign to operate inside the target
net and that the sysadmin is both dumb and blind.  And they often presume
that an attacker -- who has somehow brilliantly hacked his way deep into
the target's control system -- will then turn around to screw up a security
device like OTP access control or the firewall... rather than do something
criminally productive (or even destructive) to the system assets being
protected.

        Session stealing remains a real or, at least, potential threat at
most ACE/SecurID installations -- but I've never believe it is realistic
threat to the authentication function, per se.  PieterZ, et al, do propose
a class of attacks on a target system's access control and SecurID
authentication, however, which use TCP splicing (the active intrusion of
skillfully forged TCP packets directly into the authentication exchange,
the essential art for TCP session hijacking) to bump the good guy off the
Net -- after he has typed his Passcode, but before he has hit the
carriage-return... while the bad guy (quickly) uses the sniffed SecurID
Passcode to access the target system, masquerading as the valid user.

        It is a valid attack, but even PieterZ acknowledged that if an bad
guy can do all that he is using the same level of skill and knowledge --
the identical tools -- required to hijack an ongoing TCP session after a
SecurID or strong authentication. So, the logical question: why would an
attacker who effectively controls the network link choose not go for the
whole enchilada?  When an ongoing TCP/IP session is hijacked -- from a
user's point of view, the network connection is just dropped -- it would
likely be shrugged off as one of the daily hassles of life on the Net.

        A just-completed OTP authentication call which collapses -- likely
to be followed by a second SecurID authentication call which is wrongly
rejected -- is far more likely to result in a complaint or warning to the
sysadmin or security manager than the straightforward hijack. Withal, an
attack directly on the TCP session is less risky, more likely to succeed,
and offers potentially greater access to a target system than messing with
the TCP packets used in the OTP authentication process.  As Willie Sutton
might say: Where is the loot?

        PeiterZ's "Weaknesses in SecurID" identifies some interesting
issues -- several of which will doubtless need to be considered in future
enhancements to various OTP protocols --  but (other than by subverting the
TCP network) his torturous threat scenarios do not provide potential
attackers with any practical methods for breaking into ACE/Server-protected
systems.

        Peter Neuman and his ingenious automated tools for TCP splicing --
now potentially in the hands of sundry hackers, outlaws, or crooks --
remain (unfortunately) a threat of a different magnitude.  To deal with
that, we will all need network encyption... plus strong authentication.

        Suerte,

                        _Vin


         Vin McLellan +The Privacy Guild+ <vin () shore net>
      53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548
                         <*><*><*><*><*><*><*><*><*>