[Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On FD, and in several other security forums, Hadmut Danisch
<[EMAIL PROTECTED]>, a respected German information security analyst,
recently published a harsh critique of one optional feature in the
SID800, one of the newest of the six SecurID authentication tokens --
some with slightly different form-factors, others with additional
security functions -- sold by RSA Security, Inc. It's raised quite a
stir, and I'd like to respond.
A personal authentication token, by classical definition, must be
physical, personal, and difficult to counterfeit. The most popular
implementations in computer security move the calculation of a
pseudo-random authentication code -- a so-called "One-Time Password,"
or OTP-- off an employee's PC and into a hand-held hardware fob,
small enough to be attached to a personal key chain.
RSA's mainstay token, the SID700 SecurID -- millions of which are
used in over 20,000 enterprise installations worldwide, including
many government agencies and financial institutions -- use AES (the
US cryptographic standard) to process Current Time and a 128-bit
token-specific secret to generate and continuously display a series
of 6-8 digit (or alphanumeric) OTP "token-codes" which change every
60-seconds, and remain valid only for a couple of minutes.
In practice, a RSA authentication server can then independently
calculate the token-code that is appearing on a specific SecurID at
this particular moment; compare that against an OTP submitted by a
pre-registered user, and validate a match. RSA, which first
introduced the SecurID in 1987, has always insisted on the necessity
of "two-factor authentication" (2FA), where a remote RSA
authentication server must validate both a SecurID token-code
(evidence of "something held") and a user-memorized PIN or password
("something known.")
A stolen password can be reused indefinitely to masquerade as the
legitimate user, often with the victim wholly unaware. A
token-generated OTP, valid only briefly, is a far more robust
authenticator. With 2FA, if a SecurID is stolen or lost, it still
can't be used to obtain illicit access to protected resources without
the second secret: the user's memorized PIN or password.
The elegant simplicity of the traditional SecurID -- and patents on
the mechanism by which the "drift" in each individual SecurID's
internal clock is tracked by the RSA authentication server -- has
allowed RSA's "time-synched" SecurID to dominate the market niche for
hand-held OTP authentication devices for 20 years.
In a typical installation, anyone seeking to log on to a protected PC
or network, or to access restricted online resources, must manually
type in the OTP currently displayed on the SecurID -- as well as his
memorized PIN or password -- to have his identity and access
privileges validated. Network applications handle the combined
SecurID "pass-code" like any long traditional password. The link
between the user and the RSA infrastructure is often, but not always,
an encrypted VPN channel. That's a local decision. Data exchanges
between the RSA agent and RSA authentication server -- which
typically means between one of the 350-odd "SecurID-aware" network
applications and the RSA Authentication Manager, using RSA's own
protocol -- are always fully encrypted.
Mr. Danisch is an admirer of the classic SecurID (SID700), RSA's
traditional hand-held token. His ire is directed at one of the two
new hybrid SecurID designs that RSA has recently offered in an
attempt to respond to new requirements in the boisterous and
rapidly-evolving market for what's called "strong authentication."
With the nascent prospect of a new billion-dollar market in consumer
authentication for financial services boosted by US federal
regulatory initiatives, RSA announced the SecurID Signing Token, the
SID900. The SecurID Signing Token still has a time-synched OTP, but
RSA added a keypad and a challenge/response function which
successively authenticates the user, the remote server, and a
specific financial transaction, before the transaction (e.g., a funds
transfer) is executed.
On the other side of the market -- where again US laws and federal
regulatory initiatives have boosted demand for internal controls and
more accountability measures in enterprise IT -- RSA has introduced
the SID800, another hybrid SecurID, to meet the requirements of
organizations that want to move into a full public key infrastructure (PKI.)
The SID800 SecurID is a multi-function authentication and
cryptographic device that combines, in a single DPA-resistant token,
the mobility and availability of the classic hand-held SecurID, as
well as a "smart chip" that implements v2.1.1 Java tech (essentially
a "virtual smart card") in a USB format. It looks like a slightly
smaller version of the classic SecurID key fob, with a USB plug
jutting out at one end. It can carry up to seven X.509 digital
certificates for PKI, as w
[Full-disclosure] Re: RSA SecurID SID800 Token vulnerable
In security it's always about raising that bar a bit more. You should be in the movies :)BojanThat's jan, Bo Jan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On 9/10/06, Lyal Collins <[EMAIL PROTECTED]> wrote: If there's malware on the machine, and there is a connected USB token, then authentication is only as good as the password - malware can probe the connected token as often as desired. Read my post again. That's not necessary true. The RSA SID800 token has a smart chip running Java on it. While I don't know how the whole thing works (that's why I asked the OP to sniff the USB traffic and see what's going on), it's possible that the actual OTP generated by the token is encrypted. In this case your malware can probe as much as it wants, but it won't get anything - what you need is a directed attack on the host part of the RSA authenticator (something what 3APA3A mentioned, by changing the GINA dlls) - same as with rootkits, lower level wins. And this data stream to the authentication host is still subject to a variety of MITM attacks. There is no perfect security. In the event of an unconnected OTP token, a variety of MITM attacks still applies to OTP tokens - in the SecurID-style form factor, printed lists or anything similar. In theory, with trusted data paths everywhere (internal to worksation as well as he network) OTP is better than passwords alone. But since this data patch assumption is rarely 100% valid, OTP is as good as a password alone. In the situation where data paths are trust-able, OTP is a somewhat better than passwords alone. Does the risk justify the costs involved (tokens, token management, authentication host, and trusted data paths)? What you're missing here is a pretty common problem today called keyloggers. And 2FA like this effectivelly raises the bar *quite a bit*. Sure, you can intercept some things, there are MitM attacks and so on, but if your employee, who is using a machine on an airport wants to log in (and there's a keylogger running), it *will* help. This also helps when talking about brute force attacks - it makes them even more difficult, and you don't have to worry about your users using "fred" as password. In security it's always about raising that bar a bit more. Bojan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] RE: RSA SecurID SID800 Token vulnerable by design
Based on your description I see this as a security design problem as well, but only exploitable if the user does a one-time password based logon while the token is plugged in. It would be inteteresting to know whether folks at RSA did a risk assessment when decided to implement this functionality. Good example how ease of use and complexity have adverse effects on security. Plain old SecurID tokens that cannot be connected to anything are better. Regards, Tamas -Original Message- From: Hadmut Danisch [mailto:[EMAIL PROTECTED] Sent: Thursday, September 07, 2006 8:50 PM To: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com Subject: RSA SecurID SID800 Token vulnerable by design Hi, I recently tested an RSA SecurID SID800 Token http://www.rsasecurity.com/products/securid/datasheets/SID800_DS_0205.pd f The token is bundled with some windows software designed to make user's life easier. Interestingly, this software provides a function which directly copies the current token code into the cut-and-paste buffer, when the token is plugged in into USB. This is weak by design. The security of these tokens is based on what RSA calls "two-factor user authentication": It takes both a secret (PIN) and the time-dependend Token-Code to authenticate. The security of the Token-Code depends on the assumption that the token is resistant against malware or intruders on the computer used for communication (web browser, VPN client,...). However, if the Token Code can be read over the USB bus, this assumption does not hold. A single attack on the PC where the token is plugged in would compromise both the PIN (e.g. with a keylogger) and the token itself (e.g. writing a daemon which continuously polls the token and forwards the token in real time to a remote attacker. Ironically this could make an attack even easier: If some malware simultaneously monitors the token and the keyboard, it is much easier to detect that the keystrokes are actually related to some login procedure: Whenever the 6-digit token code appears in the keyboard or cut-and-paste input stream, you can be pretty sure that in a sliding window of about the last 100-200 keystrokes both the PIN and the address of the server to login is contained. Makes it really easy to automatically detect secrets in the input stream. Thus, two different authentication methods are together weaker than each single one. regards Hadmut ** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copy, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any options or advice contained in this e-mail are subject to the terms and conditions expressed in the governing KPMG Client engagement letter or contract. This footnote also confirms that this e-mail message has been swept by MIMESweeper for the presence of computer viruses. ** ** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copy, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any options or advice contained in this e-mail are subject to the terms and conditions expressed in the governing KPMG Client engagement letter or contract. This footnote also confirms that this e-mail message has been swept by Postini for the presence of computer viruses. ** ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
nuqneH, Well, they could have a hardware button on the token itself at least.. On Sat, Sep 09, 2006 at 01:41:55PM +0400, 3APA3A wrote: > Dear Hadmut Danisch, > > 2-factor authentication is not a way to protect against malware. > > SecurID authentication supports single sign-on technology. As a weak > side of this technology, it means, if single account on any network > host is compromised, this account is compromised in whole network, > because any resource can be accessed from compromised host. An ability > to read current key from device is required to support single sign-on. > > The only additional attack factor this issue creates is attacker can > get _physical_ access to console with user's credentials _any time_ > while user is logged in, while in case token can not be red (e.g. it's > not plugged to USB) he can only access console short after user logs in > to compromised host (while token is not changed). > > > --Thursday, September 7, 2006, 10:49:52 PM, you wrote to > full-disclosure@lists.grok.org.uk: > > > HD> However, if the Token Code can be read over the USB bus, this > HD> assumption does not hold. A single attack on the PC where the token is > HD> plugged in would compromise both the PIN (e.g. with a keylogger) and > HD> the token itself (e.g. writing a daemon which continuously polls the > HD> token and forwards the token in real time to a remote attacker. > > > > -- > ~/ZARAZA > http://www.security.nnov.ru/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On 9/9/06, Lyal Collins <[EMAIL PROTECTED]> wrote: If there's malware on the machine, and there is a connected USB token, then authentication is only as good as the password - malware can probe the connected token as often as desired. In theory, with trusted data paths everywhere (internal to worksation as well as he network) OTP is better than passwords alone. But since this data patch assumption is rarely 100% valid, OTP is as good as a password alone. In the situation where data paths are trust-able, OTP is a somewhat better than passwords alone. If you think about it in terms of how long an attacker has to act, I think you'll come to a different conclusion. Two-factor auth is better than password alone even when the end user is typing OTPs into a machine that is completely and totally rooted. The key phrase in your analysis is "connected token." Once the token is disconnected, the malware no longer has access to the authentication data. When a password is stolen it could be usable for months. When an OTP is stolen it is usable for hours, if that. Two-factor auth reduces the risk because it reduces the length of time of the compromise. Does the risk justify the costs involved (tokens, token management, authentication host, and trusted data paths)? That is the big question. Even if you are willing to pay for two-factor, transactional authentication might provide better value. Regards, Brian ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
If there's malware on the machine, and there is a connected USB token, then authentication is only as good as the password - malware can probe the connected token as often as desired. And this data stream to the authentication host is still subject to a variety of MITM attacks. In the event of an unconnected OTP token, a variety of MITM attacks still applies to OTP tokens - in the SecurID-style form factor, printed lists or anything similar. In theory, with trusted data paths everywhere (internal to worksation as well as he network) OTP is better than passwords alone. But since this data patch assumption is rarely 100% valid, OTP is as good as a password alone. In the situation where data paths are trust-able, OTP is a somewhat better than passwords alone. Does the risk justify the costs involved (tokens, token management, authentication host, and trusted data paths)? Lyal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bojan Zdrnja Sent: Sunday, 10 September 2006 8:51 AM To: 3APA3A Cc: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com Subject: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design On 9/9/06, 3APA3A <[EMAIL PROTECTED]> wrote: > Dear Hadmut Danisch, > > 2-factor authentication is not a way to protect against malware. Well, it protects - the authentication process. > SecurID authentication supports single sign-on technology. As a > weak side of this technology, it means, if single account on any > network host is compromised, this account is compromised in > whole network, because any resource can be accessed from compromised > host. An ability to read current key from device is required to > support single sign-on. It depends on the underlying SSO technology. In most cases today you have web based SSO deployments which rely on a cookie. In this case, you don't need to connect the token at all - all you have to do is login once and the browser will take care of rest. As Brian noted in the following e-mail, if an attacker can put a keylogger on your machine, he can certainly get the cookie as well and use it. > The only additional attack factor this issue creates is attacker > can get _physical_ access to console with user's credentials _any > time_ while user is logged in, while in case token can not be red > (e.g. it's not plugged to USB) he can only access console short after > user logs in to compromised host (while token is not changed). No - the OTP can be used only once, so even if you manage to get both the PIN/password and the OTP (remember, you need both to login) you can't use that because the RSA authentication manager (the server side of the whole process) marked that OTP as used. In this case an attacker can only try to brute force the OTP (after all, it's only 6 digits), but RSA has excellent measures against brute force attacks (basically, after a certain, configurable, number of unsuccessful logins the token is disabled; what's even better is that it tracks number of incorrect OTPs with correct PINs - if that is higher than a certain number, it puts the token into "2nd OTP mode" which means you have to guess 2 OTPs in a row). I think these tokens offer excellent means for authentication. Sure, they are not a silver bullet and don't solve all your security problems (nothing does), but if you have users who have to login from a lot of insecure places (airport lounges, cyber caffes) and are afraid of keyloggers stealing passwords, two factor authentication really helps. Cheers, Bojan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On 9/9/06, 3APA3A <[EMAIL PROTECTED]> wrote: Dear Hadmut Danisch, 2-factor authentication is not a way to protect against malware. Well, it protects - the authentication process. SecurID authentication supports single sign-on technology. As a weak side of this technology, it means, if single account on any network host is compromised, this account is compromised in whole network, because any resource can be accessed from compromised host. An ability to read current key from device is required to support single sign-on. It depends on the underlying SSO technology. In most cases today you have web based SSO deployments which rely on a cookie. In this case, you don't need to connect the token at all - all you have to do is login once and the browser will take care of rest. As Brian noted in the following e-mail, if an attacker can put a keylogger on your machine, he can certainly get the cookie as well and use it. The only additional attack factor this issue creates is attacker can get _physical_ access to console with user's credentials _any time_ while user is logged in, while in case token can not be red (e.g. it's not plugged to USB) he can only access console short after user logs in to compromised host (while token is not changed). No - the OTP can be used only once, so even if you manage to get both the PIN/password and the OTP (remember, you need both to login) you can't use that because the RSA authentication manager (the server side of the whole process) marked that OTP as used. In this case an attacker can only try to brute force the OTP (after all, it's only 6 digits), but RSA has excellent measures against brute force attacks (basically, after a certain, configurable, number of unsuccessful logins the token is disabled; what's even better is that it tracks number of incorrect OTPs with correct PINs - if that is higher than a certain number, it puts the token into "2nd OTP mode" which means you have to guess 2 OTPs in a row). I think these tokens offer excellent means for authentication. Sure, they are not a silver bullet and don't solve all your security problems (nothing does), but if you have users who have to login from a lot of insecure places (airport lounges, cyber caffes) and are afraid of keyloggers stealing passwords, two factor authentication really helps. Cheers, Bojan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On 9/9/06, 3APA3A <[EMAIL PROTECTED]> wrote: The only additional attack factor this issue creates is attacker can get _physical_ access to console with user's credentials _any time_ while user is logged in, while in case token can not be red (e.g. it's not plugged to USB) he can only access console short after user logs in to compromised host (while token is not changed). For web SSO in particular, accessing the token once is nearly as good as accessing it constantly. The token will be used for the initial authentication, but normally a cookie will be used for session tracking. An attacker who can sniff the token code can certainly steal the cookie as well. Two-factor auth cannot be said to make accessing the network from a compromised PC "safe". That does not make two-factor auth useless. With plain passwords, once the attacker has the password, they can access the network at will. With two-factor auth, they can access the network for a much more limited time span. Regards, Brian ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
Dear Hadmut Danisch, 2-factor authentication is not a way to protect against malware. SecurID authentication supports single sign-on technology. As a weak side of this technology, it means, if single account on any network host is compromised, this account is compromised in whole network, because any resource can be accessed from compromised host. An ability to read current key from device is required to support single sign-on. The only additional attack factor this issue creates is attacker can get _physical_ access to console with user's credentials _any time_ while user is logged in, while in case token can not be red (e.g. it's not plugged to USB) he can only access console short after user logs in to compromised host (while token is not changed). --Thursday, September 7, 2006, 10:49:52 PM, you wrote to full-disclosure@lists.grok.org.uk: HD> However, if the Token Code can be read over the USB bus, this HD> assumption does not hold. A single attack on the PC where the token is HD> plugged in would compromise both the PIN (e.g. with a keylogger) and HD> the token itself (e.g. writing a daemon which continuously polls the HD> token and forwards the token in real time to a remote attacker. -- ~/ZARAZA http://www.security.nnov.ru/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On 9/8/06, Hadmut Danisch <[EMAIL PROTECTED]> wrote: Hi, I recently tested an RSA SecurID SID800 Token http://www.rsasecurity.com/products/securid/datasheets/SID800_DS_0205.pdf The token is bundled with some windows software designed to make user's life easier. Interestingly, this software provides a function which directly copies the current token code into the cut-and-paste buffer, when the token is plugged in into USB. This is weak by design. The security of these tokens is based on what RSA calls "two-factor user authentication": It takes both a secret (PIN) and the time-dependend Token-Code to authenticate. The security of the Token-Code depends on the assumption that the token is resistant against malware or intruders on the computer used for communication (web browser, VPN client,...). I didn't play with the SID800 token (just have the SID700 token which is practically the same, but doesn't have USB capabilities). I'm not sure how difficult or easy it is to poll the token code off the device. It would make sense to me that RSA thought of this and that the communication between the polling application (the RSA Authenticator Utility) and the token itself is encrypted (for example, using some public/private encryption). If the RSA Authentication Utility requires unique identification about the token used (it's serial number, which is related to its seed) then it would be very difficult to write another polling application for attack you described. Impossible not, but difficult and it had to be very targeted because if the same public/private encryption I mentioned was used, an attacker would have to extract the public key from the application in order to decrypt the token. The easiest way to check what's going on is to use some of the USB snooping tools which enable you to see what's going on to/from the USB device - if you still have the token you can try doing this. This all being said - the token can be used in an offline mode as well, if the user want's a higher level of security, same as SID700. There will be no "advanced" features and the user will have to type in the OTP manually, but at least he can be sure that nothing can compromise the token. Cheers, Bojan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
You might want to look at: http://www.networksecurityarchive.org/html/Web-App-Sec/2005-02/msg00089.html for a discussion of this issue and the soft token issue. -- ---Matthew *** REPLY SEPARATOR *** On 9/7/2006 at 8:49 PM [EMAIL PROTECTED] wrote: >Hi, > >I recently tested an RSA SecurID SID800 Token >http://www.rsasecurity.com/products/securid/datasheets/SID800_DS_0205.pdf > > >The token is bundled with some windows software designed to make >user's life easier. Interestingly, this software provides a function >which directly copies the current token code into the cut-and-paste >buffer, when the token is plugged in into USB. This is weak by design. > >The security of these tokens is based on what RSA calls "two-factor >user authentication": It takes both a secret (PIN) and the >time-dependend Token-Code to authenticate. The security of the >Token-Code depends on the assumption that the token is resistant >against malware or intruders on the computer used for communication >(web browser, VPN client,...). > >However, if the Token Code can be read over the USB bus, this >assumption does not hold. A single attack on the PC where the token is >plugged in would compromise both the PIN (e.g. with a keylogger) and >the token itself (e.g. writing a daemon which continuously polls the >token and forwards the token in real time to a remote attacker. > >Ironically this could make an attack even easier: If some malware >simultaneously monitors the token and the keyboard, it is much easier >to detect that the keystrokes are actually related to some login >procedure: > >Whenever the 6-digit token code appears in the keyboard or >cut-and-paste input stream, you can be pretty sure that in a sliding >window of about the last 100-200 keystrokes both the PIN and the >address of the server to login is contained. Makes it really easy to >automatically detect secrets in the input stream. > >Thus, two different authentication methods are together weaker than >each single one. > >regards >Hadmut ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
