Examen de spécialiste agréé en sécurité de l'information — Automne 2023 (Reiwa 5), question 2 de l'après-midi expliquée — Les fichiers qui s'échappent par le Wi-Fi invité

La connexion de clés USB a été interdite. L’enregistrement de fichiers sur le disque local a été interdit également. Les communications vers les webmails et les services de stockage cloud non autorisés par l’entreprise ont été bloquées. Les pièces jointes aux e-mails ont été interdites. Le serveur de fichiers interne a été supprimé.

Et pourtant, les fichiers professionnels peuvent toujours être emportés.

La question 2 de l’après-midi de l’examen de spécialiste agréé en sécurité de l’information, session automne 2023 (Reiwa 5), prend pour cadre l’entreprise M, du secteur de l’habillement, qui a déjà mis en œuvre toutes ces mesures, et demande de mettre au jour les failles qui subsistent malgré tout¹. Cet article est le deuxième d’une série qui fait suite à l’explication de la question 1 (XSS stocké), et le terrain traité passe de l’application web au réseau interne et à l’authentification des postes.

Alors que la question 1 demandait « où les mesures alignées devant l’application web ont-elles pu être contournées », la question 2 demande « quel périmètre la conception des mesures avait-elle réellement l’intention de protéger ». Aucune des mesures de l’entreprise M n’est erronée en soi. Mais si l’on vérifie une par une la limite que chacune était censée couvrir, l’espace juste à l’extérieur reste ouvert.

Ce que cet article vous apporte, au-delà des exemples de réponses et de leur justification pour chaque question, ce sont des points de contrôle directement réutilisables en pratique, portant sur trois domaines : le LAN sans fil, les certificats serveur et la restriction par adresse IP source. Il est rédigé de façon à ce que les lecteurs qui préparent l’examen puissent suivre les sections question par question, tandis que ceux qui ne veulent que la perspective pratique puissent commencer directement aux chapitres 11 et 12.

1. La conclusion, d’abord

• La brèche, c’était la salle de réunion. L’entreprise M interdisait d’apporter des PC personnels, mais cette interdiction ne couvrait que l’espace de bureaux ; la salle de réunion en était exclue. Le LAN sans fil des employés et le LAN sans fil des invités y sont tous deux disponibles
• Les employés disposent de deux voies d’exfiltration : usurper une adresse MAC pour se connecter au LAN sans fil des employés, ou se contenter de se connecter au LAN sans fil des invités. La seconde est bien plus simple : il suffit de la clé pré-partagée distribuée aux invités
• Le stockage cloud (Service B) était restreint à « connexion possible uniquement depuis l’adresse IP globale de l’entreprise M ». Mais le trafic du LAN sans fil des invités est traduit par le même NAT vers la même adresse IP globale, si bien que cette restriction est contournée sans effort. Une restriction par adresse IP source est un paramètre qui autorise non pas un appareil, mais tous ceux qui partagent le même point de sortie
• Un faux point d’accès combiné à un faux site, mis en place par un attaquant externe, est arrêté par la vérification du certificat serveur. Ce qui fait vraiment le travail, ce sont deux points : « a-t-il été émis par une autorité de certification de confiance » et « le nom de serveur du certificat correspond-il à celui du site auquel on se connecte ». Selon le commentaire de notation de l’IPA, le taux de bonnes réponses à la question portant sur ces deux points a été faible
• Même en tapant http:// par erreur, HSTS remplace l’accès par du HTTPS avant de se connecter, ce qui aboutit là encore à une erreur de certificat. Et sur un hôte où HSTS est actif, il est interdit de proposer à l’utilisateur une option pour ignorer l’avertissement et continuer
• La fonction de partage de fichiers légitime devient elle aussi une voie d’exfiltration : il suffit d’indiquer sa propre adresse e-mail personnelle comme destinataire du partage externe. L’approbation du responsable existait, mais certains responsables ne vérifiaient pas le destinataire
• Les mesures reposent sur trois piliers : faire passer le LAN sans fil des employés en EAP-TLS, authentifié par un certificat client propre à chaque appareil, avec la clé privée conservée dans le TPM afin qu’elle ne puisse jamais quitter le PC professionnel ; séparer le LAN sans fil des invités du réseau de l’entreprise M (ou scinder l’adresse IP globale de sortie) ; et supprimer les VLAN, règles de filtrage et SSID devenus inutiles

2. À propos du sujet — Source et traitement dans cet article

Le sujet traité ici est le suivant.

Source : Examen de spécialiste agréé en sécurité de l’information, session automne 2023 (Reiwa 5), après-midi, question 2

L’IPA indique que, pour les sujets d’examen passés qu’elle publie, aucune autorisation ni redevance n’est nécessaire sauf disposition légale contraire. Elle ne renonce toutefois pas à ses droits d’auteur, et demande que la source soit citée sous la forme « année, session, catégorie d’examen, tranche horaire, numéro de question, etc. », et que toute modification apportée à l’énoncé soit également signalée².

Cet article ne reproduit pas tel quel les figures et tableaux du fascicule d’examen. Dans la mesure nécessaire à l’explication du mécanisme, ils sont remplacés par des schémas simplifiés et des résumés rédigés par notre société. Les énoncés des questions et les exemples de réponses sont eux aussi traités sous forme résumée. Le fascicule d’examen original, les exemples de réponses et le commentaire de notation peuvent être téléchargés gratuitement depuis le site de l’IPA ; nous recommandons de les garder ouverts pendant la lecture^{1 3 4}.

Correspondance entre les questions et les sections de cet article

Vous pouvez commencer la lecture directement à la question qui vous intéresse.

Ce qu’écrit le fascicule d’examen, et comment cet article le traite

Pour permettre de comparer avec le texte original, voici un résumé de ce qui a été traité et comment.

3. Le contexte du problème — Ce que l’entreprise M « avait déjà fait »

L’entreprise M est une filiale de l’entreprise L, spécialisée dans l’habillement, comptant 100 employés. Son immeuble de bureaux donne sur une grande artère très fréquentée du centre de Tokyo. Cette phrase aura son importance plus loin.

L’année précédente, un employé de l’entreprise M avait copié sur une clé USB des fichiers de conception de produits classés confidentiels, stockés sur le serveur de fichiers interne, puis les avait apportés à un concurrent. Sous l’impulsion de l’entreprise mère L, une refonte des mesures de sécurité est en cours. Trois mesures ont déjà été mises en œuvre :

• Installation d’un logiciel de prévention des fuites d’informations sur les ordinateurs portables prêtés aux employés (ci-après « PC professionnels »), avec interdiction de connecter des supports de stockage externes tels que des clés USB, interdiction d’enregistrer des fichiers sur le disque local (à l’exception de l’installation de logiciels), blocage des communications vers les webmails et les services de stockage cloud non autorisés par l’entreprise, interdiction d’installer des logiciels non autorisés par l’entreprise, et interdiction de joindre des fichiers lors de l’envoi d’e-mails
• Centralisation du lieu de stockage des fichiers professionnels sur un service de stockage cloud déjà utilisé auparavant (ci-après « Service B »), avec révision de sa configuration
• Suppression du serveur de fichiers interne

Comme l’incident précédent suivait le chemin « serveur de fichiers interne → clé USB », les deux extrémités de ce chemin ont été bouchées. La logique se tient.

Configuration du réseau

L’immeuble de bureaux comprend un espace de bureaux et une salle de réunion. Dans l’espace de bureaux, seul le LAN sans fil des employés est disponible ; dans la salle de réunion, les deux sont disponibles, celui des employés et celui des invités. Le projecteur de la salle de réunion est utilisé en connectant au LAN sans fil des invités soit un appareil apporté par un invité (PC, tablette ou smartphone), soit un PC professionnel.

En se limitant à ce qui est nécessaire à l’explication, la configuration se présente comme suit sous forme de schéma.

flowchart LR
    subgraph M["Réseau interne de l'entreprise M"]
        direction TB
        G["LAN sans fil invités<br/>192.168.10.0/24<br/>(AP de la salle de réunion uniquement)"]
        E["LAN sans fil employés<br/>192.168.20.0/24<br/>(bureaux et salle de réunion)"]
        S["Réseau des serveurs<br/>192.168.30.0/24<br/>DHCP, DNS, annuaire"]
        FW["Pare-feu<br/>traduit la source en<br/>une seule adresse IP<br/>globale via NAT"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["Service B<br/>(stockage cloud)"]
    FW --> I["Internet"]

Voici les spécifications à retenir.

Et il y a trois règles de sécurité : il est interdit de sortir un PC professionnel hors de l’entreprise, il est interdit d’apporter dans l’espace de bureaux un PC, une tablette ou un smartphone personnel, il est interdit de sortir un fichier professionnel hors de l’entreprise par un autre moyen que la fonction de partage de fichiers du Service B.

Avez-vous remarqué que la deuxième règle précise « dans l’espace de bureaux » ? La salle de réunion n’y est pas mentionnée.

Comment progresse ce problème

M. Y, du service informatique, avance dans la vérification de la suffisance des mesures contre l’exfiltration de fichiers depuis le Service B, avec l’appui de M. S, spécialiste agréé en sécurité de l’information (RISS) de l’entreprise mère L. Les deux examinent séparément l’exfiltration par un attaquant externe et l’exfiltration par un employé. La question 1 porte sur la première, la question 2 sur la seconde, et la question 3 sur l’élaboration des mesures.

4. Faux Wi-Fi et faux site — Questions 1(1) et 1(2)

M. Y commence par exposer le scénario suivant : un invité ayant déjà utilisé le LAN sans fil des invités, agissant en attaquant, se connecte à ce LAN sans fil depuis les abords de l’entreprise M et accède au Service B.

Ce scénario fonctionne parce que la méthode d’authentification du LAN sans fil est WPA2-PSK. La PSK (Pre-Shared Key, clé pré-partagée) est, comme son nom l’indique, une méthode où tout le monde partage la même clé. La clé pré-partagée du LAN sans fil des invités est faite pour être communiquée aux invités. Une fois communiquée, il n’existe aucun moyen de révoquer le fait que cette personne la connaît désormais (sauf à la changer pour tout le monde). Et comme l’immeuble de bureaux donne sur une grande artère fréquentée, le signal est captable même depuis l’extérieur du bâtiment.

La réponse de M. S est limpide : pour se connecter au Service B, il faut [a] un identifiant et [b] un mot de passe. C’est l’exemple de réponse à la question 1(1) (dans un ordre indifférent). Le simple fait de se connecter au LAN sans fil ne signifie pas se connecter au Service B.

Faux point d’accès et faux site

M. Y propose alors un scénario qui va plus loin : et si on préparait un faux point d’accès (AP) configuré à l’identique de celui du LAN sans fil des invités, et un faux site utilisant la même URL que le Service B, puis qu’on truquait la configuration DNS pour voler l’identifiant et le mot de passe ? En plaçant le faux AP à proximité de l’entreprise M, un employé pourrait connecter par erreur son PC professionnel à ce faux AP, tenter d’accéder au Service B, atterrir sur le faux site, et s’y connecter.

C’est ce qu’on appelle une attaque evil twin (le « jumeau maléfique »). En montant un AP avec le même SSID et la même clé pré-partagée que le LAN sans fil des invités, rien ne permet à un appareil de le distinguer de l’AP légitime. Avec WPA2-PSK, la seule chose qu’un appareil peut vérifier à propos d’un AP, c’est « qu’il connaît la même clé pré-partagée ». Un AP qui ne connaît pas la clé ne peut pas mener la procédure de connexion à son terme, mais inversement, quiconque connaît la clé peut devenir « l’AP authentique ». Dès lors que cette clé est distribuée aux invités, il faut considérer qu’elle est aussi entre les mains d’un éventuel attaquant.

La réponse de M. S est là encore limpide. Lorsqu’un employé tente d’accéder au faux site en HTTPS, un message d’erreur signalant que la connexion n’est pas sécurisée s’affiche, accompagné, selon le certificat serveur utilisé par le faux site, d’un ou plusieurs des quatre éléments suivants dans le navigateur.

• Ce certificat serveur n’a pas été émis par une autorité de certification de confiance (blanc c)
• Le nom de serveur indiqué sur ce certificat serveur diffère du nom du serveur auquel on se connecte (blanc d)
• Ce certificat serveur a été révoqué
• Ce certificat serveur a expiré

Les deux derniers éléments figuraient déjà dans le fascicule d’examen dès le départ ; la question 1(2) demande de trouver les deux premiers (blancs c et d, 40 caractères maximum chacun, ordre indifférent).

sequenceDiagram
    autonumber
    participant U as PC professionnel de l'employé
    participant F as Faux AP / faux site<br/>(attaquant)
    participant B as Service B (légitime)

    Note over F: Monte un AP avec le même SSID<br/>et la même clé pré-partagée que le LAN invités
    U->>F: Se connecte par erreur au faux AP
    Note over F: Truque le DNS pour rediriger<br/>le nom de domaine du Service B vers le faux site
    U->>F: Se connecte en HTTPS à l'URL du Service B
    F-->>U: Certificat serveur du faux site
    Note over U: Échec de la validation<br/>· pas émis par une autorité de confiance<br/>· nom de serveur du certificat différent de la cible
    Note over U: Affiche une erreur de connexion non sécurisée<br/>l'écran de connexion ne s'affiche pas
    Note over U,B: Aucune communication n'a jamais<br/>eu lieu avec le vrai Service B

Que vérifie exactement la validation du certificat ?

Le commentaire de notation écrit ceci à propos de cette question :

La question 1(2) a obtenu un taux de bonnes réponses faible. Même si un attaquant prépare un faux site, la validation du certificat serveur échouera dès lors que l’accès se fait en HTTPS. La validation du certificat serveur constitue une connaissance fondamentale pour assurer la sécurité des communications ; nous souhaitons que les candidats comprennent bien, jusque dans le détail, ce qui est concrètement vérifié.

Autrement dit, beaucoup de candidats savaient qu’« une erreur de certificat s’affiche », mais peu étaient capables de décomposer en quatre éléments ce qui est vérifié pour aboutir à cet échec. Si l’on organise les quatre éléments de la figure 2 selon ce que chacun vérifie, cela donne le tableau suivant.

Du point de vue de l’attaquant, les deux premiers points constituent un mur infranchissable. Créer un certificat auto-signé échoue au premier point ; obtenir légitimement, gratuitement, un certificat pour son propre domaine (par exemple b-service.example.net) échoue au second, puisque la cible de connexion est le domaine du Service B. En effet, un certificat pour le nom de domaine du Service B ne peut être obtenu que si l’on contrôle ce domaine. La combinaison de ces deux points constitue, on peut le dire, le cœur même du mécanisme des certificats.

La procédure de validation du chemin de certification est définie par la RFC 5280⁵, et la procédure de correspondance entre le nom inscrit sur le certificat et le nom de la cible par la RFC 6125⁶.

Les quatre éléments n’ont pas tous la même force

Il faut ici distinguer la réponse attendue à l’examen du comportement réel des navigateurs. Les quatre éléments ci-dessus sont ceux que la figure 2 de l’énoncé liste comme « détail des erreurs susceptibles de s’afficher » ; il ne faut pas en conclure que tous les navigateurs les vérifient tous les quatre avec la même rigueur.

L’émetteur, le nom de serveur et la date d’expiration peuvent tous trois être déterminés dès la réception du certificat, à partir des seules informations disponibles localement ; ils sont donc toujours vérifiés. Ce sont d’ailleurs ces trois points qui arrêtent l’attaque décrite dans cette question.

En revanche, la vérification de la révocation est d’une nature différente. Le fait qu’un certificat soit révoqué n’est pas inscrit dans le certificat lui-même ; il faut aller chercher une information ailleurs, ce qui dépend de l’implémentation et de la configuration.

• Chrome n’effectue normalement pas de vérification OCSP ou CRL en ligne. Il diffuse à la place une liste limitée appelée CRLSet, dont l’objectif principal est de bloquer rapidement des certificats en cas d’urgence ; seule une partie des listes de révocation des autorités de certification y est intégrée⁷
• Même les implémentations qui interrogent l’OCSP utilisent souvent une configuration qui laisse passer la connexion lorsqu’aucune réponse n’est obtenue (soft-fail)

Ne faites donc pas de « en cas de fuite de la clé privée, il suffit de révoquer le certificat » le pilier de votre mesure. La révocation est une chose à faire, mais ce n’est pas un mécanisme garanti d’être efficace sur tous les navigateurs des utilisateurs. Le raccourcissement récent de la durée de validité des certificats est aussi, du côté de l’industrie, une réponse au fait que l’on ne peut pas compter sur la révocation. Si vous soupçonnez une fuite de clé au sein de votre entreprise, il faut agir en parallèle de la demande de révocation : remplacer le certificat, et invalider tout ce que cette clé protégeait (sessions, clés d’API, etc.).

Un piège en pratique — qui décide de ce qu’est une « autorité de certification de confiance » ?

À partir d’ici, on sort du cadre de l’énoncé. Le premier point du tableau ci-dessus dépend de ce que le poste de travail considère comme fiable. La liste des autorités de confiance est détenue par le navigateur ou l’OS ; sous Windows, cela correspond au magasin de certificats « Autorités de certification racines de confiance ».

Autrement dit, la première vérification passe dans les situations suivantes :

• Le certificat racine d’une autorité de certification interne (CA privée) est distribué aux PC professionnels, et la clé privée de cette autorité, ou sa procédure de délivrance de certificats, a été compromise par un attaquant
• Un proxy ou un produit de sécurité qui inspecte le contenu des communications a installé son propre certificat racine sur les postes afin de terminer le TLS, et ce produit ou son exploitation a été compromis par un attaquant
• Quelqu’un a, par le passé, enregistré une exception « parce qu’une erreur de certificat s’affichait », ou a placé un certificat auto-signé dans les autorités de confiance

Le troisième cas est vraiment très fréquent sur le terrain. Un certificat installé manuellement un jour pour faire disparaître une erreur sur un système interne continue de vivre dans l’image transmise depuis le PC d’un employé ayant quitté l’entreprise, par exemple. Le contenu du magasin des autorités de certification racines de confiance est littéralement la déclaration de qui ce poste considère comme digne de confiance ; il doit donc faire l’objet d’un inventaire régulier. La question de savoir quoi placer dans quel magasin est traitée dans le guide pratique du magasin de certificats Windows.

Pour la seconde vérification (correspondance du nom de serveur), il existe un point de vigilance distinct en pratique. Une attaque où l’utilisateur se trompe de nom de domaine échappe totalement aux certificats. Si un attaquant obtient un domaine trompeur comme b-serv1ce.example.com et un certificat légitime pour ce domaine, le navigateur n’affichera aucune erreur. Ce que garantit le certificat, c’est que « le nom de serveur de la cible correspond au nom de serveur du certificat », pas que « ce nom de serveur est bien celui que l’utilisateur avait l’intention de contacter ». Un mécanisme qui ne repose pas sur cette dernière étape confiée à l’œil de l’utilisateur consiste à faire vérifier l’origine par l’authentificateur lui-même, comme dans les clés d’accès (passkeys, WebAuthn). Nous détaillons ce point dans Pourquoi les clés d’accès sont-elles sûres ?

5. Pourquoi la connexion s’arrête même en tapant http:// — Question 1(3)

M. Y insiste. Si, connecté au faux AP, un employé saisit par erreur http:// en tapant l’URL du Service B dans son navigateur, le message d’erreur ne s’affichera-t-il pas ?

C’est une question légitime. En se connectant en HTTP, le certificat serveur n’entre tout simplement pas en jeu. Le faux site semble pouvoir afficher l’écran de connexion sans la moindre erreur.

La réponse de M. S est : « Pas de souci. Comme HSTS est activé, le même message d’erreur que précédemment s’affichera même dans ce cas. » La question 1(3) demande, en 60 caractères maximum, le comportement du navigateur juste avant l’affichage de ce message d’erreur.

L’exemple de réponse est : « L’accès HTTP est remplacé par un accès HTTPS. Le navigateur reçoit ensuite le certificat serveur du faux site. »

Que se passe-t-il dans le navigateur ?

HSTS (HTTP Strict Transport Security) est un mécanisme par lequel un site déclare, via l’en-tête Strict-Transport-Security, « à partir de maintenant, viens toujours vers cet hôte en HTTPS », et le navigateur s’en souvient. Ce mécanisme est défini par la RFC 6797⁸.

Lorsqu’il tente d’accéder en http:// à un hôte dont il se souvient, le navigateur agit ainsi :

1. Il remplace le schéma de l’URL, de http à https. Si le port 80 était explicitement indiqué, il le convertit en 443 (RFC 6797, section 8.3)
2. Il se connecte donc en HTTPS. Comme le DNS est truqué, la cible réelle est le faux site
3. Il reçoit le certificat serveur du faux site
4. La validation échoue, aboutissant à la même erreur qu’au chapitre 4

L’important, c’est que le remplacement de l’étape 1 est terminé avant même que quoi que ce soit ne sorte sur le réseau. La requête HTTP en clair n’est jamais envoyée. C’est pourquoi il ne se produit jamais de situation où « comme la connexion s’est faite en HTTP, aucun certificat n’apparaît ».

Impossible de cliquer sur « continuer quand même »

HSTS possède une autre propriété d’une grande importance pratique. La section 8.4 de la RFC 6797 exige que, si une erreur survient pendant l’établissement d’un canal sécurisé avec un hôte où HSTS est actif, qu’elle soit un simple avertissement ou une erreur fatale, la connexion soit interrompue. Et la section 12.1 décrit ce comportement comme « No User Recourse » (aucun recours laissé à l’utilisateur), précisant qu’il ne faut jamais proposer une option du type « cette connexion n’est pas sécurisée, continuer quand même ? ».

Pour une erreur de certificat ordinaire, de nombreux navigateurs proposent, sur l’écran d’avertissement, des liens tels que « paramètres avancés » ou « continuer ». En pratique, il n’est pas rare de voir un utilisateur habitué aux erreurs de certificat de systèmes internes cliquer dessus par réflexe. HSTS bloque ce réflexe. On peut même dire que, face à un faux site, c’est cette impossibilité de « cliquer pour continuer » qui protège davantage que la validation du certificat elle-même.

La condition préalable de HSTS — la toute première fois n’est pas protégée

HSTS repose cependant sur une condition préalable. Comme le définit la section 8.1 de la RFC 6797, un hôte ne devient un « hôte HSTS connu » que lorsque l’agent utilisateur a reçu l’en-tête Strict-Transport-Security via un canal de communication sécurisé. Autrement dit, il faut que ce navigateur ait déjà atteint une fois le site légitime en HTTPS.

Par conséquent, HSTS ne protège pas dans les cas suivants :

• Sur un PC professionnel tout juste distribué, dont le tout premier accès a eu lieu directement sous un faux AP
• Le profil du navigateur a été recréé, ou les données de navigation ont été effacées, emportant avec elles l’enregistrement HSTS
• La durée de validité de l’enregistrement (max-age) a expiré

C’est la liste de préchargement HSTS qui comble ce problème de première fois. Si un domaine figure dans la liste intégrée par avance au navigateur, il est contraint au HTTPS même sans y avoir jamais accédé auparavant.

Cela dit, si vous envisagez d’y inscrire votre propre site, vérifiez d’abord les conditions. Les exigences d’inscription sont les suivantes⁹ :

• Fournir un certificat valide
• Si le port 80 est en écoute, rediriger de HTTP vers HTTPS sur le même hôte
• Fournir tous les sous-domaines en HTTPS (y compris www s’il existe un enregistrement DNS correspondant)
• Renvoyer, sur le domaine de base, un en-tête Strict-Transport-Security avec un max-age d’au moins 31 536 000 secondes (un an), ainsi que includeSubDomains et preload

C’est la combinaison du troisième point avec includeSubDomains qui pose le plus souvent problème. Si un ancien sous-domaine à usage interne n’est disponible qu’en HTTP, ou n’a pas de certificat, il devient inaccessible dès l’inscription. Faites l’inventaire de tous les sous-domaines avant de vous inscrire.

Et l’annulation n’est pas simple. Les demandes de suppression sont généralement acceptées, mais le changement met plusieurs mois à atteindre les navigateurs des utilisateurs, et rien n’est garanti pour les navigateurs autres que Chrome⁹. Il est plus sûr d’aborder le préchargement en considérant qu’il ne s’agit pas d’un réglage que l’on peut « annuler en cas d’erreur ».

À l’inverse, du côté de l’utilisateur d’un service, vérifier si le service cloud professionnel utilisé prend en charge HSTS est un critère qu’il est légitime d’inclure dans la sélection d’un prestataire.

6. Dès que l’approbation devient une formalité vide, la fonction de partage devient une voie d’exfiltration — Question 2(1)

À partir d’ici, l’examen passe à l’exfiltration par un employé.

M. S vérifie d’abord le fonctionnement de la fonction de partage de fichiers : les responsables approuvent-ils bien après avoir vérifié l’adresse e-mail du destinataire et le fichier lui-même ? M. Y répond : « Il semble que certains responsables ne vérifient pas. »

C’est là que M. S soulève la question 2(1) : indiquer concrètement, en 40 caractères maximum, une méthode d’abus de la fonction de partage de fichiers permettant de rendre un fichier téléchargeable depuis l’extérieur de l’entreprise M.

L’exemple de réponse est : « Indiquer sa propre adresse e-mail personnelle comme adresse du destinataire du partage externe. »

La conception est correcte, c’est l’exploitation qui a une faille

La fonction de partage de fichiers du Service B est bien pensée.

• Le partage nécessite l’approbation d’un responsable
• Le lien de partage externe n’est communiqué ni à l’auteur du partage ni à son responsable. L’auteur du partage ne peut donc pas transférer lui-même le lien pour exfiltrer le fichier
• Le lien contient une chaîne aléatoire difficile à deviner, avec une validité d’un jour

Le deuxième point, en particulier, a été conçu en pensant à l’exfiltration depuis l’intérieur. Et pourtant, cela se contourne. Il suffit en effet de désigner soi-même comme destinataire pour que le lien « non communiqué à l’auteur » finisse quand même entre ses mains.

Et cette brèche ne s’ouvre que sous une seule condition : que le responsable n’ait pas vérifié le destinataire. Le flux d’approbation est conçu en supposant que l’approbateur examine le contenu. S’il ne le fait pas, ce n’est plus qu’un circuit de livraison automatisé.

Les conditions qui vident une approbation de son sens sont bien identifiées

En pratique, lorsqu’une approbation devient une formalité vide, la cause tient généralement à l’un des éléments suivants.

Ce qui manque à l’entreprise M dans cette question, ce sont surtout les deux derniers points. Une fois mis en place un mécanisme pour faire passer les approbations, il faut aussi un mécanisme pour regarder après coup ce qui a été approuvé. Le simple fait de pouvoir lister le nombre de partages externes mensuels adressés à des domaines de messagerie gratuite rendrait déjà ce procédé bien plus facile à repérer.

La vue d’ensemble de par où commencer pour une PME est traitée dans Comment aborder la version 4.0 du guide de mesures de sécurité de l’information pour les PME de l’IPA.

7. La salle de réunion, une brèche — Question 2(2)

La question suivante de M. S est : « Peut-on apporter un PC personnel dans la salle de réunion ? » M. Y répond : « Ce n’est pas interdit, donc oui, on peut. »

C’est ici qu’interviennent les méthodes 1 et 2. Toutes deux suivent le même scénario : télécharger un fichier depuis le Service B avec un PC personnel, puis repartir avec ce PC personnel. La configuration du logiciel de prévention des fuites installé sur le PC professionnel n’a strictement aucun effet sur un PC personnel.

Méthode 1 — Usurpation de l’adresse MAC

La méthode 1 consiste à modifier [e] l’adresse MAC de l’interface sans fil du PC personnel pour lui donner celle de l’interface sans fil d’un PC professionnel, puis à connecter le PC personnel au LAN sans fil des employés. Répondre au blanc e est l’objet de la question 2(2).

Ce qui gardait l’entrée du LAN sans fil des employés, c’étaient deux choses : la clé pré-partagée du WPA2-PSK, et le filtrage par adresse MAC. Un employé peut franchir l’une comme l’autre.

• La clé pré-partagée est configurée sur le PC professionnel, dont l’employé est l’utilisateur. Dès lors qu’il s’agit d’une méthode où tout le monde partage une seule et même clé, il faut partir du principe que « l’utilisateur peut la connaître »
• L’adresse MAC peut être réécrite du côté de l’appareil. Cela se fait normalement depuis les paramètres du système d’exploitation ou les propriétés du pilote, sans outil particulier. Et comme l’adresse MAC portée par les trames du LAN sans fil n’est pas chiffrée, il est aussi possible, en captant le signal à proximité, de découvrir l’adresse MAC d’un PC professionnel déjà enregistré

Le filtrage par adresse MAC et la non-diffusion du SSID ont un sens en tant que rangement destiné à réduire les connexions accidentelles. Mais ce ne sont pas des mécanismes d’authentification capables d’arrêter quelqu’un qui cherche délibérément à entrer. Vérifiez, dans votre propre configuration, si vous ne comptez pas ces deux éléments parmi vos « mesures » de sécurité.

Méthode 2 — Se contenter de se connecter au LAN sans fil des invités

La méthode 2 est plus simple encore : connecter le PC personnel au LAN sans fil des invités, télécharger le fichier depuis le Service B, puis repartir avec le PC personnel. C’est tout.

Pas besoin d’usurper une adresse MAC. Il suffit de la clé pré-partagée du LAN sans fil des invités, qui est justement distribuée aux invités. Il est impensable qu’un employé ne la connaisse pas.

Une question s’impose alors naturellement : le Service B n’était-il pas restreint à « connexion possible, pour les identifiants attribués aux employés de l’entreprise M, uniquement depuis l’adresse IP globale de l’entreprise M » ?

Que permet réellement une restriction par adresse IP source ?

La réponse se trouve dans la configuration du pare-feu décrite dans l’énoncé. Le trafic sortant vers Internet depuis le LAN sans fil des invités, tout comme celui du LAN sans fil des employés, est traduit par le même NAT vers la même unique adresse IP globale.

Du point de vue du Service B, ces trois sources sont indiscernables. La restriction par adresse IP est contournée sans le moindre effort.

Cette configuration se retrouve, de façon récurrente, bien au-delà de l’examen. Une restriction par adresse IP source ne signifie pas « uniquement depuis cet appareil ». Elle signifie « depuis tous ceux qui sortent par cette adresse IP globale ». Voici quelques exemples typiques d’écart entre le périmètre que l’on croit avoir autorisé et le périmètre réellement autorisé.

Cela ne signifie pas que la restriction par adresse IP source est inutile. C’est plutôt qu’il ne faut pas s’appuyer sur une seule couche de restriction. Ce n’est qu’en la combinant, en plus du filtrage par adresse IP, avec un mécanisme identifiant l’appareil lui-même (certificat client ou certificat d’appareil) et un mécanisme identifiant l’utilisateur (authentification multifacteur) que l’on peut exprimer « cette personne-là, sur cet appareil-là ». Les mesures envisagées dans cette question vont d’ailleurs précisément dans cette direction.

8. Lier l’appareil au certificat — Questions 3(1) à 3(4)

Pour contrer la méthode 1, l’entreprise M choisit EAP-TLS comme méthode d’authentification pour le LAN sans fil des employés, et décide de mettre en place un serveur d’authentification.

Question 3(1) — RADIUS

La question 3(1) demande quel protocole sur UDP le serveur d’authentification utilise pour l’EAP. L’exemple de réponse est RADIUS.

Pour clarifier le schéma, trois acteurs entrent en jeu.

Entre le PC professionnel et l’AP, c’est IEEE 802.1X (EAP over LAN) ; entre l’AP et le serveur d’authentification, c’est RADIUS. RADIUS fonctionne sur UDP¹⁰. La procédure d’EAP-TLS elle-même est définie par la RFC 5216¹¹. Sous Windows Server, c’est le rôle de serveur de stratégie réseau (Network Policy Server, NPS) qui assure la fonction de serveur d’authentification¹².

Voyons ce qui change en passant de WPA2-PSK à EAP-TLS.

La dernière ligne demande une précision. Avec EAP-TLS, le certificat que le client valide n’est pas celui de l’AP, mais celui du serveur d’authentification. L’AP n’est qu’un authentificateur qui relaie l’échange EAP ; le client ne vérifie pas l’identité de l’AP lui-même.

Et pourtant, cela reste une protection contre l’evil twin du chapitre 4, parce que le matériel de clé généré uniquement après une authentification réussie n’est transmis qu’à un AP légitime possédant le secret partagé RADIUS. Un AP monté sans autorisation par un attaquant ne peut pas mener cette procédure jusqu’au bout, à moins de disposer, derrière lui, d’un véritable serveur d’authentification. Le client vérifie directement le serveur d’authentification, et la légitimité de l’AP en découle indirectement.

Cela reste toutefois conditionnel. Si le client n’est pas configuré pour savoir « quel certificat serveur, émis par quelle autorité et sous quel nom, faire confiance », il ne pourra pas distinguer un serveur d’authentification monté par un attaquant. Il existe effectivement des configurations où EAP-TLS a été mis en place, mais où la validation du certificat serveur est désactivée dans le profil du client. Une fois EAP-TLS déployé, vérifiez aussi ce point.

Question 3(2) — L’erreur relevée par le commentaire de notation

L’explication de M. Y se poursuit ainsi : le certificat client est émis par un serveur d’autorité de certification (CA) nouvellement créé, et n’est pas installé par l’employé lui-même sur son PC professionnel, mais déposé sur le PC professionnel par la fonction du serveur d’annuaire. Et l’élément [f], qui correspond au certificat client, est stocké et protégé dans le TPM du PC professionnel afin de le [g].

La question 3(2) porte sur le blanc f. L’exemple de réponse est la clé privée.

Le commentaire de notation écrit :

La question 3(2) a obtenu un taux de bonnes réponses relativement élevé, mais on a vu apparaître, dans une partie des copies, des réponses telles que « clé publique » ou « certificat serveur ». La PKI est une technologie importante, à la base de nombreuses technologies de sécurité ; nous souhaitons que les candidats comprennent bien dans quels contextes et de quelle manière elle est utilisée.

La clé publique est celle qui est intégrée au certificat et distribuée au monde entier. Elle n’a pas besoin d’être protégée. Ce qui doit l’être, c’est la clé privée, censée n’être détenue que par le propriétaire du certificat. « S’authentifier avec un certificat client » signifie précisément « prouver que l’on détient la clé privée correspondant à la clé publique contenue dans le certificat, en le démontrant par une signature réalisée avec cette clé. » C’est pourquoi, si la clé privée peut être copiée, l’authentification par certificat perd tout son sens.

Ce qui change avec le TPM — Question 3(3)

La question 3(3) porte sur le blanc g, en 20 caractères maximum. L’exemple de réponse est : « afin qu’elle ne puisse pas être extraite du PC professionnel ».

Si la clé privée est placée sous forme de fichier sur l’appareil, c’est une donnée que l’on peut copier. En la copiant sur un PC personnel, ce PC personnel réussit l’authentification comme s’il s’agissait du PC professionnel. On croit avoir bouché la méthode 1 (usurpation de l’adresse MAC), mais elle est simplement remplacée par une « usurpation de certificat ».

Le TPM permet de générer la clé en son sein et de la conserver dans un état où elle ne peut jamais en sortir. Les opérations comme la signature s’exécutent entièrement à l’intérieur du TPM, et la clé elle-même n’atteint jamais le système d’exploitation, une application ou un logiciel malveillant. Résultat : cette clé privée est fixée à ce composant physique unique.

Pour une implémentation sous Windows, on spécifie Microsoft Platform Crypto Provider comme fournisseur de stockage de clés (Key Storage Provider, KSP) du modèle de certificat. Ce fournisseur protège la clé à l’aide du TPM, et ne peut pas être sélectionné si l’option « autoriser l’exportation de la clé privée » est cochée dans le modèle de certificat¹³. C’est une contrainte logique : si l’exportation est possible, la protection perd son sens.

Le rôle du composant TPM lui-même est traité, dans le contexte du chiffrement de disque, dans le guide pratique de BitLocker. L’idée de « ne jamais laisser la clé privée sortir de l’appareil » relève de la même logique de conception que celle des authentificateurs décrite dans Pourquoi les clés d’accès sont-elles sûres ?

Pourquoi peut-on dire que « ça ne pose pas de problème » ? — Question 3(4)

Après avoir entendu l’explication de M. Y, M. S répond : « Avec cette méthode de stockage, je pense que ça ne pose pas de problème. » La question 3(4) demande la raison, en 40 caractères maximum.

L’exemple de réponse est : « Parce que les informations d’authentification nécessaires à EAP-TLS ne peuvent être stockées que sur le PC professionnel. »

En suivant le raisonnement, on obtient :

1. Le certificat client n’est pas installé par l’employé lui-même, mais distribué au PC professionnel par la fonction du serveur d’annuaire ; il ne passe jamais entre les mains de l’employé
2. La clé privée se trouve dans le TPM et ne peut pas être extraite du PC professionnel
3. Par conséquent, seuls les PC professionnels distribués par l’entreprise peuvent se connecter au LAN sans fil des employés via EAP-TLS
4. Un PC personnel, même avec une adresse MAC usurpée, ne peut pas réussir l’authentification. La méthode 1 est ainsi neutralisée

Notez la formulation conditionnelle « avec cette méthode de stockage ». Si la clé privée avait été placée sous forme de fichier sur le PC professionnel, M. S n’aurait pas pu dire que cela ne posait pas de problème. Pour une même « authentification par certificat client », le périmètre effectivement protégé dépend de la façon dont la clé privée est stockée.

Ce que le TPM ne protège pas

Cela dit, ce n’est pas parce que la clé est dans le TPM que tout est réglé. Ce que garantit le TPM, c’est uniquement que « cette clé ne peut pas être copiée vers un autre appareil ». Il ne protège pas contre les points suivants :

• L’appareil lui-même est emporté. Emporter le PC professionnel, c’est emporter le TPM avec lui. Les règles de l’entreprise M interdisent de sortir un PC professionnel hors de l’entreprise, mais une règle et une contrainte technique sont deux choses différentes. Il faut y ajouter séparément le chiffrement du disque (y compris l’authentification avant démarrage) et une procédure de révocation du certificat en cas de perte
• L’usurpation d’identité de l’utilisateur. Le TPM identifie l’appareil, mais ne garantit pas qui l’utilise. L’authentification de l’utilisateur reste nécessaire à part
• Un logiciel malveillant s’exécutant sur l’appareil. La clé privée ne peut pas être lue, mais du code s’exécutant sur cet appareil peut tout à fait « demander une signature au TPM ». Cela empêche la duplication de la clé, mais pas les abus commis pendant que l’appareil est compromis

9. Séparer l’adresse IP de sortie — Question 3(5)

Pour contrer la méthode 2 (se contenter de se connecter au LAN sans fil des invités), l’entreprise M examine deux options : modifier la configuration NAT du pare-feu, ou recourir à un service de LAN sans fil externe (Service D).

La question 3(5) demande, en 70 caractères maximum, le contenu de la modification pour la première option. L’exemple de réponse va dans le sens de : « faire en sorte que l’adresse IP source utilisée pour accéder à Internet depuis le LAN sans fil des invités soit une adresse différente de l’adresse IP globale actuellement utilisée » (l’énoncé note cette adresse IP globale a1.b1.c1.d1).

Comme on l’a vu au chapitre 7, la méthode 2 fonctionne parce que le trafic du LAN sans fil des invités sort par la même adresse IP globale que celui des employés. Il suffit donc de traduire uniquement le LAN sans fil des invités vers une adresse IP globale distincte. Sans changer la restriction d’adresse IP côté Service B, seul l’accès depuis le LAN sans fil des invités en sort exclu.

Cela fonctionne parce que plusieurs adresses IP globales sont attribuées côté WAN de l’entreprise M. En lisant la configuration d’interface du pare-feu dans l’énoncé, on voit que le masque de sous-réseau côté WAN est 255.255.255.248, soit un /29, ce qui indique que l’entreprise dispose de plus d’une adresse utilisable. C’est un indice discret mais solide, disséminé dans le tableau détaillé de l’énoncé.

Que vous puissiez appliquer la même méthode dépend de la possibilité, avec votre ligne d’accès contractée, d’utiliser plusieurs adresses IP globales. Si vous n’en avez qu’une seule, cette option n’est pas envisageable. Il faudra alors se tourner vers la solution de séparation du chapitre suivant.

10. La mesure ne s’achève qu’avec la suppression des configurations obsolètes — Questions 3(6) et 3(7)

À l’issue de cet examen, l’entreprise M décide de recourir au Service D.

• Installer dans la salle de réunion un routeur sans fil prêté par le Service D (routeur D)
• Activer sur le routeur D les fonctions de serveur DHCP et de serveur de cache DNS
• Faire en sorte que les appareils apportés par les invités se connectent à Internet sans passer par le réseau de l’entreprise M, via la carte SIM intégrée au routeur D
• Ne plus utiliser le LAN sans fil des invités pour le projecteur, et le connecter désormais par câble HDMI

flowchart LR
    subgraph M["Réseau interne de l'entreprise M (après mesures)"]
        direction TB
        E["LAN sans fil employés<br/>EAP-TLS + RADIUS<br/>clé privée dans le TPM"]
        S["Réseau des serveurs"]
        FW["Pare-feu"]
        E --> FW
        S --> FW
    end
    subgraph K["Salle de réunion"]
        T["Appareil apporté par un invité"]
        D["Routeur D<br/>vers Internet directement via SIM"]
        T --> D
    end
    FW --> B["Service B"]
    D --> I["Internet"]

Le réseau invités est désormais séparé du réseau de l’entreprise M, tant physiquement que logiquement. Il ne sort plus jamais par la même adresse IP globale.

Question 3(6) — Les communications devenues inutiles

Une fois que les appareils apportés par les invités n’utilisent plus le réseau de l’entreprise M, les communications vers le serveur DHCP et le serveur [h], jusque-là nécessaires, ne le sont plus. L’exemple de réponse au blanc h est DNS.

Comme le routeur D possède lui-même les fonctions de serveur DHCP et de serveur de cache DNS, les appareils apportés par les invités n’ont plus besoin d’utiliser le serveur DHCP ni le serveur DNS situés sur le réseau des serveurs de l’entreprise M. En relisant l’explication de l’énoncé, la réponse s’y trouve telle quelle.

Question 3(7) — Lister toutes les configurations à supprimer

La question 3(7) demande de répondre, pour ce changement, en indiquant tous les numéros de ligne à supprimer, respectivement dans la configuration des interfaces VLAN et dans la configuration de filtrage du pare-feu.

La réponse est : dans la configuration des interfaces VLAN, le VLAN du LAN sans fil des invités (ligne 1) ; et dans la configuration de filtrage, deux règles : celle qui autorise le HTTP/HTTPS du LAN sans fil des invités vers Internet (ligne 1), et celle qui autorise l’accès du LAN sans fil des invités vers le DNS du réseau des serveurs (ligne 4). À cela s’ajoute, dans la configuration des AP, la suppression du SSID des invités.

Le commentaire de notation écrit :

La question 3(7) a obtenu un taux de bonnes réponses élevé. Il fallait comprendre l’ensemble des configurations de filtrage du pare-feu ainsi que l’impact de la refonte de l’environnement du LAN sans fil pour répondre correctement, et cela a été bien compris.

Bien que le taux de bonnes réponses ait été élevé pour cette question, peu d’organisations vont réellement jusqu’au bout de cet exercice en pratique. L’installation d’un nouveau mécanisme reçoit un budget et une échéance ; la suppression d’une ancienne configuration, non. Et les oublis de suppression finissent par se manifester de la manière suivante.

Le pare-feu de cette question fonctionne selon le principe suivant, explicitement indiqué dans l’énoncé : évaluer les règles dans l’ordre croissant de leur numéro, et appliquer la première qui correspond. Avec ce mode de fonctionnement, laisser subsister, plus haut dans la liste, une règle d’autorisation devenue inutile revient exactement à laisser ouverte une brèche empêchant la règle de refus finale d’être jamais atteinte.

Cela dit, il ne faut pas généraliser ce mode d’évaluation à tous les pare-feu. Chaque produit a ses propres règles de décision.

Quel que soit le mode de fonctionnement, le fait que laisser subsister une autorisation inutilisée soit dangereux ne change pas. Ce qui change, c’est « pourquoi c’est dangereux » et « comment le corriger ». Vérifiez selon quel mode fonctionne votre équipement, et intégrez, dans votre inventaire périodique, la question « la source et la destination existent-elles encore aujourd’hui ? ».

La gestion, côté hôte, des règles de trafic entrant nécessaires aux applications professionnelles est traitée dans Le pare-feu Windows et les applications professionnelles.

11. Les mesures qui n’ont pas fonctionné, et celle qui a fonctionné

Résumé en un seul tableau, ce problème donne ce qui suit : les mesures que possédait l’entreprise M, et où elles ont été contournées.

Seule la dernière ligne relève de ce qui « a fonctionné ». Voici maintenant les mesures élaborées en réponse.

À la comparaison, la différence de nature saute aux yeux. Les mesures contournées interdisaient surtout des « moyens », tandis que la mesure qui a fonctionné et celles qui ont été élaborées modifient la « voie » elle-même ou la nature des « identifiants ». Bloquer les clés USB ne sert à rien si une voie d’accès aux fichiers subsiste ; allonger une clé pré-partagée ne change rien au fait qu’il s’agit d’un secret partagé.

12. Points de contrôle pour la pratique professionnelle

Voici les points à vérifier pour appliquer ce problème à sa propre configuration.

1. Peut-on décrire les mesures anti-exfiltration en termes de voies, et non de moyens ? Plutôt qu’une liste de moyens (clés USB, pièces jointes, webmail), dresser la liste des « appareils et réseaux capables d’atteindre les fichiers professionnels ». S’il subsiste ne serait-ce qu’une seule voie accessible par un appareil non géré, l’interdiction des moyens sera contournée
2. Les règles d’apport et d’exfiltration limitent-elles un lieu précis ? « Interdiction d’apporter dans l’espace de bureaux » autorise implicitement la salle de réunion, l’accueil, les espaces communs. Vérifier que les zonages physiques et réseau coïncident
3. Peut-on énoncer ce qu’une restriction par adresse IP source autorise réellement ? Compter tout ce qui sort par cette adresse IP globale : Wi-Fi invité, réseau invités, VPN inter-sites, passerelle d’agrégation du télétravail, environnement de test
4. Les identifiants du LAN sans fil sont-ils propres à chaque appareil ? Une clé pré-partagée est un secret partagé identique pour tous ; si une personne le divulgue, c’est celui de tout le monde qui fuit, et il est impossible d’arrêter un seul appareil en particulier
5. Le filtrage par adresse MAC et la non-diffusion du SSID ne sont-ils pas comptés parmi les mesures ? Ce sont l’un et l’autre du rangement destiné à réduire les connexions accidentelles, pas de l’authentification
6. La clé privée du certificat client est-elle dans un état où elle ne peut pas être extraite de l’appareil ? Une clé privée placée sous forme de fichier peut être copiée. Spécifier un fournisseur de stockage de clés basé sur le TPM, et ne pas autoriser l’exportation
7. Le client sur lequel EAP-TLS a été déployé valide-t-il bien le certificat du serveur d’authentification ? Désactiver cette vérification fait perdre toute résistance à un faux serveur d’authentification
8. Une erreur de certificat serveur peut-elle être contournée par l’utilisateur en cliquant sur « continuer » ? Configurer HSTS sur ses propres sites. Ne pas laisser traîner les erreurs de certificat des systèmes internes, au risque d’apprendre aux utilisateurs que « l’erreur, ça se clique pour continuer »
9. Le contenu du magasin des autorités de certification racines de confiance fait-il l’objet d’un inventaire ? Ce qu’il contient représente exactement les entités que cet appareil considère comme dignes de confiance dès lors qu’elles ont émis un certificat
10. Les approbateurs du flux d’approbation disposent-ils des éléments nécessaires à leur décision ? Et les résultats des approbations sont-ils consultés après coup ? Passer régulièrement en revue les partages adressés à des domaines externes ou à des messageries gratuites
11. Les configurations des voies mises hors service sont-elles supprimées ? Interfaces VLAN, règles de filtrage, SSID, entrées de listes d’autorisation. Traiter le travail de suppression avec la même rigueur — et la même échéance — que le travail d’ajout

Pour conclure — Une mesure qui ne précise pas son « périmètre » ne protège rien

Si la question 1 demandait « quelle mesure arrête quelle étape de quelle attaque », la question 2 demande « quel périmètre chaque mesure protège-t-elle ».

Chacune des mesures de l’entreprise M avait un périmètre implicite. Le logiciel de prévention des fuites d’informations couvrait le PC professionnel, et rien de plus. L’interdiction d’apporter un appareil couvrait l’espace de bureaux, et rien de plus. Le filtrage par adresse MAC couvrait « ceux qui n’usurpent pas d’identité », et rien de plus. La restriction par adresse IP source couvrait « tous ceux qui sortent par cette adresse IP globale », et rien de plus. Chaque périmètre fonctionnait correctement ; c’est simplement que la jointure avec le périmètre voisin restait ouverte.

Ce qui rend ce problème pertinent pour la pratique, c’est que l’entreprise M y est dépeinte comme une entreprise ayant pris ses mesures au sérieux. Après l’incident de l’année précédente, elle a bouché les deux extrémités du chemin d’exfiltration, et a même installé un logiciel dédié. Si des failles subsistent malgré tout, ce n’est pas parce que le responsable a été négligent, mais parce qu’une méthode consistant à ajouter les mesures une par une ne laisse jamais voir les interstices entre les périmètres.

Pour trouver ces interstices, il n’y a pas d’autre solution que de dresser, non pas une liste de mesures, mais une liste de voies d’accès. C’est exactement ce que faisaient M. Y et M. S dans ce problème : séparer « l’attaquant externe » et « l’employé », et pour chacun, boucher une à une les voies d’accès possibles. La « capacité à envisager, sous des angles variés, les menaces propres à un environnement utilisant un LAN sans fil » que l’IPA mentionne dans l’intention de l’épreuve désigne sans doute précisément ce travail.

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) propose des revues de conception fondées sur les réseaux et les configurations d’appareils existants, ainsi que la mise en œuvre de la distribution de certificats et de la protection des clés dans les environnements Windows.

• Conseil technique et revue de conception
• Développement Windows
• Investigation de bugs et analyse des causes
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Nous avons interdit la connexion de clés USB et interdit aussi l'enregistrement sur le disque local. Pourquoi peut-on quand même sortir des fichiers ?

Parce que ce qui a été interdit, ce sont des fonctions du PC professionnel prêté par l'entreprise, et non la voie d'accès à l'endroit où se trouvent les fichiers. Dans ce problème, l'employé utilise son propre PC personnel. Sans jamais toucher au PC professionnel, il connecte son PC personnel au LAN sans fil de la salle de réunion, se connecte au stockage cloud (Service B) avec son propre identifiant, télécharge les fichiers, et repart avec ce PC personnel lui-même. La configuration du logiciel de prévention des fuites installé sur le PC professionnel n'a strictement aucun effet sur un PC personnel. L'entreprise M interdisait bien d'apporter un PC personnel, mais cette interdiction ne portait que sur l'espace de bureaux ; la salle de réunion en était exclue. Même si l'on bouche les moyens un par un (clé USB, pièce jointe, webmail), l'exfiltration réussit tant qu'il subsiste une voie permettant d'atteindre les fichiers.

Le Service B était restreint à « connexion possible uniquement depuis l'adresse IP globale de l'entreprise M ». Pourquoi cela ne bloque-t-il pas l'accès depuis le LAN sans fil des invités ?

Parce que le trafic du LAN sans fil des invités passe lui aussi par le NAT du même pare-feu et est traduit vers la même adresse IP globale avant de sortir vers Internet. Du point de vue du Service B, l'accès depuis un PC professionnel à l'intérieur de l'entreprise et l'accès depuis un PC personnel connecté au LAN sans fil des invités dans la salle de réunion apparaissent comme provenant exactement de la même adresse IP source. Il est impossible de les distinguer. Il faut comprendre qu'une restriction par adresse IP source est un paramètre qui autorise non pas « seulement cet appareil », mais « tous ceux qui partagent ce point de sortie ». Le Wi-Fi invité, les VPN inter-sites, les passerelles d'agrégation pour le télétravail — tout ce qui sort par la même adresse IP globale — entrent tous dans le périmètre autorisé.

Le LAN sans fil des employés était protégé par un filtrage par adresse MAC. Cela ne constitue-t-il pas une mesure de sécurité ?

Non. Car une adresse MAC peut être librement réécrite du côté de l'appareil. La méthode 1 de ce problème consistait à changer l'adresse MAC de l'interface sans fil d'un PC personnel pour lui donner celle d'un PC professionnel enregistré, puis à s'y connecter. Comme l'adresse MAC contenue dans les trames du LAN sans fil circule sans être chiffrée, il est même possible, en captant le signal à proximité, de découvrir l'adresse MAC d'un appareil déjà enregistré. La même chose vaut pour la non-diffusion du SSID : même désactivée, le SSID devient identifiable à partir de l'échange qui a lieu lorsqu'un appareil se connecte. Le filtrage par adresse MAC et la non-diffusion du SSID réduisent les connexions accidentelles, mais ce ne sont pas des mécanismes d'authentification capables d'arrêter une connexion intentionnelle.

Même avec un faux point d'accès et un faux site mis en place, pourquoi peut-on affirmer que l'employé ne sera pas trompé ?

Parce que, dès lors que la connexion se fait en HTTPS, un faux site ne peut pas réussir la validation du certificat serveur. La figure 2 de l'énoncé liste quatre éléments susceptibles d'apparaître comme détail de l'erreur qui en résulte : non émis par une autorité de certification de confiance ; nom de serveur indiqué sur le certificat différent de celui de la cible ; révoqué ; expiré. Un attaquant ne peut pas obtenir de certificat légitime pour le nom de domaine du Service B : un certificat auto-signé échoue au premier point, et un certificat légitimement obtenu pour le propre domaine de l'attaquant échoue au second. Selon le commentaire de notation de l'IPA, le taux de bonnes réponses à la question portant sur ce contenu de vérification était faible. À noter que ces quatre éléments n'ont pas tous la même force. Ce qui arrête réellement l'attaque, ce sont les deux premiers (émetteur et nom) ainsi que la date d'expiration : ces points sont toujours vérifiés par le navigateur. La vérification de la révocation, en revanche, dépend de l'implémentation et de la configuration. Chrome, par exemple, n'effectue normalement pas de vérification OCSP ou CRL en ligne ; il utilise à la place une liste limitée appelée CRLSet, dont l'objectif principal est le blocage d'urgence. Ne partez donc pas du principe qu'une révocation garantit un blocage. Et si un PC professionnel dispose du certificat racine d'une autorité de certification interne, et que la clé privée de cette autorité, ou sa procédure de délivrance, a été compromise par un attaquant, même le premier point de vérification passe.

Que se passe-t-il si l'on se trompe et que l'on saisit « http:// » dans l'URL ? Que fait concrètement HSTS ?

Le navigateur remplace le HTTP par du HTTPS avant de se connecter, si bien que le résultat reste, là encore, une erreur de certificat serveur. HSTS est un mécanisme par lequel le navigateur se souvient du contenu d'un en-tête reçu lors d'une précédente connexion HTTPS à ce site. La RFC 6797 exige que, lorsqu'une URL pour l'hôte cible contient le schéma http, l'agent utilisateur le remplace par https, en convertissant le port 80 en 443 s'il était indiqué explicitement. Autrement dit, la requête HTTP en clair disparaît avant même de sortir sur le réseau. Plus important encore : si la validation du certificat échoue lors d'une communication avec un hôte pour lequel HSTS est actif, la connexion doit être interrompue, qu'il s'agisse d'un avertissement ou d'une erreur fatale. Il est explicitement précisé qu'il ne faut jamais proposer à l'utilisateur une option du type « cette connexion n'est pas sécurisée, continuer quand même ? ». HSTS suppose cependant que ce navigateur a déjà atteint une fois le site légitime en HTTPS et a reçu l'en-tête correspondant. Sur un appareil tout neuf dont le tout premier accès tombe directement sur un faux site, HSTS ne protège pas. C'est la liste de préchargement intégrée au navigateur qui comble ce premier accès.

Que change le fait de stocker la clé privée d'un certificat client dans le TPM ?

La clé privée ne peut plus être extraite de ce PC professionnel. Une clé privée conservée sous forme de fichier sur l'appareil peut être copiée puis transportée sur un PC personnel, ce qui permet à ce PC personnel de réussir l'authentification comme s'il s'agissait du PC professionnel. Si la clé est générée à l'intérieur du TPM dans un état non exportable, les opérations telles que la signature s'exécutent entièrement à l'intérieur du TPM, et la clé elle-même n'atteint jamais le système d'exploitation ni un logiciel malveillant. Résultat : seuls les PC professionnels distribués par l'entreprise peuvent réussir l'authentification EAP-TLS. C'est la raison pour laquelle M. S a pu dire, dans ce problème, que « cette méthode de stockage ne pose pas de problème ». Pour une implémentation sous Windows, on spécifie Microsoft Platform Crypto Provider comme fournisseur de stockage de clés du modèle de certificat, avec l'exportation de la clé privée désactivée. Le TPM protège cependant uniquement le fait que « la clé ne peut pas être dupliquée vers un autre appareil » ; il ne change rien au fait que la personne qui détient physiquement cet appareil peut l'utiliser. En cas de perte ou de vol de l'appareil, il faut prévoir séparément le chiffrement du disque et la révocation du certificat.

Que faut-il retenir de ce problème pour sa propre pratique ?

Quatre choses. Premièrement, penser les mesures anti-exfiltration en termes de voies d'accès, et non de moyens : bloquer les clés USB, les pièces jointes et le webmail un par un ne sert à rien s'il subsiste un appareil capable d'atteindre les fichiers. Deuxièmement, écrire concrètement le périmètre que la restriction par adresse IP source autorise réellement : si le Wi-Fi invité ou un VPN partage la même sortie, il entre aussi dans ce périmètre. Troisièmement, faire de l'authentification du LAN sans fil un identifiant propre à chaque appareil : une clé pré-partagée est un secret partagé identique pour tout le monde, si bien que sa fuite par une seule personne compromet tout le monde. Passer à EAP-TLS avec des certificats clients, et faire en sorte que la clé privée ne quitte jamais le TPM, fixe l'identifiant à l'appareil. Quatrièmement, supprimer les configurations devenues inutiles : la dernière sous-question de ce problème demandait de lister l'intégralité des configurations d'interface VLAN et des règles de filtrage du pare-feu restant après la mise hors service du LAN sans fil des invités ; selon le commentaire de notation de l'IPA, le taux de bonnes réponses était élevé, mais peu d'organisations vont réellement jusqu'au bout de cet exercice en pratique.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.