Lockheed Martin and RSA Tokens
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
| Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
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
Sean
May 30th 2011
1 decade ago
JJ
May 30th 2011
1 decade ago
dave
May 31st 2011
1 decade ago
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
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
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
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
http://www.oxid.it/
http://www.oxid.it/ca_um/topics/rsa_securid_token_calculator.htm
JerryH
May 31st 2011
1 decade ago
Yvon
Jun 1st 2011
1 decade ago