RSA SecurID Authentication Security: Detecting and Foiling Break-In Attempts
UPDATE (Apr 3): An RSA representative has passed along a link to the best practices that customers should follow in order to secure their SecurID installations. This guidance is now publicly available here.
In the wake of the recent RSA SecurID breach, it is important for affected organizations to be able to detect and prevent possible break-in attempts against their authentication systems. RSA has so far failed to openly disclose the details of the breach. This is unfortunate, since it makes effective mitigation and response more difficult for customers. However, given that it is very likely that the so-called “token seed records” have been compromised, the following are some steps organizations can take to detect and defend against possible exploitation attempts.
Step 1: Instruct users to protect their accounts, token serial numbers and PINs/passwords and immediately report any attempts to elicit this information from them.
Step 2: Implement a strong out-of-band authentication process for users calling help desk to request PIN/password resets.
Step 3: Configure adequate PIN/password strength and account lockout policies on the Authentication Manager server.
Step 4: Configure the Authentication Manager servers to forward their audit logs to a central syslog host or SIEM appliance that supports parsing and alerting on syslog messages (see bottom of this article for instructions).
Step 5: On the syslog server or SIEM appliance, set up custom parsing rules and alerting scripts to notify administrators and security teams of the tell-tale signs of malicious activity described below.
NOTE: If your SIEM solution cannot be configured to parse, report and alert on the syslog messages described here, I strongly urge you to reevaluate your SIEM strategy.
SIGNS TO WATCH FOR
- The most obvious indicator of an attack is a sharp increase in the number of failed login attempts and account lockouts. This type of activity points to a very clumsy and unsophisticated attacker, perhaps using an automated tool to try to enumerate accounts and PINs. It is more a nuisance than a real threat, since a policy of locking out an account after a reasonable number of invalid login attempts renders this mode of attack largely ineffective.
- A more sophisticated attacker will obtain a list of valid account names before launching the attack (this can be approached via standard social engineering and network reconnaissance methods). If we assume that the attacker is in possession of a list of valid accounts, and the ability to leverage a database of stolen token seed records, their next objective will be to tie individual accounts to their corresponding token seed records. Each token seed record can be mapped to a user account via a token serial number. This is again information that an attacker would obtain most effectively via social engineering or other out-of-band methods. It is therefore crucial to instruct users to protect their token serial numbers as if they were passwords and report any attempts to elicit this information from them.
- Supposing that a patient and sophisticated adversary successfully obtained all the required preliminary information (a list of valid accounts with corresponding token seed records), he is now fully equipped to launch a direct attack. His objective will be to defeat the final layer of security: the user’s PIN or password. This is typically much weaker in a two-factor system like SecurID than it would be in a password-only authentication system. Since a token-based login process is already quite cumbersome, most users are likely to choose the simplest and shortest PIN that is permitted by policy, with a 4-digit numeric PIN being typical.
- In an effort to be as stealthy as possible and avoid causing noisy account lockouts, the attacker will patiently try a very low-volume series of login attempts, giving enough time between successive attempts for the invalid login counter to reset itself. Alternatively, the attacker will again resort to social engineering methods such as calling the help desk to request a reset of the PIN/password (this mode of attack must be defended against by ensuring that the out-of-band authentication of callers to help desk is sufficiently strong). The audit log records PIN resets, and a report of such events should be reviewed and verified with account owners on a periodic basis. This at least gives a fighting chance of detecting accounts which have been compromised through this technique.
- Having successfully cleared all the obstacles so far, there is one final hurdle the attacker must overcome: The determination of clock drift between the RSA token’s clock and the Authentication Manager server’s clock. Since the two clocks are never perfectly in sync, it is very likely that the 6-digit code displayed on the token will differ from that calculated by the authentication server based on its local clock time. The RSA protocol compensates for this by asking the user for the next code displayed on the token (to identify the exact spot in the tokencode sequence that the token is currently at), calculates the delta between the two clocks and resynchronizes itself to match the token’s clock. An attacker who is generating tokencodes by leveraging stolen seed records is likely to trigger this mechanism at least once per compromised account. Such ‘next tokencode’ events are recorded in the audit log and are another indicator of possible malicious activity.
Here is what an account lockout event looks like in the audit log (all on one unbroken line):
Here is what a successful PIN reset looks like in the audit log (all on one unbroken line):
Here is what a ‘next tokencode’ event looks like in the audit log (all on one unbroken line):
- Track and investigate attempts to elicit sensitive information (PINs, serial numbers, etc.) from users.
- Treat help desk calls for PIN/password resets with caution and use strong out-of-band processes to verify the caller’s identity.
- Track and verify PIN/password reset events in the audit log.
- Establish a baseline for the typical volume of failed login attempts and account lockouts. Review failed login and account lockout reports on a daily basis and investigate any significant deviations from the norm.
- Look for repeated, regular sequences of failed login attempts against individual accounts in the audit trail.
- Look for ‘next tokencode’ events in the audit trail and verify with the account owners whether they represent legitimate logins. Tokens with unreliable clocks which routinely generate ‘next tokencode’ events due to clock drift should be replaced.
HOW TO FORWARD AUTHENTICATION MANAGER AUDIT LOGS TO A SYSLOG HOST
To export Authentication Manager audit logs to an external syslog host, perform the following two steps. In the instructions, replace <syslog-ip> with the IP address of the syslog host. The instructions assume that Authentication Manager 7.1 is running on a Linux server or RSA SecurID 3.0 appliance.
- Edit the file ‘/usr/local/RSASecurity/RSAAuthenticationManager/utils/resources/ims.properties’ and add the following entries:
ims.logging.audit.admin.syslog_host = <syslog-ip>
ims.logging.audit.admin.use_os_logger = true
ims.logging.audit.runtime.syslog_host = <syslog-ip>
ims.logging.audit.runtime.use_os_logger = true
ims.logging.system.syslog_host = <syslog-ip>
ims.logging.system.use_os_logger = true
Edit the file ‘/etc/syslog.conf’ and add the following entry:
Restart the syslog service.