My security camera shipped a GitHub admin token in its login page
A consumer “security” camera was found to embed a live GitHub admin token in its login page and reference U.S. Department of Defense IP space in its firmware, highlighting how carelessly many IoT vendors handle credentials, networking and basic security hygiene. Commenters recount similar experiences with hardcoded keys, reused MAC addresses and proprietary apps that expose API secrets, and argue that these products should be isolated on separate VLANs or replaced with devices that support open or third‑party firmware. The thread also branches into how widespread misuse of public IP ranges and slow, confusing IPv6 adoption compound the risks when poorly designed networked devices are deployed at scale.
Overall reaction to the camera + GitHub token issue
- Many are unsurprised: hardcoded secrets, insane defaults, and broken security are seen as normal in IP cameras and IoT.
- Some note the irony that “security” cameras often have very poor infosec.
- A common mitigation suggestion: put cameras on an isolated VLAN with no internet access and only allow traffic to a local NVR.
Department of Defense IP addresses in firmware
- Several commenters think the DoD IPs in firmware are odd but not necessarily malicious.
- It’s described as common (though bad) practice to “borrow” unused public IP ranges (including DoD blocks) as private internal space, sometimes even by ISPs and large enterprises.
- Others argue that using publicly assigned ranges internally is clearly a misconfiguration that can break connectivity, especially if the real owner ever uses that space.
- Some speculate about corporate structures (defense affiliates) or even supply-side attacks, but this is acknowledged as speculation.
IoT security horror stories
- OBD-II dongles allegedly shipped with identical Bluetooth MAC addresses used as authentication keys in multiple apps, giving cross-device access to many cars.
- APK reversals for smart lighting show embedded backend and commerce API keys; unclear how much extra access these actually grant.
- General sentiment: most consumer IoT vendors do not prioritize security, often hand software tasks to hardware engineers, and apps/cloud backends are riddled with issues.
Networking, IPv4/IPv6, and address choices
- Long subthread on people misusing public IPv4 ranges (1.1.1.0/24, 5.0.0.0/8, various DoD /8s) as “private” space and the routing chaos this causes.
- IPv6 is debated: some praise globally unique addressing and large space; others call it ergonomically painful, poorly understood by home/small admins, and hard to adopt.
- NAT vs firewall: some miss the “accidental security” of IPv4 NAT; others emphasize that firewalls, not NAT, should provide protection.
Open / safer camera options
- Multiple projects mentioned: OpenIPC, Thingino, ESP32-CAM, Pine64 Pinecube, Wyze reflashes, and general advice to use ONVIF cameras on isolated networks.
- Tradeoff noted between wanting open firmware and wanting turnkey, supportable systems (e.g., for boilers/alarms).
Meta: article style and content level
- Mixed views on the blog’s terseness: some want more tool/method explanation; others appreciate the lack of padded “explainer” content.
- Minor nitpicks about capitalization style and CSS for external links.