Force brute : anatomie d’une attaque

Le tapage médiatique généré par NotPetya a fait passer inaperçu ce qui aurait pu constituer une menace plus importante : une attaque par force brute du parlement du Royaume-Uni. Même si de nombreuses personnes y ont simplement vu le prétexte idéal pour faire des plaisanteries sur le Brexit sur Twitter, une attaque telle que celle-ci visant un organe gouvernemental majeur nous rappelle que la force brute reste une menace répandue à prendre en compte.

Cet événement soulève également des questions essentielles sur la façon dont une telle attaque a bien pu se produire tout simplement :

Ces problèmes suggèrent que nous devons accorder plus d’attention à ce type d’attaque qui reste mal compris en dépit de son importance.

Qu’est-ce que la force brute ?

Pour résumer, il existe deux méthodes pour s’infiltrer dans une organisation : l’exploitation des erreurs humaines ou le tâtonnement. L’exploitation des erreurs humaines fait l’objet de nombreuses variantes d’attaque : le phishing (erreur de l’utilisateur), l’exploitation d’une faiblesse de la configuration (erreur de l’administrateur) ou la mise à profit d’une vulnérabilité zero day (erreur du développeur). Le tâtonnement, quant à lui, repose sur un seul type d’attaque : la force brute.

Généralement, une attaque par force brute sert à deviner les données d’identification, même si elle est aussi parfois utilisée pour deviner d’autres éléments tels que des URL.

Une attaque par force brute est une tentative visant à deviner des mots de passe depuis les locaux mêmes du hacker une fois que celui-ci est parvenu à s’emparer des mots de passe chiffrés. Il est ainsi en mesure d’utiliser de puissants ordinateurs pour tester un nombre considérable de mots de passe sans risquer d’être détecté. En revanche, une telle attaque par force brute ne peut pas être la première étape d’une attaque puisque le pirate doit déjà avoir en sa possession une copie des mots de passe chiffrés de la victime.

La variante en ligne et en temps réel de l’attaque tente quant à elle de frapper de manière répétée une fonction logique d’un système ou d’une application pour deviner les données d’identification. Puisque cette technique n’implique pas de disposer préalablement des mots de passe chiffrés, les hackers peuvent l’employer pour essayer de pénétrer dans un système dans lequel ils ne disposent d’aucun point d’accès.

Des attaques par force brute se produisent-elles en ligne ?

Au final, tenter de deviner à la fois un nom d’utilisateur et un mot de passe est très difficile. Étant donné que la plupart des systèmes ne précisent pas si c’est le nom d’utilisateur ou le mot de passe qui est incorrect en cas d’échec de la connexion, le pirate commence par s’attaquer aux utilisateurs connus. Il peut déterminer des noms d’utilisateur en recourant à de l’intelligence open source : dans de nombreuses organisations, par exemple, les noms d’utilisateur respectent une structure prévisible basée sur le nom de l’utilisateur – et une simple recherche sur LinkedIn révèlera un grand nombre de ces noms.

Cela dit, ce type d’attaque classique en ligne par force brute (du moins lorsqu’il vise des systèmes bien établis) relève plus du mythe que de la réalité. La raison est simple : la plupart des systèmes et applications modernes intègrent une contre-mesure, le verrouillage. Au bout d’un certain nombre de tentatives de connexion, le compte est verrouillé et exige une intervention de l’administrateur afin d’être débloqué. Aujourd’hui, ce sont plus les verrouillages qui posent problème aux services informatique que la force brute, et la surveillance des verrouillages arrive devant la détection de la force brute dans leur liste de tâches.

Les applications personnalisées font toutefois exception. Si le pirate ne peut pas exploiter la connexion Windows classique, il est bien possible qu’il parvienne à venir à bout de la connexion à une nouvelle application Web spécialement développée pour une campagne marketing saisonnière.

L’entrée en scène du « credential stuffing »

Alors que les attaques par force brute en ligne classiques semblent en recul, le credential stuffing se fraie un chemin sur le devant de la scène. Le « credential stuffing » est une attaque qui consiste à utiliser des données d’identification (paires constituées d’un nom d’utilisateur et d’un mot de passe) volées sur des sites Internet publics pour pénétrer dans un système visé. Le nombre d’attaques fructueuses de sites Web publics est en augmentation, et les hackers publient les bases de données d’identifiants ou les vendent au marché noir. L’hypothèse, qui se vérifie bien trop souvent, est que les personnes utilisent les mêmes nom d’utilisateur et mot de passe d’un site à l’autre.

Le credential stuffing passe entre les mailles des protections basées sur le verrouillage puisqu’il utilise chaque nom d’utilisateur une seule fois. En utilisant des paires de nom d’utilisateur / mot de passe connues, le credential stuffing augmente également la probabilité de réussite avec un nombre inférieur de tentatives.

Le verrouillage s’avérant une contremesure inefficace, les organisations intègrent des mécanismes d’authentification à deux facteurs pour essayer de contrer le credential stuffing et, de manière plus générale, le vol de données d’identification. L’authentification à deux facteurs exige d’un utilisateur qu’il utilise un autre élément en plus d’un mot de passe pour s’authentifier : il peut par exemple s’agir d’un téléphone portable particulier sur lequel il pourra recevoir un SMS. Face à la lourdeur de l’authentification à deux facteurs, une authentification réussie accepte généralement tout accès « similaire ». « Similaire » peut signifier l’utilisation du même appareil ou la même position géographique. La plupart d’entre nous ont déjà fait l’expérience de sites Web publics qui exigent une authentification à deux facteurs lorsque nous y accédons depuis un nouvel appareil, un ordinateur public ou lorsque nous sommes en voyage.

Bien que robuste, l’authentification à deux facteurs présente plusieurs inconvénients majeurs puisqu’elle affecte le ressenti de l’utilisateur et exige une connexion interactive. Il n’est rien de plus agaçant que de devoir procéder à une authentification à deux facteurs sur son téléphone alors que l’on vient d’atterrir dans un aéroport étranger après un long vol. La fonction est par conséquent bien souvent laissée au choix de l’utilisateur. Par conséquent, elle exige un système de détection souvent basé sur une capacité d’analyse pour déterminer qu’une attaque par force brute est en cours.

Détection des attaques par force brute

La méthode de détection la plus couramment préconisée pour la force brute offre une solution à la variante classique mais peu usitée de l’attaque : les échecs de connexion répétés pour un même utilisateur durant un cours laps de temps. De nombreux exercices proposés aux débutants pour créer des règles de corrélation de Gestion des événements et informations de sécurité (SIEM) demandent de détecter des attaques par force brute en identifiant exactement un tel scénario. Bien qu’élégant et direct, cet exercice porte sur un vecteur d’attaque quasiment inexistant et dans la réalité il faut bien plus que cela pour détecter une attaque par force brute.

Les attaques par force brute n’en ont pas moins un dénominateur commun : le nombre élevé d’échecs de tentatives d’authentification. Toutefois, la détection ne pouvant se baser sur l’utilisateur, un système doit utiliser une autre clé pour établir un lien entre les événements qui constituent l’attaque.

Une méthode exigera de procéder au suivi des échecs d’authentification depuis une seule source, souvent l’adresse IP. Cependant, les adresses IP publiques devenant plus rares et plus coûteuses, de plus en plus d’utilisateurs finissent par partager la même adresse IP source.

Face à ce problème, un mécanisme de détection peut « apprendre » quel est le débit normal de connexions ou d’échecs d’une adresse IP source pour déterminer quel serait un débit anormal, prenant ainsi en compte la possibilité que plusieurs utilisateurs se connectent depuis la même IP source. Le détecteur peut également utiliser l’empreinte digitale d’un appareil, c’est-à-dire une combinaison de propriétés habituelles d’un appareil en cas d’événement de détection, afin d’isoler une source particulière parmi toutes celles qui utilisent la même adresse IP. L’empreinte ne peut cependant pas constituer un facteur principal. Elle peut seulement aider à vérifier la détection, étant donné que la plupart des propriétés d’empreinte digitale sont sous le contrôle du pirate et qu’il peut les avoir falsifiées.

Les attaques distribuées, qui utilisent par exemple un botnet ou essaient de détourner les données à l’aide d’un réseau de proxies privés tels que TOR, compliquent encore la donne en rendant inutile toute surveillance de la source. L’empreinte digitale d’appareil peut fonctionner dans une certaine mesure, en particulier si l’attaque est quand même menée par une source unique mais qu’elle emprunte différents itinéraires. Une autre approche consiste à utiliser les connaissances dont on dispose sur les menaces pour aider à identifier les accès effectués par les nœuds de botnet ou proxies privés connus.

La détection dans la pratique

Jusqu’ici, nous sommes partis du principe que les événements utilisés pour l’analyse sont clairs et nets : tout échec de connexion est clairement identifié en tant que « connexion », le résultat est clairement identifié en tant que réussite ou échec et le nom d’utilisateur est toujours dans le même champ et au même format.

En pratique, le traitement d’un flux d’événements dans le but de pouvoir l’exploiter pour détecter une attaque par force brute est une difficulté supplémentaire à prendre en compte.

Prenons l’exemple de Windows, la source la plus courante d’événements. Les événements Réussite de la connexion Windows (ID 4624) et Échec de la connexion Windows (ID 4625) sont consignés en local sur chaque ordinateur. Cette caractéristique les rend encore plus difficiles (voire impossibles) à collecter. Cela signifie également que le pirate, qui peut avoir pris possession de l’ordinateur, peut empêcher leur réception. Le contrôleur de domaine enregistre un événement d’authentification qui peut servir de proxy à un événement de connexion. Ce cas existe avec des variantes Kerberos (ID événement 4768) et NTLM (ID événement 4776) pour Windows 2008 et supérieur, et dans un autre ensemble d’ID d’événement de versions antérieures de Windows.

Une fois que nous avons déterminé quels événements suivre, nous devons encore savoir comment identifier correctement la réussite et l’échec. En local, la réussite et l’échec de la connexion font l’objet d’événements séparés tandis qu’au niveau des événements d’authentification du contrôleur de domaine la réussite et l’échec sont signalés dans l’événement.

La recherche Splunk suivante (issue du référentiel de recherche GoSplunk), que j’ai utilisée pour distinguer les échecs de connexion Windows des réussites, montre le niveau de connaissances requis pour extraire de telles informations des événements – et encore, elle ne s’avère d’aucune aide pour l’authentification au niveau du contrôleur de domaine.

Une détection basée sur la chaîne cybercriminelle

L’exemple de la force brute montre clairement que la détection des attaques n’est pas une mince affaire. Aucune des méthodes de détection présentées ci-dessus n’est imparable et les hackers perfectionnent sans relâche leurs méthodes pour éviter d’être détectés.

La détection exige de maîtriser les techniques d’attaque et de bien connaître le comportement des systèmes surveillés. Elle exige également des mises à jour et des améliorations constantes. Il est donc essentiel que tout système utilisé pour détecter les attaques par force brute inclue des algorithmes immédiatement opérationnels ainsi que leurs mises à jour. Se limiter à donner les moyens de collecter les événements et d’écrire les règles ou algorithmes ne suffit pas car il reste encore à l’utilisateur à mettre en œuvre lui-même la logique de détection réelle. Cela suggère également qu’il pourrait être intéressant de comprendre comment le système détecte la force brute au lieu de se contenter de la vague promesse que les attaques par force brute seront détectées. L’enseignement apporté dépassera de loin celui d’un exemple classique.

Et ici encore, cela montre qu’il est primordial de mettre en place un système de détection en couches qui bloquera les pirates au-delà du point d’infiltration, et tout l’intérêt de commencer par la chaîne cybercriminelle.