With the ongoing focus on RSA and in particular the well publicised hack and subsequent exploitation of the two factor authentication solution, SecurID, I thought it about time an objective response was made about RSA SecurID as opposed to the up in arms approach of “SecurID is broken”. More importantly, how can existing users of SecurID protect themselves until they get new tokens, whether through the normal lifecycle replacement or an RSA initiated full scale swap out.
First off, what exactly has happened?
It appears from the various security forums and technology websites that a targeted attack was made against RSA employees which was successful in providing the attackers with remote access into the internal RSA network. Through various account privilege escalation processes and ever deeper penetration the attackers managed to obtain access to various degrees of proprietary RSA SecurID information. This information has then been used to target a number of RSA SecurID corporate customers, the highest profile and publicised one being Lockheed Martin, the US defence contractor.
Unfortunately, to date RSA have not released any specific details of what the attackers managed to obtain but an understanding of how RSA SecurID tokens protect organisations is a good starting point to understand what may have occurred.RSA SecurID is a two factor (2FA) one time password (OTP) solution for providing authentication services. An RSA token has a 6 or 8 digit LCD that displays a number (the passcode) that changes every 60 seconds. The 2FA in this case is your username and private PIN (what you know) and the passcode (what you have – i.e. the passcode on your token). The changing passcode is created using a pseudo random number generator that is embedded within the token for which there is a seed code. On the back end authentication system that same seed code is used to enable this system to know what the current passcode that the token is displaying.
Given that the algorithm RSA uses to generate the next token passcode is believed to be known it becomes very clear that the seed value for each token is the critical component that must remain confidential to ensure that an attacker cannot predict the passcode of a given token at any given time. The supposition is that the direct attack on RSA resulted in the hackers obtaining either some or all of the seed codes for the issued and active RSA tokens. If this is the case then a large amount of the security that RSA SecurID tokens affords to individuals and organisations is potentially compromised. However, does this mean that we should all hold our hands up and say RSA is broken we have to change our authentication systems immediately?
My view is not immediately. Why? Well the seed code, although an extremely important component, doesn’t on its own provide an attacker who has access to this supposed harvest of seed codes the ability to log into any RSA protected customers system because;
1) A list of seed codes doesn’t immediately identify which token it relates too;
2) Even if there is a way of deriving the token serial number from the seed code (this is another supposition being touted) then there is no way of identifying remotely which token belongs to which corporate customer;
3) Even if the attacker somehow knows which seed codes belong to tokens owned by a particular customer (yet another supposition) then the attacker then needs to find out which of the customers users have SecurID tokens and which token belongs to which user and their associated user logon ID;
4) Even if an attacker knows which token a user has and their associated logon ID, the user still has a secret PIN component which assuming token lockouts are in place would protect against directed brute force attacks.
Let’s take points 1 and 2 as a possible given. We are still left with a number of protections in place. For point 3 a separate attack would need to be launched against a target RSA customer. One option would be to hack into the RSA customers network to obtain this information (e.g. perhaps it is stored in a spreadsheet or weakly protected staff HR/ID system) by which time the whole point of obtaining a users SecurID credentials is probably already immaterial.
Alternatively, and this is probably one of the most likely scenarios, social engineering techniques may be used combined with some good guesswork. Remember, if an attacker has the seed code then all they need to now obtain is the users token serial number, their username and their PIN. To achieve this then either some decent shoulder surfing in a public internet cafe of a user logging onto a protected site with SecurID credentials would be required (including seeing the token serial number), or combination of offline collection of the token serial number and then a targetted attack at an individual such as a spear phishing attack or installation of a key logger to obtain those critical final component details.
RSA have intimated that a complete token replacement programme may be their next step in remediating the security breach and improving user confidence, but in the mean time what protective measures can SecurID users take to reduce their risk exposure. Well, with most social engineering techniques the answer is end user awareness and education.
1) Don’t leave SecurID tokens lying around, especially in public places
2) Don’t wear your SecurID token around your neck and especially attached to the lanyard of your building access pass – this usually has the users name on and a good guess at usernames is usually quite productive – first.last maybe?
3) If possible try to make your corporate userid indirectly related to your name so that it isn’t guessable. E.g. have random letters or numbers in your ID such as John Smith might become smithjb9 or something equally unpredictable.
4) When using a SecurID token try to ensure that the serial number isn’t visible to prying eyes. If available for your token form factor then the leather keyfob protectors should be used as these cover the back of the token.
5) Instruct users never to reveal their token serial number to someone calling them pretending to be their helpdesk trying to sort out an issue with their token. Serial numbers should only be divulged to the users company help desk when they have called the help desk directly in response to troubleshooting an authentication issue.
6) Remind users about the dangers of unsolicited emails and phishing attacks.
7) Encourage users always to manually type in the URL of company resources when accessing corporate systems. This reduces the potential for a phishing email to trick the user into thinking they are logging into their company site.
Of course, some of RSA’s competitors are taking advantage of the current hiatus and offering extremely competitive pricing to encourage users to switch vendor. Is this the right solution? I’m not going to say yes or no, but it is worth considering a number of factors in your decision. Just like the Microsoft OS platform, RSA has probably been specifically targeted due to the massive coverage and crown jewel customers, such as Lockheed Martin. If everyone switches to a competitor then, just as Apple are starting to experience, the focus can start to turn onto the players gaining greater market penetration. Who’s to say if the competitors would be susceptible to the same or even different attacks as RSA? What is really needed now to help companies make this decision is some clear information from RSA on exactly what happened, and what measures are now being put in place to stop it re-occurring both at the original hack level, but also from a procedural and technical level around seed generation, storage and registration process. Anything less and the receipt of a replacement token is only a temporary solution which will not instil the confidence in a concerned user base to enable a decision to remain with RSA to be acceptable.
