Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Researchers Can Generate RSA SecurID Random Numbers Flawlessly

Soulskill posted more than 2 years ago | from the everybody-needs-a-hobby dept.

Security 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."

cancel ×

98 comments

Sorry! There are no comments related to the filter you selected.

Not exactly... (5, Informative)

Anonymous Coward | more than 2 years ago | (#40078859)

"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... (5, Insightful)

Fwipp (1473271) | more than 2 years ago | (#40078981)

Exactly. They're cloning the software token, not breaking the scheme that the hardware uses.

Re:Not exactly... (5, Informative)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#40079279)

My understanding is that the two schemes are the same. The software version is just the cheap-n-lazy implementation for people who don't want to deal with airgapped hardware tokens.

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... (5, Interesting)

Cramer (69040) | more than 2 years ago | (#40079585)

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:Not exactly... (1)

lgw (121541) | more than 2 years ago | (#40079877)

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:Not exactly... (1)

swillden (191260) | more than 2 years ago | (#40081367)

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... (5, Informative)

datajack (17285) | more than 2 years ago | (#40081383)

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:Not exactly... (1)

RightwingNutjob (1302813) | more than 2 years ago | (#40081721)

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:Not exactly... (1)

jaymemaurice (2024752) | more than 2 years ago | (#40083545)

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:Not exactly... (1)

Bert64 (520050) | more than 2 years ago | (#40084097)

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:Not exactly... (1)

Bert64 (520050) | more than 2 years ago | (#40084081)

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 is a big risk.

I would only consider using a token scheme where:
a, the algorithm is published and has been reviewed by competent third parties.
b, anything private like seeds of privkeys is generated by the end user, not beholden to a third party.

Re:Not exactly... (0)

Anonymous Coward | more than 2 years ago | (#40086531)

"And now it turns out that their software 'tokens' retain their seed values in local storage forever."

They need the seed value to generate each token, what else are they going to do?

The software tokens have always been a compromise favouring convenience over security.

Re:Not exactly... (1)

PhunkySchtuff (208108) | more than 2 years ago | (#40097907)

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 targeted keyfob - there's a good chance you'll watch it for 12 months straight and not see a single vanishing differential - but if you happen to have, for example an employer-provided keyfob that while it's in legitimately your possession for a long enough time to observe such an event, and then the keyfob is recycled (such as if you finish the job for which you were given the keyfob and it's then handed on to someone else) then you can predict future output of that individual keyfob.

More info for those who are interested is here:
http://eprint.iacr.org/2003/162.pdf [iacr.org]

Re:Not exactly... (4, Informative)

chrb (1083577) | more than 2 years ago | (#40079329)

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:Not exactly... (2)

Sir_Sri (199544) | more than 2 years ago | (#40079593)

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 API you're equally screwed.

It also reduces the RSA token problem to the same problem as everything else in security. If machine isn't properly secured, both with regular software updates/AV/Firewalling, and from users clicking on random files with administrator privileges then anything else you do is basically pointless.

Re:Not exactly... (1)

Chuckstar (799005) | more than 2 years ago | (#40081241)

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:Not exactly... (1)

jaymemaurice (2024752) | more than 2 years ago | (#40083577)

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... (0)

Anonymous Coward | more than 2 years ago | (#40083781)

I have to carry arround this key chain that says "he must work somewhere where security is important".

Or just "he must have an account with a bank that knows what two-factor authentication means."

Re:Not exactly... (0)

Anonymous Coward | more than 2 years ago | (#40079065)

Really though, how is a hardware (keyfob or handheld variety) token fundamentally different from a software token? The handheld tokens ultimately run software that could be duplicated. Certainly hard-hacks are more difficult, but not impossible.

Re:Not exactly... (4, Insightful)

Kenja (541830) | more than 2 years ago | (#40079091)

The keyfob is fairly tamper proof. You would need to pop it open and use some sort of device to read the memory where the token is kept. Since the fobs are filled with epoxy and go dead if the power source is disconnected, this is difficult.

Re:Not exactly... (1)

dgatwood (11270) | more than 2 years ago | (#40079127)

The hardware token is not networked, and thus cannot readily by attacked and cloned without physical access (if then).

Re:Not exactly... (1)

Lumpy (12016) | more than 2 years ago | (#40079457)

The keyfob number is printed on the back of them.

Re:Not exactly... (1)

dgatwood (11270) | more than 2 years ago | (#40081391)

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 concern, but even then, it could be easily prevented with a piece of black tape. By contrast, software tokens could be trivially cracked as part of the normal process of compromising random people's devices. As two-factor authentication becomes more common for online banking, such fishing expeditions will become more common as well.

Re:Not exactly... (2)

Lumpy (12016) | more than 2 years ago | (#40082175)

" 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:Not exactly... (1)

phayes (202222) | more than 2 years ago | (#40084297)

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:Not exactly... (0)

Anonymous Coward | more than 2 years ago | (#40085495)

Not on mine or anyone elses in the company here, It's printed on the back in duarable paint/ink. I have had this keychain fob for 3 years and can still read it.

Re:Not exactly... (1)

dgatwood (11270) | more than 2 years ago | (#40090345)

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!

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, watch the person key it in, or hack the person's device. This is much harder than remote hacking because:

  • I'm going to assume that most people are not clueless enough to give up a PIN to a random person over the phone (unlike a serial number, which most people would assume is a harmless piece of information).
  • Watching the person key in the PIN requires physical proximity.
  • If you've already hacked the person's computing device, had it used a software-based token generator, you would already have the key information without needing to figure out that person's phone number, call them (with a risk of being traced), and trick them into revealing the serial number.

Thus, attacking a hardware-based token generator is much harder than attacking a software-based token generator under pretty much all circumstances, and requires the attacker to take a much higher personal risk.

Re:Not exactly... (1)

zill (1690130) | more than 2 years ago | (#40082035)

The serial number isn't the seed. Having the serial number doesn't help the attacker.

Re:Not exactly... (1)

Bert64 (520050) | more than 2 years ago | (#40084125)

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:Not exactly... (1)

jaymemaurice (2024752) | more than 2 years ago | (#40085147)

^^ 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 secret number. If I am correct, even if the server storing the serial to seed mapping is compromised, there is still no way practical way to clone the tokens because you won't have the ability to predict the next numbers, only confirm if the numbers generated were plausible or not based on the predicted/known state of the tokens clock. Even if you know the serial number of the token, have all the seeds, there is the clock synchronization issue and often there is a pre or postpended user set pad.

Re:Not exactly... (3, Insightful)

nahdude812 (88157) | more than 2 years ago | (#40079161)

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 (1)

freaker_TuC (7632) | more than 2 years ago | (#40085061)

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:Same protocol (1)

freaker_TuC (7632) | more than 2 years ago | (#40085067)

hacker == harder ..

Oh boy, do I hate automatic spelling checkers ..

Re:Same protocol (1)

nahdude812 (88157) | more than 2 years ago | (#40090567)

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 physical access (vs reversing the software key, which is subject to the possibility of remote access via an alternate channel). In this case, the software pads are weakened and the hardware pads are not.

Re:Not exactly... (2, Insightful)

erroneus (253617) | more than 2 years ago | (#40079489)

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 (2)

Chirs (87576) | more than 2 years ago | (#40079645)

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:Not exactly... (1)

idontgno (624372) | more than 2 years ago | (#40079649)

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 token is reprogrammable with the reverse-engineered token serial, so it is eminently clonable.

What's worse, soft token cloning is remotely exploitable if the attacker can gain enumeration access to the Active Directory hosting the account credentials and knows the target machine's hostname. And that makes the soft-token exploitability worse.

Re:Not exactly... (0)

Anonymous Coward | more than 2 years ago | (#40095901)

The serial number is not the seed. The serial number is not used in anyway to generate tokencodes. The serial number is only used as unique ID, which allows an admin to issue the right token for the right seed value. The *device* (not token) serial number, when referring to software tokens, was intended to be used to make token copying more difficult. Binding a token to a device.

Re:Not exactly... (0)

Anonymous Coward | more than 2 years ago | (#40079761)

While that's true, it's all software, it's a matter of difficulty (and thus likelihood).

The hardware/fob version is inherently much more difficult to compromise due to physical access. Whereas the software can be REMOTELY accessed, and quite easy at that thanks to the poor security of its containment vessel (Windows).

While the complexity of the mechanism is identical, the difficulty is drastically reduced, and thus the effective security level offered by the software is waaaaay less than the hardware at this point. That is (or should have been) the point of TFA, as well as TFS. But alas, someone was going for JuicyPoints(tm) instead.

Re:Not exactly... (1)

BrianRoach (614397) | more than 2 years ago | (#40080615)

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:Not exactly... (1)

erroneus (253617) | more than 2 years ago | (#40084969)

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:Not exactly... (1)

jaymemaurice (2024752) | more than 2 years ago | (#40085157)

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.

uh durr (-1)

Anonymous Coward | more than 2 years ago | (#40078875)

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?

This is great news! (5, Funny)

CubicleZombie (2590497) | more than 2 years ago | (#40078877)

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!

Re:This is great news! (2)

JoeMerchant (803320) | more than 2 years ago | (#40078949)

Better still, you can outsource your work to India and they can sign in with your token.

Re:This is great news! (5, Funny)

Beardo the Bearded (321478) | more than 2 years ago | (#40079143)

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:This is great news! (0)

Anonymous Coward | more than 2 years ago | (#40080085)

That's ok, we're finishing up negotations with your company to do the work for 50% of what you presently make.

Sincerely,

Indian Engineer

Re:This is great news! (-1)

Anonymous Coward | more than 2 years ago | (#40081275)

That's ok, we're finishing up negotations with your company to do the work for 50% of what you presently make.

Sincerely,

Indian Engineer

As if. They'll see that you're in India, that your credentials from unheard-of Indian schools and businesses, and that you can't speak/write English well and they'll trash your application.

you don't need to see his RSA token (0)

Anonymous Coward | more than 2 years ago | (#40078887)

these aren't the secureIDs you're looking for

Suuuuure it's random (-1)

Anonymous Coward | more than 2 years ago | (#40078901)

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.

Re:Suuuuure it's random (3, Insightful)

Fwipp (1473271) | more than 2 years ago | (#40078967)

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.

Re:Suuuuure it's random (4, Informative)

YodasEvilTwin (2014446) | more than 2 years ago | (#40079003)

This has nothing to do with randomness. For example, you could use numbers that are random (or as good as random) by sampling background radiation and still run into the same issue. The problem lies in the fact that those samples need to be shared. You can't log in if the server isn't using the exact same number sequence as your token. The seed provides the means to get the number sequence; replacing the seed with the data from your radiation sampler might be good in that it's probably harder to hackers to access, but it doesn't change the fundamental nature of the issue.

Re:Suuuuure it's random (3, Informative)

JoeMerchant (803320) | more than 2 years ago | (#40079099)

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:Suuuuure it's random (1)

Anonymous Coward | more than 2 years ago | (#40080323)

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:Suuuuure it's random (0)

Gerzel (240421) | more than 2 years ago | (#40079041)

My death will not stop it, unless my plan succeeds...

Like, duh... (1)

Anonymous Coward | more than 2 years ago | (#40078921)

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:Like, duh... (1)

Bert64 (520050) | more than 2 years ago | (#40084183)

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 easy to screw it up (eg run it on a phone, connect that phone to the compromised workstation via usb).

Summary is somewhat misleading (4, Informative)

supersat (639745) | more than 2 years ago | (#40078931)

This applies to software tokens only.

Re:Summary is somewhat misleading (2)

Jeng (926980) | more than 2 years ago | (#40079543)

As opposed to the ones you get at the arcade?

Misleading title (2, Informative)

Anonymous Coward | more than 2 years ago | (#40078957)

and they aren't doing it by reverse engineering RSA software, but rather exploiting windows API's.

Re:Misleading title (1)

gl4ss (559668) | more than 2 years ago | (#40080075)

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? (3, Informative)

noc007 (633443) | more than 2 years ago | (#40078975)

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? (4, Informative)

LordLimecat (1103839) | more than 2 years ago | (#40079097)

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:Isn't this old news? (1)

noc007 (633443) | more than 2 years ago | (#40079215)

Ahh. Didn't know one needed the seed as well. Thanks for the info.

/I never thought the SecureID stuff was was an awesome solution anyways.

Re:Isn't this old news? (1)

phayes (202222) | more than 2 years ago | (#40084357)

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:Isn't this old news? (0)

Anonymous Coward | more than 2 years ago | (#40079623)

DNRTF: Did Not Read The Fucking?

Re:Isn't this old news? (1)

Hal_Porter (817932) | more than 2 years ago | (#40085051)

WTF : Watched the Fucking

Re:Isn't this old news? (1)

whitesea (1811570) | more than 2 years ago | (#40082383)

This is such old news, that RSA changed the algorithm after the original proprietary algorithm had been broken. The demonstration you saw no longer works.

Re:Isn't this old news? (1)

chill (34294) | more than 2 years ago | (#40082563)

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:Isn't this old news? (0)

Anonymous Coward | more than 2 years ago | (#40082675)

"The RSA algorithm" and "algorithms used by the RSA company" are two seperate things.
In other words, you haven't a clue what you're talking about.

Re:Isn't this old news? (1)

whitesea (1811570) | more than 2 years ago | (#40108783)

The algorithm everybody is talking about is the old algorithm used in SecureID tokens before the vendor producing them bought RSA. When Security Dynamics bought RSA, they took their name as the name of the whole company, because it was such a venerated brand. After the old algorithm for the token could no longer be used, because everybody and their brother could easily generate the "unpredictable" SecureID values, they switched to AES-based approach, which has not been broken so far. RSA algorithm is a public key encryption/signature algorithm, which should be properly implemented, otherwise there exist many ways to break a raw or improper implementation. Hope this clears up confusion brought by the fact that RSA means so many different things these days.

Didn't Lockheed just... (1, Interesting)

LostMyBeaver (1226054) | more than 2 years ago | (#40078997)

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.

Re:Didn't Lockheed just... (0)

Anonymous Coward | more than 2 years ago | (#40082081)

Any suggestions of what they could do differently? IIRC the attack also required a username and password, and was related to the regular corporate VPN and not a network that was related to national security.

Re:Didn't Lockheed just... (1)

LostMyBeaver (1226054) | about 2 years ago | (#40180531)

haha sorry... too little too late from me. I haven't check mail in ... forever :)

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 (subcontractor of a subcontractor twice removed or something) and found that it's often a miracle Lockheed could accomplish anything. In order to score new projects, the people who would have been worth anything to begin with were taking off of projects regularly in order to be placed on new projects since the second Lockheed scored one project, they'd start posturing for the next claiming "You'll have the brainiacs that did this on your project"... so they'd get at most 3 months on each project. What's left afterwards are burnt out guys or guys that weren't really that good to brag about in a sales room.

I have to admit, I don't know an alternative. Usually I'm quick to think of something, but given the scale of a project like this, I'd say there's no company suited for this and it would be far more intelligent to focus on having in-house resources for this. People may complain about "big government", but in reality, in situations like this one, often the best solution is simply to do it yourself. :(

Re:Didn't Lockheed just... (1)

Bert64 (520050) | more than 2 years ago | (#40084203)

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 (4, Insightful)

WaffleMonster (969671) | more than 2 years ago | (#40079039)

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:Not so fast (1)

idontgno (624372) | more than 2 years ago | (#40079781)

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 susceptible to social engineering attacks.

Add to that the fact that once you've uncovered the seed, you can program another independent copy of the token software to clone the key generation sequence of the original soft token, in perfect synchronization, so it becomes useless as a distinctive "something you have" 2nd factor.

It's kind of sad and alarming that the components chosen for seed generation are remotely discoverable, and that it's so easy to clone a soft token with a recovered seed value. The former is much harder with a hardware token (if you reach over to me and pick up the RSA hardware token on my ID lanyard, I'm gonna notice, and you'll be lucky if I don't slap your hand away), and the latter seems impossible (you can't jam someone else's seed value into your token, so you can't clone their identity that way).

Re:Not so fast (1)

Bert64 (520050) | more than 2 years ago | (#40084217)

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:Not so fast (2)

Thaelon (250687) | more than 2 years ago | (#40080257)

The old rule still applies: Physical access is access.

What you have (5, Insightful)

g0es (614709) | more than 2 years ago | (#40079043)

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.

Re:What you have (1)

Anonymous Coward | more than 2 years ago | (#40080127)

Yes, but it is more expensive.

At least that is the answer I got with my software token...

Re:What you have (1)

cstdenis (1118589) | more than 2 years ago | (#40081591)

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.

Re:What you have (0)

Anonymous Coward | more than 2 years ago | (#40082233)

I had a software token running on my Android smart phone for the last MMO I played and while I agree that it probably isn't good enough to protect Lockheed Martin, etc its IMO perfectly fine for situations where users aren't likely to be specifically targeted... which is what many (most?) soft tokens are used for.

Obvious (2)

Sparticus789 (2625955) | more than 2 years ago | (#40079055)

So RSA tokens can be broken if someone copies the RSA software token. It doesn't take a security researcher to figure this out. Any 7th grader knows that if you steal someone's key to their locker, you can open it.

If this is what "security researchers" get paid to do, sit around and state the obvious, I am in the wrong career field.

Re:Obvious (-1)

Anonymous Coward | more than 2 years ago | (#40079243)

The researchers have a way to (1) use the key to produce the key from the RSA token (which I don't suppose you happened to do yourself), and (2) extract the key from a running Windows machine (I also suppose that you did not figure out how to do this). Do you also complain about farmers "everybody knows that plants grow with sun and water, if that's all farmers get paid to do, that's a scam."

Open it up and extract token. (-1)

Anonymous Coward | more than 2 years ago | (#40079063)

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?

Re:Open it up and extract token. (2)

g0es (614709) | more than 2 years ago | (#40079089)

Yes

Re:Open it up and extract token. (2)

Jafafa Hots (580169) | more than 2 years ago | (#40079589)

Also, if you happen to notice a block of bricks overhead, jump up and hit it with your head.

Unsurprising, since... (1)

kiite (1700846) | more than 2 years ago | (#40079267)

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... (4, Interesting)

idontgno (624372) | more than 2 years ago | (#40079545)

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".

Re:Unsurprising, since... (0)

Anonymous Coward | more than 2 years ago | (#40086695)

"and figured out how to extract the seed value out of a specific installation"

Actually he hasn't. His step five is missing an implementation, yet he claims to have cloned a token.

It is currently unknown if he has completed an implementation for step five, and actually cloned a token; or whether he simply cloned a VM to dupe a token. (A much less impressive feat).

This very question is raised on his blog, so far it has been ignored.

'I guess the real story is "soft tokens don't protect their internal secrets as well as hardware tokens".'

This should be obvious to anyone in the field.

I'll also note that the very same version of the RSA software token software that he was testing, has a plug-in to enable the use of smartcards or TPM to prevent this attack. (Essentially a write/verify (but no read) hardware device)

A software token has always been a trade off between ease/convenience/cost of issuing/carrying Vs Security. In order or security, and decreasing order of ease/cost, it's pretty much:
1. Hardware token
2. Software token
3. SMS based token.

Event-based tokens (0)

Anonymous Coward | more than 2 years ago | (#40079277)

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).

SecurID not broken (4, Insightful)

Old Wolf (56093) | more than 2 years ago | (#40079563)

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:SecurID not broken (1)

igb (28052) | more than 2 years ago | (#40080431)

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

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 implementing soft-tokens.

Re:SecurID not broken (0)

Anonymous Coward | more than 2 years ago | (#40080647)

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 WAS always possible in theory. Lately there has been huge effort, and success, in developing algorithms which operate on encrypted inputs and produce encrypted outputs, while never decrypting the input or even having POSSIBILITY of decrypting it, since the key is not known. To give an example, you can take two ENCRYPTED numbers, A and B, and calculate the ENCRYPTED sum of the numbers, C, without ever decrypting A, B, or even knowing the key that was used. The primary target of this research is the creation of methods to allow cloud-based compute farming while maintaining the secrecy of your data and the algorithms which are operating on it, so that for instance, Microsoft cannot snoop on your calculations while you are crunching numbers on Azure. But it could just as well be applied to the problem being discussed here.

Something is only impossible until someone figures out how to do it.

Pastebin gone, paseted here: (-1)

Anonymous Coward | more than 2 years ago | (#40079779)

- --> 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

WORST I'VE SEEN (2)

mr_stinky_britches (926212) | more than 2 years ago | (#40082023)

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 (1)

kriston (7886) | more than 2 years ago | (#40090579)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>