Researchers Can Generate RSA SecurID Random Numbers Flawlessly
Fluffeh writes "A researcher has found and published a way to tune into an RSA SecurID Token. Once a few easy steps are followed, anyone can generate the exact numbers shown on the token. The method relies on finding the seed that is used to generate the numbers in a way that seems random. Once it is known, it can be used to generate the exact numbers displayed on the targeted Token. The technique, described on Thursday by a senior security analyst at a firm called SensePost, has important implications for the safekeeping of the tokens. An estimated 40 million people use these to access confidential data belonging to government agencies, military contractors, and corporations. Scrutiny of the widely used two-factor authentication system has grown since last year, when RSA revealed that intruders on its networks stole sensitive SecurID information that could be used to reduce its security. Defense contractor Lockheed Martin later confirmed that a separate attack on its systems was aided by the theft of the RSA data."
"When the above has been performed, you should have successfully cloned the victim's software token and if they run the SecurID software token program on your computer, it will generate the exact same random numbers that are displayed on the victim's token," Fouladi wrote.
Good job leaving the word software out of the summary there in the /. lead in.
This seems like an obvious answer to me. Without any remote communication how did they think the tokens and the system came up with the same key? Magic?
Now I don't have to worry about forgetting to bring home the RSA token for my company's VPN. I can just leave it under the keyboard with all my password post-its!
:wq
these aren't the secureIDs you're looking for
The promise of randomness is always false. Cryptography that is bidirectional -- as opposed to one-time pads -- inherently uses pseudo-random methods. Since it's not actually random, it can be cracked.
Expect to go through this every few years until you are dead.
This should be no surprise. The software token in a smartphone or a computer MUST have the seed stored somewhere in the device that the device can read and access.
Which means if an attacker can control the victim's computer, of course the software-based token has no security, only obscurity and hastle.
This applies to software tokens only.
and they aren't doing it by reverse engineering RSA software, but rather exploiting windows API's.
DNRTF
If it's about figuring out the algorythm used by their SecureID fobs, this is old news. At the last job during a PCI audit, the auditor was showing off the pen test tools he downloaded for free off the net. I think it was Cain and Able had a tool that did this; as long as you knew the serial numbers on the back (a brief amount of physical access or social engineering) it would report back the six digit number the fob was displaying. Obviously you still need the other parts of the credentials, but the algorithm used by the fob was already broken.
Score a major government security contract?
Never understood why the hell companies like Lockheed score multi billion dollar deals that they are thoroughly unsuited for.
Key point from TFA "was easy for people with control over the machines to deduce and copy"
If anything is running on a computer it is possible to probe it and figure out what it is doing and duplicate it if you have complete control over it. It does not much matter what it is how fancy an algorithm is being used or how it is configured.
If you want something to stay secret then it needs to self destruct when someone tries to fuck with it or anything it depends on to work.
Reminds me of the outraged cries of those 1337 few over the years who independantly discovered operating system x must be defective since you can bypass password authentication or access controls by mounting an unencrypted hard disk in a different computer. No shit.
I have never understood why software tokens have been allowed to be considered a "factor" in multi factor authentication. Particulary when it is stored on the same laptop/computer that the user is utilizing to connect to the secure resource. Doesn't it make more sense to have each factor seperated by an air gap or alternate communiation channel? That way if the system where the users is typing a password is compromised only the password is compromissed with possibly the ping from the token which would be a one time key. Even if the one time key and the password are comprimised the attacker basicly has to use it at the same time.
If this is what "security researchers" get paid to do, sit around and state the obvious, I am in the wrong career field.
sudo make me a sandwich
So.. if this all comes down to possessing magical "tokens", can I take the RSA keychain thingy out of my pocket, open it with a screwdriver, and remove the magical token and use it to take over the world?
This is, in fact, how one-time passwords work. Once upon a time, RSA strengthened the security of their tokens through algorithm obscurity. The only news is that the algorithm cannot be considered obscure any longer. And this news is old. The fact that some random "researcher" learned enough of a programming language to create a program that takes a number and uses it as a random seed is not something that anyone (aside from said "researcher", and probably his proud parents) should care about.
I'm glad I use event-based One Time Password tokens, and not time-based tokens like this (from a different vendor than RSA, by the way).
I read TFA.. the algorithm is not broken and the seed isn't deducible from the output; all they've done is read the seed out of software auth running on a general purpose computing device.
This has always been possible in theory -- obviously, the computer software has to generate the output so it must have the seed in an accessible form; probably under several layers of obfuscation and encryption (which ultimately adds no security, as the software still has to be able to wade through it to get to the seed). It's very similar in concept to someone being able to obtain your PGP or SSH private keys if they have local access to your system.
There is no risk to people with a hardware auth device, unless the server is compromised (in which case this form of authentication is useless anyway).
It could theoretically be a custom ASIC, in which case it's not really a processor running a program as much as a physical embodiment of the program.
- --> Joshthegod p> MrOsama \> Cosmo %> CyberZeist /> s3rver.exe > ---
"Fuck With The Best , Die Like The Rest"
#hack #UGNazihack #UGNazi #Cocksec #WHMCS
Whmcs Hacked by UGNazi:
Complete Database:
Whmcs.com Database Release http://whmcs.ugnazi.com/whmcs/whmcs%20dbs.rar , Password is UGNazi. #UGNazi
Complete Root Files:
Whmcs.com Website Files Release http://whmcs.ugnazi.com/whmcs/Whmcs%20Root%20Files.rar , Password is UGNazi. #UGNazi
Complete Cpanel Files:
Whmcs.com Whole Cpanel Release http://whmcs.ugnazi.com/whmcs/All%20Whmcs%20Files%20Including%20All%20Cpanel%20Files.rar , Password is UGNazi. #UGNazi
Passwords for all files are:
UGNazi
Wow, this is one of the worst summaries I've seen in the last 2 days on /.
Censorship is obscene. Patriotism is bigotry. Faith is a vice. Slashdot 2.0 sucks.
OTP/HOTP is the same in software and hardware; to provide (backward) compatibility. Hacking a hardware key is a lot hacker, because it requires more sophisticated materials to read but still, hardware is nothing more but a chip running software. Once the software OTP is hacked, it would drag along the hardware variants of it.
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
But, of course, you can predict SecurID if you know the seed. That's the whole point of how SecurID and all other token security systems work.
It's like saying that a one-time pad is broken if you have the predetermined list of keys. Of course, that's the whole point.
Kriston