मेरे सुरक्षा कैमरे की लॉगिन पेज में GitHub admin token शिप किया गया था
एक consumer “security” camera में उसकी login page के अंदर live GitHub admin token और firmware में U.S. Department of Defense IP space का संदर्भ मिला, जिससे पता चलता है कि कई IoT vendors credentials, networking और basic security hygiene को कितनी लापरवाही से संभालते हैं। Commenters hardcoded keys, reused MAC addresses और proprietary apps के ऐसे ही अनुभव बताते हैं जो API secrets उजागर करते हैं, और तर्क देते हैं कि इन products को अलग VLANs पर isolate किया जाना चाहिए या ऐसे devices से बदला जाना चाहिए जो open या third‑party firmware support करते हों। Thread आगे public IP ranges के व्यापक दुरुपयोग और धीमी, उलझनभरी IPv6 adoption पर भी जाती है, जो खराब ढंग से डिज़ाइन किए गए networked devices को बड़े पैमाने पर deploy करने पर risks को और बढ़ाते हैं.
कैमरा + GitHub token समस्या पर समग्र प्रतिक्रिया
- कई लोगों को यह देखकर कोई हैरानी नहीं हुई: hardcoded secrets, बेहद खराब defaults, और टूटी हुई security को IP cameras और IoT में सामान्य माना जाता है।
- कुछ लोग इस विडंबना पर ध्यान देते हैं कि “security” cameras की infosec अक्सर बहुत खराब होती है।
- एक सामान्य mitigation सुझाव: cameras को एक isolated VLAN पर रखें, internet access न दें, और केवल local NVR तक traffic allow करें।
Firmware में Department of Defense IP addresses
- कई commenters को firmware में DoD IPs अजीब लगते हैं, लेकिन जरूरी नहीं कि यह malicious हो।
- इसे एक common (हालाँकि खराब) practice बताया गया है: unused public IP ranges (DoD blocks सहित) को private internal space की तरह “borrow” करना, कभी-कभी ISPs और बड़े enterprises द्वारा भी।
- अन्य लोग तर्क देते हैं कि publicly assigned ranges को internal रूप से उपयोग करना स्पष्ट misconfiguration है, जो connectivity तोड़ सकता है, खासकर अगर असली owner कभी उस space का उपयोग करे।
- कुछ लोग corporate structures (defense affiliates) या supply-side attacks तक के बारे में अनुमान लगाते हैं, लेकिन इसे speculation माना गया है।
IoT security horror stories
- कथित तौर पर OBD-II dongles समान Bluetooth MAC addresses के साथ ship किए गए, जिन्हें कई apps में authentication keys के रूप में उपयोग किया गया, जिससे कई cars पर cross-device access मिल गया।
- Smart lighting के लिए APK reversals में embedded backend और commerce API keys दिखाई देती हैं; यह स्पष्ट नहीं है कि इससे वास्तव में कितना अतिरिक्त access मिलता है।
- सामान्य भावना: अधिकांश consumer IoT vendors security को प्राथमिकता नहीं देते, अक्सर software tasks hardware engineers को दे देते हैं, और apps/cloud backends समस्याओं से भरे होते हैं।
Networking, IPv4/IPv6, और address choices
- लोगों द्वारा public IPv4 ranges (1.1.1.0/24, 5.0.0.0/8, विभिन्न DoD /8s) को “private” space की तरह गलत तरीके से इस्तेमाल करने और इससे होने वाले routing chaos पर लंबी subthread चली।
- IPv6 पर बहस हुई: कुछ लोग globally unique addressing और बड़े space की प्रशंसा करते हैं; अन्य इसे ergonomically painful, home/small admins के लिए poorly understood, और अपनाने में कठिन मानते हैं।
- NAT बनाम firewall: कुछ लोग IPv4 NAT की “accidental security” को याद करते हैं; अन्य जोर देते हैं कि protection के लिए NAT नहीं, firewalls होने चाहिए।
Open / safer camera options
- कई projects का उल्लेख हुआ: OpenIPC, Thingino, ESP32-CAM, Pine64 Pinecube, Wyze reflashes, और ONVIF cameras को isolated networks पर उपयोग करने की सामान्य सलाह।
- Open firmware चाहने और turnkey, supportable systems चाहने के बीच tradeoff नोट किया गया (जैसे boilers/alarms के लिए)।
Meta: article style और content level
- ब्लॉग की terseness पर mixed views थे: कुछ लोग अधिक tool/method explanation चाहते हैं; अन्य padded “explainer” content की कमी को पसंद करते हैं।
- capitalisation style और external links के लिए CSS पर छोटे-मोटे nitpicks थे।