From proff Wed Sep 11 18:46:07 1996 Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id SAA11112 for best-of-security; Wed, 11 Sep 1996 18:46:07 +1000 Received: from brimstone.netspace.org ([128.148.157.143]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id GAA07824; Wed, 11 Sep 1996 06:56:51 +1000 Received: from netspace.org ([128.148.157.6]) by brimstone.netspace.org with ESMTP id <24225-7218>; Tue, 10 Sep 1996 16:30:53 -0500 Received: from netspace.org (netspace [128.148.157.6]) by netspace.org (8.7/8.6.12) with SMTP id QAA28895; Tue, 10 Sep 1996 16:32:02 -0400 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 371701 for BUGTRAQ@NETSPACE.ORG; Tue, 10 Sep 1996 16:07:22 -0400 Received: from netspace.org (netspace [128.148.157.6]) by netspace.org (8.7/8.6.12) with SMTP id QAA25976 for ; Tue, 10 Sep 1996 16:06:31 -0400 Approved-By: ALEPH1@UNDERGROUND.ORG Received: from relay1.shore.net (relay1.shore.net [192.233.85.129]) by netspace.org (8.7/8.6.12) with ESMTP id NAA09917 for ; Tue, 10 Sep 1996 13:40:14 -0400 Received: from [198.115.177.220] (slip-0-20.slip.shore.net [198.115.177.220]) by relay1.shore.net (8.7.5/8.7.3) with SMTP id NAA02518; Tue, 10 Sep 1996 13:39:21 -0400 (EDT) X-Sender: vin@shell1.shore.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Approved-By: Vin McLellan Message-ID: Date: Tue, 10 Sep 1996 13:37:06 -0400 Reply-To: Vin McLellan Sender: proff From: Vin McLellan Subject: Re: SecurID White Paper - A Comment X-To: Firewalls@GreatCircle.com X-cc: mcn@EnGarde.com, frankw@in.net, peiterz@SECNET.COM, hobbit@avian.org, mudge@l0pht.com, adam@homeport.org To: Multiple recipients of list BUGTRAQ 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 , 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 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" . 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 . 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 ) 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+ 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>