Logo

Tous publics
Afficher seulement les articles tous publics
Public technique
Affichement seulement les articles techniques

Comprendre et implémenter Content-Security-Policy

Benjamin 08 mars 2019 Public technique

Lorsque nous faisons des audits web pour nos clients, nous relevons parfois que certains entêtes de sécurité sont manquants dans les réponses du serveur web : X-Content-Type-Options, X-Frame-Options, X-XSS-Protection... Toutefois, un entête dont nous constatons systématiquement l'absence est Content-Security-Policy. Nous pensons que cet état de fait est dû à la fois à la relative "jeunesse" de cet entête, mais aussi sa complexité de mise en place par rapport aux autres.

Nous allons dans cet article tenter de faire ressortir l'impact très positif que peut avoir cet entête sur la sécurité des sites web, et détailler la manière de la paramétrer afin, nous l'espérons, de faciliter son adoption.

CSP, kézako ?

Content-Security-Policy est un entête de sécurité HTTP dont la première spécification date de février 2015, mise à jour par une deuxième version en décembre 2016, et toujours en cours d'évolution via une troisième version. Concrètement, cet entête renvoyé par le serveur indique aux navigateurs des utilisateurs quelles sources sont autorisées à charger du contenu sur le site concerné.

Prenons un cas simple : vous faites l'inclusion sur votre site de polices d'écriture particulières via un service externe. De plus, vous utilisez un service de mesure d'audience externe. En paramétrant correctement cet entête, vous allez pouvoir indiquer que le navigateur des utilisateurs est autorisé à charger sur votre site des polices d'écriture et des scripts depuis les serveurs de Google (et le vôtre, si nécessaire), mais pas depuis d'autres serveurs.

De quelles menaces concrètes cet entête protège-t-il ?

Premier cas : les failles Cross-Site Scripting

Les failles Cross-Site Scripting (ou XSS) proviennent d'un manque de filtrage des saisies utilisateurs. Elles permettent à un attaquant de charger du code Javascript qui s'exécutera dans le navigateur des utilisateurs.

Le code malicieux exécuté peut avoir divers objectifs : entres autres, récupérer toutes les saisies utilisateurs et les envoyer sur le serveur de l'attaquant (nom d'utilisateur, mot de passe, données personnelles, numéro de carte bancaire...) ou miner des cryptomonnaies en utilisant les ressources de l'ordinateur des utilisateurs (cette attaque s'appelle le cryptojacking).

Lorsqu'il découvre une faille XSS, un attaquant va tenter d'infecter un maximum d'utilisateurs. Pour cela, il va écrire du code qui soit sera injecté en une seule fois directement dans le site web vulnérable (on parle de script inline), soit il sera chargé depuis son propre site, donc depuis une adresse IP ou un nom de domaine différent du site web vulnérable.

Dans ce cas, Content-Security-Policy permet d'empêcher un attaquant de charger son script sur la page, qu'il soit inline ou hébergé sur son propre serveur, puisqu'il n'aura pas été explicitement approuvé dans la politique.

Deuxième cas : chargement indélicat de publicités

Il a été observé que certaines entités ont injecté du code Javascript au sein de sites web légitimes, et pourtant non vulnérables (à priori), à fin de servir leurs propres intérêts. Comment ? Ces entités fournissent en fait un accès Internet à leurs clients, et ont pris la liberté de modifier à la volée les sites web consultés.

Il s'agit par exemple du Fournisseur d'Accès Internet américain Comcast, qui injectait du code Javascript de plusieurs centaines de lignes dans les pages consultées par ses visiteurs afin de promouvoir ses équipements type modem et routeurs. Selon la société, il s'agissait d'avertir les utilisateurs qu'ils utilisaient un modem obsolète.

La situation s'est produite sur la connexion WiFi fournie par certains hôtels Marriott à ses clients, ou encore sur la connexion WiFi fournie par AT&T à certains aéroports. Dans les deux cas, la raison invoquée était de trouver des sources de revenus permettant de financer le réseau WiFi aux usagers.

Là encore, Content-Security-Policy permet d'empêcher des sociétés et prestataires de charger leur propre contenu à la volée sur une page, puisqu'il n'aura pas été explicitement approuvé dans la politique.

Troisième cas : librairie externe attaquée

De plus en plus de librairies externes sont hébergées sur des CDN (Content Delivery Networks) et chargées depuis ces serveurs sur les sites qui en font l'usage. On pense notamment à jQuery, Bootstrap ou encore FontAwesome, pour les plus connues. Ces scripts sont donc chargés sur des milliers de sites, qui choisissent d'utiliser ces CDN plutôt que de le servir à leurs utilisateurs depuis leur propre serveur. Cela permet de réduire la bande-passante et d'accélérer les temps de chargement.

Les attaquants y ont vu une occasion incroyable : attaquer un seul serveur, celui qui héberge le code source des librairies, permet de compromettre les milliers de serveurs qui l'utilisent. Cela s'est produit courant 2018, lorsque plusieurs librairies Javascript chargées entre autres par TicketMaster (et près d'un millier de sites de e-commerce) ont été attaquées par le groupe d'attaquants Magecart. Les clients de ces sites e-commerce se sont fait dérober leurs données personnelles et de paiement.

Le chercheur en sécurité Scott Helme a quant à lui constaté le même problème sur de nombreux sites Internet, notamment le site des Cours fédérales américaines, le site de la Sécurité Sociale anglaise, ou encore le site d'un département d'Australie. Tous ces sites chargeaient la librairie BrowseAloud, qui permet aux malvoyants de lire les contenus web, et qui s'est faite attaquer par un groupe d'attaquants. Le but était cette fois de miner des cryptomonnaies sur les ordinateurs des visiteurs.

Dans ce cas particulier, Content-Security-Policy aurait aidé à se protéger, mais n'aurait pas forcément été suffisant. Si l'attaquant utilise la librairie pour charger un fichier se trouvant sur son propre serveur, Content-Security-Policy empêche le code situé sur le serveur de l'attaquant de se charger. En revanche, si l'attaquant compromet la librairie en ajoutant son propre code dans la librairie, Content-Security-Policy utilisé seul est inefficace : il faut alors utiliser Sub-Resource Integrity.

Comment définir une Content-Security-Policy ?

L’objectif de la première étape est de connaître tous les services externes que vous utilisez : régies publicitaires, outils de mesures d'audiences, librairies Javascript, polices d'écritures, images, services de cartographie, etc. Il convient de lister, pour chacun de ces services, le type de ressource chargée, ainsi que les noms de domaine qui hébergent le contenu chargé.

Par exemple, dans le cas de notre site vitrine (algosecure.fr), cette cartographie des services externes peut se décliner de la manière suivante :

Service Type de ressource Nom de domaine
Mapbox Images, scripts et données de la carte interactive de notre page Contact *.mapbox.com
Notre propre instance de Matomo Scripts et images pour la mesure d'audience nostats.algosecure.fr
YouTube Une iframe, pour afficher une vidéo www.youtube.com
Le site de l'université de Carnegie-Mellon Une image, pour afficher le logo CERT www.sei.cmu.edu

La seconde étape a pour objectif de construire la politique. Il s'agit d'indiquer, pour chaque type de contenu, les sources autorisées. Nous allons également ajouter :

  • une instruction qui permet, pour tous les types non-définis dans notre politique (images, scripts et iframes), d'autoriser le chargement depuis notre propre nom de domaine (c'est à dire 'self'),
  • une instruction qui permet de journaliser les erreurs de chargement.

C'est en effet l'une des fonctionnalités bien pensées de la CSP : si du fait d'un mauvais paramétrage, votre politique venait à bloquer des ressources légitimes dont vous auriez souhaité autoriser le chargement, ces blocages seront journalisés afin de déterminer précisément quelle source a essayé de charger du contenu et quelle instruction de votre politique a été enfreinte, afin de vous aider à améliorer votre CSP. Le site Report-URI permet à cet effet de récolter ces journaux et vous les présenter de manière intelligible. Le service est gratuit pour les "petits" sites, et avec des tarifs progressifs pour les sites plus importants.

Par ailleurs, la CSP possède un mode nommé "Report Only", qui permet dans un premier temps de ne pas bloquer les ressources qui n'auraient pas été autorisées dans la CSP. Seuls les rapports vous seront envoyés, et aucun ressource ne sera bloquée dans la navigateur des clients.

Finalement, notre politique est donc la suivante :

Content-Security-Policy-Report-Only "default-src 'self' nostats.algosecure.fr data: *.mapbox.com www.sei.cmu.edu; frame-src www.youtube.com; report-uri https://algosecure.report-uri.com/r/d/csp/enforce"

Après avoir vérifié que la politique fonctionne correctement et ne bloque pas la navigation sur notre site, nous changerons l'instruction Content-Security-Policy-Report-Only en Content-Security-Policy. Tant que nous laissons le mode Report-Only, rien ne sera bloqué, la navigation ne sera pas impactée côté client.

La dernière étape consiste à d'implémenter cette politique dans le composant du serveur qui sert les pages de votre site à vos utilisateurs.

Implémenter la Content-Security-Policy

Apache

Nous plaçons l'instruction suivante dans le fichier global security.conf (ou dans les paramètres du vhost si l'on possède plusieurs sites hébergés sur le même serveur) :

Header always set Content-Security-Policy-Report-Only "default-src 'self' nostats.algosecure.fr [...]"

Il faut ensuite activer le module headers, puis redémarrer Apache :

sudo a2enmod headers
sudo service apache2 restart

Nginx

L'instruction suivante est à placer dans le contexte serverdu fichier de configuration :

add_header Content-Security-Policy-Report-Only "default-src 'self' nostats.algosecure.fr [...]";

Puis on recharge la configuration :

nginx -s reload

IIS

Par interface graphique, il faut aller dans les paramètres des "En-têtes de réponse HTTP", puis ajouter un entête personnalisé :

Il est également possible d'injecter la section de code suivante dans le contexte customHeaders du contexte httpProtocol de votre fichier web.config :

<add name="Content-Security-Policy-Report-Only" value="default-src 'self' nostats.algosecure.fr [...]" />

Les modifications prennent effet immédiatement.

Tester sa Content-Security-Policy

Une fois la politique implémentée, vous pouvez vous rendre sur le site cspvalidator.org qui vous indiquera si la politique en place est valide.

Surveiller sa Content-Security-Policy

À ce stade, la politique est implémentée, mais de par l'utilisation du mode Report-Only, rien n'est bloqué côté client. Il faut surveiller que la politique ne crée pas d'interférences avec l'affichage du site, la retravailler pour ajouter ou supprimer des sources, dans l'objectif de passer du mode Report-Only au mode "normal".

Pour cela, le site Report-URI fonctionne bien : il permet d'afficher toutes les ressources qui seraient bloquées côté client. Il convient d'analyser ces blocages, déterminer ceux qui sont légitimes ou non, puis faire évoluer votre Content-Security-Policy en conséquence.

Voici par exemple un rapport d'une ressource ayant été bloquée chez des clients. Ce rapport est en l'occurrence assez simple à comprendre : nous avions inclus une instruction de style au sein du code HTML (donc inline) d'une des pages du site, alors que nous n'avions pas explicitement autorisé la source de contenu inline. Pour résoudre le problème, il nous a suffit de déplacer cette instruction dans un fichier de style CSS (comme ça aurait dû l'être dès le début).

Il faut ainsi passer sur chaque blocage, et évaluer s'il est pertinent ou non d'autoriser le chargement de la ressource sur votre site.

Une fois que vous vous serez assuré que tout fonctionne correctement, vous pourrez supprimer la partie -Report-Only du nom de l'entête configuré dans votre serveur web, puis recharger la configuration. Félicitations, votre Content-Security-Policy est en place et fonctionnelle !

Conclusion

Content-Security-Policy est pour nous l'un des entêtes HTTP les plus puissants en termes de sécurité. Il vous permet de garder la main sur les ressources externes chargées sur votre site. Bien que cela ne constitue pas une protection suffisante pour se prémunir de tous types d'attaques, cet entête offre un niveau de sécurité assez élevé aux sites qui l'implémentent. Son taux d'adoption mérite d'être amélioré. Pour se prémunir encore davantage à l'injection de contenu malveillant sur un site, il est possible d'utiliser Sub-Resource Integrity : ce sera peut-être le sujet d'un prochain article.

Des doutes quant à l'implémentation de cet entête ? N'hésitez pas à nous contacter, nous nous ferons un plaisir de répondre à vos interrogations :)

Arrivée du RGPD : quelles obligations pour les entreprises ?

Jean-Philippe 29 janvier 2018 Tous publics

Cet article décrit les grandes étapes à réaliser pour se mettre en conformité au RGPD. Toute entreprise traitant des données personnelles pour son activité devra se conformer aux obligations du RGPD, applicable à partir de mai 2018. La responsabilité des organismes est renforcée, et tout organisme concerné devra à minima démontrer, à partir de cette date, qu'elle a entamé les démarches pour se conformer au règlement, sous peine de lourdes sanctions financières.

Les mesures techniques et organisationnelles appropriées devront être entreprises pour garantir notamment la confidentialité, l'intégrité, la disponibilité et la résilience des systèmes et des services de traitement.

Objectifs du règlement européen RGPD

Le règlement européen RGPD (Règlement Général de Protection des Données) ou GDPR (General Data Protection Regulation) vise à renforcer à renforcer les droits des personnes concernées, notamment en améliorant la protection des données.

Tout traitement sur des données à caractère personnel doit, en principe, respecter les fondements suivants :

  • le consentement de la personne concernée,
  • le respect des libertés et des droits fondamentaux de la personne,
  • le respect des obligations légales en termes de sécurité,
  • les données doivent être collectées pour des finalités explicites, spécifiques et légitimes.

Ces dispositions seront applicables pour tous les états membres de l'Union Européenne; la GDPR remplacera la Directive Européenne sur la protection des données personnelles adoptée en 1995.

Qui est concerné par le RGPD ?

Le RGPD s'applique aux traitements de données à caractère personnel. Les données personnelles sont des données qui identifient, même indirectement, une personne physique. Il peut s'agir d'un fichier de gestion des ressources humaines, d'un fichier clients et prospects, comme d'un simple numéro de badge ou d'une adresse IP.

Si la définition des données personnelles est particulièrement large, celle de traitement ne l'est pas moins, puisqu'il s'agit de toute opération qui porte sur des données personnelles.

Finalement, toutes les entreprises et les administrations traitent des données personnelles et sont donc concernées par le RGPD.

Les 6 grands principes définis par le RGPD

- Licéité, transparence et loyauté : le traitement doit être licite, c'est à dire reposer sur le consentement de la personne concernée; les personnes concernées par un traitement les concernant doivent être informées (transparence); le traitement doit correspondre à la description faite (loyauté).

- Limitation sur les finalités : les finalités sur les traitements doivent être spécifiées dès le départ, et les personnes concernées informées; en aucun cas, le traitement ne doit servir d'autres finalités.

- Minimisation des données : l'entreprise ne doit conserver que les données strictement nécessaires. Par exemple, celles-ci doivent en principe être effacées ou anonymisées dès lors qu'elles ne sont plus utiles à l'accomplissement des finalités poursuivies.

- Exactitude : les données traitées doivent être exactes et à jour, afin de protéger les personnes contre des menaces extérieures et contre des décisions basées sur des données erronées.

- Limitation de la conservation : quand les données personnelles ne sont plus utilisées pour la finalité, elles doivent être supprimées; une politique de rétention des données doit être mise en place.

- Intégrité et Confidentialité : les données personnelles doivent être classées confidentielles, et n'être accessibles qu'aux personnes autorisées. L'intégrité des données doit également être assurée tout au long du traitement.

Principales dispositions du RGPD

1 - Nomination d'un délégué à la protection des données ou DPO

Le DPO (Data Protection Officer) ou Délégué à la Protection des Données (DPD) doit être associé à toutes les questions liées à la protection des données à caractère personnel. Ses principales missions sont :

  • de contrôler le respect du règlement,
  • de réaliser l'inventaire et les études d'impacts sur les traitements,
  • de conseiller le responsable des traitements sur son application,
  • d'être le point de contact avec l'autorité de contrôle,
  • de répondre aux sollicitations de personnes souhaitant exercer leur droit.

La nomination d'un DPO est conseillée pour toutes les entreprises; elle est obligatoire pour :

  • les autorités et organismes publics : ex. ministères,
  • les organismes dont les activités concernent le suivi systématique et à grande échelle
    • sur des personnes : ex. fichiers clients pour les banques, les FAI, etc...
    • sur des données sensibles (ex. de santé) ou relatives à des condamnations ou infractions (biométrie, opinions publiques)

2 - Le transfert des formalités CNIL au responsable du traitement

En France, la mise en place du RGPD vient modifier le rôle de la CNIL. Jusqu’à présent, conformément à la loi Informatique et Libertés en vigueur, les entreprises procédant à des traitements de données doivent effectuer des déclarations auprès de la CNIL, et obtenir des autorisations de sa part. Avec le RGPD, ces déclarations ne sont plus nécessaires, mais la responsabilité de chaque entreprise est renforcée : toute entreprise doit être en mesure de prouver, par la mise en place d’outils internes d’audit, que chaque traitement est conforme aux dispositions du RGPD.

La déclaration est donc supprimée et désormais, les entreprises doivent tenir à jour, en interne, un Registre des Activités de Traitement (RAT). Ce registre, qui décrit les caractéristiques essentielles du traitement revient, en quelque sorte, à effectuer sa déclaration en interne. Lors d'une procédure de contrôle, la CNIL y aura évidemment accès et contrôlera la correspondance entre le contenu du RAT et les caractéristiques des traitements réellement mis en oeuvre.

Les entreprise de moins de 250 salariés n'ont en principe pas à mettre en oeuvre un RAT. Néanmoins, il sera le plus souvent prudent de tenir à jour ce registre, puisque les exceptions à ce principe sont floues. Par exemple, une entreprise de moins de 250 salariés doit tenir un RAT si les traitements qu'elle met en oeuvre ne sont pas occasionnels. Or, toute entreprise traite des données relatives à ses ressources humaines, à ses clients, à ses prospects... et l'on imagine assez mal qu'ils soient occasionnels. Ainsi, toutes les entreprises de moins de 250 salariés devraient finalement se doter d'un registre des activités de traitement.

3 - Etude d'impact sur la vie privée

Les traitements les plus dangereux devront faire l'objet d'une étude d'impact sur la vie privée voire, d'une consultation de la Commission Nationale de l'Informatique et des Libertés (CNIL). Cette étude doit prévoir les mesures pour diminuer les conséquences sur les dommages potentiels relatifs à la protection des données personnelles.

Pour réaliser cette étude d'impact, la CNIL met à disposition un outil téléchargeable (outil PIA).

4 - Security by design and by default : Des principes de protection des données dès la conception

Le RGPD impose de prendre en compte des exigences relatives à la protection des données personnelles dès la conception des produits, services et systèmes exploitant des données à caractère personnel. De plus, le RGPD introduit la notion de sécurité par défaut imposant à toute organisation d'avoir un Système d'Information sécurisé.

5 - Notification en cas de fuite de données

Le RGDP impose de notifier dès que possible l'autorité de contact (la CNIL pour la France) en cas de violation grave de données, afin que les utilisateurs puissent prendre des mesures appropriées. Le formulaire de notification de violation des données personnelles est disponible sur le site de la CNIL (formulaire Notification de violation)

6 - Des sanctions plus importantes

Le RGPD donne aux régulateurs (la CNIL en France) le pouvoir d'infliger des sanctions financières allant jusqu'à 4% du chiffre d'affaires mondial annuel d'une entreprise ou 20 millions d'euros (le montant le plus élevé étant retenu), en cas de non-respect. Si la CNIL est renvoyée à un simple rôle consultatif, le renforcement de son pouvoir de sanction, notamment d'amende administrative, devrait inciter les responsables de traitements à tenir compte de ses avis, quand bien même ils ne seraient que consultatifs.

Les grandes étapes pour se conformer au RGPD

La CNIL décrit une démarche en 6 étapes :

1 - Désigner un DPO (Data Protection Officer)

Le DPO peut être le CIL (Correspondant Informatique et Libertés), qui sera formé au règlement GDPR et sera le point d'entrée pour mettre en œuvre la conformité.

2 - Cartographier les traitements de données personnelles

Objectif : recenser tous les traitements manipulant des données personnelles, en identifiant :

  • le responsable de chaque traitement,
  • les catégories de données personnelles traitées,
  • les objectifs poursuivis par les opérations de traitement,
  • le flux sur les données : origine et destination des données, où sont hébergées les données,
  • la durée de conservation des données.

3 - Prioriser les actions pour la mise en conformité

Pour chaque traitement issu du registre des traitements, il sera nécessaire d'indentifier les actions de mise en conformité à mener par rapport au RGPD. Ces actions doivent ensuite être priorisées au regard des risques encourus.

4 - Faire une étude d'impact pour gérer les risques

L'étude d'Impact sur la Vie Privée (EIVP ou DPIA - Data Protection Impact Assessment) permet d'étudier les impacts sur la vie privée des personnes concernées. L'étude DPIA doit contenir : les finalités du traitement, l'appréciation des risques sur les droits des personnes, les mesures à mettre en place pour traiter les risques pour se conformer au RGPD. Pour réduire les risques, mettre en œuvre :

  • sur les données à protéger : du chiffrement, de l'anonymisation,
  • sur les impacts potentiels : tracer les activités, les violations de donnéesi,
  • sur les supports : traiter les vulnérabilités des matériels, des logiciels, ...

5 - Organiser les processus internes

Les processus internes doivent prendre en compte l'arrivée du RGPD :

  • nommer un DPO et notifier à l'autorité de contrôle,
  • protéger les données dès la conception (privacy-by-design), minimiser la durée de conservation,
  • exercice du droit des personnes concernées,
  • intégrer des clauses dans les contrats avec les sous-traitants et notifier les clients,
  • sensibiliser régulièrement les utilisateurs,
  • informer dans les meilleurs délais l'autorité de contrôle et les personnes concernées, en cas de violation.

6 - Documenter la conformité

La documentation doit inclure :

  • le registre des traitements de données personnelles,
  • les analyses d'impact pour chaque traitement des données,
  • le recueil du consentement des personnes concernées,
  • l'information des personnes concernées,
  • l'encadrement du transfert éventuel de données hors Union Européenne,
  • les contrats avec les sous-traitants.

Quelques normes utiles pour se conformer au RGPD

ISO 27001 : la norme ISO 27001 définit, dans son Annexe A, 114 exigences de sécurité pour mettre en place un SMSI (Système de Management de la Sécurité de l'Information). On retrouve de nombreux points communs entre les exigences de l'ISO 27001 et le RGPD. L'ISO 27002 donne les bonnes pratiques pour mettre en place un SMSI.

PCI DSS : la norme PCI-DSS s'applique aux entreprises traitant des données de cartes de paiement, pour renforcer la protection des systèmes de paiement contre les riques de compromission et de vol. PCI-DSS et RGPD renfocent la protection et la sécurité des données clients, sur des périmètres différents.

En guise de conclusion,

Le règlement RGPD impose de respecter des bonnes pratiques (à travers une analyse de risques) sur la gestion des données personnelles, et d'acquérir les bonnes démarches pour la protection de ces données. Le projet de conformité RGPD nécessite de prendre en compte les aspects méthodologiques, juridiques et techniques.

Algosecure peut vous accompagner pour la mise en conformité RGPD

La mise en conformité RGPD concerne de nombreux domaines d'activités, aussi bien techniques qu'organisationnels.

Nos équipes d'experts peuvent échanger avec vous pour vous accompagner dans votre démarche de mise en conformité au règlement RGPD : nhésitez pas à nous contacter.

WannaCrypt - Retour sur une cybermenace mondiale

Alexandre 23 mai 2017 Tous publics

Vous avez surement dû entendre parler des incidents de sécurité informatique de ce week-end. Pour une fois qu’on parle de cybersécurité sur les chaines nationales, on se devait d’en parler un peu !

Rappel des faits

  • Des ordinateurs Windows de plus de 150 pays se sont fait infecter par un virus de type ransomware, qui rend les données de l'ordinateur illisibles en les chiffrant (documents Word, PDF, photos, musique...) et vous propose de les récupérer en payant une rançon de quelques centaines d'euros.
  • Le ransomware pénètre une entreprise via une vulnérabilité dans des serveurs Windows vulnérables exposés sur Internet.
  • Le ransomware se propage d'ordinateur en ordinateur en exploitant une faille dans le protocole de partage de fichiers SMB, connue et exploitée depuis longtemps par la NSA pour ses opérations d'espionnage.
  • Les détails de la faille ont été divulgués à Microsoft qui a publié une mise à jour en mars mais qui n’a pas été appliquée par tous, d'où les vagues de contamination.
  • Devant l'ampleur des dégâts, Microsoft a aussi publié un patch pour les systèmes qui ne sont normalement plus supportés, développé en février mais diffusé seulement après l'infection.
  • Un chercheur en sécurité a réussi à ralentir la diffusion du ransomware, jusqu'à ce que des versions modifiées émergent.

Quel coût pour les entreprises ?

Beaucoup de sociétés choisissent de ne pas agir de manière proactive pour la sécurité de leur système d'information. Nous entendons souvent dire "on a perdu une matinée, on a restauré et c'est bon". Mais perdre une demi-journée de travail est si anodin ? En additionnant :

  • la demie journée-homme perdue,
  • les charges,
  • la valeur du travail effectué,

Multiplié par le nombre de salariés... ça commence à chiffrer ! On peut également ajouter :

  • la valeur de la rançon (dans le cas de WannaCrypt, entre 300$ et 600$ par poste),
  • le temps d'arrêt de l'infrastructure,
  • les frais d'intervention d'une société de sécurité,
  • les pertes de contrats suite à la perte de réputation,
  • ...

Les coûts cachés d'un incident de sécurité peuvent être nombreux.

Si je ne suis pas infecté, je ne risque plus rien ?

Pas forcément. En effet, WannaCrypt n'était que la première version. D'autres évolutions du ransomware ont suivi, notamment pour modifier ou supprimer le kill switch (le mécanisme qui bloque le fonctionnement du malware lorsqu'il est analysé dans une machine isolée d'Internet, une sandbox) et vont continuer à suivre. De plus, ce malware n'a utilisé que l'une des nombreuses failles connues de la NSA. Il y a fort à parier que d'autres failles seront exploitées à l'avenir pour reproduire ce type de menace.

Comment se protéger ?

En sécurité, le principe de protection en couche est privilégié : aucun mécanisme n'est sûr à 100%, il faut donc multiplier les mécanismes et mesures de protection pour accroître sa sécurité. Se contenter de déployer un logiciel antivirus ou un pare-feu n'est pas la solution, ce n'est qu'une étape indispensable. Un incident de sécurité, moindre soit-il, peut couter de l’argent, voire influer sur la pérennité de n’importe quelle structure. Voici les étapes pour vous en protéger.

Faire les mises à jour de Windows

WannaCrypt peut contaminer un poste seul, comme tout autre ransomware. Mais dans le cas présent, il s'est propagé du fait que la mise à jour corrigeant la vulnérabilité n'a pas été appliquée. Cela provient donc d'une gestion non-conforme de la maintenance du parc informatique.

Nous vous rappelons donc que les mises à jour de Windows doivent être activées de manière automatique, et si tel n'est pas le cas, un suivi rigoureux doit être effectué pour compenser.

Superviser votre infrastructure

Nous vous conseillons de réaliser une supervision du système d'information afin de surveiller les modifications massives de données d'un poste ou d'un serveur, et de mettre en place des alertes en cas d'incident.

Anticiper les problèmes avec des sauvegardes

Faire des sauvegardes c’est bien. Pouvoir les restaurer c’est encore mieux ! AlgoSecure vous conseille de mettre en place des sauvegardes, mais aussi et surtout, de tester la restauration des sauvegardes. Qui plus est, ces sauvegardes doivent se trouver sur une partie de votre infrastructure qui ne sera pas à risque d'être contaminé.

Contactez-nous !

Un doute, une question ? N'hésitez pas à nous contacter, et retrouvez la liste de nos services sur notre site Internet.

Utiliser un gestionnaire de mots de passe

Benjamin 20 février 2017 Tous publics

Malgré l'apparition de nouvelles solutions depuis quelques mois ou années (lecteur d'empreintes digitales, mots de passe à usage unique, authentification double-facteur...), force est de constater que les mots de passe resteront pendant encore un moment la solution la plus utilisée pour s'identifier et protéger l'accès à des ressources.

Parallèlement à cela, les attaques informatiques et les fuites de base de données se multiplient, en témoignent les affaires Dailymotion, LinkedIn, Yahoo, Dropbox, Twitter et Tumblr...

Les critères de mots de passe... ça soûle !

Jusqu'à récemment, le conseil fourni aux utilisateurs était de choisir son mot de passe avec "intelligence" : majuscules, minuscules, chiffres, caractères spéciaux... Cette solution est très gênante pour les utilisateurs, et ne règle pas le problème de la réutilisation d'un mot de passe entre plusieurs services. D'autres solutions existent (comme des dés de génération de mots de passe, ou diceware) mais ne nous paraissent pas pratiques non plus.

Qu'est-ce qu'un gestionnaire de mots de passe ?

Un gestionnaire de mots de passe est un système qui va gérer pour vous :

  • la génération de mots de passe suffisamment complexes ;
  • le stockage sécurisé de ces mots de passe ;
  • l'expiration des mots de passe, pour vous rappeler d'en changer régulièrement.

Le principe est simple : vous n'avez à vous rappeler que d'un mot de passe, celui qui déverrouille le gestionnaire, choisi avec des critères sécurisés et ennuyeux... mais au moins, il n'y en a qu'un à se souvenir.

De plus, il vous permet de recenser à un même endroit tous les comptes que vous avez sur différents sites, et donc de mieux maîtriser votre présence en ligne et vos données.

Deux types de gestionnaires existent : les gestionnaires en ligne (DashLane, LastPass, 1password...) et les gestionnaires hors-ligne (KeePass, Enpass, Roboform...). À l'heure où l'on s'inquiète de voir partir toutes nos données dans "le cloud" ainsi que de la sécurité et de la confidentialité de celles-ci, confier à un service externe la gestion de tous ses mots de passe est pour nous un non-sens. D'autant plus que vu le type de données qu'ils stockent, ils sont davantage la proie des attaquants que d'autres services (LastPass s'est déjà fait pirater).

Nous privilégions donc l'utilisation d'un gestionnaire de mots de passe hors-ligne, stocké sur votre ordinateur.

Nous avons choisi KeePass, car il est gratuit et surtout open-source, c'est à dire que tout le monde peut inspecter le code du logiciel afin de l'améliorer et corriger les failles de sécurité, un principe qui nous est cher à AlgoSecure. De plus, il est simple d'utilisation et existe sur toutes les plateformes (Windows, Mac, Linux, Android et iOS).

Pourquoi ne pas enregistrer ses mots de passe dans son navigateur ?

Il est très déconseillé d'enregistrer ses mots de passe dans son navigateur. D'une part, pour des raisons pratiques : que se passe-t-il si l'ordinateur est volé, perdu, ou qu'il ne fonctionne plus ? D'autres part, stocker ses mots de passe dans son navigateur encourage l'utilisateur à ne pas à utiliser des mots de passe différents et complexes pour chaque service. Enfin, des outils permettent de voler les mots de passe stockés dans les navigateurs ou d'autres logiciels. Ci-dessous, l'un de ces logiciels a récupéré des mots de passe dans Internet Explorer et Firefox :

Installer KeePass

La première chose à faire est donc d'installer la version de KeePass correspondant à votre système :

  • Windows : télécharger et installer la Professional Edition, version Installer
  • Linux : installer le paquet keepass2 ou keepassx (généralement avec sudo apt-get install keepass2)
  • Mac (KeePassX) : télécharger et installer KeePassX, avec le lien Binary bundle
  • Android (KeePassDroid) depuis Google Play
  • iOS (KeePass Touch) sous iOS

Dans ce guide, nos captures seront réalisées sous Windows, mais le principe est le même pour les autres systèmes.

Créer une base

Au premier lancement du logiciel, rien ne s'affiche. Il va falloir créer une base de données, c'est à dire le fichier où seront stockés les mots de passe sur l'ordinateur. Pour cela, cliquer sur File, New, et indiquer l'endroit où enregistrer le fichier sur votre ordinateur.

S'affiche ensuite une fenêtre vous demandant de choisir un mot de passe principal (ou master password). N'oubliez pas que c'est le seul mot de passe que vous aurez à retenir dorénavant, celui qui protègera tous vos autres mots de passe. Nous insistons donc sur le fait qu'il faut qu'il soit long et complexe.

Pour ce faire, nous recommandons aujourd'hui de choisir 4 ou 5 mots, plutôt longs, n'ayant pas de rapport entre eux ou avec vous-même. Par exemple : bataille, attendre, dentifrice, orbite. Ensuite, vous appliquez une petite variation afin d'introduire une complexité : par exemple, les séparer par un chiffre, un symbole, mettre une des lettres de chaque mot en majuscules... Ce qui pourrait ainsi donner : batailLe3attendRe3dentifriCe3orbiTe, ou encore Bataille#Attendre#Dentifrice#Orbite. Nous estimons que ce genre de mot de passe est plus facile à retenir que, par exemple, #b;&j7]znR-!>F9.

Vous pouvez également choisir une citation, une maxime, un vers, un refrain, ou une réplique de film que vous aimez bien, en changeant certains caractères (les espaces par un point d'exclamation, les "o" par le chiffre 0, etc). Quelle que soit la méthode retenue, la barre Estimated quality doit devenir verte.

Ne notez ce mot de passe nulle part, conservez-le en lieu sûr dans votre mémoire.

Après avoir cliqué sur OK, une deuxième fenêtre vous propose de choisir un nom et une description pour la base de mots de passe. Entrez des informations vous permettant d'identifier votre base.

Allez ensuite dans l'onglet Security, puis cliquez sur le bouton 1 Second Delay. KeePass choisira automatiquement les paramètres mathématiques les plus adaptés à votre ordinateur pour protéger votre base de mots de passe.

Cliquez ensuite sur OK pour créer la base de mots de passe ! Le logiciel se décompose en deux parties : une colonne sur la gauche qui vous permet de créer des groupes pour classer vos identifiants (par exemple, un groupe Site d'achats, un autre Email, etc), et une partie sur la droite qui présente les identifiants du groupe.

Par défaut, deux entrées ont été créées afin de tester le principe de fonctionnement du logiciel, Sample Entry et Sample Entry #2. Vous pouvez les supprimer en faisant un clic droit sur la ligne de ces entrées, et en choisissant Delete Entry. Les entrées se placent dans un nouveau groupe, Recycle Bin, l'équivalent de la corbeille.

Ajouter des identifiants

Nous allons ajouter de nouveaux identifiants dans la base, en commençant par le plus important des comptes : votre compte email. Celui-ci vous permet en effet de réinitialiser les mots de passe de tous les sites sur lesquels vous avez des comptes, il est donc à protéger en priorité.

Rendez-vous sur le site de votre fournisseur d'email et lancez une procédure de changement de mot de passe, généralement dans les options ou paramètres du compte. Par exemple, pour Gmail, il faut se rendre sur ce lien. Le premier mot de passe qui vous est demandé est votre mot de passe actuel, puis vous arrivez sur cet écran :

Retournez dans la fenêtre de KeePass, cliquez sur le groupe eMail sur la gauche, faites un clic droit sur la partie de droite et choisissez Add Entry afin d'ajouter de nouveaux identifiants (une "entrée").

Dans la fênetre qui s'affiche, vous devrez indiquer :

  • un titre (le nom de votre fournisseur d'emails, par exemple Gmail)
  • votre nom d'utilisateur (généralement votre adresse email)
  • l'URL du formulaire de connexion du site (vous pourrez éditer l'entrée pour la rajouter plus tard)
  • l'expiration automatique du mot de passe, pour avoir un rappel et donc le changer dans 6 mois (par exemple)

Comme vous pourrez le voir, KeePass vous a déjà généré un mot de passe : vous n'avez qu'à cliquer sur le bouton avec les trois petits points, tout à droite de la ligne Password, pour l'afficher.

Vous pouvez alors copier le mot de passe qui vous a été généré, cliquer sur OK, puis coller le mot de passe dans le formulaire de changement de mot de passe que vous avez ouvert dans votre navigateur Internet. Après validation du formulaire, votre mot de passe sera modifié.

Se connecter à un site

Se connecter à un site est alors très simple : ouvrez votre base KeePass (File, Open, Open file) ainsi que le formulaire de connexion au site dans votre navigateur. Faites un clic gauche de la souris sur le champ "Nom d'utilisateur" (ou login, adresse email...) du formulaire de connexion dans votre navigateur, puis basculez sur la fenêtre de KeePass.

Sélectionnez l'entrée correspondant à vos identifiants, puis appuyez sur Ctrl + V (ou Pomme + V sous Mac) sur les touches de votre clavier. KeePass va automatiquement basculer sur la fenêtre de votre navigateur, saisir vos identifiants dans le formulaire, et cliquer sur le buton "Se connecter". Magique !

Il se peut que certains (rares) formulaires de connexion soient mal conçus et que le Ctrl + V ne fonctionne pas. Il faut dans ce cas copier-coller manuellement les informations depuis KeePass : un double-clic sur votre adresse email ou sur les ******** de votre mot de passe suffit à copier l'information dans le presse-papier pour une durée d'une dizaine de secondes, afin que vous puissiez le coller (Ctrl + V ou Pomme + V sous Mac) dans le formulaire.

Réglages "avancés"

Les réglages suivants amélioreront votre usage du logiciel.

  • Ce guide du site PC Astuces vous indiquera comment passer en français l'interface de KeePass.
  • En double-cliquant sur l'URL d'une entrée dans KeePass, votre navigateur s'ouvre directement sur cette URL.
  • Cet article de NextInpact explique comment configurer une YubiKey avec KeyPass. Une YubiKey est une petite clé USB d'une quarantaine d'euros qui déverrouillera votre fichier KeyPass, ou même d'autres comptes type Facebook ou Gmail, seulement lorsqu'elle sera branchée à votre ordinateur (ou proche de votre smartphone avec la version Neo et un smartphone disposant d'une puce NFC).
  • Vous pouvez durcir les paramètres de mots de passe par défaut. Allez dans Tools, Generate Password. Dans la section Generate using character set, indiquez 16 caractères, sélectionnez toutes les cases sauf Space (qui peut parfois poser problème). Dans l'onglet Advanced, cochez les deux cases (Each character must occur at most once et Exclude look-alike characters). Revenez dans l'onglet Settings et cliquez sur l'icône de disquette, sur la même ligne que Profile à droite, puis sélectionnez (Automatically generated passwords for new entries).

Quels sont les inconvénients d'un gestionnaire de mots de passe ?

La solution miracle n'existe pas, et chaque solution possède ses défauts.

D'un point de vue pratique, le fonctionnement par fichier nécessite que vous copiiez ou synchronisiez le fichier entre votre ordinateur et votre smartphone si vous avez l'habitude de vous connecter à vos comptes en mobilité.

D'un point de vue sécurité, il est possible pour un attaquant ayant piraté votre ordinateur de lire le contenu du fichier en mémoire, si vous avez votre base de mots de passe ouverte. C'est notamment possible via un outil, et également via les failles Spectre et Meltdown. Aussi, nous recommandons de fermer KeePass après avoir récupéré le mot de passe souhaité, et de ne pas laisser sa base ouverte. Toutefois, si un attaquant accède à votre ordinateur, cela signifie que votre sécurité est déjà compromise, gestionnaire de mots de passe ou non !

Il est également possible de récupérer le fichier et tenter de bruteforcer le mot de passe principal (tester très vite toutes les combinaisons possibles), si vous avez choisi un mot de passe principal faible, d'où l'intérêt de choisir une phrase de passe solide comme nous le suggérons.

La vache qui root

Jonathan 25 octobre 2016 Public technique

Une faille corrigée peut réapparaître quelques années plus tard. C'est le cas pour une faille hautement critique découverte par Phil Oester dans le kernel Linux. La faille vieille de 9 ans est une élévation de privilège, c'est à dire qu'un utilisateur avec des droits restreints peut exécuter une action avec des droits administrateurs (root dans le cas présent).

Dirty COW

La vulnérabilité est surnommée Dirty COW en référence au mécanisme Copy-On-Write du noyau Linux. Elle correspond à la CVE-2016-5195. Comme écrit plus haut, il s'agit d'une faille permettant à un simple utilisateur d'exécuter des programmes avec les privilèges root. Cette faille est d'autant plus critique que :

  • Il est facile d'écrire un exploit, une liste de POC est disponible ici
  • La faille est présente dans quasiment toutes les différentes distributions Linux, on peut citer Debian, Ubuntu et certaines version de RedHat...

La faille a déjà été corrigée pour les distribution RedHat, Debian et Ubuntu, pour les autres il faudra attendre avec patience...

Fonctionnement

Dans le noyau Linux, lorsqu'un processus souhaite écrire dans un fichier, une copie de ce dernier est créée au moment de l'écriture : c'est le mécanisme de Copy-On-Write. La vulnérabilité est basée sur cette fonctionnalité. L'exploitation est décomposée en plusieurs étapes :

  • Récupérer l'adresse mémoire de la copie du fichier avec la fonction mmap(). Le contenu du fichier est "mappé" en mémoire.
  • Effectuer parallèlement deux actions à l'aide de 2 threads:
    1. La première action est une écriture en boucle dans la zone mémoire pour générer des copies (Cow) de la zone.
    2. La deuxième action est l'utilisation de la fonction madvice() avec l'argument MADV_DONTNEED. Ce dernier indique au système qu'il peut libérer la zone mémoire utilisée.

La combinaison de ces deux actions peut provoquer une race condition, c'est à dire que l'écriture est effectuée avant que la copie en mémoire soit créée.

La vidéo suivante permet de donner plus de détails techniques sur l'exploit et la faille en elle-même:

Démonstration

Je me connecte en tant que root, pour créer un fichier accessible uniquement en lecture

(jonathan)$ sudo -s
(root)$ echo "Je suis root, personne ne peut modifier ce fichier" > test_DirtyCow
(root)$ exit
(jonathan)$ ls -ltr test_DirtyCow
-rw-r--r-- 1 root root 51 oct.  26 11:02 test_DirtyCow
(jonathan)$ echo "Algosecure is the best!" > test_DirtyCow
-bash: test_DirtyCow: Permission non accordée

Je ne peux donc pas modifier le fichier avec mes droits actuels. Je vais maintenant utiliser le POC dirtyCow pour modifier le fichier

(jonathan)$ ./dirtyc0w test_DirtyCow "Algosecure is the best et peut réécrire le fichier            "
mmap 7f6921ee3000

madvise 0

procselfmem 2005032704
(jonathan)$ cat test_DirtyCow 
Algosecure is the best et peut réécrire le fichier
(jonathan)$ echo "Algosecure is the best!" > test_DirtyCow
-bash: test_DirtyCow: Permission non accordée

Le fichier a bien été modifié. Cependant si le contenu à écrire dans le fichier dépasse la taille réelle du fichier, l'écriture sera tronquée. Inversement, si le contenu est plus petit, alors seul les n premiers octets du fichier seront écrasés.

Ce test n'est pas significatif de la criticité de la vulnérabilité. Cependant, en modifiant un fichier comme /etc/shadow ou les exécutables /bin/ls, /bin/cat, /bin/ping les conséquences seraient beaucoup plus importantes.

Pour aller plus loin...

Cette faille ne touche pas uniquement les machines Linux, elle concerne également tous les terminaux Android. Ce lien explique comment procéder pour la version Android.

1 / 2