RSA mis à mal par un chercheur ?
La publication le 2 mars d’un papier attribué au célèbre cryptograhe P-C. Schnorr a attisé la curiosité de la communauté par la dernière phrase de son abstract "This destroyes the RSA cryptosystem.". Le papier étant daté de 2019, et cette dernière annonce, mal orthographiée, ne figurant pas dans l’article, la communauté a d’abord considéré cela comme la farce d’une tierce personne qui aurait ajouté des fausses infos pour faire croire que RSA était cassé. Schnorr a toutefois confirmé avoir publié cet article tout en précisant qu’il s’agissait de la mauvaise version. La mise à jour ayant été publiée le 3 mars. Alors qu’en est-il ? La méthode publiée dans ce papier "casse"-t-elle bien RSA comme le prétend Schnorr ?
La sécurité de l’algorithme de cryptographie asymétrique RSA repose sur la complexité de la factorisation d’entiers en nombres premiers. Le coût de la factorisation est exprimé en fonction du nombre de chiffre du nombre à factoriser : la "force-brute" a une complexité O(1/2 exp(k)), qualifiée d’exponentielle. Les meilleurs algorithmes de factorisation ont actuellement un temps sous-exponentiel. Dans son papier, Schnorr annonce pouvoir factoriser des modules de 400 bits et 800 bits en respectivement 4.2·10⁹ et 8.4·10¹⁰ opérations, soit un coût polynomial. Si cela s’avère correct, cela remettrait effectivement en cause la sécurité de l’algorithme RSA. Plusieurs cryptologues ont déjà émis un avis sur les réseaux sociaux ; certains tentant de reproduire les résultats de Schnorr sans succès. D’autres reprochent également le manque de preuve associée à l’importance de l’annonce qu’est le cassage de RSA (résolution de certains challenges publiques RSA par exemple). Sans compter que ce n’est pas la première fois que Schnorr prétend pouvoir factoriser des entiers en temps polynomial (1991, 2009), sans qu’il n’ait jamais démontré pouvoir réellement le faire.
Une nouvelle technique d’attaque pour forger des fichiers pdf malveillants
Les fichiers au format pdf peuvent être signés par une autorité quelconque pour en assurer l’innocuité par exemple. Seulement, les lecteurs/éditeurs de pdf (Adobe et autres) permettent un certain nombre de modifications sur le document, sans que ça n’invalide la signature qui serait déjà apposée sur le document. Un exemple : remplir un pdf qui contient des champs de texte, des boutons et autres cases à cocher. Par cette nouvelle attaque, il serait possible d’exploiter ces fonctionnalités pour faire un fichier pdf qui, sans cliquer sur un bouton spécial, contient un certain contenu, et qui, si l’utilisateur clique sur le petit bouton quelconque dans le formulaire, remplace le contenu du pdf par un autre qui était déjà présent, mais caché sous le formulaire initial. Par conséquent, l’utilisateur qui signe le document, le regarde, voit un formulaire quelconque, et assume – à tort – la légitimité du fichier. Une fois le document signé, l’attaquant récupère le pdf signé, clique sur le bouton qui modifie le contenu par celui malveillant et enregistre à nouveau le fichier pdf, lui permettant d’obtenir un fichier pdf signé par une autorité de confiance.
Les traqueurs en ligne se tournent de plus en plus vers la technique de dissimulation CNAME
Le suivi des utilisateurs sur un site internet à des fins publicitaires se fait généralement via des cookies et un script JavaScript. La régie publicitaire héberge ce script sur son propre domaine, disons regiepublicitaire.fr, et le distribue à tous ses clients/partenaires. Un utilisateur visitant n’importe quel site partenaire va ainsi contacter regiepublicitaire.fr pour récupérer le script. L’utilisation d’un point centralisé pour obtenir le script de tracking permet aux bloqueurs de publicité d’aisément repérer regiepublicitaire.fr et d’interdire son accès. Cela correspond aux extensions de type uBlock Origin mais aussi aux navigateurs, dont Firefox et Safari en tête, qui depuis plusieurs années font la guerre aux technologies de pistage.
Pour contrer ce comportement de plus en plus en vogue, les régies publicitaires utilisent une nouvelle technique, nommée CNAME Cloaking. CNAME est le nom d’un enregistrement DNS permettant de faire correspondre un nom de domaine à un autre. Dans ce le cas présent, l’idée est d’utiliser ce système pour rediriger abcdefgh.monsite.fr/tracking.js vers regiepublicitaire.fr/tracking.js. Ainsi, chaque site utilise son propre sous-domaine aléatoire et personnalisé pour charger le script, empêchant alors les bloqueurs de publicités de facilement les détecter.
L’article publié le 23 février 2021 par Dimova et al. note plusieurs points importants. Tout d’abord, d’après leur analyse des sites les plus utilisés, cette technique est de plus en plus déployée au fil des ans, semblant remplacer progressivement les techniques plus classiques. Ensuite, et c’est là que le bas blesse réellement, passer d’un "third-party" (site fournissant le script différent de l’origine) à un "first-party" (le site d’origine charge le script depuis le même nom de domaine) entraine de lourdes conséquences dans la sécurité. En effet, le navigateur base une bonne partie de son modèle sur ce principe d’origine. Cela modifie par exemple son comportement pour l’accès aux cookies, permettant de traquer les utilisateurs ou… de gérer leur identification dans les applications. En utilisant un script third-party, seuls les cookies correspondant à regiepublicitaire.fr sont disponibles pour être envoyés vers ce site. A contrario, en utilisant abcdefgh.monsite.fr, l’ensemble des cookies stockés pour monsite.fr sont fournis. Autrement dit, on envoie à la régie publicitaire à la fois l’identifiant de l’utilisateur mais aussi son cookie de session. Dans l’analyse de Dimova et al, 95% des sites utilisant le CNAME Cloaking laissent fuiter les cookies via les headers HTTP. En terme de contre-mesure, l’extension uBlock Origin a publié une mise à jour permettant de détecter ce comportement. Pour cela, elle requiert des droits supérieur afin d’analyser les requêtes vers les sous-domaines
Microsoft publie des patchs de sécurité pour plusieurs vulnérabilités 0-day affectant Exchange
Microsoft a publié plusieurs patchs de sécurité à destination des serveurs Exchange 2013, 2016 et 2019, (les versions Exchange 2010 ne sont pas directement affectées). Les failles corrigées sont identifiées par quatre CVE : CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065. Ces vulnérabilités, qui permettent des élévations de privilèges, des contournements des outils d’authentification et encore de prendre le contrôle à distance d’un serveur Exchange attaqué, nécessitent, selon Microsoft, que les attaquants aient la capacité d’établir une connexion avec le serveur visé sur le port 443 pour aboutir. Bien qu’a priori peu sophistiquées lorsqu’elles sont utilisées séparément, Microsoft explique que les vulnérabilités sont exploitées par un groupe associé à la Chine. Baptisé "Hafnium", ce groupe vise principalement des entités américaines dans différents secteurs d’activités. Par mesure de précaution, Microsoft a donc préféré ne pas attendre le Patch Tuesday pour proposer un correctif à destination des serveurs Exchange.
Y’a plus, je laisse ?
Nous avons largement évoqué l’attaque SolarWinds dans ce blog. La complexité de la chaîne d’attaque a impressionné tous les experts ; dans une tentative de défense à la limite de la malhonnêteté, la Direction de SolarWinds n’a rien trouvé de mieux que de faire porter la responsabilité à…un stagiaire.