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