Researchers Can Generate RSA SecurID Random Numbers Flawlessly 98
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."
Not exactly... (Score:5, Informative)
"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.
Re:Not exactly... (Score:5, Insightful)
Exactly. They're cloning the software token, not breaking the scheme that the hardware uses.
Re:Not exactly... (Score:5, Informative)
Honestly, what makes me nervous about this is not the fact that, shocking!, software can be reverse engineered; but that RSA seems to mix a disconcerting amount of laziness and hubris in with their competent math.
As best we currently know, it is Not Possible to deduce subsequent token outputs merely given access to previous token outputs. However, it is trivial to do so given access to the seed value. And yet, RSA's last big security fuckup was because they weren't purging seed values for tokens sold to customers. And now it turns out that their software 'tokens' retain their seed values in local storage forever.
Way to let a desire for convenience drag defeat from the jaws of victory, guys.
Re:Not exactly... (Score:5, Interesting)
It's my understanding of the system (from dealing with one years ago)... the server can recover the seed used by a hardware token given it's serial number, and two sequential tokens. Perhaps the serial number is the "seed" and it's figuring out the tokens clock. However, it's perfectly clear the server can generate the same numbers as the token. The strength of the system is keyed to protecting that algorithm. Soft-tokens are a bad joke and only slightly better than a password, but are themselves based on a "password".
Re: (Score:2)
If that's true the software tokens are badly broken: their serial number is just a hash of the hostname and the User SID, both of which are easy enough to get remorety.
Re: (Score:2)
If that's true the software tokens are badly broken: their serial number is just a hash of the hostname and the User SID, both of which are easy enough to get remorety.
Nah, I'm sure it's a keyed hash. The server can do this because it has the key.
Re:Not exactly... (Score:5, Informative)
The server cannot 'recover' the seed from the serial number.
When you buy hardware tokens, you are supplied with a copy of the seeds, associated with the token serial numbers, to import into the server. The SecurID scheme is time based. What is recovered through supplying the serial number and two token-codes (combined with the existing knowledge of the seed) is the current state of the token's internal clock.
The serial number printed on the back of the token is NOT the seed. It is not (to the best of my knowledge and trust in RSA) related to the seed in any way other than the mapping held in the database of the server.
This story is purely sensationalist. The SecurID algorithm has been known for a long time, that token codes can be generated when the seed is somehow compromised is a non-issue. That a software token seed can be recovered given full access to the host is also obvious to anyone reasonably aware of the realities of cryptography.
Re: (Score:2)
That a software token seed can be recovered given full access to the host is also obvious to anyone reasonably aware of the realities of cryptography.
Shhh!! Don't let Them know that. They'll take away my Linux DVD player!!!1!
Re: (Score:2)
Add to that, even if you know the seed, you need to know the state of the clock in that token as well... not that it's hard if you have seen unencrypted token data for the token you are cloning... but as a remote attacker who only has a seed, the username and a pin and the algorythm, you still need a resonable prediction of that physical tokens clock.
This article summary should have said SOFTWARE tokens, as this is much less impressive.
Re: (Score:2)
Protecting the algorithm is pointless, it could always be reverse engineered from the server implementation which has been available for years. A program called 'cain' has had an implementation of this algorithm for quite some time.
The strength of the system is protecting the seed values, and this is dependent not only on the customer to not leak their seeds, but also on rsa to not leak everyone's seeds.
Re: (Score:2)
The algorithm has long ago been reverse engineered, i believe a program called "cain" has been able to generate token values for quite some time when given the initial seed value.
The big flaw in this system however, is that the seed values are provided by rsa and not generated locally by the customer, so if rsa gets hacked (as they did), or employs someone who can be bribed etc, the seeds leak and the whole system is compromised.
You as a customer are dependent on rsa, but you have no control over them, this
Re: (Score:2)
As best we currently know, it is Not Possible to deduce subsequent token outputs merely given access to previous token outputs. However, it is trivial to do so given access to the seed value. And yet, RSA's last big security fuckup was because they weren't purging seed values for tokens sold to customers. And now it turns out that their software 'tokens' retain their seed values in local storage forever.
With the hardware tokens, there is a class of attack that is only feasible if you have the hardware token for a long time and closely monitor the numbers it produces. Every once in a while (on average, around one third of keys will experience this once a year) it will repeat a number for two lots of 90 seconds - a vanishing differential. Knowing this vanishing differential, it then becomes computationally feasible to recover the keyfob's secret key.
This class of attack doesn't really help to break a single
Re:Not exactly... (Score:5, Informative)
They're cloning the software token, not breaking the scheme that the hardware uses.
The algorithm that the software and hardware implement is the same. What has been done here is to show that the software mechanisms in place to protect the token file under Windows can be broken, despite the claims of RSA:
This file can be viewed by any SQLite database browser, but sensitive information such as the checksum and seed values are encrypted. RSA documentation states that this database file is both encrypted and copy protected: “RSA SecurID Software Token for Windows uses the following data protection mechanisms to tie the token database to a specific computer:
* Binding the database to the computer's primary hard disk drive
* Implementing the Windows Data Protection API (DPAPI)
These mechanisms ensure that an intruder cannot move the token database to another computer and access the tokens. Even if you disable copy protection, the database is still protected by DPAPI.”
So if the RSA software token is installed on a Windows PC, and you can access that PC (remotely or physically), then you can copy the token; the result is the same as having cloned a person's hardware token.
Re: (Score:3)
Well not just remotely access, you need to remotely have administrator access, or have otherwise compromised the machine.
Which makes this a half MS and half RSA problem. If your software absolutely must run on windows, no matter how unsuitable windows is for the task, then you rely on microsoft API's and general OS features/security etc. If they don't secure their secure device API properly then there is only so much you can do, equally if they don't document how to properly use/connect to a secure device
Re: (Score:2)
the result is the same as having cloned a person's hardware token.
Sort of the same. But the difference is very important. The difference is that any RSA customer could decide (and some have probably already decided even before this) that a software system running on a networked PC is not secure enough and decide to only use the hardware tokens, which are not susceptible to cracks like this.
Re: (Score:2)
My RSA admin declined me a Blackberry software token on basis of security so I have to carry arround this key chain that says "he must work somewhere where security is important".
Re:Not exactly... (Score:5, Insightful)
Re: (Score:2)
The hardware token is not networked, and thus cannot readily by attacked and cloned without physical access (if then).
Re: (Score:2)
The keyfob number is printed on the back of them.
Re: (Score:2)
It still requires physical access. Therefore, it is still orders of magnitude safer than a software token on a networked device like a phone, laptop, etc. that can potentially be cracked from thousands of miles away.
Yes, ostensibly someone with a really high power camera lens could shoot a picture of the back from across the street while the person is using it, but even that means a targeted attack on a specific individual with a lot of prep work ahead of time. For high-profile targets, that might be a c
Re: (Score:3)
" like a phone, laptop, etc. that can potentially be cracked from thousands of miles away."
Hi this is phil from IT. Yeah we are having some problems with logins, can you read me the number off the back of your dongle? Thanks!
All hacked from thousands of miles away....
Re: (Score:2)
The serial number is just a sticker on the back of the token. If the RSA admin is that worried he just has to remove the sticker or replace it with the name of the user it is given to so that tokens can be distinguished.
Re: (Score:2)
Again, that's a targeted attack. There are lots of things that are possible when you are attacking a specific person that do not work for mass attacks such as would occur with viruses and trojans. Also, in order to do anything useful with it, you would need to know the person's account name and PIN, which means you would either have to convince the person to reveal it, watc
Re: (Score:2)
Re: (Score:2)
RSA keeps a copy of all the seeds, in a database linked to the serial numbers of the tokens...
RSA suffered a security breach during which that database was leaked...
If you can acquire that database, then having the serial number is game over.
Re: (Score:2)
^^ What he said... you need the serial number and the database that maps back to the tokens seed which most people assume is a unique private key, randomly generated and assigned to random tokens with serial numbers. The client is given the public key seed which maps back to the serial number for the tokens they purchase. The algorythm on the token generates a random secret number. The algorythm on the server is used to determine if any of the enroled tokens for that user could have generated the random sec
Re:Not exactly... (Score:4, Insightful)
The hardware versions are the ones used for the more important operations. Their seed is a lot harder to snoop. If the hardware version became fundamentally broken, an awful lot of systems and networks would suddenly be a lot weaker.
All random number sequences produced by computers are reproducible if you know the algorithm and the seed; that's in fact the whole strategy behind the RSA SecureID token - if you know the seed, you know the value fo any given point in time. It's not that they discovered random number generators are actually pseudo random number generators, it's just that they snooped a software key. Snooping a hardware key is a lot harder, and requires physical access since these aren't networked in any way. It's very misleading for the article title to sound like the hardware versions were broken when they weren't.
Same protocol (Score:2)
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.
Re: (Score:2)
hacker == harder ..
Oh boy, do I hate automatic spelling checkers ..
Re: (Score:2)
Not necessarily, it depends on how it's hacked. If it's hacked in a way that observing values from the pad allow you to guess the secret on which the pad is based, then yes, it's now fundamentally broken.
If the software hack is just that they discovered how to determine the secret on which the pad is based by reversing it from where it's stored, the hardware pads are no less safe than they were all along; you still can't observe the hardware key without an awful lot more trouble - and again, this requires
Re: (Score:3, Insightful)
The "hardware token" *IS* running software. Did you think it was not running a processor and running a program???
And in order for that to work, it operates the same way the SOFTWARE system which validates and verifies the numbers on the RSA ID.
The compromise is the same whether it is a hardware or software device... in the end, they are all software devices.
not necessarily true (Score:3)
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.
Re: (Score:2)
True. For the Windows software token, you compute the "serial number" (seed) with the Windows account Security ID (SID) and the hostname of the machine the software is installed it. For the hardware token.... you look at the serial number very thoughtfully stamped into the back of the token. But in the latter case, I don't think you can transfer the serial number into another hardware SecurID, so unless you can emulate a HW token using "stolen" serial numbers, you can't clone a HW token, whereas the SW toke
Re: (Score:2)
You are absolutely correct.
The difference, of course, is that you would need physical access to the keyfob in my pocket. Even if you managed that feat without me noticing, you'd destroy it in the process of extracting the information you need thus alerting me that something was amiss.
Re: (Score:2)
No you wouldn't. That's why the breech of RSA happened. They just needed the seed information in order to clone the output of RSA devices out there.
RSA devices are about authentication. The authentication system is software. It must operate identically to the "hardware" devices to be useful.
Most people get that hardware which runs software is still software. But people aren't getting that "programmable hardware" is still software too.
Re: (Score:2)
Except the magic of soft ware is that two processes can be coded to behave differently... it could have been trivial for RSA to assume a different hash salt for tokens with different serial numbers or enrollment behaviours.
This is great news! (Score:5, Funny)
Re: (Score:3)
Better still, you can outsource your work to India and they can sign in with your token.
Re:This is great news! (Score:5, Funny)
That's what I do, I just have two Engineers in India do my work and FTP it to me once a week. They get paid 1/10th of what I do, so I do basically no work for 80% of my paycheque.
Outsourcing works both ways.
Re:Suuuuure it's random (Score:4, Insightful)
This attack doesn't actually rely on any of that - it's akin to photocopying all the one-time pads you've given to the user. To say that this is bidirectional cryptography is misleading at best.
Comment removed (Score:5, Informative)
Re:Suuuuure it's random (Score:4, Informative)
Solved with public/private key pairs (long ago), short version:
Server publishes public key and has internal copies of its private key and all authorized users' public keys.
User wants to authenticate, server challenges with a unique nonce (sampled from background radiation, or whatever) authenticated with server's private key if you're paranoid.
User responds with self-authenticated version of the nonce, possibly encoded with server's public key for good measure.
The only hole is key control, which is where the two+ factor stuff starts playing in.
Re: (Score:1)
You don't understand how this particular mechanism works. It is not intended to talk to the server directly or to be connected to a computer (the software version does that simply by virtue of where it's run, but the keyfob doesn't).
It is simply a one-time-use password generator.
Re: (Score:1)
My death will not stop it, unless my plan succeeds...
Like, duh... (Score:1)
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.
Re: (Score:2)
Even worse considering that the primary purposes such tokens are used for, is to mitigate against the damage which can be caused if a password is leaked... And one of the most common ways for passwords to leak, is via keyloggers which require privileged access to a compromised host anyway.
So if you have the capability to run a keylogger, you have the capability to copy the software token. You only gain any benefit from the system, if you run the soft token on a physically separate device and even then its e
Summary is somewhat misleading (Score:5, Informative)
Re: (Score:3)
As opposed to the ones you get at the arcade?
Misleading title (Score:2, Informative)
and they aren't doing it by reverse engineering RSA software, but rather exploiting windows API's.
Re: (Score:2)
eh? "exploiting the windows api's"(or using windows re-configuring as intented) was done after reverse engineering what to do.
device_serial_number=Left(SHA1(host_name+user_SID+“RSA Copyright 2008”),10).
I mean, coming up with a good local unique identifier on most systems is hard, but in rsa's case they shouldn't even have written the dll in the first place for their scheme.
Isn't this old news? (Score:4, Informative)
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.
Re:Isn't this old news? (Score:5, Informative)
The token generation algorithm uses essentially two parameters: the key fob serial number and a token activation key; each of them are usually provided by the vendor in *.XML files.
From here [www.oxid.it].
Basically, they also need the seed, which is the problem being tackled here.
Re: (Score:2)
Ahh. Didn't know one needed the seed as well. Thanks for the info.
Re: (Score:2)
The serial number is just used to be able to determine which key has which seed. Two factor auth may not be "awesome" but it is necessary in some situations.
Re: (Score:1)
WTF : Watched the Fucking
Re: (Score:2)
Re: (Score:2)
Uh, what? No.
The fundamentals of RSA's algorithm (RSA) are not "broken".
Please provide links if you think otherwise. No, the various attacks listed on Wikipedia don't count.
Re: (Score:2)
Didn't Lockheed just... (Score:2, Interesting)
Never understood why the hell companies like Lockheed score multi billion dollar deals that they are thoroughly unsuited for.
Re: (Score:2)
Thank you for posing that question, I regularly attack people for simply bashing governments and not offering a alternative. After all, it's easy being a critic, you just have to point out the problems and not offer solutions.
I didn't know the details of the attack, but like most "news worthy items" the details were unimportant to the reporter of the article I read. So I was short in information. I have worked with/for (subcont
Re: (Score:2)
Because only the large incumbents are able to jump through all the hoops required to do the government contracts...
And all the large incumbents are equally incompetent, so its not as if they can use someone better.
Not so fast (Score:5, Insightful)
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.
Re: (Score:2)
The fact that a computer can be coerced to give up all of its secrets if you have physical access is not the point here.
The main problem is that the secrets needed to deduce the seed of a software token can be uncovered without access to the machine in question. Specifically, the SID of the user's Windows account (easy to find if you have access to the account's AD) and the hostname of the Windows machine (often written on labels, also used as host component of DNS or WINS names). And both quite easily susc
Re: (Score:2)
If you can reach a host over the network, windows will happily disclose its hostname via several of its default protocols (netbios/nbname, rpc, rdp etc), no need to find physical labels.
Also on older versions of windows, the SID could be dumped out remotely by default too.
Re: (Score:3)
The old rule still applies: Physical access is access.
What you have (Score:5, Insightful)
Re: (Score:1)
Yes, but it is more expensive.
At least that is the answer I got with my software token...
Re: (Score:2)
Aren't most software tokens smartphone apps? That still gives a reasonable air gap if you are using a computer as the primary access method.
Obvious (Score:2)
If this is what "security researchers" get paid to do, sit around and state the obvious, I am in the wrong career field.
Re: (Score:2)
Re: (Score:3)
Unsurprising, since... (Score:1)
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.
Re:Unsurprising, since... (Score:5, Interesting)
I know this is Slashdot, but this thread is taking "TL;DR" to whole new places.
The news isn't that RSA's algorithm is out in the wild. Without the account-specific sequence generation seed value, the algo is worthless.
The news is that the researches have examined the Windows software version of the access code generator ("software token") and figured out how to extract the seed value out of a specific installation. With that seed value, you can take another copy of the software token and clone the key generation sequence of the first, allowing you to spoof the other token's identity.
This is why most RSA installations I know of also require the use of a PIN concatenated with the token-generated number. That way, coaxing the code out of the software token isn't enough to authenticate as the identity of the person the token is assigned to; you have to guess the PIN as well (maybe by looking under keyboards).
I guess the real story is "soft tokens don't protect their internal secrets as well as hardware tokens".
SecurID not broken (Score:5, Insightful)
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).
Re: (Score:2)
There are some slightly better techniques: McCune's Flicker system [cmu.edu] leverages TPMs (which any corporate laptop will have) in a way which means you can perform cryptographic operations securely unless the attacker can compromise the hardware in a pretty fundamental way. It would be ideal for implemen
WORST I'VE SEEN (Score:3)
Wow, this is one of the worst summaries I've seen in the last 2 days on /.
But, of course, you can if you know the seed (Score:2)
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.