Tip

Secure tokens: Preventing two-factor token authentication exploits

The recent RSA breach is just another in the quickly lengthening list of high-profile companies suffering from serious security incidents. RSA reported

    Requires Free Membership to View

that what it called an advanced persistent threat (APT) was able to compromise some of its systems. While RSA was not breached by a vulnerability in SecurID, its token authentication product, RSA reported data about SecurID was stolen, which some have speculated may increase the likelihood of future attacks against SecurID.

This tip will discuss the top threats to token-based authentication, including the attacks security pros are most likely to see, and how to make sure tokens and other authentication methods are protected against these specific attacks.

RSA incident and recommendations
The RSA attack was reported to have started with a spear phishing email containing a malicious Excel file attachment with an embedded Adobe Flash zero-day exploit. This spear phishing email was used to compromise RSA’s security and install a remote administration tool.

RSA reported SecurID was affected, which could mean a number of things. The most integral part of the SecurID system is the token itself: The token comes either as hardware or software with a serial number, paired with a seed file imported on the server when new tokens are set up. Some have speculated that attackers stole data detailing which serial numbers correspond to which seed files. The attack could have also exposed the source code of the system, allowing the attacker to find vulnerabilities in the server software to attack later. RSA recommends using a password or PIN in combination with the SecurID token code, and RSA released a list of required actions for its SecurID customers in response to the attack.

Top threats to token-based authentication
Token-based authentication, also known as two-factor authentication, typically uses hardware devices in combination with a username and PIN/password. The hardware devices can be physical one-time password (OTP) tokens, OTP software tokens installed on mobile devices, grid cards, USB devices, scratch cards, SMS or mobile authenticators, among many others. All of these products have similar vulnerabilities: An attacker could attack the token infrastructure, the token vendor, the token itself or the client. An attacker targeting the token infrastructure could try to exploit the authentication server or protocol to breach the security of the system.

The RSA attack is an example of an attacker targeting the token vendor to compromise the security of the authentication system as a whole. Attacking tokens, specifically smartcards, has been done using differential power analysis. The Zeus Trojan is famous for attacking the client, even when tokens are in use.  The free tool, Cain and Abel, even includes functionality for generating the token code if the serial number and the seed file are imported, as long as the time is synched.

The most common attacks security pros may see are not surprising: Clients are most often attacked, since they and their users are still, generally, the weakest link in an enterprise’s environment. Thus, it's important to prevent malware from stealing the token as it is entered on the client. Some USB tokens include functionality for reading the token directly and inserting it into Web forms for authentication. This might protect against some malware, but malware could still intercept the Web form submission to capture the token. One of the benefits of one-time passwords is, as the name suggests, they only work once and/or for a limited time period. If the seed files were compromised in the RSA attack, phishers could potentially use the seed, along with information phished from the rest of your environment to attack your systems. Thus, making sure employees are aware of the potential dangers from phishing is essential.

Enterprise defense strategies
Security pros should take into account these threats when considering which kind of authentication to implement or how to harden existing implementations. You can defend a token infrastructure by limiting network access or firewalling the infrastructure off so only necessary access is allowed to the system. Should an attacker successfully exploit your token vendor, you can protect your enterprise by openly communicating with the vendor to understand what other vulnerabilities could be exploited as a result of the breach. In addition, regularly review logs to determine if anything suspicious is happening with authentication, and implement the token vendor’s software in a way that it is easy to switch to a new vendor if the existing system doesn’t meet your level of assurance.

To defend against attacks on the token itself, invest in secure tokens with strong tamper-resistant features such as tamper-evident cases and software/hardware designed to resist alteration, educate users about keeping their tokens physically secure, and follow RSA’s recommendations issued after the incident. Also, check out other advice on defending the client against attack.

Conclusion
Since minimal information has been released publically by RSA about its recent APT breach, enterprises have had to guess and make plans to ensure their SecurID systems are securely implemented and maintained. Enterprises, though, should have already been following the recommendations made by RSA as a result of this incident, since many of the recommendations are standard best security practices. For targeted attacks on high-security environments, the RSA attack may weaken the security of the enterprise, but, for most enterprises, the incident should have minimal impact.  

About the author:
Nick Lewis (CISSP, GCWN) is an information security analyst for a large Public Midwest University responsible for the risk management program and also supports its technical PCI compliance program. Nick received his Master of Science in Information Assurance from Norwich University in 2005 and Telecommunications from Michigan State University in 2002. Prior to joining his current organization in 2009, Nick worked at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University. He also answers your information security threat questions.

This was first published in July 2011

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.