Sendmail 8.7.5 vulnerability

[peiterz () SECNET COM (Peiter Z)]

        The stance and statements that Vin make are quite interesting. We at
Secure Networks take offense to some of the implications that are made
in his post and wish to point out other statements we believe to be
in error.

        First:

> (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.)

        The above is quite an interesting statement coming from a person who
does a lot of paid contract work for SDTI. 'Hello kettle, you're black!'

        I will leave Neuman and Willoughby to defend themselves in regards to
some of Vin's comments towards them.

        Let me explain why I did not embark upon session hi-jacking in the
white paper. Session hi-jacking is something that SecurID never claimed
to protect against. I did mention session hi-jacking briefly in the
paper but did not feel it was fair to bash SDTI on this. All of the
vulnerabilities mentioned in the paper demonstrate problems that
the SecurID mechanism claims to prevent against and could be corrected
if the product was written properly (or kept up to date - depending upon
the viewpoint you take).

>        Properly forging TCP packets, the essential skill for tcp-splicing,
> is still beyond the wannabes on Alt.2600.

    The above statement is completely incorrect. The tools are readilly
available and have been for some time now. Even to the "wannabes".

> the typical OTP app is a dial-in phone connection, through a communications
> server --

        Please come into the 90's Vin. If your security is in having an
unmonitored connection why not stop selling telnet clients for the SecurID
card or at least market it to dial-in type customers. Why not? Because
there's more money selling into the 'net', whether or not the application
is particularly suited for it or not.

> Even crypto won't bring on Nirvana.

Yes. This is true. Funny how an encrypted s/key session (and many other
OTP's) gains much more security from the encrypted link than SecurID does.
The problem being that the SecurID authentication mechanism is out of
band from the, in this example, telnet session.

>        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."

        This passage really irks me.  First, what gives you the right to
label an employee of a legitimate company a member of the 'hacker elite'.
The only person that I mentioned that has any ties to the hacker community
,to the best of my knowledge, in my paper was hobbit () avian org. I do not
know if he appreciates being labeled as a hacker but his knowledge and
understanding of security would definately place him in the 'elite' ranks.

        As for the attacks being esoteric, we opted *not* to publish the
source code for the racing attacks, which are *still* viable against
the current incarnation of the SecurID solution. As a point of interest,
we do not have our own Ace server. We were given permission by a company
that runs one to break into their network (for a security assesment) and
to use the information that we found from the network traffic in the report.
Of course we were asked not to release any information pointing back to
this company. We gained the information on the ACE client server protocol
in this fashion. How, you might ask, did we break in to their internal
network? Through SecurID of course. Thus I do not think all of the attacks
mentioned in the paper are too terribly 'esoteric' [Is everyone getting
this? Yes, we were able to break into their network because they were
using SecurID]. Besides, esoteric or not, these are problems with the
SecurID mechanism that shouldn't exist. I would assume that there are
some employees at SDTI whose job it is to speculate on attacks against
this product and to recommend / implement fixes. No?

>        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.

        Please see my previous paragraph. We broke through an otherwise
largely secure network through their use of SecurID. I am surprised to
hear you refer to this as 'relatively harmless and fruitless'.

>        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.)

        Interestingly enough, this document was not available on the web
server when you posted your message. A call to SDTI inquiring about it
recieved the response of "We are currently working on the paper but it
has not been completed yet". Funny how you have this inside information.

>        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 am sorry to hear that this is how SDTI addresses security issues :
Undocumented and burried fixes that are then shoved upon the user community.
What makes you think that this vulnerability was not a real problem for
the ACE/SecurID user community less than a year ago. Are all ACE/Server's
that are in use on the internet running these "fixed" versions? It would
also be nice if SDTI would offer some proof to the validity of the "fix".

        I look forward to reading the SDTI bulletin by Jim Kotanchik. Rest
assured that I will have comments and packet dumps showing several
succesfull attacks against the SecurID mechanism if the bulletin states
that the attacks are 'relatively harmless and fruitless', as you say.


Sincerely,

 PeiterZ () silence secnet com