Go to content

Le Purple team sur Hadoop

Depuis 2018, nos demandes d’accompagnement sur des missions de type Purple Team s’intensifient. Le Purple Team, c’est un travail d’équipe. Les équipes d’audit accompagnent les équipes d’analystes SOC pour mettre en place de nouvelles règles de détection sur un périmètre donné. (https://www.conix.fr/purple-team/)

Périmètres d’intervention du Purple Team

Tous les systèmes soumis à des règles de détection peuvent être pris en compte par un Purple Team afin d’améliorer les capacités d’analyse du SOC. Pour exemple, voici 3 types de périmètres réalisés chez nos clients :

  • Active Directory: c’est le service d’annuaire de Microsoft Windows permettant la centralisation de l’identification et de l’authentification des ordinateurs et des utilisateurs au sein d’un réseau informatique. Maitriser la gestion des identités et des accès est primordial pour une entreprise. Les attaquants savent aussi qu’ils peuvent y trouver une ouverture, d’où la nécessiter de surveiller, et avec les bonnes règles d’analyse de ce service.
  • Proxy : c’est le composant logiciel qui se place entre deux réseaux. Il permet de faciliter, de surveiller mais aussi de filtrer les échanges entre deux hôtes. Ce composant assure une traçabilité des accès et est un puit d’information pour les analystes SOC. L’exploitation de ces journaux permet de revoir les règles de filtrage, et là encore de créer des règles de détection et de corrélation efficaces.
  • Hadoop: c’est un framework libre et open source développé en Java. Il est lié au Big Data et se démocratise pour les entreprises de plus en plus confrontée au stockage des données (https://www.conix.fr/tour-dhorizon-des-technologies-du-big-data/). Hadoop permet la création d’applications distribuées au niveau du stockage et du traitement des données. Il est échelonnable depuis un seul serveur à des milliers de machines, augmentant ainsi la capacité de stockage et de traitement des données. Le Framework est aussi conçu pour détecter et gérer les pannes, le rendant ainsi hautement disponible.

Pour chaque périmètre à auditer, nous avons élaboré un cahier de tests incluant des attaques à jouer et des méthodes de détection à implémenter. Ce cahier de test se personnalise suivant les spécificités de l’entreprise.

La définition d’un cahier de test « Purple Team » suit la méthodologie suivante :

  • Étude de l’état de l’art et des attaques sur le périmètre (prise en compte du contexte externe).
  • Création d’un cahier de tests définissant les attaques et les méthodes de détection associées.
  • Mise en place d’un laboratoire de tests et réalisation des scénarios.
  • Enrichissement du cahier de tests suite aux résultats.
  • Réunion avec les correspondants d’audit au sein de l’entreprise pour compléter et valider le cahier de tests (personnalisation suivant le contexte interne).

Framework Hadoop

Scenario d’attaque

Pour illustrer nos propos, nous avons choisi de vous présenter la préparation du cahier de tests pour le périmètre Hadoop, lié au Big Data, et moins connu des équipes de sécurité.

Lors de cette mission nous avons mis en place un laboratoire constitué de trois machines :

Après la réalisation des étapes préliminaires et la création de la première version du cahier de tests, nous proposons les scénarios d’attaque à notre client, et après validation nous les jouons en mode Purple Team.

A l’état initial, en moyenne, seules 2 attaques sur 20 à 25 scénarios sont détectées par les règles implémentées par les SOC de nos différents clients.

Avec la mise en œuvre du Purple Team, 6 à 10 nouvelles règles de détections sont implémentées en production au cours de la mission, couvrant ainsi une plus large surface de détection. Les règles qui n’ont pas été implémentées pendant la phase de tests (priorisation des actions) font l’objet d’un plan d’action pour les implémenter ultérieurement. Parfois, une mission d’audit de suivi est aussi demandée pour vérifier la bonne implémentation de ces règles de détection.

Définition du cahier de tests

Un des scénarios de notre cahier de tests mettait en scène l’exploitation d’une vulnérabilité RCE (Remote Code Execution) au travers de l’outil de streaming d’Hadoop.

Pour la mener à bien, l’attaquant doit installer le client Hadoop sur sa machine et le configurer pour se connecter au serveur cible.

Pour ce faire, l’attaquant peut accéder au fichier de configuration du serveur Hadoop (généralement accessible sans authentification) sur le port 50070 (http://<IP-cible>:50070/conf). Avec ce fichier, l’attaquant peut configurer son client en reportant les réglages sur ses propres fichiers core-site.xml, mapred-site.xml et yarn-site.xml.

Il faut ensuite décider de l’utilisateur à usurper pour l’attaque (le choix de l’utilisateur se fait côté client et il est donc possible de personnifier l’utilisateur de notre choix) en utilisant la commande suivante :

export HADOOP_USER_NAME=<user>

Par défaut, il n’y a pas de mécanismes d’authentification sur HADOOP (! en paramètre standard !), on peut donc choisir l’utilisateur que l’on veut sans avoir besoin de mot de passe.

Ensuite, l’attaquant appelle le service de streaming en injectant son payload (sa charge malveillante), de la manière suivante :

bin/hadoop jar share/hadoop/tools/lib/hadoop-streaming-2.7.3.jar –input string –outpout <nomFichierCreerAvecResultatCommande> -mapper ‘<commande>’ –reducer NONE –background

Pour finir, il récupère le résultat de sa commande dans l’espace de stockage d’Hadoop, accessible via l’interface WEB.

L’attaquant peut aussi faire un reverse/bind shell et donc ne pas avoir besoin de chercher le fichier contenant le résultat de la commande.

Bilan de l’attaque réalisée

D’un point de vue détection, au premier abord, il semble complexe de différencier la création de transactions légitimes des demandes malveillantes. Dans notre POC réalisé en laboratoire, nous avons travaillé sur des payloads « classiques » et mis en place des règles de détection basiques en mode blacklist.

Détection de l’attaque par blacklist, ici un bind shell

Cependant ce type de détection par blacklist se contourne aisément dans les cas réels.

Nous avons donc par la suite travaillé avec nos clients à la mise place d’une détection par liste blanche. Bien que ce type de méthode soit plus coûteuse en investissement de départ, elle se révèle bien plus sûre et exhaustive sur du long terme.

Conclusion

Nous constatons grâce à ce type d’exercice les bienfaits de la coopération entre auditeurs et analystes SOC et cela nous permet de mettre en place des règles testés en conditions d’attaques réelles et sur des scénarios concrets. C’est un nouveau type de livrables d’audit matérialisés sous formes de règles de détections implémentées en direct par les SOC chez qui nous intervenons.