Yay Yay RSA!

xrayspx's picture
xrayspx - Fri, 03/18/2011 - 11:56pm

The key point I took away from RSA's communications today is that all implications are that it's likely their token seed database was taken and that token codes are predictable, and may be able to be matched to customers.

They didn't say this, clearly, but every action they suggest to mitigate risk points to the fact. The mitigation steps they give are:

  • Consider changing PINs
  • Remove all remote access from your Auth Management servers. This was key, they said "turn off telnet, ftp, yadda yadda", but they also said "disable ssh". Meaning you should only be able to login from the console, period.
  • Watch for strange access elevations of users that would put them in a group that can see the database mapping tokens to users/PINs
  • Evaluate and audit your helpdesk procedures to make sure your helpdesk folks aren't potentially leaking information that could be valuable in an attack. So if your Helldesk people are chatting with users, they might tell that user slightly more than they need to know about our auth process or other salient fact that could be combined with other information to escalate access.
  • Institute training on social networking and make sure both your Helldesk staff and userbase are always on their toes and verifying who they're talking with.

    Those glaringly point to the possibility that the only thing protecting clients are their PIN codes. If someone has a predictable database of token codes, what do they need to attack to gain access? PINs. What are we told to protect to our last breath? The database of PINs on the Auth Management servers and stop Helldesk people blabbing about things users don't need to know. Also, stop Helldesk people resetting PINs for folks. Scenario:

    Caller: Hi this is Bob, I can't log into the VPN.

    Helldesk: Are you sure you're putting the token code in right, can I have the Serial?

    Caller: Sure, serial is 928374

    Helldesk: Have you checked CAPS lock, blah blah num lock etc, yadda yadda

    Caller: I know I'm putting the token code in right, can you reset my PIN?

    Helldesk: sure

    pwnd.

    RSA are saying that the data which was copied "cannot directly lead to a compromise, but can lower the effectiveness of current two-factor auth deployments". The only thing that can mean is that those deployments are now actually one-factor deployments.

    They have lowered the attack plane with a 4 digit PIN from 1/10,000,000,000 over a 60 second or so span until the token code changes, to a 1/10000 chance of guessing over a much more manageable timeframe, since they don't have to worry about the code rolling over.

    Even in the case that you have token lockouts after a certain number of failed attempts, this also appears to be time-sensitive. In tests, I went 4 or 5 failed attempts past the limit on a test device, then entered my PIN correctly, and it let me in. 2 minutes later, my token was locked out. So it seems it does not lock immediately on the 6th failed attempt if you have max failures set to 5. If that's actually the case, then an attacker could try their 10000 PINs in a very short period of time and perhaps squeak in before they get locked out.

    • Fixed Tags: