Faille Target 2013, alertes FireEye ignorées et segmentation

Faille Target 2013, alertes FireEye ignorées et segmentation

Fin 2013, le distributeur américain Target perd environ 40 millions de cartes de paiement et les données personnelles de jusqu’à 70 millions de clients, en pleine saison des fêtes. Le cas est resté dans les manuels pour une raison précise : l’outil de détection a vu l’attaque, l’a signalée, et le signalement est arrivé devant des humains avant qu’une seule donnée ne quitte le réseau. La détection a fonctionné ; c’est tout ce qui vient après elle qui a cédé.

Explication de la marmotte

Une alarme incendie qui sonne dans un immeuble où tout le monde a pris l’habitude des fausses alertes : le détecteur fait son travail, personne ne se lève. Cette page raconte un cambriolage géant où l’alarme a bel et bien retenti, et sert à comprendre pourquoi une sonnerie ne vaut rien sans quelqu’un chargé d’y répondre.

→ Lire l’explication complète de la marmotte

Chronologie de l’intrusion Target, du prestataire aux caisses

Les faits viennent de sources publiques : le rapport du personnel de la majorité de la commission du Commerce du Sénat américain (« A “Kill Chain” Analysis of the 2013 Target Data Breach », 26 mars 2014), l’enquête de Bloomberg Businessweek (« Missed Alarms and 40 Million Stolen Credit Card Numbers », mars 2014), les articles de Brian Krebs, les auditions du directeur financier John Mulligan devant le Sénat et les rapports annuels de Target.

Le point d’entrée s’appelle Fazio Mechanical Services, une entreprise de climatisation et de réfrigération de Pennsylvanie. Environ deux mois avant l’intrusion, un courriel d’hameçonnage porteur d’un logiciel malveillant (Krebs cite Citadel) lui vole ses identifiants d’accès à un portail fournisseurs de Target : facturation électronique, dépôt de contrats, gestion de projet. La légende veut que les attaquants soient entrés « par la climatisation ». C’est faux, et la nuance compte : le prestataire ne pilotait aucun équipement de magasin par ce portail. C’était un accès administratif, de ceux qu’on ouvre pour payer des factures et qu’on oublie ensuite pendant dix ans.

Date (2013)	Événement
12 novembre	Première intrusion dans le réseau (date donnée par Target au Sénat ; le rapport cite aussi le 15 novembre pour l’usage des identifiants de Fazio)
15 au 28 novembre	Logiciel de capture testé sur un petit nombre de caisses
Vers le 28 novembre	L’antivirus Symantec signale une activité suspecte
30 novembre	Déploiement sur la majorité des caisses, installation du logiciel d’exfiltration ; alertes FireEye relayées de Bangalore à Minneapolis, sans suite
2 décembre	Nouvelle version du logiciel, nouvelles alertes FireEye, sans suite ; début de l’exfiltration vers des serveurs relais, puis vers la Russie
12 décembre	Le département de la Justice prévient Target
15 décembre	Target confirme et retire le logiciel
18 décembre	Brian Krebs révèle l’affaire
19 décembre	Annonce publique de Target

Les cartes ont été capturées du 27 novembre au 15 décembre. Le chemin exact suivi entre le portail fournisseurs et le réseau des caisses n’est pas établi publiquement dans le détail ; ce que le rapport du Sénat établit, c’est que la segmentation entre le réseau administratif et celui des caisses ne l’a pas empêché.

Le logiciel est une variante de BlackPOS (aussi nommée Kaptoxa), un « RAM scraper », c’est-à-dire un programme qui fouille la RAM (Random Access Memory, la mémoire vive) de la caisse. Les données de piste magnétique y séjournent en clair un bref instant, entre la lecture de la carte et le chiffrement. Chiffrer le transport et le stockage ne change rien à cet instant-là : le logiciel lit avant.

Exemple : déroulé de l’attaque et alertes FireEye non traitées

Le schéma suit les acteurs dans l’ordre réel. À lire en cherchant une seule chose : le moment où une information exacte arrive devant quelqu’un et ne déclenche aucune décision.

Sept lignes d’attaque, trois lignes de défense. Les deux premières lignes de défense ont marché : l’outil a détecté, l’équipe de surveillance de Bangalore a relayé. La troisième n’est pas une flèche : c’est un pavé posé sur Minneapolis, d’où rien ne repart, ce qui est la représentation graphique la plus honnête d’une alerte reçue et rangée.

FireEye avait été installé environ six mois plus tôt, pour 1,6 million de dollars selon Bloomberg. Sa fonction de suppression automatique du logiciel malveillant détecté était désactivée. Ce réglage n’a rien d’exotique : la plupart des équipes préfèrent décider elles-mêmes plutôt que de laisser un produit couper des machines de production. Le raisonnement tient debout, à une condition que personne n’écrit jamais dans le dossier d’architecture : que quelqu’un décide, effectivement, dans un délai connu.

Surface d’attaque : accès tiers, segmentation et mémoire des caisses

Le rapport du Sénat relève une série d’occasions manquées, qu’on peut ranger en cinq : accès tiers insuffisamment cloisonné, absence d’authentification à deux facteurs exigée pour ce prestataire, segmentation insuffisante entre réseau administratif et réseau des caisses, alertes non traitées, exfiltration non bloquée. Cinq couches, cinq occasions d’arrêter l’attaque. Chacune se traduit en règle générale.

L’accès tiers. Un compte de prestataire hérite du niveau de sécurité du poste le moins protégé chez ce prestataire. Une entreprise de réfrigération n’a ni l’équipe ni le budget d’un distributeur national, et c’est normal : son métier est le froid. Un mot de passe seul, sur un portail exposé, vaut donc ce que vaut l’antivirus d’une petite structure face à un hameçonnage. Second facteur obligatoire, compte nominatif, droits limités à l’application, et surtout aucun chemin réseau depuis la zone où vit le portail vers le reste. Le sujet est traité dans la page sur le Zero Trust appliqué aux prestataires.

La segmentation. Un découpage en zones qui n’est pas appliqué par un équipement de filtrage n’est qu’un plan d’adressage. La question à poser à une architecture n’est pas « y a-t-il des zones ? » mais « quel flux initié depuis la zone fournisseurs atteint une caisse, et qui l’a autorisé ? ». Si la réponse demande une réunion, la segmentation est décorative. Les fondamentaux sont dans la page filtrage, segmentation et NAC.

La sortie. L’exfiltration a duré deux semaines. Une caisse parle à un nombre fini de destinations connues ; un serveur interne qui pousse des fichiers vers l’extérieur n’en fait pas partie. Le filtrage de sortie par liste fermée est la mesure la moins glorieuse et la plus rentable du lot.

La topologie ci-dessous montre le cloisonnement cible (pas le réseau réel de Target, dont le détail n’est pas public). À regarder : aucun flux ne part de la zone fournisseurs vers les caisses, et les caisses ne sortent que par un point contrôlé.

Traitement des alertes : tri, escalade et blocage automatique

Voici le cœur du dossier. Ce qui a manqué ne s’achète pas chez un éditeur : un tri qui distingue l’alerte grave du bruit, une escalade avec un destinataire nommé, une responsabilité de décision attribuée, et un blocage automatique là où le délai humain est trop long.

Une alerte « relayée » est une alerte dont chacun pense que l’autre s’en occupe. Le relais de Bangalore vers Minneapolis a transmis l’information, pas l’obligation d’agir. Une escalade sans accusé de réception, sans délai maximal et sans personne habilitée à dire « on isole ces machines » est un transfert de courriel avec un organigramme autour. La mécanique d’érosion (volume, faux positifs, habituation) est décrite dans la page sur la fatigue d’alerte au SOC, et son versant cognitif dans celle sur la charge cognitive de l’analyste.

Le compromis central est celui du blocage automatique. Ce qu’on gagne en le désactivant : aucun faux positif ne coupe la production, et couper des caisses un week-end de fêtes est le genre de décision qui se discute en comité de direction. Ce qu’on paie : la détection ne vaut plus que le temps de réaction de l’humain le plus lent de la chaîne. Chez Target, ce temps a été de quinze jours, et il a fallu le département de la Justice pour l’interrompre.

La position défendue ici : le blocage automatique se décide par classe d’actif, pas par produit ni par principe.

• Actifs à fonction fixe (caisses, bornes, automates) : blocage automatique activé. Une machine qui exécute toujours le même logiciel n’a aucune raison légitime d’en voir apparaître un nouveau. Le taux de faux positifs y est bas par construction, et le coût d’un arrêt à tort (quelques caisses isolées) reste borné.
• Actifs à usage variable (postes de travail, serveurs applicatifs) : décision humaine admissible, à condition de fixer un délai maximal de décision et de prévoir l’isolement par défaut à son expiration.
• Dans tous les cas : désactiver un blocage est une acceptation de risque. Elle se signe, elle a un propriétaire, et elle crée une dette d’astreinte : quelqu’un doit être joignable et habilité à trancher.

Conditions de validité : cette répartition suppose un inventaire qui sait dire à quelle classe appartient une machine, et un taux de faux positifs mesuré, pas supposé. Sans ces deux éléments, on active le blocage au hasard, et le premier arrêt de production injustifié le fera désactiver partout, pour toujours.

Dernier piège, fréquent : un outil fraîchement déployé n’a pas encore la confiance de ceux qui le lisent. Six mois après l’installation, les analystes ne savent pas encore si une alerte de sévérité maximale est rare ou quotidienne. Tant que personne n’a rejoué d’attaque simulée pour étalonner cette confiance, l’outil parle une langue que son équipe ne comprend pas tout à fait.

Limites de la détection et de la conformité PCI DSS

Target avait été certifié conforme PCI DSS (Payment Card Industry Data Security Standard, le référentiel de sécurité des données de cartes) en septembre 2013, deux mois avant l’intrusion. Aucune contradiction là-dedans : une certification atteste qu’à une date donnée, sur un périmètre donné, des contrôles existaient. Elle ne dit rien de leur fonctionnement un samedi soir de novembre. La conformité est une photographie ; l’attaque, elle, se tourne en vidéo.

Ce que les mécanismes en place ne garantissaient pas, et d’où devait venir le reste :

• Un outil de détection ne garantit aucune réaction. Il produit un signal. La réaction vient d’une organisation : rôles, délais, droits d’agir.
• Le chiffrement des cartes ne couvre pas la mémoire vive du terminal. Tant que le chiffrement n’est pas fait dans le lecteur lui-même, les données existent en clair sur la caisse. La protection vient alors du contrôle de ce qui s’exécute sur la machine.
• L’authentification forte d’un tiers ne garantit pas son innocuité. Un prestataire dont le poste est compromis s’authentifie très bien, second facteur compris, dans certains scénarios. Le cloisonnement réseau prend le relais.
• La segmentation ne détecte rien. Elle ralentit et canalise. Sans supervision des flux refusés, elle bloque en silence et ne prévient personne.

Chaque couche a un trou connu, et c’est précisément pour cela qu’on en empile plusieurs. Le cas Target montre l’empilement complet échouant en série, ce qui arrive quand chaque couche compte sur la suivante.

Conditions d’exploitation d’une chaîne d’alerte opérante

Avant d’acheter un outil de détection, quatre choses doivent exister. Sans elles, l’investissement produit des journaux de qualité à l’usage des enquêteurs.

Prérequis. Un inventaire des actifs classés par criticité ; une cartographie des flux autorisés entre zones ; une liste des comptes tiers avec leur propriétaire interne ; un point de sortie unique et filtré pour les zones sensibles.

Responsabilité. Pour chaque classe d’alerte grave : qui la reçoit, qui décide, en combien de temps, et ce qui se passe automatiquement si personne ne décide. Le quatrième point est celui qu’on oublie, parce qu’il oblige à écrire noir sur blanc que les humains peuvent être absents.

Supervision de la chaîne elle-même. Mesurer le délai entre émission et prise en charge, le taux d’alertes fermées sans action, le nombre d’alertes de sévérité maximale restées sans propriétaire. Une alerte critique sans accusé de réception passé un délai fixé doit elle-même déclencher une alerte, vers quelqu’un d’autre. Tester la chaîne de bout en bout par injection régulière d’un échantillon inoffensif : si le test ne remonte pas jusqu’à un humain, l’attaque ne remontera pas non plus.

Secrets et rotation. Les identifiants de prestataires expirent, se renouvellent, et se révoquent le jour où le contrat s’arrête. Un compte tiers dormant est un accès offert à quiconque fouille les boîtes aux lettres du prestataire.

Reprise. La procédure d’isolement d’une zone (caisses comprises) doit être écrite et répétée, avec le mode dégradé qui va avec. Une équipe qui n’a jamais isolé un segment à blanc hésitera à le faire en vrai, et l’hésitation se compte en cartes volées.

Bilan financier et suites de la compromission Target

Le 10 janvier 2014, Target ajoute aux 40 millions de cartes les données personnelles (nom, adresse postale, téléphone, courriel) de jusqu’à 70 millions de clients. La directrice des systèmes d’information, Beth Jacob, démissionne le 5 mars 2014 ; le président-directeur général, Gregg Steinhafel, part le 5 mai 2014.

Coût cumulé déclaré par Target fin 2016 : 292 millions de dollars, soit 202 millions nets après 90 millions d’assurance. S’y rattachent un accord de 18,5 millions avec 47 États et le district de Columbia (mai 2017), 10 millions pour l’action de groupe des consommateurs (2015), environ 67 millions pour Visa et environ 39 millions pour les banques émettrices MasterCard.

À mettre en regard : un outil à 1,6 million qui a donné la bonne information, gratuitement, deux fois. D’autres dossiers, comme celui de Facebook et la fonction « Voir en tant que », montrent des défauts de conception ; celui-ci montre un défaut d’organisation, plus banal et nettement plus répandu.

FAQ

L’attaque est-elle passée par le système de climatisation ?

Non. Les identifiants volés donnaient accès à un portail fournisseurs administratif (facturation, contrats, gestion de projet). Le prestataire était une entreprise de climatisation, mais il ne pilotait aucun équipement de magasin par cet accès. Le raccourci a la vie dure parce qu’il est plus amusant que la vérité.

La suppression automatique aurait-elle arrêté l’attaque ?

Les alertes du 30 novembre ont précédé le début de l’exfiltration, le 2 décembre : une suppression automatique du logiciel détecté serait donc intervenue avant toute fuite. Affirmer qu’elle aurait tout arrêté dépasse ce que les sources établissent, puisque les attaquants disposaient déjà d’un accès au réseau. Elle aurait au minimum forcé une réaction.

La certification PCI DSS de septembre 2013 était-elle erronée ?

Les sources publiques citées ici ne l’établissent pas. Une certification porte sur l’existence de contrôles à une date et sur un périmètre donnés. Elle ne mesure ni le traitement quotidien des alertes ni la tenue réelle de la segmentation face à un attaquant déjà entré.

🐝 Ce qui arrive si on s’en passe

Sans chaîne de traitement d’alerte dotée d’un propriétaire, d’un délai et d’une action par défaut, l’outil de détection change de fonction : il cesse de protéger et se met à archiver. La durée de présence de l’attaquant n’est plus fixée par la défense, mais par le premier tiers qui remarque la fraude, banque ou autorité judiciaire. Les journaux conservés établissent alors, heure par heure, que l’information était disponible, ce qui transforme un incident technique en question de responsabilité des dirigeants. Enfin, chaque alerte grave restée sans effet apprend à l’équipe que ce niveau de sévérité n’engage à rien, et dégrade le traitement de la suivante.

🦫 Explication de la marmotte 🍫

Des voleurs envoient un courriel piégé à une petite entreprise qui travaille pour une grande chaîne de magasins. Ils récupèrent ainsi le nom d’utilisateur et le mot de passe que cette entreprise utilise pour déposer ses factures sur un site du distributeur. Avec ce seul mot de passe, ils entrent. Le réseau qui sert aux factures et celui qui relie les caisses ne sont pas assez séparés : les voleurs passent de l’un à l’autre. Ils installent sur les caisses un programme qui copie les numéros de carte au moment précis où la carte est lue, juste avant que ces numéros soient rendus illisibles. Un logiciel de surveillance repère ce programme et envoie des avertissements. Une première équipe les transmet à une seconde, chargée de réagir. Cette seconde équipe ne fait rien. Le logiciel aurait pu effacer lui-même le programme des voleurs, mais cette option avait été éteinte, pour que des humains gardent la décision. Aucun humain ne décide. Deux jours plus tard, les numéros commencent à partir vers des ordinateurs situés à l’étranger, et cela dure deux semaines, jusqu’à ce que la justice prévienne le distributeur. La surveillance avait donc bien fonctionné. Ce qui a échoué, c’est la suite : personne n’était clairement chargé d’agir, dans un temps fixé, après l’avertissement.

À lire aussi

• WannaCry et MS17-010 : fenêtre d'exposition et correctifsWannaCry, EternalBlue et MS17-010 montrent comment les deux mois entre un correctif publié et un correctif déployé deviennent la fenêtre d'exposition d'un parc Windows.
• Sécurité des systèmes bancaires et financiersLes systèmes bancaires et financiers combinent exigences PCI DSS, DORA, disponibilité continue et lutte antifraude temps réel.
• Sécuriser un paiement e-commerce contre la fraudeArchitecture de sécurité des plateformes e-commerce contre la fraude au paiement et l'exposition des données de carte bancaire.
• Pourquoi les certifications pénalisent les PME rigoureusesAnalyse du fardeau imposé par les certifications de sécurité multiples aux petites structures et des alternatives proportionnées pour évaluer leur niveau réel.

Pages voisines

La citent

• WannaCry et MS17-010 : fenêtre d'exposition et correctifs
• EDR : fonctionnement, angles morts et contournements

Faille Target 2013, alertes FireEye ignorées et segmentation

Elle cite

• Faille Facebook Voir en tant que 2018 et vol de jetons d'accès
• Comment auditer les comptes orphelins après un départ
• Comment contrer le spear phishing et la fraude au président
• Comment mener un exercice de simulation d'incident
• Filtrage, segmentation, NAC et Zero Trust
• Pourquoi un analyste SOC rate une alerte critique
• Réduire la fatigue d’alerte dans un SOC
• Zero Trust pour les accès des prestataires