12,90 € TTC
p. 06 Objection votre honneur, l’IPA n’était pas coupable
p. 14 Azure AD/Office 365 : le point de vue de la réponse à incident
p. 20 La sécurité des bornes de recharges électriques
p. 28 Introduction
p. 29 Déploiement de correctifs à l’aide d’Ansible
p. 38 Analyse statique et automatisée de code
p. 46 Dépilons les couches de CVE
p. 56 Une nouvelle génération de rootkits sous Linux
p. 64 Le bourbier des dépendances : confusion et sabotage
p. 74 Alcasar : le NAC autoproclamé
« Il existe deux types de cryptographie dans le monde : la cryptographie qui protège vos documents de la curiosité de votre petite sœur et celle qui empêche les gouvernements les plus puissants de lire vos fichiers. ». Quand Bruce Schneier écrivait ceci en 1998, peu de citoyens de pays occidentaux considéraient l’intérêt de protéger leurs communications d’oreilles indiscrètes et surtout pas de leur gouvernement.
Un peu plus de vingt ans plus tard, l’opinion du grand public en matière de protection de la vie privée a fortement évolué. La fourniture par Meta du contenu des échanges entre une mère et sa fille dans le cadre d’une enquête pour un avortement dans l’État du Nebraska [1] va probablement encore accroître la pression des utilisateurs quant à des mécanismes de chiffrement ne permettant plus l’accès aux données pour les entreprises opérant le service. Meta s’est d’ailleurs fendu d’une communication quelques jours plus tard pour rappeler qu’ils travaillaient sur l’activation par défaut du chiffrement de bout en bout (E2EE) [2] afin de rendre techniquement impossible la restitution des échanges en clair.
Au milieu des années 2010, la crainte du terrorisme permettait aux autorités politiques de justifier le besoin de mettre en place des clefs de recouvrement dans les logiciels contre l’avis des experts et notamment de l’ANSSI. Il semble qu’aujourd’hui le danger de ces pratiques et leur inefficacité commencent à être entendus par les politiques au point que l’État propose désormais une messagerie qui intègre du E2EE à ses agents [3]. De plus, l’accès au pouvoir de dirigeants clivants dans certains pays occidentaux a concouru à faire évoluer l’opinion publique quant au besoin de protéger la sécurité de ses échanges numériques, y compris vis-à-vis de leur gouvernement.
Techniquement, cela induit plusieurs défis. Le premier est de l’ordre de l’expérience utilisateur. Il s’agit à la fois de ne pas complexifier l’utilisation pour le grand public des outils et de ne pas induire de régressions fonctionnelles. En particulier, la sauvegarde, l’indexation des messages et des fichiers échangés, la récupération des données en cas de perte des identifiants et leur accès depuis de multiples terminaux devra rester possible afin de ne pas rendre le fonctionnement inaccessible pour les profanes. Le second challenge est que l’activation du E2EE pour tous les messages met à mal le modèle économique des principaux fournisseurs de messageries instantanées tels que Meta et Google qui s’appuient sur les messages échangés pour proposer de la publicité ciblée et pour entraîner leurs moteurs d’IA. Si l’usage de publicité ciblée peut rester possible en recourant à de nouvelles primitives cryptographiques proposées par le chiffrement homomorphe [4], il est certain que les fournisseurs de service dont le modèle économique repose uniquement sur la valorisation des données utilisateurs aient beaucoup à perdre à mesure que les mécanismes d’E2EE se généralisent.
Pour finir, on pourra s’étonner que si les questions de vie privée sont particulièrement discutées sur les logiciels de messageries instantanées, ce débat ne semble pas du tout toucher le domaine de l’e-mail. S/MIME, s’il est parfois déployé en environnement professionnel, l’est le plus souvent uniquement pour la signature, très rarement pour le chiffrement des messages. Quant à OpenPGP, faute d’implémentation simple, il a toujours été boudé par la majorité des utilisateurs. Ironie de l’histoire, il s’agit pourtant d’une des premières applications grand public du E2EE…
Cédric Foll / cedric@miscmag.com / @follc
[1] https://france24.com/fr/amériques/20220811-facebook-critiqué-après-avoir-fourni-à-la-justice-des-messages-sur-un-avortement-illégal-au-nebraska
[2] https://about.fb.com/news/2022/08/testing-end-to-end-encrypted-backups-and-more-on-messenger/
[3] https://tchap.gouv.fr
[4] https://fr.wikipedia.org/wiki/Chiffrement_homomorphe
Face à la transformation digitale de notre société et l’augmentation des cybermenaces, la cybersécurité doit être aujourd’hui une priorité pour bon nombre d’organisations. Après plus de 20 années de publications et de retours d’expérience, MISC apporte un vivier d’informations techniques incontournable pour mieux appréhender ce domaine. Précurseur sur ce terrain, MISC a été fondé dès 2002 et s’est peu à peu imposé dans la presse française comme la publication de référence technique en matière de sécurité informatique. Tous les deux mois, ses articles rédigés par des experts du milieu vous permettront de mieux cerner la complexité des systèmes d’information et les problèmes de sécurité qui l’accompagne.
À l’époque où j’ai commencé l’informatique, lorsqu’une faille de sécurité était découverte sur une brique applicative, le passage des mises à jour sur les serveurs se faisait souvent à renfort de ./configure;make;make install. Certains vieux barbus restent nostalgiques de l’époque dorée où recompiler sendmail chaque semaine sur autant de distributions Linux qu’ils géraient de serveurs constituait le cœur de leur travail. Pour nos Bastard Operator From Hell, la valeur professionnelle se mesurait au nombre d’options de compilations connues sur gcc et leur capacité à modeler chaque serveur à leur image en s’éloignant au maximum des standards. Si certains regardent de haut les plus jeunes qui ne savent même plus recompiler un noyau, il convient de rappeler que le nombre de serveurs gérés par un admin sys a souvent été multiplié par un facteur dix à cent en vingt ans.
Alcasar est un portail captif (NAC) utilisé pour filtrer et contrôler les utilisateurs ayant accès à un réseau ouvert sur le Web. C’est un projet français développé initialement au sein du ministère de la Défense. Open source et maintenu par une petite communauté, ce projet répond à un besoin bien réel, mais malheureusement de manière imparfaite : utilisation par défaut du HTTP, emploi de MD5 à des fins de sécurité, utilisation de « crypto-maison », mots de passe utilisateurs transmis en clair… Au final, Alcasar est un NAC au service de l’usurpation d’identité de ses utilisateurs.
Lors du développement d'une application, un développeur va intégrer des dépendances tierces à son projet. Ces dépendances peuvent provenir de dépôts publics ou internes à l'entreprise. Les différents langages de programmation fournissent des gestionnaires de paquets pour faciliter l'installation et la mise à jour de ces dépendances (pip pour Python ou npm pour JavaScript par exemple). La confiance accordée à ces gestionnaires de paquets ouvre la voie à un nouveau type d'attaque permettant à un attaquant d'installer des dépendances malveillantes au sein du système d'information d'une entreprise. Cet article présente la possibilité de corrompre la chaîne d'approvisionnement (supply chain) d'un projet via ses dépendances privées, dont la sécurité est rarement remise en question.