Hack RSA SecurID : l'histoire n'est pas terminée !

Beaucoup de personnes dans la communauté de la sécurité informatique se demandent pourquoi tant de silence de la part de RSA SecurID. La phrase qui ressort le plus est : « RSA Silent About Compromise For 7 Days – Assume SecurID Is Broken ». Effectivement, le doute n’est pas bon en sécurité des systèmes d’information. Mais que fait donc RSA ?

Selon moi, comme mentionné dans mon 1er billet, cette histoire est un évènement marquant de la sécurité informatique.

Actuellement les hypothèses fusent sur la nature du Hack de RSA SecurID, plusieurs d’entre elles semblent finalement se confirmer. La question est de savoir si l’algorithme propriétaire de RSA SecurID est cassé ou simplement si les « Seeds » sont dans la nature. Les dernières informations vont plus dans le sens d’un vol des « Seeds » . D’après le dernier article de SecurityVibes, un des membres affirme que les « Seeds » sont volés. Cette information n’est pas encore confirmée. En supposant que cette hypothèse est vérifiée, on peut se demander ce que l’on peut faire avec ces « Seeds » ? Afin de mieux comprendre, voici un petit « training 101 » sur le fonctionnent de RSA SecurID.

RSA SecurID est un One Time Password (OTP) de type « time based ». Dans chaque Token ou Authentifieur, il y a un secret d’une longueur de 128 bits (le fameux « Seed » - AES-128 block cipher). Ceci est valable uniquement pour la nouvelle génération des Tokens (SID700, SID800, etc). Nous appellerons ce « Seed », le secret partagé. Afin de générer le Tokencode sur l’authentifieur (normalement 6 digits chaque minute), l’idée est d’utiliser le secret partagé et le temps (Time UTC) comme paramètres dans une simple fonction de hachage cryptographique. Cette fonction de hachage est propriétaire pour les OTP RSA SecurID. Chacun est libre de penser ce qu’il veut sur cette approche ! Personnellement, je préfère le principe de Kerckhoffs.

Ce que je viens d’apprendre, et cela est surprenant, c’est que RSA SecurID utilise aussi le numéro de série comme paramètre dans la fonction de hash. Ce numéro est unique par Token. Il est inscrit au dos des Token Hardware. D’après les quelques essais que j’ai fait, je pense que l’on peut utiliser directement ce numéro de série.

D'après l'article de SecurityVibes citant l'opinion de Paul C Dwyer de la International Cyber Threat Task Force JS pose la question si le numéro de série est ensuite encodé pour fabriquer un Serial Number Interne au Token sur une longueur de 64 bits.

Mais cela reste à vérifier formellement !

Le shéma suivant illustre le calcul présumé du TokenCode selon l'hypothèse qu'il n'y a pas de chiffrement du serial nunber:

Pour résumer, afin de générer le TokenCode, il nous faut 3 paramètres:

• Le numéro de série du Token
• Le secret partagé (« Seed ») (128 bits ou 64 bits pour les anciens Authentifieur)
• Le temps (Time UTC)

Pour le moment, et partant du principe que l'hypothèse est juste, cela ne nous donne qu’un seul facteur du mécanisme d’authentification, et par définition, si l’on veut avoir une authentification forte, il nous faut au minimum un deuxième facteur. Dans le cas de RSA SecurID, il s’agit d’un Pin Code. Généralement celui-ci est numérique, voire alpha numérique, et d’une longueur de 4 à 8 caractères. Pour bénéficier d’une authentification forte, on combine alors le PinCode et le Tokencode. Selon la terminologie RSA, cela s’appelle le PASSCODE.

Ainsi, on a : PASSCODE = PinCode + TokenCode.



Revenons à notre hypothèse. Soit les « Seeds » sont dans la nature. Quelques questions se posent :

• qui détient ces « Seeds » ?
• peut-on les trouver facilement dans la nature ?
  
• peut-on les acheter pour quelques Dollars ?
• et si la réponse était oui… ?

Comment ensuite attaquer une entité qui utilise RSA SecurID comme moyen de défense ? La réponse n’est pas simple ! Si l’hypothèse est qu’il suffit de lire le numéro de série gravé sur un Token Hardware et de posséder le « Seed » correspondant au Token alors il faut ensuite connaitre le PinCode et le Username. Comment s'y prendre ? Je vous laisse imager....

Les scénarii sont multiples. Peut être un modèle de menace peut aider.

Peut être un autre article ? Si vous avez envie :-) Je suis preneur !

Après un moment de réflexion, une analyse de menace, des recherches, des échanges, il n’est pas facile aujourd’hui de se faire une idée précise du risque encouru par les entités qui utilisent SecurID. Mais comme mentionné au début de ce billet, le doute est le pire ennemi de la sécurité des systèmes d’information. Enfin si j'ai bien compris !

vos commentaires sont les bienvenus !

Note: Merci à Anne Gosselin (Stagiare chez MARET Consulting - Master in cryptography) et JS, newsoft, Antonio pour votre aide à la rédaction de ce billet.

SMA, le 2011-04-01

Infos récentes:

Par le SANS:

The Recent RSA Breach - Imagining the Worst Case, And Why it Isn't Time to Panic (Yet)

Zataz:
SecurID de RSA compromis ?