1 पॉइंट द्वारा GN⁺ 2025-12-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कम कीमत वाले 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
  • 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/main server में XML elements की संख्या के लिए boundary check नहीं है
    • बहुत अधिक XML requests भेजने पर memory overflow और camera crash होता है
    • CVSS v4.0 score 7.1 (High)
  • CVE-2025-14299 (HTTPS Content-Length integer overflow)

    • port 443 का HTTPS server Content-Length header को validation के बिना atoi() से process करता है
    • 32-bit systems पर overflow के कारण crash होता है
    • CVSS v4.0 score 7.1 (High)
  • CVE-2025-14300 (WiFi hijacking)

    • connectAp API 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 टिप्पणियां

 
GN⁺ 2025-12-21
Hacker News राय
  • इस तरह के लेख वास्तविक विफलता के मामलों और उन समस्याओं को मिलाकर आलोचना करते हैं जिनसे FAANG भी जूझता है, और यही बात खटकती है
    खासकर “TP-Link का firmware repository बिना authentication वाले public S3 bucket में था” इस हिस्से को आलोचनात्मक रूप से लेना गलत तरीका है
    उलटे, इसे security through obscurity से बचने का अच्छा उदाहरण माना जा सकता है
    ऐसे लेख उलटा management को गलत तरह के ‘और ताले लगाओ’ निर्देश देने पर मजबूर कर सकते हैं

    • लेख पढ़ने में आसान था, लेकिन उसमें LLM ने लिखा हो ऐसा टोन महसूस हुआ
      AI से लिखे लेखों में अक्सर सूक्ष्म बारीकियाँ कम होती हैं और हर चीज़ को ज़रूरत से ज़्यादा नया, अच्छा या बुरा बताने की प्रवृत्ति होती है
      यह खराब लेख नहीं है, लेकिन पढ़ते समय सावधानी चाहिए। आजकल HN पर आने वाले ज़्यादातर लेख AI की मदद से लिखे हुए लगते हैं
    • “firmware repository public है” वाली बात पर किसी ने मज़ाक में कहा, “चलो Linux की बात न करें”
    • ऐसे reverse engineering ब्लॉग बस मज़ेदार और शिक्षाप्रद तरीके से कहानी कहने का माध्यम होते हैं
      मैंने भी ऐसे लेख कई बार लिखे हैं, और यह वाला सचमुच दिलचस्प था
      असल में “firmware कैसे मिला” इस कहानी का सबसे कम महत्वपूर्ण हिस्सा है
    • firmware public होने वाली बात में मुझे बिल्कुल भी नकारात्मक संकेत नहीं लगा। जानना चाहूँगा कि क्या किसी और को ऐसा लगा
    • मेरा मानना है कि firmware हमेशा public होना चाहिए। वही सही दिशा है
  • बहुत संभव है कि ज़्यादातर दूसरे camera models में भी इसी तरह की security vulnerabilities हों
    TP-Link community page के मुताबिक C200 का latest firmware 1.4.4 दिखाया गया है, लेकिन लेख में 1.4.2 का ज़िक्र है
    यानी कुछ updates हुए हैं, लेकिन लगता है security patches शामिल नहीं किए गए

    • पहले जब मैंने Zyxel products का analysis किया था, तब भी यही निष्कर्ष निकला था
      कई निर्माता common hardware को सिर्फ brand बदलकर बेचते हैं
      संबंधित विश्लेषण: Part 1, Part 2
    • ऐसे cameras local connection के लिए ठीक हैं, लेकिन आम users के लिए अब भी usability issues काफी हैं
  • इसी वजह से IoT network segmentation ज़रूरी है
    सभी smart cameras और IoT devices को अलग VLAN में रखना चाहिए, और internet access को firewall के ज़रिए सीमित करना चाहिए
    TP-Link camera users के लिए सुझाई गई settings:

    1. router में UPnP disable करें
    2. VLAN से IoT devices को अलग करें
    3. सिर्फ ज़रूरी endpoints के लिए outbound access allow करें
    4. संभव हो तो open firmware से बदलें
    5. नियमित रूप से updates चेक करें
      hardcoded key की समस्या खास तौर पर गंभीर है, और पूरी product line को प्रभावित करती है
    • मैंने एक बार दोस्त के home network की जाँच की थी, और PoE intercom system के ज़रिए पूरे internal network तक पहुँचा जा सकता था
      उसने IoT devices को VLAN से अलग नहीं किया था, और कोई alert system भी नहीं था
      उस दिन उसे VLAN isolation और access restriction की अहमियत सीधे समझ में आ गई
      लगता है बहुत से लोग इसी तरह अपना internal network उजागर कर रहे होंगे
    • कुछ लोगों ने पूछा कि क्या VLAN setup को step-by-step समझाने वाली कोई guide है। तकनीकी रूप से यह संभव है, लेकिन ठोस प्रक्रिया की ज़रूरत होती है
  • Thingino के बारे में कहा गया कि वह C200 को support करता है

    • लेकिन असल में वह C200 के 5 versions में से सिर्फ कुछ को ही support करता है
      सही chipset की जाँच के लिए OpenIPC देखना चाहिए
    • Thingino community का बनाया firmware वाकई प्रभावशाली है
      अगर compatible camera हो, तो इसे ज़रूर आज़माना चाहिए
  • मैं अपने सभी cameras को internet-blocked VLAN में रखकर इस्तेमाल करता हूँ
    HomeKit के ज़रिए local access मिल जाता है, इसलिए अलग app के बिना भी सब ठीक चलता है

  • इस स्तर की सुरक्षा लापरवाही लगभग जानबूझकर की गई लगती है
    लाखों units बेचकर भी बुनियादी vulnerability testing न करना समझना मुश्किल है
    मेरा मानना है कि $150 से कम के ज़्यादातर Wi-Fi cameras में इसी तरह की समस्याएँ होंगी
    सच में सुरक्षित इस्तेमाल करना हो तो non-proprietary Wi-Fi ↔ Ethernet adapter खुद बनाकर इस्तेमाल करना ही एक रास्ता बचता है

    • यह camera official site पर $17.99 में बिक रहा है
      hardware, packaging, logistics, testing, returns वगैरह निकाल दें तो बचता हुआ प्रति unit $5 से कम का मुनाफ़ा है
      अगर इसमें $100,000 अतिरिक्त development cost जोड़ दी जाए, तो वह 20,000 units जला देने जैसा है
      TP-Link जैसी कई product lines वाली कंपनी के लिए यही लागत सालाना कई करोड़ डॉलर तक पहुँच सकती है
      आखिरकार ढाँचा ऐसा बन जाता है कि न्यूनतम development के साथ shipping कर दी जाती है
    • कुछ USB-powered cameras USB network adapters को support करते हैं
      तकनीकी रूप से सक्षम लोग Thingino firmware के साथ local-only environment बना सकते हैं
    • ऐसे cameras को कभी भी untrusted network पर नहीं रखना चाहिए। यह बिल्कुल बुनियादी सिद्धांत है
    • “सभी Wi-Fi cameras में मिलती-जुलती समस्याएँ होती हैं” इस बात से मैं पूरी तरह सहमत हूँ
  • पता नहीं 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 इस्तेमाल किया होता, तो शायद काम कहीं तेज़ होता