Cas type E7 corrigé : authentification et habilitations

a) Une pulvérisation de mots de passe (password spraying) : depuis une même adresse (203.0.113.45), l'attaquant essaie un seul mot de passe par compte sur plus de 150 comptes différents, à quelques secondes d'intervalle (de 02:11:03 à 02:19:52), jusqu'à trouver un compte, mrenaud, dont le mot de passe correspond. Ce n'est pas une force brute sur un compte : il y aurait plusieurs essais sur le même identifiant.

b) Le verrouillage compte les échecs par compte : avec un seul essai par compte, aucun compte n'atteint le seuil de 5. L'attaque est conçue pour rester sous ce seuil.

c) La session VPN de mrenaud a duré de 02:19:53 à 02:47:18 (27 minutes et 25 secondes) et octets-out=2147483648 indique 2 147 483 648 octets, soit 2 Gio, transférés vers l'extérieur : une exfiltration de données probable. L'incident est une violation de données potentielle, à qualifier au plus vite (quelles données ? des données personnelles d'adhérents ?).

a) Par exemple : désactiver le compte mrenaud et révoquer ses sessions ; bloquer l'adresse 203.0.113.45 sur le pare-feu ; rechercher dans les journaux (VPN, contrôleurs de domaine, serveurs de fichiers) ce que le compte a fait pendant la session et si d'autres comptes ont été touchés ; réinitialiser le mot de passe de mrenaud après avoir vérifié son poste ; conserver les journaux comme preuves (copie protégée, avec empreinte).

b) Une violation de données personnelles présentant un risque pour les personnes doit être notifiée à la CNIL dans les 72 heures après en avoir pris connaissance (article 33 du RGPD), et documentée dans le registre des violations. Si le risque est élevé pour les adhérents (les IBAN permettent des fraudes et des hameçonnages ciblés), ils doivent aussi être informés (article 34). Le dépôt de plainte est recommandé.

Constats. 8 caractères avec trois types donnent au mieux 8 × log₂ 62 ≈ 47,6 bits, sous les 50 bits que la CNIL demande même avec une restriction d'accès, et loin des 80 bits d'un mot de passe seul. Le changement tous les 90 jours pousse aux variantes prévisibles (du type Valfleuri2026!), justement celles qu'essaie une pulvérisation ; la CNIL ne le demande plus que pour les comptes d'administration. Le verrouillage définitif par le support coûte cher et ne bloque pas la pulvérisation. Les administrateurs n'ont pas de règle renforcée.

Politique révisée.

• Salariés : au moins 12 caractères avec les quatre types, ou 14 sans caractère spécial imposé, ou une phrase de passe de 7 mots ; refus des mots de passe connus et compromis, et de ceux qui contiennent le nom de l'organisation ; plus de changement périodique, mais changement obligatoire en cas de compromission ; temporisation puis verrouillage temporaire après une dizaine d'échecs, et détection des échecs répartis sur plusieurs comptes depuis une même source.
• Administrateurs : stratégie affinée (PSO) d'au moins 16 caractères, renouvellement périodique, comptes d'administration distincts des comptes bureautiques et MFA obligatoire.
• Pour tous : stockage des mots de passe applicatifs avec Argon2id ou bcrypt, et un gestionnaire de mots de passe fourni par l'entreprise.

a) L'attaquant a trouvé le mot de passe de mrenaud, un facteur de connaissance. Avec une MFA, il lui aurait aussi fallu un facteur de possession (le téléphone ou la clé de sécurité de M. Renaud) : le serveur RADIUS aurait refusé l'accès malgré le bon mot de passe, et l'échec du second facteur aurait pu déclencher une alerte.

b) Une application d'authentification sur le téléphone professionnel, avec code TOTP ou notification avec appariement de nombres, vérifiée par le serveur RADIUS du VPN (ou un certificat machine sur les portables gérés, en plus du mot de passe). Le SMS est déconseillé : il peut être intercepté ou détourné par SIM swapping, et les exploitations visitées ont souvent une mauvaise couverture réseau, alors qu'un code TOTP se calcule hors connexion.

a) La clé est connue de tous les salariés actuels et anciens, et de toute personne à qui elle a été donnée : n'importe lequel peut se connecter au réseau interne depuis le parking. Aucune connexion n'est imputable à une personne, et changer la clé oblige à reconfigurer tous les appareils, ce qui explique qu'on ne le fasse jamais.

b) WPA3-Entreprise (802.1X) : le supplicant (le portable ou le téléphone du salarié) s'authentifie auprès de l'authentificateur (la borne Wi-Fi), qui relaie l'échange EAP au serveur d'authentification RADIUS, lui-même relié à l'Active Directory. Méthode recommandée : EAP-TLS avec des certificats machine délivrés automatiquement aux postes du domaine, qui ne transmet aucun mot de passe ; à défaut, PEAP-MSCHAPv2 avec vérification obligatoire du certificat du serveur imposée par GPO. Un départ se traite en désactivant le compte, ou en révoquant le certificat.

a) Par l'attribution dynamique de VLAN : la stratégie RADIUS qui correspond au groupe des salariés renvoie, dans son Access-Accept, les attributs Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802 et Tunnel-Private-Group-Id = 20. Le switch ou la borne place la connexion dans ce VLAN.

b) Les capteurs : authentification par adresse MAC (MAB) dans une stratégie dédiée qui les place dans le VLAN 30, avec un filtrage strict sur le pare-feu (ils ne parlent qu'au serveur de supervision), puisqu'une adresse MAC se falsifie. Les adhérents : un SSID invités relié au VLAN 40, isolé de tous les réseaux internes, avec un portail captif et des codes temporaires remis à l'accueil, une limitation de débit et la journalisation des connexions.

• Groupes globaux par fonction : GG_Resp_Silos (les quatre responsables), GG_Qualite (les trois personnes du service), GG_Direction.
• Groupes de domaine local par droit sur la ressource : DL_Qualite_M et DL_Qualite_L.
• Imbrication : GG_Resp_Silos et GG_Qualite membres de DL_Qualite_M ; GG_Direction membre de DL_Qualite_L.
• Permissions NTFS sur Qualite : Modification pour DL_Qualite_M, Lecture pour DL_Qualite_L (pas de Contrôle total, qui permettrait de changer les autorisations). Autorisations de partage larges (Modification pour les utilisateurs authentifiés), le tri se faisant en NTFS.

a) Le compte partagé maintenance rend les actions non imputables : impossible de savoir quel technicien du prestataire a fait quoi, et le mot de passe circule entre plusieurs personnes. L'accès RDP direct, sans second facteur, expose le serveur de supervision (et, par rebond, le réseau des silos) à la force brute et à la réutilisation d'un mot de passe volé.

b) Un bastion d'administration : chaque technicien du prestataire a un compte nominatif, s'authentifie avec une MFA, n'est autorisé que vers le serveur de supervision et pendant les créneaux du contrat ; le bastion injecte le mot de passe de la cible (que le technicien ne connaît pas) et enregistre les sessions. Pare-feu : RDP (TCP 3389) vers le serveur de supervision autorisé uniquement depuis l'adresse du bastion, tout accès RDP direct depuis Internet ou depuis les autres réseaux refusé ; seul l'accès HTTPS au bastion est publié.

L'écart de 9 minutes dépasse la tolérance de 5 minutes de Kerberos : les horodatages chiffrés envoyés par les postes sont refusés par les contrôleurs de domaine, qui craignent un rejeu. Correction immédiate : resynchroniser l'heure des postes (w32tm /resync). Correction durable : vérifier que les postes se synchronisent bien sur la hiérarchie de temps du domaine (et non sur une horloge locale déréglée par la coupure), que le contrôleur émulateur PDC se synchronise sur une source NTP fiable, et que le flux NTP (UDP 123) passe entre le silo et le siège.

a) Lignes 1 et 2 : la saisie de l'utilisateur est concaténée dans la requête SQL, d'où une injection SQL : un identifiant comme ' OR 1=1 -- (avec une espace après les deux tirets) neutralise la condition sur le mot de passe et ouvre une session sur le premier compte. Ligne 2 : le mot de passe est haché avec MD5, rapide, cassé et sans sel ; en cas de fuite, la plupart des mots de passe sont retrouvés en quelques minutes. On peut ajouter, ligne 5 : pas de régénération de l'identifiant de session (fixation de session).

b)

$req = $pdo->prepare('SELECT id, role, empreinte_mdp FROM adherent WHERE login = ?');
$req->execute([$_POST['login']]);
$adherent = $req->fetch();

if ($adherent && password_verify($_POST['mdp'], $adherent['empreinte_mdp'])) {
    session_regenerate_id(true);
    $_SESSION['id'] = $adherent['id'];
    $_SESSION['role'] = $adherent['role'];
    header('Location: /accueil.php');
    exit;
}
$erreur = 'Identifiant ou mot de passe incorrect.';   // même message dans tous les cas

La requête préparée sépare le code SQL des données ; password_verify() compare le mot de passe à l'empreinte salée ; le message d'erreur unique évite d'indiquer si l'identifiant existe.

Deux stratégies se combinent :

1. Immédiatement, pour toutes les lignes : remplacer chaque empreinte MD5 par password_hash($empreinteMd5, PASSWORD_DEFAULT) (on hache l'ancienne empreinte), avec une colonne format = 'md5-bcrypt'. Plus aucune empreinte MD5 brute ne reste en base : une fuite ne livre que des empreintes lentes. À la connexion, on vérifie password_verify(md5($saisi), $empreinte) pour ces lignes.
2. À la première connexion réussie de chaque adhérent, on recalcule une empreinte normale avec password_hash($saisi, PASSWORD_DEFAULT), on passe le format à standard et l'on n'utilise plus MD5 pour cet adhérent.

Les comptes qui ne se reconnectent jamais restent protégés par l'étape 1 ; au bout d'un délai, on peut leur imposer une réinitialisation par courriel.

a) L'API renvoie les factures de l'adhérent 215 : elle vérifie que l'appelant est authentifié (proteger), mais pas que l'identifiant de l'adresse est le sien. C'est une référence directe non sécurisée (IDOR), forme de contrôle d'accès défaillant (A01 du Top 10 de l'OWASP). En faisant varier le nombre, un adhérent lit les factures de tous les autres.

b)

app.get('/api/adherents/:id/factures', proteger, async (req, res) => {
  const estLuiMeme = req.utilisateur.role === 'adherent'
    && String(req.utilisateur.id) === req.params.id;
  const estGestionnaire = req.utilisateur.role === 'gestionnaire';
  if (!estLuiMeme && !estGestionnaire) {
    return res.status(403).json({ erreur: 'Accès interdit' });
  }
  const [factures] = await db.execute(
    'SELECT numero, date_facture, montant FROM facture WHERE id_adherent = ?',
    [req.params.id],
  );
  res.json(factures);
});

L'identité et le rôle viennent de req.utilisateur, posé par proteger à partir du jeton vérifié, jamais de la requête. On vérifie aussi le type de compte : les identifiants des adhérents et des salariés viennent de deux tables différentes, et un salarié dont salarie.id vaut 215 ne doit pas passer pour l'adhérent 215. Les accès des gestionnaires aux factures des adhérents peuvent en plus être journalisés.

a) Ajouter une date de début obligatoire et une date de fin facultative, avec une contrainte de cohérence :

ALTER TABLE habilitation
  ADD COLUMN date_debut DATE NOT NULL DEFAULT (CURRENT_DATE),
  ADD COLUMN date_fin DATE NULL,
  ADD CONSTRAINT chk_habilitation_dates CHECK (date_fin IS NULL OR date_fin >= date_debut);

La clé primaire (id_salarie, id_appli) garantit déjà un seul rôle par application. L'application ne retient que les lignes où date_debut <= CURRENT_DATE et date_fin est nulle ou postérieure ou égale à la date du jour.

b)

SELECT id_salarie, id_appli, role, date_fin
FROM habilitation
WHERE date_fin BETWEEN CURRENT_DATE AND CURRENT_DATE + INTERVAL 7 DAY
ORDER BY date_fin;

Les lignes sans date de fin (NULL) ne sont pas retenues : NULL BETWEEN … n'est pas vrai.

Problèmes. Le message différent selon que l'adresse existe ou non permet d'énumérer les adhérents (on teste une liste d'adresses). L'envoi d'un mot de passe en clair par courriel l'expose dans la boîte de messagerie (interception, accès à la messagerie, transfert), et ce mot de passe peut rester utilisé longtemps.

Procédure sûre. Toujours le même message (« Si un compte correspond, un courriel a été envoyé ») ; génération d'un jeton aléatoire d'au moins 128 bits, dont seule l'empreinte est stockée, avec une expiration courte (30 minutes par exemple) ; envoi d'un lien contenant ce jeton ; sur la page du lien, l'adhérent choisit lui-même un nouveau mot de passe, soumis aux règles de la politique ; le jeton est invalidé après usage ; les sessions ouvertes sont fermées et un courriel de notification confirme le changement ; le nombre de demandes est limité par adresse et par IP.