SecurID: No Need for the Seed!

Monday, May 30, 2011

Pascal Longpre


The recent news alleging that the RSA SecurID seed formula compromise was responsible for the breach at Lockheed Martin has left me amazed, to say the least.

Falsely considered by many as a "something you have" factor of authentication, the SecurID token falls short of delivering the level of confidence expected from such a device.

Back in 2000, I wrote an article on BugTraq, along with proof of concept code, describing a very simple, but yet very effective attack against SecurID authenticated services. 

The attack scenario unfolds as follows:

First, a Trojan must be installed on a victim's computer accessing the service. I will not go in details on how this can be done. You can watch this short video for a basic course on how to hack a company in 5 easy steps. Typically, the larger the target company is, the most likely a hacker will be able to get in through social engineering.

Second, the Trojan will use a technique I call "keystroke grabbing and replaying". The Trojan simply monitors the user interface activity, waiting for the user to be asked to authenticate on a targeted service like a VPN corporate access.

At the other end of the planet, the attacker who has installed the target's VPN client and configuration patiently waits for the user to authenticate. When the user begins to enter its 6 digit SecurID password, the Trojan captures the characters entered and immediately sends them through SSL to the attacker's machine where a network listener receives the keystrokes and automatically feeds them to the VPN login prompt.

After the 6th digit is captured and before the user has time to blink, the Trojan either hits the cancel button or crashes the victim's machine while the attacker's computer receives the last keystroke and automatically issues the "Enter" command. The attacker is then granted access to the network while the user is clueless about what just happened. 

In order to pull such an attack, you don't need to hack the RSA network and steal their secret seed formula; you only need very basic programming skills and a few hours of work. This technique has already been used by banking Trojans.

I think that "What you have" password generation tokens used as a second factor of authentication are basically flawed. The mere fact that the generated password can be handed over the phone, shoulder surfed or put in front of a live webcam tells a lot about the different ways they can be abused remotely.

By comparison, smartcards offer a real second factor of authentication. You need to have them on hand in order to authenticate and while some attacks are possible on the middleware, they are far more complex to achieve.

Smartcards have been protecting European banking transactions for the last 15-20 years and are still holding strong against attacks when compared to their mag stripe counterparts.

In the end, and this holds for any authentication mechanism we use, be it passwords, phone factors, smartcards or biometrics, security is 100% dependent on the trust we have in the device used to access the remote service.

The current trend to cloud-enable critical business functions and to make them available from any device has put aside the requirement for real strong authentication in favor of ease of use and cost reduction.

Until this is addressed properly and until we can trust the devices we use to be free from malware, we can only expect to see the current wave of corporate network hacking grow bigger and bigger.

Cross-posted from Silicium Security 

Possibly Related Articles:
Network Access Control
Information Security
RSA Authentication Trojans Hacking Smart Cards SecurID
Post Rating I Like this!
Matt W Im not sure id describe smart cards as "a real second factor". In fact theres a confusion in your article between online authentication and local. Mag strips and smart cards are designed for local authentication but the same or similar online MITM attacks can be carried out against smartcard online authentication if the local device/terminal is compromised. The problem is there is no mutual authentication at that point, the user cant trust any information on the terminal display and theres no transaction specific information to confirm exactly what the user is authenticating which cant be intercepted. For local authentication where the terminal is trusted (train station, ATM) smartcards are convenient and relatively secure for now, for online authentication Id recommend the passwindow method which displays transaction specific information (mutual authentication)to the user as well as the OTP to prevent MITM. Some might recommend the transaction signing electronic tokens however because the onus is on the user to enter the transaction information the MITM attack is modified as we saw with KBC and Dexia in Belgium last year to coach the user through a fraudulent authentication.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.