Skip to main content

Chapitre 1.1 Quiz - Architecture reseau et surfaces d'attaque

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

Question 1​

Un attaquant sur le meme segment LAN envoie des reponses ARP non sollicitees affirmant que l'adresse IP de la passerelle (192.168.1.1) correspond a son adresse MAC. Les hotes du segment commencent a acheminer tout leur trafic via la machine de l'attaquant. Quelle couche du modele OSI est exploitee, et quelle est la raison principale pour laquelle cette attaque est efficace ?

Reveler la reponse et l'explication

Reponse : Couche 2 - Couche Liaison de donnees

Explication :

ARP opere a la Couche 2 (Liaison de donnees). L'attaque est efficace car :

  1. ARP est sans etat - les hotes acceptent et mettent en cache les reponses ARP meme s'ils n'ont jamais envoye de requete (ARP gratuit). Il n'existe pas de mecanisme de defi-reponse.
  2. Aucune authentification - il n'y a pas de liaison cryptographique entre une adresse IP et une adresse MAC a la Couche 2. N'importe quel hote peut revendiquer n'importe quelle IP.
  3. Confiance du domaine de diffusion - tous les hotes sur le meme VLAN recoivent et traitent les diffusions ARP.

Chaine d'impact : Compromission Couche 2 -> tout le chiffrement des couches superieures (TLS aux couches L4-L7) devient inefficace pour la confidentialite, car l'attaquant controle le routage avant meme que le canal chiffre ne commence.

Commandes de detection :

# Surveiller la table ARP pour les changements (Linux)
watch -n 1 arp -n

# Detecter l'empoisonnement ARP avec arpwatch
arpwatch -i eth0

# Verifier le cache ARP pour les MACs dupliques (plusieurs IPs partageant le meme MAC)
arp -n | awk '{print $3}' | sort | uniq -d

Attenuation : L'inspection ARP dynamique (DAI) sur les commutateurs Cisco valide les paquets ARP par rapport a la table de liaisons DHCP snooping :

Switch(config)# ip arp inspection vlan 10
Switch(config-if)# ip arp inspection trust   ! sur les liaisons montantes uniquement

Question 2​

Vous executez la commande Nmap suivante contre une cible : nmap -sS -sV -p 22,80,443,445 10.0.0.50 et obtenez la sortie suivante :

PORT    STATE    SERVICE       VERSION
22/tcp  open     ssh           OpenSSH 7.4 (protocol 2.0)
80/tcp  open     http          Apache httpd 2.4.6
443/tcp filtered https
445/tcp open     microsoft-ds  Windows Server 2008 R2 microsoft-ds

Que signifie filtered pour le port 443, et quelle preoccupation de securite souleve le resultat SMB que vous devez examiner immediatement ?

Reveler la reponse et l'explication

Reponse : Filtre = pare-feu supprimant les paquets ; SMB sur Server 2008 R2 = probablement vulnerable a EternalBlue (MS17-010).

Explication - etat filtered :

Dans un scan SYN Nmap :

  • open - SYN-ACK recu : le service est en ecoute
  • closed - RST recu : le port est accessible mais rien n'ecoute
  • filtered - aucune reponse ou ICMP inatteignable recu : un pare-feu, ACL ou filtre base sur l'hote supprime silencieusement les paquets

filtered ne signifie PAS que le service ne fonctionne pas - cela signifie que quelque chose dans le chemin bloque la sonde. C'est en fait le comportement correct d'un pare-feu.

SMB sur Windows Server 2008 R2 :

Windows Server 2008 R2 executant SMB (port 445) est un signal d'alarme critique :

  • Microsoft a mis fin au support standard en 2013, au support etendu en 2020
  • CVE-2017-0144 (EternalBlue / MS17-010) - execution de code a distance via SMBv1, sans authentification requise
  • Cette vulnerabilite a ete utilisee par les rancongiciels WannaCry et NotPetya pour se propager mondialement

Validation immediate :

# Verifier si la cible est vulnerable a EternalBlue
nmap --script smb-vuln-ms17-010 -p 445 10.0.0.50

# Verifier la prise en charge des versions SMB
nmap --script smb-protocols -p 445 10.0.0.50

# Utiliser Metasploit pour la validation (test autorise uniquement)
use auxiliary/scanner/smb/smb_ms17_010
set RHOSTS 10.0.0.50
run

Sortie vulnerabilite attendue :

Host is VULNERABLE to MS17-010! - Windows Server 2008 R2 SP1 x64

Priorite de remediation : CRITIQUE - patcher immediatement ou isoler l'hote.

Question 3​

Un developpeur vous dit : "Nous n'exposons pas SSH en externe, donc notre service SSH sur le port 22 n'a pas besoin d'une authentification par cle - l'authentification par mot de passe suffit." Expliquez pourquoi ce raisonnement est errone, en referant a au moins deux scenarios d'attaque distincts.

Reveler la reponse et l'explication

Reponse : La pensee perimetre-seulement ignore les menaces internes et les mouvements lateraux apres compromission.

Explication :

C'est le sophisme classique de la confiance implicite du reseau interne. Voici les scenarios d'attaque :

Scenario 1 - Menace interne / poste de travail compromis

Un attaquant qui a hameconnage un employe ou plante un malware sur un poste de travail est deja dans le reseau. Si SSH utilise l'authentification par mot de passe et que les employes utilisent des mots de passe faibles ou reutilises :

# L'attaquant execute un bruteforce SSH interne avec Hydra
hydra -L users.txt -P /usr/share/wordlists/rockyou.txt ssh://10.0.0.50

# Medusa pour le bruteforce SSH parallele
medusa -H hosts.txt -U users.txt -P passwords.txt -M ssh -t 4

Scenario 2 - Bourrage d'identifiants depuis des bases de donnees compromises

Les mots de passe de breches precedentes (LinkedIn, Adobe, RockYou2021 - 8,4 milliards d'entrees) sont utilises contre SSH interne. Les utilisateurs qui reutilisent des mots de passe sont compromis immediatement.

Scenario 3 - MITM sur le reseau interne

Si l'usurpation ARP est active (voir Q1), un attaquant peut intercepter la negociation SSH. Bien que SSH chiffre la session, l'authentification par mot de passe envoie le mot de passe sur le canal chiffre - si l'attaquant presente une cle d'hote falsifiee et que l'utilisateur l'accepte (modele de confiance TOFU), le mot de passe est capture.

Les cles SSH attenunent cela : la cle privee ne quitte jamais le client. L'authentification est une preuve cryptographique de possession, non un secret transmis sur le reseau.

Durcissement SSH correct :

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers deploy admin
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

# Restreindre les IPs sources dans le pare-feu (meme en interne)
ufw allow from 10.0.1.0/24 to any port 22  # Uniquement depuis le sous-reseau de gestion

# Recharger la configuration SSH sans perdre les sessions
systemctl reload sshd

Point cle : L'emplacement reseau (interne vs externe) n'est pas un controle de securite. La defense en profondeur necessite que chaque service soit durci independamment.

Question 4​

Etant donne la sortie suivante de dig axfr @dns1.target.com target.com, quelle mauvaise configuration de securite est presente, et quelles informations un attaquant peut-il en extraire ?

; <<>> DiG 9.16.1 <<>> axfr @dns1.target.com target.com
;; global options: +cmd
target.com.              3600 IN SOA   dns1.target.com. hostmaster.target.com. ...
target.com.              3600 IN NS    dns1.target.com.
target.com.              3600 IN NS    dns2.target.com.
target.com.              3600 IN MX    10 mail.target.com.
www.target.com.          3600 IN A     203.0.113.10
mail.target.com.         3600 IN A     203.0.113.11
vpn.target.com.          3600 IN A     203.0.113.15
dev-internal.target.com. 3600 IN A     10.0.0.50
db01.target.com.         3600 IN A     10.0.0.100
staging-api.target.com.  3600 IN A     10.0.0.75
Reveler la reponse et l'explication

Reponse : Transfert de zone DNS non restreint (AXFR) - le serveur de noms permet a n'importe quel hote de telecharger la zone entiere.

Explication :

Un transfert de zone (AXFR) est un mecanisme permettant aux serveurs DNS secondaires de repliquer les donnees de zone depuis le primaire. Il ne devrait etre autorise qu'aux serveurs de noms secondaires autorises. Lorsqu'il est non restreint, tout attaquant peut telecharger la zone DNS complete - une carte complete de votre infrastructure.

Ce que l'attaquant apprend de cette sortie :

EnregistrementInformation reveleeValeur pour l'attaque
vpn.target.com -> 203.0.113.15IP du point de terminaison VPNCible pour le bourrage d'identifiants, scan CVE
dev-internal.target.com -> 10.0.0.50Serveur dev interne, plage IP priveeConfirme le sous-reseau interne 10.0.0.0/24
db01.target.com -> 10.0.0.100Nom d'hote et IP interne du serveur de BDDCible de mouvement lateral haute valeur
staging-api.target.com -> 10.0.0.75Serveur API de stagingSouvent moins durci que la production
hostmaster.target.comAdresse email de l'administrateur (dans SOA)Cible de harponnage

Cette sortie dit a l'attaquant :

  • La plage IP interne : 10.0.0.0/24
  • Tous les services exposes sur Internet et leurs IPs
  • L'existence d'un point de terminaison VPN (cible privilegiee)
  • La convention de nommage et l'IP du serveur de BDD
  • Qu'il existe une API de staging (probablement avec des controles plus faibles)

Remediation :

# Bind9 : restreindre le transfert de zone aux serveurs de noms secondaires uniquement
# /etc/bind/named.conf.options
acl "secondaires-approuves" {
    203.0.113.20;   # IP du serveur de noms secondaire
    203.0.113.21;
};

zone "target.com" {
    type master;
    file "/etc/bind/db.target.com";
    allow-transfer { secondaires-approuves; };  # Restreindre AXFR
    allow-query { any; };                        # Les requetes normales fonctionnent toujours
};

# Verifier la correction : ceci devrait maintenant renvoyer "Transfer failed"
dig axfr @dns1.target.com target.com

# DNS Microsoft : restreindre les transferts de zone dans le gestionnaire DNS
# Proprietes -> Transferts de zone -> Autoriser uniquement vers des serveurs specifiques

DNSSEC ne previent PAS l'enumeration de zone - il garantit uniquement l'authenticite. Pour empecher l'enumeration, NSEC3 avec opt-out et les restrictions de transfert de zone sont tous deux necessaires.