My next class:

Lockheed Martin and RSA Tokens

Published: 2011-05-30. Last Updated: 2011-05-30 14:30:51 UTC
by Johannes Ullrich (Version: 1)
10 comment(s)

Just about a month ago, RSA notified its customers about a major breach of its systems. One of the big questions was if the breach leaked sufficient information to emulate RSA tokens.

RSA tokens are not random. They can't be random because the RSA authentication server has to know what number is displayed on the token. Based on the release from Lockheed Martin, suggesting that the RSA token was successfully emulated, one can only assume that the breach of RSA leaked sufficient data to predict the number displayed by a particular token. It may also have leaked which token was handed to what company (or even user).

However, remember that not all is lost. There are simple steps that you can and should do to protect your RSA token users:

- use a strong PIN or password. RSA tokens are just one factor of a two factor authentication scheme. You will have to enter a PIN or a password in addition to the token ID.

- monitor for brute forcing attempts. If your PIN is not trivial, an attacker will need a few attempts to guess it. Monitor for brute force attempts and lock accounts if someone attempts to brute force them. To prevent the associated denial of service attack, be ready to mass-unlock accounts and block access by IP address or other parameters.

- monitor your systems for accesses from odd IP addresses. Geo-location can help identify these out-layers. Keep logs indicating who logged in from what IP address in the past.

Also see:

http://isc.sans.org/diary.html?storyid=10609
http://isc.sans.org/diary.html?storyid=10618

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: breach lockheed martin rsa
10 comment(s)
My next class:

Comments

A) Use keypad tokens - otherwise you're vulnerable to keyloggers and traffic intercept.
B) If you can't switch all your users to keypads, just do your system/network admins - they are high value targets.
C) With the remaining non-keypad tokens, switch all users to strong passwords - don't use PINs, they are from another century.
D) DONT rely on 'failed logins' - use source IP address and time of day as an indicator of suspecious activity.
E) Brute forcing doesn't work against RSA (which locks out tokens after a few mis-tries).

For clarification - and I'm not suggesting this relates to the LM breach, just theorising:
1) It seems that attackers know the token seeds for every organisation :-(
2) If they can intercept the PIN and a one token code (e.g. via keylogger, traffic intercept etc.) then they know the PIN/password and one old code.
3) They can determine which token you have offline, as it's the one that would generate that old code at that old moment in time.
4) Again offline, using the seed for that token, they can then generate the current valid code, and prepend the captured PIN/password.

This doesn't take any 'online' brute-forcing, and basically means if you don't protect your PIN/Passwords you're hosed.

Keypads should be a reasonable fix for this (assuming your authentication comms are secure - SSL etc.), but obviously protecting your endpoints is (shock, horror!) still critical.

Source IP and time/day analysis still seems like by far the best historical and live indicator of attack.....

Fun eh?
Dom

Dom De Vitto (dom@devitto.com)

May 30th 2011
1 decade ago

So RSA two factor authentication has been reduced to the equivalent of WEP plus a brute-forceable PIN in most instances.

Sean

May 30th 2011
1 decade ago

While it may not be scalable for very large organizations, we only allow company-owned assets for remote access. We use either a whitelisted MAC address or a client-side certificate, depending on the client. Systems trying to connect and failing these checks are always followed up. Since there is no end-user interaction for these factors, even a keystroke logger wouldn't be aware of it.

JJ

May 30th 2011
1 decade ago

RSA tokens use a stong secret that is only bound to an account when the customer administrator assigns the token to a user on their server. Even if records of a batch of tokens were stolen from RSA, and which customer bought them, it does not give a mapping to individual users. Further more, there is no token identifing information normally sent during authentication.

dave

May 31st 2011
1 decade ago

Your explanation misses the mark, and you give dangerous advice.

SecureID is a 2-factor system. The entire point behind a 2-factor system is that you have decided that you should not rely on passwords alone. Therefore, to think clearly about the benefit you hope to get from the 2nd factor, you must consider passwords compromised. Therefore, advice like "use a long password" is off the mark.

Fact is, some fraction of home computers have keystroke loggers installed. I don't know the precise number, but say it might be 1%. If you are big company with 10,000 employees, you could easily expect that 100 or so employees compromised. Whatever they type is known to the bad guys. This means passwords, and it also means the numbers that come out of the SecureID token.

The fact that bad guys can observe the numbers that come out of the SecureID token would normally not allow the bad guys to predict the next number that comes out of the token. This feature comes from the mathematics of the algorithm that produces the numbers and the size of the keyspace. The size of the keyspace matters because for a strong algorithm, there is no attack better than trying every possible key.

What if something happened that suddenly reduced the size of the keyspace hugely? I don't know for sure that this is what recently occurred, but I believe there is an excellent chance that this is precisely what occurred.

This would be very damaging. I suppose that only a few million SecureID tokens have ever been made. If you had the file of all the keys of all the tokens ever built, you would only need to search this short list. I don't know how long the SecureID keyspace is, but suppose it is 128 bits. That means there are 2^128 keys you would have needed to search before obtaining the list of all keys used. After obtaining the list, you only need search 2^21 or so. You have just sped up searching by a factor of 2^107.

So here's how a bad guy can attack you now. He has a keylogger installed on one of your employees computers. He sees the password your employee types. He sees the 6 digits that come out of the SecureID token. He does a quick computation, using his file of keys. He tries all million or so keys in that file. Chances are that only 1 of them produces the 6 digits your employee just typed! Bingo! The bad guy now knows the key of your employee's SecureID token.

The result won't always be unique. Sometimes he'll have to wait until your employee uses the token twice. But then ... he'll have it nailed.

The bad guy can now impersonate your employee.

If I'm right, then your suggestions like "use a strong password" are very dangerous, because they mislead people into believing that they can control the danger of this event.

I believe the only correct solution is to turn off all SecureID token access.

Pete

May 31st 2011
1 decade ago

Sean: No, no brute forcing required, just the right input information.

JJ: Yep, sounds good, but be wearly of infected whitelisted/certificated machines - as per usual :-(

Dave: Totally wrong. The token is (pretty much) a unique identifier for a token generator assigned to an organisation, at a time T, given seed S. Bad guys know the time, and the seeds, so can derive the token. You're hosed.

Pete: The seed information is/was held with information on the organisation and contact email/phone - so they're not scanning a few million, but only the valid tokens for that target, - probably a few thousand. Hence the attack is so successful and trivial :-( Otherwise, great breakdown :-)


PINcards really should resolve this - assuming the PIN encoding algorythm is secret (ideally a perfect hash), this will foil a PIN-grabbing keylogger, and hence the whole attack.

Obviously, if someone has reverse engineered and rainbow'd the PINcard hash, in which case you're back to being hosed again :-(

Dom De Vitto (dom@devitto.com)

May 31st 2011
1 decade ago

I mean, seriously, when considering how many people were depending not only on a single type of second factor authentication (one time passwords), but also a single commercial product, this was bound to eventually happen.

Hopefully now that "this 'exploit'" is in the wild (I hate that phrase), it will force people away from not only OTP, but a single commercial product.

There's a ton of public/private key pair products out there, like Alladin's eToken (who kindly sent me a demo dongle).

Much like Intermedia should see people jumping off Microsoft BPOS's deck, I expect that public/private key solution vendors will now see the same.

P.S.
I still can't find the exploit, algos, or pre-packaged "generator" app anywhere.
*puts on tin foil hat*

mbrownnyc

May 31st 2011
1 decade ago

Dom: I know how the SecurID token works. I've been on the inside. It's not an organization wide thing. Each token has a unique unrelated key. Granted if you can narrow down the number of seeds to try it becomes a simpler brute force problem. There are a lot of tough predicates in your example, like knowing the algorithm to predict a token code for a given time and seed.

I would claim that breaking into RSA is the slowest way to do that. Easier to hack into the companies RSA server and get the seeds and code from it. Of course if you can do that, the target has other problems.

dave

May 31st 2011
1 decade ago

Cain and Abel added a SecurID token code calculator in 2003. This was updated in 2007 to handle the new AES-based tokens.
http://www.oxid.it/
http://www.oxid.it/ca_um/topics/rsa_securid_token_calculator.htm

JerryH

May 31st 2011
1 decade ago

Don't want to scare anyone but the algorithm used by the RSA pincards was basically to add the pin to the current passcode. So if your passcode (what is being displayed) is 111111 and your pin is 2222 then you would end up entering 113333.

Yvon

Jun 1st 2011
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives