Important Statement from RSA Regarding RSA SecurID Software Token Provisioning Best Practices

[#1]

Summary

RSA Engineering reviewed a report from Fox-IT titled “Operation Wocao: Shining a light on one of China’s hidden hacking groups”, dated Dec 17, 2019.

RSA considers the scenario presented by the report to be against recommended deployment practices rather than a security vulnerability within the product. From the scenario in the report, we believe the software token compromise described has two key requirements.

• The adversary must have access to a software token XML file.
• The file must have been created without a password.

The distribution of unprotected software token XML files (i.e. files created without a password) is the root-cause of the issue reported by Fox-IT.  RSA recommends that customers follow RSA SecurID^® Software Token Security Best Practices to minimize risks during token provisioning.

Risk Mitigation

The following list outlines mechanisms that could have reduced or mitigated the risk in this case:

• Dynamic seed provisioning methods, such as CT-KIP, provide a more secure mechanism to initialize a user’s software token. There is no risk that the end-user mishandles the software token initialization data (XML file).
• Distribution of software tokens via SDTID (XML) format, by default, require a file password. The password should be provided to the user via some other channel. The software token file password provides an additional layer of protection should the mechanism used to transmit the software token XML file be compromised. The file password should not be provided within the email to which the software token XML is attached.
• If a software token XML file is distributed manually or as an email attachment, users should be instructed to remove/destroy any local copies of XML file after it is imported into the token. The most recent software token removes the local XML file after successful import.
• A temporary PIN should be assigned to the token. This temporary or transport PIN is provided to the end-user and used for the first authentication (during which the system prompts the end-user to set their PIN).
• These factors can be combined and provided by different personnel to increase security around provisioning new users and associated credentials. For example, one administrator sets and provides the temporary PIN while another administrator provides the file password.
• A software token offers a trade-off between security and convenience but is not without some level of risk. Other tokens, such as hardware tokens, reduce risk by eliminating any end-user interaction in the seed management process.

RSA Software Token “Device Binding ID”

The software token “Device Binding ID” provides a mechanism to help ensure the token XML file is imported into the intended device. It is not a security control and should not be considered as such. If the software token application or runtime environment is altered, it may be possible for an adversary, in possession of an unprotected software token XML file, to bypass Device Binding ID protection mechanisms. Dynamic seeding mechanisms or utilizing a software token XML file password (sent out-of-band) would have eliminated this specific threat vector.

Personal Identification Number

The report does not mention the user’s Personal Identification Number (PIN). The report presents a hypothetical scenario through which the adversary may have obtained the software token’s seed (and therefore the ability to generate a tokencode). It fails to mention that the tokencode is useless without the user’s PIN. Appropriate lockout policies make access to a single factor (i.e. the tokencode) less advantageous.

Questions and Answers

Q: How did the adversary obtain the software token XML file?

The details of how this was accomplished were not provided in the report. While no details were provided, it is assumed the file was retrieved from the user’s local system or from an email sent during token distribution. A software token XML file created during software token distribution contains the token seed. It should be password-protected and handled as would any sensitive information. Once imported, software token XML files should be removed from the local system and any related emails (with the software token XML as an attachment) should be removed. This is especially critical if software tokens are distributed without a password.

Q: How can I determine if I am already a victim of this attack?

There is no way to determine if you have already been a victim of this attack. The primary risk resulted from distributing software token XML files without a password. If your organization sends unprotected software token XML files as email attachments, you should assume your organization is vulnerable to this attack.

If there are concerns, authentication failures and PIN changes should be carefully reviewed by administrative personnel. This attack does not allow the adversary to authenticate unless they are also in possession of the user’s PIN.

Q: What can I do to make sure I am not vulnerable to this attack?

Per best practices, we recommend distributing software tokens via CT-KIP (dynamic seeding) or use other seeding mechanisms such as scanning a CT-KIP “QR-Code” with a software token from the self-service console. CT-KIP uses a one-time use “Activation Code”. During the redemption of the Activation Code, a new token seed is negotiated, and the Activation Code is no longer valid for token initialization.

If Software token XML files are distributed via email, the administrator must set a strong password for the file and provide the password to the end-user through an alternate mechanism. If unprotected software tokens (i.e., token files without passwords) were previously distributed as email attachments, mail system administrators may want to look at finding and removing any Software Token XML files attached to such email.

There may be other business risks associated with processes around provisioning new users/employees or any situation where a token without a PIN is provided to an end-user. This provisioning risk can be mitigated by the assignment of a temporary PIN (changed by the user upon first use).

Any tokens distributed via email but never used to authenticate should be disabled immediately and redistributed in a more secure manner.

Q: Should I redistribute or replace all my software tokens?

To ensure that software token seeds cannot be retrieved from backup XML files and copies, you should consider redistributing or replacing any software tokens that were distributed as XML files (i.e. email attachments) without a password. The risk is higher in the provisioning process before the “real user” has imported the XML file and set the token PIN. Once the real end-user has set the PIN, the XML file loses some of its value. Once a token PIN is set, attempts to guess the PIN are generally prevented by lockout policies and appear in authentication audit logs, etc.

Q: What changes are being made by RSA to the Device Binding ID and Software Tokens?

The alleged compromise involved altering the software token application to permit import. The software token application has mechanisms to be resistant to tampering and debugging. RSA Engineering routinely keeps up-to-date with the security industry best practices during software application development and applies them to our products as deemed necessary to protect our customers.

Please contact your RSA Sales Representative should you desire RSA Professional Services to review and/or assist with your RSA SecurID deployment.

Additional Information

For additional information on token provisioning best practices, please refer to the article entitled https://community.rsa.com/community/products/securid/blog/2017/08/04/credential-provisioning-challenges-how-can-i-securely-provide-credentials-to-end-users and the RSA SecurID Software Token Security Best Practices Guide for RSA Authentication Manager 8.x.

EOPS Policy

RSA has a defined End of Primary Support policy associated with all major versions. Please refer to the Product Version Life Cycle for additional details.