Le marronnier actuel de la sécurité concerne SSL. Sur le papier, SSL, c'est très bien. Cela permet d'augmenter la sécurité de manière peu intrusive pour l'utilisateur. Dans les faits, l'implémentation laisse à désirer. NewsOft a déjà expliqué ça très bien dans un message de blog il y a quelque temps.
Le dernier évènement concerne un virus possédant du code signé par un certificat Malais valide. On peut imaginer que la clé privée a été volée, comme cela a été le cas pour les drivers signés de Stuxnet, mais une autre hypothèse émerge, sans doute plus plausible.
La Malaisie possède plusieurs sites gouvernementaux en .gov.my. Certains sont sécurisés en SSL. Un certificat signé par une autorité reconnue leur a donc été généré.
C'est un de ces certificats qui a été utilisé pour signer le code d'un virus, explication de l'attaque.
Si vous volez une clé privée associée à un certificat, alors il est possible de profiter de la confiance relative à ce certificat. Il se trouve que des certificats de serveurs webs en malaisie avait en utilisation de la clé l'autorisation de signature de code (premier problème). Dans une optique de moindre privilège, il est inutile de donner à un certificat authentifiant un site web une autorisation de signature de code! Si le pirate a la clé privée de ce certificat, alors il peut signer du code avec la confiance de ce certificat.
Si un pirate n'a pas la clé privée, il peut essayer de la calculer. Une clé RSA768 bits a été cassée en plus de deux ans et demis de calculs. Les docs de l'ANSSI recommandent des clés supérieures à 1536 bits (chercher "Niveau standard").
Dans le cas du certificat malais, la clé ne faisait que 512 bits, et c'est le second problème! On peut donc dire que sa factorisation est possible en un temps relativement court. [A ce sujet, je n'ai pas trouvé de bench précis sur ce point. Si quelqu'un a des valeurs chiffrées, je prends.]. [1]
Donc un autre scénario que le vol de clé privée se dessine: Un pirate scanne internet [2] à la recherche de certificats exhibant une clé faible et des privilèges de signature de code, casse la clé privée et l'utilise pour signer son code offensif. Aucune intrusion chez le possesseur de la clé est nécessaire. HeadShot.
Nous savons que des CA sont à éviter, il faudrait désormais un mécanisme permettant de surveiller les certificats exhibant des particularités "faibles". Typiquement un certificat signé avec une clé de 512 bits ne doit pas être de confiance indépendamment de la validité de sa signature par une CA.
Note:
[1] Si quelqu'un sait casser une clé avant le 16 décembre, il peut profiter d'un certificat SSL valide! Le prendre ici. 512 bits de clé. Chrome refuse le téléchargement de la page pour cause de révocation, by the way.
Le dernier évènement concerne un virus possédant du code signé par un certificat Malais valide. On peut imaginer que la clé privée a été volée, comme cela a été le cas pour les drivers signés de Stuxnet, mais une autre hypothèse émerge, sans doute plus plausible.
La Malaisie possède plusieurs sites gouvernementaux en .gov.my. Certains sont sécurisés en SSL. Un certificat signé par une autorité reconnue leur a donc été généré.
C'est un de ces certificats qui a été utilisé pour signer le code d'un virus, explication de l'attaque.
Si vous volez une clé privée associée à un certificat, alors il est possible de profiter de la confiance relative à ce certificat. Il se trouve que des certificats de serveurs webs en malaisie avait en utilisation de la clé l'autorisation de signature de code (premier problème). Dans une optique de moindre privilège, il est inutile de donner à un certificat authentifiant un site web une autorisation de signature de code! Si le pirate a la clé privée de ce certificat, alors il peut signer du code avec la confiance de ce certificat.
Si un pirate n'a pas la clé privée, il peut essayer de la calculer. Une clé RSA768 bits a été cassée en plus de deux ans et demis de calculs. Les docs de l'ANSSI recommandent des clés supérieures à 1536 bits (chercher "Niveau standard").
Dans le cas du certificat malais, la clé ne faisait que 512 bits, et c'est le second problème! On peut donc dire que sa factorisation est possible en un temps relativement court. [A ce sujet, je n'ai pas trouvé de bench précis sur ce point. Si quelqu'un a des valeurs chiffrées, je prends.]. [1]
Donc un autre scénario que le vol de clé privée se dessine: Un pirate scanne internet [2] à la recherche de certificats exhibant une clé faible et des privilèges de signature de code, casse la clé privée et l'utilise pour signer son code offensif. Aucune intrusion chez le possesseur de la clé est nécessaire. HeadShot.
Nous savons que des CA sont à éviter, il faudrait désormais un mécanisme permettant de surveiller les certificats exhibant des particularités "faibles". Typiquement un certificat signé avec une clé de 512 bits ne doit pas être de confiance indépendamment de la validité de sa signature par une CA.
Note:
[1] Si quelqu'un sait casser une clé avant le 16 décembre, il peut profiter d'un certificat SSL valide! Le prendre ici. 512 bits de clé. Chrome refuse le téléchargement de la page pour cause de révocation, by the way.
[2] Ce travail de scan des sites HTTPS est effectué en tâche de fond par l'EFF, sans doute les pirates ont ils profité de ces bases?
Apparemment, factoriser 512 bits n'est pas impossible (mais je ne peux pas confirmer moi-même, n'étant pas un expert):
RépondreSupprimer* http://blog.fox-it.com/2011/11/21/rsa-512-certificates-abused-in-the-wild/
* https://github.com/GDSSecurity/cloud-and-control/tree/master/gnfs-info
J'ai refait une (rapide) recherche sur ces factorisations. Elles sont effectivement réalisables en pratique.
RépondreSupprimerEn 1999 (!) une clé 512 avait été cassée http://it.slashdot.org/story/99/08/29/0213230/512-bit-rsa-key-cracked.
Et de manière plus récente (2009), opera indiquait quelques semaines à quelques jours http://my.opera.com/securitygroup/blog/2009/09/29/512-bit-rsa-key-breaking-developments