Deux victimes, un fournisseur : trouver le fournisseur commun à deux intrusions
Le défi
Un groupe de cliniques et une entreprise de fret, dans des secteurs différents et sans aucun client, salarié ni réseau en commun, se sont fait dérober des données la même semaine par une session à laquelle personne ne s'est jamais connecté. Aucun des deux ne trouve de courriel d'hameçonnage, de mot de passe volé ni de logiciel malveillant, et tous deux utilisaient une authentification multifacteur qui n'a jamais été sollicitée. Ce que deux organisations comme celles-là partagent, ce sont des fournisseurs. Six documents publics sont sur le tableau. Trouvez le fournisseur présent dans les deux histoires et capable de créer une session sans connexion.
Ce que tu vas apprendre
- Dresser l'inventaire des fournisseurs de deux organisations à partir de divulgations publiques
- Croiser deux ensembles et utiliser des preuves secondaires pour trancher
- Reconnaître les fonctionnalités d'usurpation d'identité des fournisseurs comme un chemin d'authentification non journalisé
- Expliquer pourquoi la MFA reste silencieuse quand une session est créée côté serveur
- Utiliser une troisième organisation, non touchée, comme groupe témoin
Compétences testées
Prérequis
- Le fonctionnement du SSO et de la MFA
- La lecture d'une notification de violation de données
Comment ça marche
Quand deux organisations qui n'ont rien en commun sont touchées la même semaine par le même mécanisme inexpliqué, le point commun est presque toujours un fournisseur. Les inventaires de fournisseurs sont bien plus publics que les entreprises ne le pensent : les notifications de violation nomment les systèmes, les déclarations réglementaires précisent le périmètre, les offres d'emploi décrivent la pile technique en détail, et les ingénieurs répondent aux questions sur les forums.
La faiblesse spécifique ici est une fonctionnalité d'usurpation d'identité. Les outils de support proposent souvent un moyen pour un agent d'ouvrir l'application d'un client en tant que l'un des utilisateurs de ce client, car c'est le moyen le plus rapide de reproduire un bug. La session est créée du côté du fournisseur, si bien que le fournisseur d'identité du client n'est jamais sollicité. Aucun événement de connexion, aucune sollicitation MFA, aucune localisation anormale, rien dans le journal d'authentification du client. Tout ce que la victime utiliserait normalement pour enquêter est aveugle par conception.
C'est pourquoi le départage ne dépend pas du fournisseur le plus grand ou le plus manifestement critique pour la sécurité. Il dépend du fournisseur capable de créer une session sans effectuer de connexion, car c'est la seule capacité qui correspond à ce que les deux victimes ont décrit.
Erreurs fréquentes
- Répondre « Latchkey SSO ». Il apparaît dans les deux piles et c'est le fournisseur d'identité, ce qui en fait la réponse intuitive. Son historique de statut couvre toute la période, son évaluation externe est propre, et la victime affirme qu'il n'y a rien dans ses journaux. Croiser les ensembles ne suffit pas, il faut éliminer.
- Répondre « Northfield » ou « Vantage ». Chacun n'apparaît que chez une seule victime.
- Traiter le fil du forum comme du bruit. La clinique qui a abandonné Tidemark en juillet et qui n'a pas été touchée est ce qui se rapproche le plus d'un groupe témoin sur le tableau.
- Chercher le vecteur d'accès initial chez les victimes. Aucune des deux victimes n'était le point d'entrée. L'attaquant était déjà à l'intérieur du fournisseur.
Comment s'en protéger
Considérez tout fournisseur capable d'agir en tant que vos utilisateurs comme faisant partie de votre périmètre d'identité.
- Recensez quels fournisseurs disposent de droits d'usurpation, d'assistance ou de connexion support, et désactivez la fonctionnalité là où personne ne l'utilise réellement.
- Exigez une approbation client par session pour l'usurpation, avec une expiration, afin qu'une compromission côté fournisseur ne puisse pas créer de sessions en silence.
- Exigez que les journaux d'audit côté fournisseur soient exportables vers votre propre SIEM en quasi temps réel. Harlow et Calder n'ont pas pu interroger le journal qui contenait la réponse avant une semaine après l'intrusion.
- Générez une alerte sur toute activité privilégiée issue de sessions sans événement d'authentification correspondant dans votre fournisseur d'identité. Cette corrélation est peu coûteuse et c'est exactement la faille dans laquelle vit cette attaque.