Author:Jeff Jarmoc, Dell SecureWorks' Counter Threat Unit^SM Intelligence Services
Date: March 17, 2011

Executive summary

RSA is the security division of EMC software, best known for the popular SecurID two-factor authentication tokens used in high-security environments. RSA announced that a cyberattack resulted in the compromise and disclosure of information "specifically related to RSA's SecurID two-factor authentication products". The full extent of the breach remains publicly unknown. RSA states that "this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack." Organizations that make use of SecurID should be alert for attempts at circumventing their authentication infrastructure, though no specific attacks are known to be occurring at the time of this publication.

RSA's breach disclosure

On March 17, 2011, RSA announced ^[1] that a cyberattack on its systems was successful and resulted in the compromise and disclosure of information "specifically related to RSA's SecurID two-factor authentication products". While the full extent of the breach remains publicly undisclosed, RSA states that "this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack."

In a filing with the Securities and Exchange Commission (SEC) ^[2], EMC officially disclosed the breach to investors and regulators. EMC indicated it "does not believe that the matter described in the letter and note will have a material impact on its financial results." The filing was accompanied by a copy of their initial announcement, as well as a SecurCare Online Note ^[3], which was made available to their customers. This SecurCare note provides little additional detail, but advises actions that customers should take to protect their infrastructure. These actions fall into the category of best practices, and do not address new risks to infrastructure supporting a SecurID deployment.

Background on SecurID operation

As shown in Figure 1, the SecurID system can be implemented with either a physical hardware token (typically a key-fob or wallet sized card), or a software based token (with implementations for desktop and mobile devices). In either case, the authentication system relies on these tokens to produce a time-synchronized one-time password (OTP) that is unique to a given token and only valid for a brief time.

Figure 1. SecurID system implementations.

This function is performed through the use of a proprietary algorithm that uses the current time and an embedded device-specific 128-bit seed to produce a rotating code known as a 'tokencode'. A user authenticates by combining this tokencode with a PIN (Personal Identification Number) to produce a one-time password that is submitted to the server. PINs are not required in all implementations. PINs are created by the user on the first attempted use of a token after deployment or re-assignment. For this reason, PINs may not always be required.

Figure 2. SecurID authentication process.

A back-end server (known as ACE/Server) holds these same seeds and algorithm, and can thus perform the same calculation to verify a password was generated from the current tokencode. This process is intended to verify that the client possesses a token, but more accurately indicates that they have knowledge of the appropriate seed and RSA's algorithm. The huge number of possible seeds and constantly changing nature of the tokencodes effectively thwart password guessing and interception attacks. It's generally accepted in cryptography that "If the cryptographic algorithm must remain secret in order for the system to be secure, then the system is less secure."^[6] This axiom is commonly known as Kerckhoffs's Principle. ^[7] The RSA SecurID algorithm is proprietary, but is known to many RSA partners. Efforts have also been made to reverse engineer the algorithm and perform an analysis of the underlying security. ^{[4] [5]} While not fully public, exposure of the algorithm is unlikely to affect overall system integrity.

However, seed secrecy is critical. An exposure of the seed to a third party may allow duplication of tokencodes, and by extension allow the guessing of PINs and one-time passwords.

Impact of the Breach on RSA customers

Due to RSA's public nondisclosure of specific details regarding the nature of the compromise, the impact of this breach on their customers remains largely unknown. However, based on this information and a knowledge of SecurID's operation, it's possible to establish theories as to what information may have been compromised. These theories in turn help to formulate response plans.

The compromised information may have related to one or more of the following factors, each of which would potentially impact the integrity of the SecurID system to varying degrees:

Records of seeds used in hardware or software tokens manufactured to date
Relationship of those seeds to specific token serial numbers
Relationship of seeds or token serial numbers to specific clients
Information regarding RSA's SecurID algorithm that could expose mathematical and cryptographic weaknesses
Information regarding specific implementations of the algorithm that may reveal implementation weaknesses in specific products
Source code or other information regarding ACE server that may reveal vulnerabilities

Until further information is available, the prudent course of action is to assume the worst: that SecurID seeds have been exposed, their assignment to specific RSA customers is known, and the source code of ACE server and other products has been compromised and may reveal weaknesses.

Recommended actions

With the potential impacts from the previous section in mind, the response should focus on a few key areas.

Direct attacks against an ACE server.
- Confirm current patch levels and general server hardening
- Monitor IPS/IDS logs
- Monitor server logs
Brute-Force attacks attempting to determine the specific seed used for a given account's SecurID token, as well as attacks aimed at compromising other authentication factors.
- Monitor for repeat authentication failures, both on the ACE server and on intermediate appliances and systems
- Monitor for authentication failures not followed by success both on the ACE server and on intermediate appliances and systems
Changes in source of authentication attempts.
Multiple concurrent logins for a single account.

Caution is also warranted surrounding the integrity of communication channels over which OTPs and tokencodes are submitted. Even under a conservative scenario where seeds were disclosed, but specific customer ownership was not, it may be possible to determine which seed is in use by observing a small number of submitted tokencodes. PINs can also be exposed through such observation. Considering these factors yields the following recommendations:

Ensure OTPs are only submitted over encrypted channels.
Be vigilant for phishing or impersonation schemes that may seek to capture OTPs.
Educate users' expectations as to which systems prompt for OTPs to protect against phishing and social engineering attempts.

Conclusion

Until additional information becomes available regarding the specific information that was compromised, a good deal of assumption and speculation is involved in preparing an appropriate response. However, certain information would be of interest to threat actors and fit RSA's criteria that the information could "... potentially be used to reduce the effectiveness of a current two-factor authentication implementation ..." while not facilitating "... a successful direct attack on any of our RSA SecurID customers." Monitoring for anomalies and additional intelligence may allow customers to further focus response efforts.

By focusing on the publicly available information and factors discussed in this analysis, customers can implement a specific response to decrease the likelihood of exposure via the SecurID authentication compromise.