TP-Link Tapo C200: हार्डकोडेड keys, buffer overflow, और AI-आधारित reverse engineering के दौर में privacy
(evilsocket.net)- कम कीमत वाले TP-Link Tapo C200 IP कैमरा के firmware का AI-आधारित reverse engineering से विश्लेषण करने पर कई security vulnerabilities मिलीं
- firmware में hardcoded SSL private key शामिल है, जिससे उसी network के भीतर HTTPS traffic decrypt किया जा सकता है
- विश्लेषण प्रक्रिया में AI tools (Grok, GhidraMCP, Cline आदि) का उपयोग करके firmware structure की समझ और function के अर्थ के विश्लेषण को automate किया गया
- पाई गई प्रमुख vulnerabilities में buffer overflow (CVE-2025-8065), integer overflow (CVE-2025-14299), WiFi hijacking (CVE-2025-14300) आदि शामिल हैं, जिनमें से कुछ पर authentication के बिना remote attack संभव है
- इस मामले को ऐसे उदाहरण के रूप में देखा जा रहा है, जहाँ AI security research की efficiency बढ़ाता है और साथ ही IoT devices की structural weaknesses को उजागर करता है
Firmware प्राप्ति और decryption
- Tapo Android app का reverse engineering करके TP-Link का public S3 bucket मिला, जहाँ से सभी devices का firmware बिना authentication के download किया जा सकता है
- उदाहरण command:
aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request --recursive
- उदाहरण command:
- tp-link-decrypt tool का उपयोग करके firmware decrypt किया गया
- RSA key को TP-Link के GPL code release materials से निकाला जा सकता है
- decrypt किया गया firmware bootloader, kernel, SquashFS root filesystem संरचना से बना है
AI-आधारित reverse engineering
- Ghidra, GhidraMCP, Cline, Anthropic Opus/Sonnet 4 आदि का उपयोग करके firmware analysis automate किया गया
- AI ने functions की भूमिका समझाई और variable names को अर्थपूर्ण तरीके से rename किया, जिससे code readability बेहतर हुई
- इस प्रक्रिया से HTTP handlers, discovery protocol, encryption routines आदि को map किया गया
- यह पुष्टि हुई कि firmware के भीतर SSL private key boot के समय generate नहीं होती, बल्कि embedded है
- उसी network के भीतर मौजूद attacker HTTPS traffic decrypt कर सकता है
प्रमुख vulnerabilities
-
CVE-2025-8065 (ONVIF SOAP XML parser memory overflow)
- port 2020 पर
/bin/mainserver में XML elements की संख्या के लिए boundary check नहीं है - बहुत अधिक XML requests भेजने पर memory overflow और camera crash होता है
- CVSS v4.0 score 7.1 (High)
- port 2020 पर
-
CVE-2025-14299 (HTTPS Content-Length integer overflow)
- port 443 का HTTPS server
Content-Lengthheader को validation के बिना atoi() से process करता है - 32-bit systems पर overflow के कारण crash होता है
- CVSS v4.0 score 7.1 (High)
- port 443 का HTTPS server
-
CVE-2025-14300 (WiFi hijacking)
connectApAPI authentication के बिना accessible है और setup पूरा होने के बाद भी active रहती है- attacker कैमरे को attacker network से connect कराकर video traffic intercept कर सकता है
- CVSS v4.0 score 8.7 (High)
-
authentication के बिना WiFi scan API (
scanApList)- आसपास के WiFi का SSID, BSSID, signal strength, security settings लौटाता है
- Apple BSSID Locator आदि के जरिए सटीक GPS location tracking संभव है
- remote attacker camera की वास्तविक location पहचान सकता है
Disclosure और response process
- 22 जुलाई 2025 को TP-Link security team को पहली रिपोर्ट भेजी गई, जिसमें PoC और वीडियो शामिल थे
- 150 दिन बाद (19 दिसंबर) इसे public किया गया, जिसके बाद TP-Link ने security advisory जारी की
- TP-Link के पास अपना CVE issuing authority (CNA) है, जिससे वह अपने products की vulnerabilities के reporting और disclosure process को सीधे control करता है
- अपनी website पर कंपनी प्रतिस्पर्धियों की तुलना में कम CVE संख्या को marketing metric की तरह इस्तेमाल करती है, जिससे conflict of interest की ओर इशारा होता है
निष्कर्ष
- AI tools reverse engineering की efficiency को अधिकतम करते हैं और security research की accessibility बढ़ाते हैं
- लेकिन hardcoded keys, authentication के बिना APIs, और कमजोर parser structure जैसे मुद्दे IoT devices में मौलिक security की कमी को उजागर करते हैं
- TP-Link का यह मामला AI युग में security research और manufacturer responsibility के बीच संतुलन के सवाल को प्रतीकात्मक रूप से दिखाता है
1 टिप्पणियां
Hacker News राय
इस तरह के लेख वास्तविक विफलता के मामलों और उन समस्याओं को मिलाकर आलोचना करते हैं जिनसे FAANG भी जूझता है, और यही बात खटकती है
खासकर “TP-Link का firmware repository बिना authentication वाले public S3 bucket में था” इस हिस्से को आलोचनात्मक रूप से लेना गलत तरीका है
उलटे, इसे security through obscurity से बचने का अच्छा उदाहरण माना जा सकता है
ऐसे लेख उलटा management को गलत तरह के ‘और ताले लगाओ’ निर्देश देने पर मजबूर कर सकते हैं
AI से लिखे लेखों में अक्सर सूक्ष्म बारीकियाँ कम होती हैं और हर चीज़ को ज़रूरत से ज़्यादा नया, अच्छा या बुरा बताने की प्रवृत्ति होती है
यह खराब लेख नहीं है, लेकिन पढ़ते समय सावधानी चाहिए। आजकल HN पर आने वाले ज़्यादातर लेख AI की मदद से लिखे हुए लगते हैं
मैंने भी ऐसे लेख कई बार लिखे हैं, और यह वाला सचमुच दिलचस्प था
असल में “firmware कैसे मिला” इस कहानी का सबसे कम महत्वपूर्ण हिस्सा है
बहुत संभव है कि ज़्यादातर दूसरे camera models में भी इसी तरह की security vulnerabilities हों
TP-Link community page के मुताबिक C200 का latest firmware 1.4.4 दिखाया गया है, लेकिन लेख में 1.4.2 का ज़िक्र है
यानी कुछ updates हुए हैं, लेकिन लगता है security patches शामिल नहीं किए गए
कई निर्माता common hardware को सिर्फ brand बदलकर बेचते हैं
संबंधित विश्लेषण: Part 1, Part 2
इसी वजह से IoT network segmentation ज़रूरी है
सभी smart cameras और IoT devices को अलग VLAN में रखना चाहिए, और internet access को firewall के ज़रिए सीमित करना चाहिए
TP-Link camera users के लिए सुझाई गई settings:
hardcoded key की समस्या खास तौर पर गंभीर है, और पूरी product line को प्रभावित करती है
उसने IoT devices को VLAN से अलग नहीं किया था, और कोई alert system भी नहीं था
उस दिन उसे VLAN isolation और access restriction की अहमियत सीधे समझ में आ गई
लगता है बहुत से लोग इसी तरह अपना internal network उजागर कर रहे होंगे
Thingino के बारे में कहा गया कि वह C200 को support करता है
सही chipset की जाँच के लिए OpenIPC देखना चाहिए
अगर compatible camera हो, तो इसे ज़रूर आज़माना चाहिए
मैं अपने सभी cameras को internet-blocked VLAN में रखकर इस्तेमाल करता हूँ
HomeKit के ज़रिए local access मिल जाता है, इसलिए अलग app के बिना भी सब ठीक चलता है
इस स्तर की सुरक्षा लापरवाही लगभग जानबूझकर की गई लगती है
लाखों units बेचकर भी बुनियादी vulnerability testing न करना समझना मुश्किल है
मेरा मानना है कि $150 से कम के ज़्यादातर Wi-Fi cameras में इसी तरह की समस्याएँ होंगी
सच में सुरक्षित इस्तेमाल करना हो तो non-proprietary Wi-Fi ↔ Ethernet adapter खुद बनाकर इस्तेमाल करना ही एक रास्ता बचता है
hardware, packaging, logistics, testing, returns वगैरह निकाल दें तो बचता हुआ प्रति unit $5 से कम का मुनाफ़ा है
अगर इसमें $100,000 अतिरिक्त development cost जोड़ दी जाए, तो वह 20,000 units जला देने जैसा है
TP-Link जैसी कई product lines वाली कंपनी के लिए यही लागत सालाना कई करोड़ डॉलर तक पहुँच सकती है
आखिरकार ढाँचा ऐसा बन जाता है कि न्यूनतम development के साथ shipping कर दी जाती है
तकनीकी रूप से सक्षम लोग Thingino firmware के साथ local-only environment बना सकते हैं
पता नहीं TP-Link का S3 firmware repository कब तक खुला रहेगा
इसमें लगभग 990GiB data है, इसलिए अच्छा होगा अगर कोई इसे archive या torrent के रूप में backup कर ले
मैं इस camera को Unifi + ONVIF के साथ सिर्फ non-critical उपयोग के लिए इस्तेमाल करता हूँ
इसे अलग VLAN में रखकर internet block किया हुआ है, और खुशी की बात है कि यह फिर भी ठीक से काम करता है
cameras की जाँच करते समय मैंने drmnsamoliu.github.io साइट का सहारा लिया था
मैंने Ghidra और AWS Amazon Q का इस्तेमाल करके एक toy drone की video feed को reverse engineer किया था
अगर GhidraMCP इस्तेमाल किया होता, तो शायद काम कहीं तेज़ होता