- La défense réseau commence par lister les actifs et les hiérarchiser, mais la surface d’attaque réelle prend la forme d’un graphe de dépendances de sécurité entre les actifs
- Au lieu d’attaquer de front l’actif le mieux protégé, les attaquants cherchent un chemin de contournement vers les actifs à forte valeur en passant par des postes de travail ou des voies d’administration faiblement protégés
- Dans les réseaux Windows, des éléments comme les méthodes de connexion, les identifiants, les TGT Kerberos, les hachages NTLM, les mots de passe d’administrateur local communs ou les scripts de connexion peuvent tous devenir des arêtes du graphe
- Les défenseurs doivent transformer l’inventaire des actifs en graphe et réduire la connectivité via la segmentation de l’infrastructure, les silos d’identifiants, le moindre privilège, l’authentification à deux facteurs et la rotation des identifiants
- Comme les attaquants apprennent l’infrastructure réelle par fragments plutôt qu’à partir de schémas obsolètes, les défenseurs ne peuvent garder l’avantage qu’en comprenant plus précisément les relations de connexion du réseau actuel
Ce que la défense en liste ne voit pas
- De nombreuses défenses réseau sont faussées avant même tout contact avec l’attaquant, car elles comprennent mal le terrain
- Les défenseurs se concentrent sur la protection des actifs, leur priorisation et leur classement par charge de travail et fonction métier
- Les services d’administration système, les bases de données d’inventaire d’actifs et les feuilles de calcul BCDR débordent de listes d’actifs
- Mais ce que les défenseurs doivent réellement gérer, ce n’est pas une liste d’actifs isolés, c’est un graphe où les actifs sont reliés par des relations de sécurité
- Les attaquants atterrissent en un point du graphe via des techniques comme le spearphishing, puis se déplacent dans le réseau à la recherche de systèmes vulnérables
- Ce graphe n’est pas donné de l’extérieur : il est créé par les défenseurs eux-mêmes lorsqu’ils conçoivent et exploitent le réseau
Ce que signifie le graphe à l’intérieur du réseau
- Le graphe du réseau est un ensemble de dépendances de sécurité qui crée des classes d’équivalence entre les actifs
- Quatre grands facteurs influencent ce graphe
- la conception du réseau
- la manière dont le réseau est administré
- les logiciels et services utilisés dans le réseau
- le comportement des utilisateurs
- Dans l’exemple d’un contrôleur de domaine, une seule voie d’administration faible peut abaisser le niveau de sécurité de l’ensemble des actifs à forte valeur
- Bob administre le contrôleur de domaine depuis son poste de travail
- Si ce poste n’est pas protégé au même niveau que le contrôleur de domaine, alors le contrôleur de domaine peut lui aussi être compromis
- D’autres comptes disposant de privilèges administrateur sur le poste de Bob peuvent également compromettre Bob et le contrôleur de domaine
- Ces administrateurs se connectent, pour leur travail, à une ou plusieurs autres machines
- Si l’attaquant en compromet une, un chemin vers le contrôleur de domaine apparaît
Six Degrees of Mallory : déplacement latéral en suivant le graphe
- L’attaquant peut attendre sur une machine compromise qu’un compte à forte valeur s’y connecte, puis utiliser un outil de vidage de mots de passe comme mimikatz
- Le cluster de gauche dans le graphe d’exemple est un Terminal Server unique utilisé par plusieurs centaines de personnes
- Si l’attaquant compromet cette machine, il peut avec le temps extraire les identifiants de nombreux utilisateurs
- Une exploration du graphe révèle plusieurs chemins vers le High Value Asset
- La compromission du Terminal Server permet aussi de compromettre User46 et User128
- User46 est administrateur de Machine2821, et User128 est administrateur de Machine115
- En compromettant ces postes de travail, il devient possible de compromettre User1 et User34
- User1 et User34 sont tous deux administrateurs du High Value Asset
- Pour protéger le High Value Asset, tous les éléments dont il dépend doivent être protégés avec le même niveau d’exigence ; ils forment ainsi une classe d’équivalence
Les relations qui créent des dépendances de sécurité
- Dans un réseau Windows, lorsqu’un utilisateur effectue certains types de connexion, comme Interactive ou Terminal Server, ses identifiants peuvent être exposés au vol si l’hôte sous-jacent est compromis
- L’exposition concerne non seulement les identifiants, mais aussi des équivalents de single sign-on comme les TGT Kerberos et les hachages NTLM
- Les dépendances de sécurité naissent aussi de relations d’administration ordinaires
- Comptes administrateur local avec mot de passe commun : après avoir extrait le mot de passe administrateur local d’un système, il peut être réutilisé sur d’autres hôtes qui emploient le même mot de passe
- Serveurs de fichiers hébergeant des scripts de connexion exécutés par de nombreux utilisateurs, ainsi que serveurs de mise à jour logicielle
- Serveurs d’impression qui transmettent des pilotes d’impression aux machines clientes lors de leur utilisation
- Autorités de certification qui émettent des certificats valides pour la connexion par carte à puce
- Administrateurs de base de données capables d’exécuter du code dans le contexte d’un serveur de base de données tournant avec un utilisateur privilégié
- Les relations indirectes font aussi partie du graphe
- Lorsqu’une machine vulnérable est compromise, l’attaquant peut créer de nouvelles arêtes dans le graphe
- Si un utilisateur possède, dans deux domaines sans relation de confiance, des comptes avec le même mot de passe, une arête cachée apparaît entre ces domaines
Comment réduire le graphe
- La première étape pour les défenseurs consiste à transformer l’inventaire des actifs en graphe afin de visualiser le réseau
- Il faut ensuite élaguer le graphe en recherchant les arêtes indésirables qui provoquent de grandes explosions de connectivité
- Mettre en place une segmentation de l’infrastructure et des silos d’identifiants
- Réduire le nombre d’administrateurs et minimiser les privilèges avec des approches Just-In-Time / Just Enough
- Utiliser l’authentification à deux facteurs pour limiter certains déplacements le long des arêtes
- Appliquer des mécanismes robustes de rotation des identifiants pour se préparer à la compromission de comptes utilisateurs
- Réexaminer les relations de forest trust
Construire un modèle du réel meilleur que celui des attaquants
- Les défenseurs ne doivent pas céder l’avantage aux attaquants lorsqu’ils visualisent le terrain
- Les défenseurs peuvent disposer d’une vue complète de leur réseau, tandis que les attaquants doivent l’apprendre morceau par morceau
- Les attaquants n’étudient ni des modèles mentaux inexacts, ni des systèmes d’inventaire incomplets, ni des schémas réseau obsolètes, mais l’infrastructure telle qu’elle existe aujourd’hui
- Les défenseurs doivent eux aussi administrer leur réseau à partir de cette réalité pour se rapprocher d’un état d’esprit de défense réellement préparé
Pour aller plus loin
- Heat-ray: Combating Identity Snowball Attacks Using Machine Learning, Combinatorial Optimization and Attack Graph : J. Dunagan, D. Simon, A. Zheng
- Two Formal Analyses of Attack Graphs : S. Jha, O. Sheyner, J. Wing
- Using Model Checking to Analyze Network Vulnerabilities : P. Ammann, R. Ritchey
- A Graph-Based System for Network-Vulnerability Analysis : C. Phillips, L. Swiler
- Automated Generation and Analysis of Attack Graphs : J. Haines, S. Jha, R. Lippman, O. Sheyner, J. Wing
- Modern Intrusion Practices : Gerardo Richarte
- Attack Planning in the Real World : Jorge Lucangeli Obes, Gerardo Richarte, Carlos Sarraute
1 commentaires
Avis de Hacker News
Un attaquant a généralement une mission, par exemple exfiltrer des données importantes, déstabiliser une cible ou déployer un ransomware, et peut explorer aussi profondément que nécessaire jusqu’à l’accomplir.
À l’inverse, le défenseur doit suivre simultanément de nombreux signaux et vecteurs de menace ; il est donc contraint de penser en listes, et doit même prioriser les éléments à traiter en raison de la réglementation.
À moins que des défenseurs ne soient répartis arbitrairement un peu partout dans le graphe pour y chercher des activités intéressantes, je ne vois pas comment ils pourraient penser en graphes. Ce que propose l’auteur finit simplement par devenir des signaux de plus dans une liste que le défenseur doit comparer.
Quand les défenseurs l’ont adoptée, ils ont pu identifier des attaques potentielles avant que la red team ne les exécute. Une équipe intelligente reprendra immédiatement, par exemple, des techniques de red team consistant à crawler AWS sous forme de graphe pour trouver des chemins allant de comptes de faible valeur vers des comptes de forte valeur.
Ce n’est pas une question de jeu à somme nulle ni de basculement radical, mais les défenseurs peuvent davantage penser comme les attaquants et utiliser plus souvent des outils d’attaquants pour la défense.
Il faut donc protéger les chemins menant à cet objectif, indépendamment de leur forme ou du fait qu’ils se limitent ou non au logiciel.
Un attaquant pourrait exploiter une CVE pour mettre le système de divertissement en déni de service, mais on peut se demander à quel point cela compte réellement.
La grande majorité des attaques réelles ressemble plutôt à « regardons ce qu’on peut trouver, et on verra plus tard comment l’utiliser ». C’est aussi le cas de nombreuses activités offensives comme la collecte d’informations, les opérations d’influence ou la propagande.
Les défenseurs utilisent des listes parce qu’ils doivent gérer simultanément des centaines, voire des milliers d’actifs. Quand on doit gérer beaucoup de choses, on fait des listes, on les parcourt et on applique des check-lists.
Bien sûr, les défenseurs devraient aussi établir des graphes de dépendances, mais il faut d’abord dresser la liste, vérifier qu’elle est à jour, qu’elle suppose une confiance limitée et que les ressources sont isolées, puis construire le graphe de dépendances.
Les défenseurs doivent penser à la fois en listes et en graphes, tout en gérant un nombre énorme d’éléments, tandis que les attaquants n’ont besoin d’en examiner que quelques-uns.
Sans l’intuition permettant de transformer la liste en graphe, on se retrouve avec une simple liste d’actifs critiques et à jouer au jeu de la taupe contre des dizaines de milliers de chemins d’accès qu’on n’avait pas envisagés.
J’ai l’impression que cet article va trop loin. Ou bien que la raison est juste, mais pas la cause. Le travail d’un défenseur n’est pas la défense en soi.
La cybersécurité n’est pas un match de sport avec des objectifs clairs et symétriques, et des positions qu’on occupe à tour de rôle ; c’est plutôt un événement annexe et une distraction à côté de l’autre activité métier que le défenseur essaie réellement de mener.
À l’inverse, tout le travail de l’attaquant consiste à attaquer le système. Il n’a pas d’autre finalité, de maître secondaire ni de considérations qui viendraient affaiblir l’attaque.
Si l’attaquant gagne, c’est pour la même raison que Microsoft sort mieux des systèmes d’exploitation que Cisco. Pour Cisco, le système d’exploitation est un moyen ; pour Microsoft, c’est une fin.
Il explique aussi pourquoi les entreprises sont rarement vraiment sanctionnées par le marché après une fuite de données.
Les cyberattaques ont des objectifs clairs : vol de données, interruption de service, etc. Cela peut être vrai pour des acteurs immatures qui veulent seulement casser et semer le chaos, mais si l’on considère les acteurs étatiques ou les criminels motivés par l’argent, c’est complètement à côté de la plaque.
J’ai plutôt l’impression que cet article ne va pas assez loin :-)
Une « liste » est une représentation condensée des composants, tandis qu’un « graphe » est une représentation condensée de l’interopérabilité. Le point de vue des composants relève de l’analyse ; le point de vue des interactions n’a pas encore de bon mot, mais comme le dit l’article, il devient souvent la surface d’attaque.
Un système adaptatif complexe possède des composants et un bus de messages, et l’important est que ce bus fournisse aux composants un moyen d’interopérer. On peut attraper les fourmis une par une, mais pour vraiment les arrêter, il faut leur retirer la capacité à laisser des traces de phéromones.
Ce serait bien d’avoir un mot comme « analyse » pour comprendre les modes d’interopérabilité. Quelque chose comme Gestaltysis ?
J’ai brièvement travaillé dans une entreprise de cybersécurité, et je n’arrivais pas à formuler pourquoi je n’aimais pas son produit, ni pourquoi l’approche de cette entreprise et d’une bonne partie du secteur finissait par me sembler factice.
Maintenant, je comprends. Nous construisions un outil destiné à soutenir la pratique la plus inutile en cybersécurité : la checklist au niveau de l’organisation.
Au centre de toute activité, il y a des listes et des échéances récurrentes. Il faut se présenter régulièrement et faire ce qui doit être fait.
Bien sûr, je suis d’accord pour dire qu’à l’étape de ce « ce qui doit être fait », il faut une approche plus profonde et meilleure.
Pour pouvoir dire : « Nous avons suivi toutes les checklists, et le logiciel de sécurité ne l’a pas détecté, donc ce n’est pas notre faute. »
Si une entreprise se souciait vraiment de la sécurité, elle engagerait une red team au lieu de payer pour des scanners inutiles avec un rapport signal/bruit inférieur à 1 %.
Regardez l’aviation : les pilotes vivent grâce aux checklists. Cela ne garantit pas qu’aucun problème ne surviendra en vol, mais ne pas suivre une checklist, ou la traiter à la légère, c’est appeler la catastrophe. Ces checklists reposent sur des années d’expérience coûteuse.
En revanche, une checklist qui existe simplement pour pouvoir dire « nous avons une checklist », ou qui n’est pas régulièrement revue et mise à jour en fonction des conditions réelles, n’a aucun sens.
Beaucoup d’entreprises comprennent cela de travers. Elles pensent que la checklist elle-même est la sécurité, alors qu’en réalité une checklist n’est qu’un outil pour rappeler de continuer à faire ce qui a déjà été correctement mis en place. Dès qu’on traite la checklist comme un objectif, on s’égare.
En tant que pentester, je dirais que les attaquants ne pensent pas forcément en graphes non plus.
À part BloodHound, aucun outil utilisant des graphes ne me vient vraiment à l’esprit.
En sécurité web, je ne vois pas non plus où s’appliquerait cette « pensée en graphe ». À la place, la liste des attaques à tester est très longue : https://portswigger.net/web-security/all-topics
Et ce qui finit dans un rapport de pentest, ce n’est pas un graphe, mais une liste de choses à faire. Par exemple : la signature SMB, ne pas utiliser de comptes administrateur de domaine pour gérer toutes les machines, etc.
Si cette formule est populaire, c’est surtout parce qu’elle flatte l’ego de la communauté hacker. « Nous sommes les intelligents, les défenseurs ne font que manipuler des feuilles Excel », en gros.
Il y a quand même une part de vérité. Les défenseurs peuvent passer beaucoup de temps sur des choses peu importantes. Par exemple, appliquer manuellement les benchmarks CIS à tous les serveurs tout en ratant les fruits à portée de main qui permettraient de bâtir une posture de sécurité solide.
Dans beaucoup d’entreprises, les défenseurs ne sont que des administrateurs système qui ne savent pas sur quoi se concentrer.
L’exemple qui me vient tout de suite à l’esprit est celui des chaînes de bugs. En combinant quelques vulnérabilités de niveau CVSS 4 à 7, on peut obtenir un résultat de niveau 9,8, comme une exécution de code à distance complète. Relier ces bugs revient fondamentalement à parcourir un graphe d’éléments de compromission.
BloodHound est excellent, et c’est un bon outil visuel pour conceptualiser les graphes d’attaque, mais ce n’est qu’une partie du processus de compréhension d’un domaine cible du point de vue de l’attaquant.
S’il n’existe pas d’outil aussi propre que BloodHound pour le pentest web, c’est parce qu’il est difficile de réduire une chaîne de compromission à un simple outil. Dans AD, les frontières de sécurité sont relativement comprises et codifiées, alors que dans les applications web, les chaînes sont souvent propres à l’application concernée plutôt qu’au framework sous-jacent.
Si des éléments comme la signature SMB ou « ne pas tout administrer avec un compte DA » apparaissent dans un rapport de pentest, c’est parce qu’ils constituent des nœuds qui brillent très fort, très tôt dans la chaîne de compromission. Dans la vraie vie, les compromissions arrivent souvent de cette manière.
Ce n’est pas tant que les pentesters ne comprennent pas la pensée en graphe ; c’est plutôt que, parfois, le premier nœud du graphe signifie déjà une compromission quasi complète, donc il n’y a plus vraiment de raison de poursuivre le parcours.
C’est surtout une reformulation élégante de l’idée selon laquelle les défenseurs doivent protéger tous les points d’entrée, tandis que les attaquants n’ont besoin de trouver qu’une seule faiblesse.
Par exemple, on pourrait imaginer utiliser des honeypots pour renvoyer des exploits zero-day vers les machines des attaquants. Peut-être que c’est même conçu intentionnellement dans des produits de Google, Microsoft, etc.
Aller franchement du côté black hat, avec une sorte de déni plausible, et servir du ransomware aux opérateurs de ransomware.
En l’écrivant, ça ressemble à une méchante mégacorporation toute-puissante de science-fiction, mais ces entreprises-là vont généralement jusqu’à assassiner leurs ennemis.
J’ai aussi fait de la réponse à incident, et j’ai de l’expérience en pentest et en red team. C’est une formule raccourcie, mais elle est assez juste, et je ne pense pas qu’elle doive être aussi négative que le suggère l’article.
La défense se compose de plusieurs éléments. Par exemple : développer des contrôles efficaces qui réduisent le risque et l’impact des incidents de sécurité, identifier les attaques et les compromissions, et répondre aux incidents. Les listes de standards et de réponses fonctionnent bien.
La défense inclut aussi des décisions d’architecture où il faut penser au graphe du réseau pour concevoir ces contrôles. Le domaine défensif est lui aussi varié : architecture/ingénierie, gestion des risques, réponse à incident, sécurité applicative, formation, threat intelligence, etc.
Il est également intéressant que l’auteur suggère que le problème vient du fait que la défense pense en listes, puis propose une liste d’éléments à prendre en compte pour améliorer la défense.
Les attaquants gagnent parce qu’après avoir trouvé une faiblesse, il leur suffit de réussir une seule fois. Les défenseurs doivent protéger tout en même temps.
Il me semble que chaque réseau devrait avoir au moins un honeypot pour piéger les intrus. Par exemple de faux identifiants de cryptomonnaie, de faux coffres de mots de passe, etc.