Wednesday, March 23, 2011

RSA SecurID Breach - Seed Record Threats

The following is a threat model that assumes the RSA SecurID seed records have been stolen by a sophisticated adversary, which is probably what happened.

But first, a word from our muse, Bruce Schneier, regarding what he titled back in 2005 as the "Failure of Two Factor Authentication":
Two-factor authentication isn't our savior. It won't defend against phishing. It's not going to prevent identity theft. It's not going to secure online accounts from fraudulent transactions. It solves the security problems we had ten years ago, not the security problems we have today.
[snip]
Here are two new active attacks we're starting to see:
  • Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank's real website. Done right, the user will never realize that he isn't at the bank's website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user's banking transactions while making his own transactions at the same time.
  • Trojan attack. Attacker gets Trojan installed on user's computer. When user logs into his bank's website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.
See how two-factor authentication doesn't solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.
[Snip]
Two-factor authentication ... won't work for remote authentication over the Internet.
Bruce was absolutely right. We saw examples of that.

...

Now, let's put the pieces together-- the active MITM attacks that Bruce described, which could result in an offline/passive attack.

In both cases above, the adversary has to act immediately to essentially take over an authenticated session, using either the real-time MITM scenario, or the trojan scenario. But let's assume that the "good guys" have, by now, read Bruce's article [but in all reality, they probably haven't, hence they have an RSA SecurID investment] and have paid attention to the RSA jabber that says to watch for an increase in login attempts. In these examples Bruce describes, the adversary grabs the session and disconnects the valid user (possibly at the presentation layer, by taking over the session in malware that doesn't display what the actions are occurring in the authenticated session).

However, let's assume the adversary let's the user keep his authenticated session. The adversary just monitors the credentials that are entered:
  1. The User ID, and
  2. The one-time-passcode (token's readout, a.k.a. "tokencode", plus the user's PIN)
"Relax," says the security administrator. "That's what these RSA SecurID thingies are for-- to make it meaningless when a bad guy eavesdrops on credentials."

Well, except in the case where the "bad guy" has all of the seed records for all RSA SecurID tokens ever sold.

Quoting from our article from yesterday:
Assume an adversary has now in their possession, all of the seed records for all RSA SecurID tokens that are currently valid (which based on above and previous seems very plausible). Assume they have sufficient computing hardware to mass compute all of the tokencodes for all of the tokens represented by those seed records for a range of time (they obviously are well funded to get the "Advanced Persistent Threat" name). This would be the output of the RSA SecurID algorithm taking all the future units of time as input coupled with the serial number/token codes to generate all of the output "hashes" for each RSA SecurID token that RSA has ever made. These mass computed tokencodes for a given range of time would basically be one big rainbow table, a time computing trade-off not too unlike using rainbow tables to crack password hashes.
[Snip]
Since tokencodes are only 6 digits long, and RSA has sold millions of tokens, the chances of a collision of a token's output with another token's output at a random point in time is significant enough, but phish the same user repeatedly (like asking for "next tokencode") and the adversary now can significantly narrow down the possibilities of which tokens belong to which user because different tokens must appear random and not in sync with each other (otherwise RSA SecurID would have much bigger problems). Do this selectively over a period of time for a high valued asset, and chances are the adversary's presence will go undetected, but the adversary will be able to determine exactly which token (serial number, i.e. seed record) belongs to the victim user.
So, now that the adversary has these "rainbow tables" of RSA SecurID tokencodes, and now that the active attacks Bruce described have morphed into a passive attempt, all it will take is watching particular users create valid sessions-- maybe as little as a single attempt, depending upon the mathematics and randomness of the RSA SecurID token output, but probably more like watching a handful of attempts. At that point, the adversary can then impersonate the victim user at any point in the future.

So, if RSA SecurID seed records are compromised, there is really not much advantage in an RSA SecurID implementation. The threats are essentially the same as an adversary grabbing conventional passwords. The only difference is that a passive attack against compromised seed records may take multiple monitoring attempts, as opposed to a single event. But with simple malware, that won't be much more effort, especially for a high valued asset.

So given what we know, we can assume seed records were compromised. And given how little RSA is talking about it, we cannot really know how they are responding to it. Will they just distribute new tokens without compromised seed records, or will they do something much more significant? Based on what we know today, it makes more sense for an organization that is thinking about an RSA SecurID deployment to rely instead on conventional passwords (e.g. Microsoft Active Directory), and spend the extra money on monitoring for fraud and stronger identity validation for things like password resets.

4 comments:

Anonymous said...

ok. first all valid points so not going to argue them technically. However, you are assuming that the hacker is monitoring all of this real time, and passes the credential back to the REAL site within seconds (since the algorithm number changes pretty quickly by the time it is generated, read, typed and next one is there by the server. I dont like tokens either, but the point is, the hacker needs to be totally on top of it more than he would with a static password. All these tokens do is make it harder, not impossible.

Your statement of grouping two factor authentication in the begining as all inb one bucket is also erroneous. A smartcard, where the private key never leaves the encrypted SAM, and uses a PKI cert that the server recognizes, should not be able to be harvested from either man in the middle or malware. If so, it is a VERY advanced attack and not to rule out other measures that should be taken in conjunction to not entirely rely on these devices/methods.

The real problem with the token is that i believe the keys are symmetric and are not all that private exposing the whole paradigm, moreso than man in the middle i could mint my own tokens. Much scarier...

Tim MalcomVetter said...

Anonymous:

First, don't trust crypto to take care of you for everything. It's far from perfect-- it's the endpoints you need to worry about.

Second, Bruce's original comments that I quoted assume a real-time MITM attack on the tokens, but that's not required if the adversary does the "rainbow table" approach to generating all token codes for a period of time.

Suppose an adversary wants to target a particular individual or organization. If they can get their MITM-ware to just monitor credentials (could be on the endpoint, could be in the communication stream somehow-- lots of ways to accomplish that), then they could *record* the credentials and send them off for offline (non-real-time) analysis. Gathering a handful of successful example authentication attempts, comparing to a set of "rainbow tables" for the given period of time when the records were sent could generate all the information needed to isolate and identity which user has which seed record (token serial number). Once that is known, the adversary will have everything needed to impersonate the RSA SecurID tokencode for future points in time.

Third, unless the smartcard does all the encryption inside its own CPU, it's vulnerable just like anything else. I have seen numerous PKI implementations where the private key is stored "securely", but then the computations occur in the regular CPU (which can be recorded) or later stored in RAM (which can also be recorded). If it's a device, and it talks on the System Bus, in a monolithic kernel OS, any other system device (because all device drivers are kernel resident) can do things like DMA (Direct Memory Access) and other scary techniques to talk directly to devices on behalf of the OS kernel. At that point, the "smartcard" may be stupid enough as to divulge information it should not. Not saying all implementations do this, but just that very few do.

In general, if you cannot trust the computer on the remote end of a network connection, how can you trust the authentication result coming from that same unstrusted computer? It's a paradox.

Anonymous said...

Just wanted to point you to this page: http://www.articlesbase.com/communication-articles/phishing-with-the-man-in-the-middle-for-two-factor-authentication-5387530.html
Unless you wrote it, it seems like someone has been lifting material fairly liberally.

Tim MalcomVetter said...

Hi Anonymous,

No, I didn't write that article you linked to. While there are similar themes, I don't see any direct plagiarism. If I missed blatant plagiarism, well, I'll just chalk that up as emulation is the highest form of flattery. :)