Aller au contenu
Hermes Codex

Analyse d'Artefact : Droits Sudo et Élévation de Privilèges

1. Emplacement des artefacts (le puzzle de la configuration)

Section intitulée « 1. Emplacement des artefacts (le puzzle de la configuration) »

La configuration sudo est rarement confinée à un seul fichier. Les administrateurs système et les outils de provisionnement automatisé (comme Ansible ou Terraform) utilisent massivement des répertoires d’inclusion modulaires (drop-in directories).

En supposant que l’image forensique compromise est montée sur /mnt/analyse/, les analystes doivent inspecter deux emplacements principaux :

  1. Le fichier de configuration principal : /mnt/analyse/etc/sudoers
  2. Le répertoire d’inclusion : /mnt/analyse/etc/sudoers.d/

2. Décoder la syntaxe Sudo

Section intitulée « 2. Décoder la syntaxe Sudo »

La syntaxe sudoers dicte exactement quelles actions sont permises. Elle suit un paradigme strict : QUI OÙ=(EN_TANT_QUE) QUOI

Pour chasser les modifications malveillantes, les analystes doivent comprendre comment lire ces règles :

  • La règle “Open Bar” (Dangereuse) : nico ALL=(ALL:ALL) ALL

    • Qui : l’utilisateur nico
    • Où : sur tous les hôtes (ALL)
    • En tant que : n’importe quel utilisateur ou n’importe quel groupe (ALL:ALL)
    • Quoi : peut exécuter n’importe quelle commande (ALL).

  • La directive “NOPASSWD” (Le rêve de l’attaquant) : www-data ALL=(ALL) NOPASSWD: ALL

    • Cette règle permet au compte de service web www-data de devenir root sans jamais taper de mot de passe. Si des acteurs de la menace déploient un webshell sur un serveur avec cette configuration, ils obtiennent immédiatement la domination root sans avoir besoin d’un second exploit.

3. Le piège des GTFOBins (Élévation de privilèges subtile)

Section intitulée « 3. Le piège des GTFOBins (Élévation de privilèges subtile) »

Les administrateurs tentent souvent d’appliquer le principe du moindre privilège en restreignant un utilisateur à une seule commande administrative spécifique. Cependant, cela crée bien souvent une vulnérabilité sévère.

  • L’intention : backup ALL=(root) /usr/bin/find (l’utilisateur de sauvegarde n’est autorisé qu’à utiliser la commande find pour localiser des fichiers).
  • La faille : de nombreux binaires Unix natifs possèdent des fonctionnalités interactives ou la capacité de générer des sous-shells. La commande find, par exemple, dispose d’un indicateur -exec.
  • L’attaque : sudo find . -exec /bin/sh \;

En exécutant cette commande, l’attaquant contourne instantanément la restriction et génère un shell root interactif.

Ce concept est connu sous le nom de GTFOBins (Get The F*** Out Binaries). Des centaines de binaires légitimes (vim, less, awk, tar, python, nmap) peuvent être abusés de cette manière. Si vous observez un binaire très spécifique autorisé dans le fichier sudoers, croisez-le avec le référentiel GTFOBins pour déterminer s’il permet des échappées de shell.

4. Triage DFIR et intégrité des fichiers

Section intitulée « 4. Triage DFIR et intégrité des fichiers »

Lors de la réalisation d’une analyse hors ligne, vous devez examiner les métadonnées des fichiers avant d’analyser leur contenu.

  1. Analyse des MAC Times : vérifiez l’heure de modification (mtime) de /etc/sudoers et de tous les fichiers au sein de /etc/sudoers.d/. Un horodatage de modification récent qui s’aligne avec la fenêtre d’intrusion suspectée est la preuve définitive d’une tentative de LPE ou de persistance.
  2. Permissions des fichiers : par conception, les fichiers sudoers doivent être en lecture seule (0440 ou -r--r-----). Si un fichier dans /etc/sudoers.d/ possède des permissions d’écriture (0640 ou plus), c’est une anomalie grave indiquant une falsification ou une erreur de configuration majeure.

5. Requêtes de Threat Hunting automatisées

Section intitulée « 5. Requêtes de Threat Hunting automatisées »
audit_sudoers_offline.sh
#!/bin/bash
TARGET_DIR="/mnt/analyse"


echo "[+] Audit du fichier sudoers principal pour NOPASSWD..."
grep -E -i "nopasswd" $TARGET_DIR/etc/sudoers | grep -v "^#"


echo "[+] Audit du répertoire d'inclusion sudoers.d..."
grep -rE -i "nopasswd" $TARGET_DIR/etc/sudoers.d/ | grep -v "^#"


echo "[+] Vérification des permissions de fichiers dangereuses (Devrait être 440)..."
stat -c "%a %n" $TARGET_DIR/etc/sudoers $TARGET_DIR/etc/sudoers.d/* | grep -v "440"

Prochaines étapes de corrélation

Section intitulée « Prochaines étapes de corrélation »

Si vous identifiez une règle malveillante, pivotez immédiatement vers les Journaux d’authentification Linux (auth.log ou secure). Interrogez les journaux pour COMMAND= afin d’identifier exactement quand l’attaquant a utilisé ses privilèges sudo fraîchement créés et quelles commandes de post-exploitation il a exécutées. Par ailleurs, passez en revue l’Analyse des comptes pour vérifier si l’attaquant s’est ajouté directement aux groupes sudo ou wheel dans /etc/group.

Références et lectures complémentaires

Section intitulée « Références et lectures complémentaires »