RSA SecurID SID800 Token vulnerable by design

[Thor Lancelot Simon]

On Wed, Sep 13, 2006 at 10:23:53PM -0400, Vin McLellan wrote:
> 
[... a long message including much of what I can only regard as
 outright advertising for RSA, irrelevant to the actual technical
 weakness in the SID800 USB token that Hadmut described, and which
 Vin's message purportedly disputes.  It would be nice if, when confronted
 with such a "response" in the future, the moderator of this list would
 return it to its author with the requirement that the marketeering be
 stripped out before the actual content be forwarded to this list!  I
 have snipped everything irrelevant to my own response. ... ]

> None of these features -- none of the SID800's cryptographic 
> resources -- were of apparent interest to Mr. Danisch. He ignored 
> them all when he denounced the SID800 as "vulnerable by design."

As well he should have, because they are utterly irrelevant to the
genuine design flaw which he pointed out, and which Vin seeks to
minimize (by burying it in irelevancies?) here.

> What particularly disturbs Mr. D is one option among in the SID800 
> SecurID features which allows RSA's local client software to poll and 
> retrieve a single OTP from the token when the SID800 is plugged into 
> the PC's USB port.  Given the potential for malicious malware to 
> invade and take control of any Windows PC -- malware that can seize 
> and misuse both the user's PIN and an OTP fresh from the USB bus -- 
> it was irresponsible, Danisch suggests, for RSA to make such a option 
> available to its customers.

And so it was.  Vin simply handwaves away the fact that if RSA's client
software can poll the token and retrieve the current OTP, so can any
malicious software running on the host to which the token is attached.

It is not correct to suggest that perhaps this could be done only once,
when the token were first plugged in to the host system's USB port,
because USB *by design* allows the host to cut and restore power to
devices under software control, so that the SID800 can, even if it
somehow is intended to only allow token retrieval "once upon plug-in
and once only" (something Vin seems to imply, but does not directly
state) simply be repeatedly tricked into thinking that it has just been
plugged in.

> In the second version of the SID800 -- an option selectable by local 
> management pre-purchase, and burnt into the token's USB firmware by 
> RSA -- the user can select a menu in which he instructs the SecurID 
> to load one OTP token-code directly into the paste buffer, presumably 
> for immediate use. Since internal access to the SecurID's OTP via the 
> USB bus makes it a potential target for "malware or intruders on the 
> computer," claimed Mr. Danisch, "This is weak by design."  I beg to 
> differ. Effective IT security is about an appropriate balance, not 
> walls of iron or stone.

"Good cooking is about full-bodied flavor, not wire rope or persian
kittens"; but let's leave the irrelevant analogy aside and stick to the
facts that seem to be discussed here, I suppose.

Vin claims that the user "instructs the SecureID to load one OTP
token-code directly into the paste buffer".  This is a very, very odd
claim, because it implies that the user communicates directly with a
USB peripheral and "instructs" _the peripheral_ to autonomously "load"
a token-code -- some bytes -- into an area in host memory that is used
by the host operating system's user interface.  We should note that,
unlike Firewire, USB *does not include a mechanism by which a
peripheral on the bus may initiate a DMA transfer into the memory of
the host system that is the master of the bus* so clearly what Vin
claims cannot be strictly true.  What, then, should we think that it
likely means?  I think he must mean something like this:

  "The user instructs the RSA-supplied application code running on the
   host system to retrieve one token code from the SecureID across the
   USB bus, and place that retrieved token code into the paste buffer."

If that is not what Vin means, I think that he should respond and say
exactly what he does mean, in a way that does not make reference to
mythical properties that USB peripherals do not have.

Now, consider what it means that it is even _possible_ for the RSA-
supplied application to retrieve a token code from the SID800 in this
way.  It means that by, at worst, cutting and restoring power to the
USB port in question, malicious software can retrieve *a new, current
token code* *any time it wants to do so*.  In other words, while, with
traditional SecureID tokens, it is possible for malicious software to
steal token codes typed by the user into a compromised host system _when
the user types them_, and by engaging in a man-in-the-middle scheme
impersonate the intended target system to the user _that once_ (since
SecureID token codes can not be used twice), this new system does, in
fact, open up the gaping new security hole Hamisch claims it does:

   With this USB-connected token, malicious software on the host can poll
   the token and retrieve a *new* token-code *any time it wants to*,
   without the user's intervention and with no need to implement a complex
   man-in-the-middle attack on the user to avoid the user's notice.

> Can this token-code in the paste buffer be misused? Not likely, even 
> if it is immediately stolen by malware and immediately used for some 
> nefarious purpose.

And here we see that Vin evidently does not understand the nature of the
vulnerability RSA has created with their USB-connected token and host
software, because he seems to think that the problem is that the software,
by design, places a single token-code in the paste buffer; as he notes,
malicious software that could steal that code could just as easily steal
a code from a traditional SecureID token typed in by the user.

But that is not the problem!

The problem is that _because there is an interface to poll the token for
a code across the USB bus_, malicious software can *repeatedly* steal new
token codes *any time it wants to*.  This means that it can steal codes
when the user is not even attempting to authenticate, and so the SecureID
server's traditional countermeasure of denying near-simultaneous attempts
to use the same token code becomes *entirely worthless* for there will be
no genuing, user-initiated authentication attempt for the attacker's
submission of the stolen code to be simultaneous *with*.

It seems clear, in fact, that whether RSA has burned the "OTP paste"
feature into the token's firmware or not, any USB-connected token that
works even remotely like the SecureID token is vulnerable to this kind
of attack.  As long as token codes can be requested by the host system
across the USB bus and are passed back by the token, without the user's 
intervention, an attacker can use software on the host to steal token
codes when the user is *not* present to cause a simultaneous
authentication attempt (and thus raise an alarm on the server) and use
them, along with a keylogged password, at will.

It is noteworthy that a token that requires *any* kind of intervention
by the user -- even something as simple as a press of a button on the
token which illuminates when the host presents the token-code request --
is invulnerable to such an attack, potentially at a much lower cost in
terms of user interface difficulty than the traditional SecureID token
where the user's action is to type in the entire token-code by hand.
It is regrettable that instead of wasting time (and, evidently, the
time of its consultants) trying to handwave away the severe security
problem with the SID800 design, RSA does not turn its efforts to the
design of tokens which use simpler mechanisms (like the aforementioned
button-press) to ensure that the user is present, and thus maintain
security while not imposing on the user the onerous requirement of
typing in the whole code.

> PS. I have been a consultant to RSA for nearly 20 years and my bias 
> is overt. I beg the indulgence of the List for the length of my comments.

Simply to clear the air, I would like to ask Vin to answer the following
simple question: did you compose and send your response to Hadmut at the
request or suggestion of someone at RSA, or was the idea to send it
entirely your own?

Thor

P.S. I am not and never have been a consultant to, shareholder in, nor
     employee of, RSA nor any other company in the token or smart-card
     market.  If what I write is emphatic, that is probably because of
     my intense dislike for long, equivocating messages full of what I
     can only regard as marketing language, when they appear on technical
     lists in response to genuine technical contributions.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com