Mi cámara de seguridad envió un token de administrador de GitHub en su página de inicio de sesión
Se descubrió que una cámara de “seguridad” de consumo incrustaba un token activo de administrador de GitHub en su página de inicio de sesión y hacía referencia al espacio IP del Departamento de Defensa de EE. UU. en su firmware, lo que pone de relieve lo descuidadamente que muchos proveedores de IoT manejan credenciales, redes e higiene básica de seguridad. Los comentaristas cuentan experiencias similares con claves codificadas, MAC reutilizadas y apps propietarias que exponen secretos de API, y sostienen que estos productos deberían aislarse en VLAN separadas o reemplazarse por dispositivos que admitan firmware abierto o de terceros. El hilo también deriva hacia cómo el uso indebido generalizado de rangos IP públicos y la adopción lenta y confusa de IPv6 agravan los riesgos cuando se despliegan a gran escala dispositivos de red mal diseñados.
Reacción general al problema de la cámara y el token de GitHub
- Muchos no se sorprenden: secretos codificados, valores predeterminados disparatados y seguridad rota se consideran normales en las cámaras IP y en IoT.
- Algunos señalan la ironía de que las cámaras “de seguridad” a menudo tengan una infoseg muy pobre.
- Una sugerencia común de mitigación: poner las cámaras en una VLAN aislada, sin acceso a internet y permitiendo tráfico solo hacia un NVR local.
Direcciones IP del Departamento de Defensa en el firmware
- Varios comentaristas creen que las IP del DoD en el firmware son extrañas, pero no necesariamente maliciosas.
- Se describe como una práctica común, aunque mala, “tomar prestados” rangos públicos de IP no usados (incluidos bloques del DoD) como espacio interno privado, a veces incluso por parte de ISP y grandes empresas.
- Otros sostienen que usar rangos asignados públicamente de forma interna es claramente una mala configuración que puede romper la conectividad, especialmente si el propietario real llega a usar ese espacio.
- Algunos especulan sobre estructuras corporativas (afiliadas de defensa) o incluso ataques en la cadena de suministro, pero se reconoce que esto es especulación.
Historias de terror sobre seguridad en IoT
- Supuestamente, dongles OBD-II enviados con direcciones MAC Bluetooth idénticas se usaban como claves de autenticación en varias apps, lo que daba acceso cruzado a muchos coches.
- Las reversas de APK para iluminación inteligente muestran claves incrustadas de backend y de API comercial; no está claro cuánto acceso adicional conceden realmente.
- Sentimiento general: la mayoría de los proveedores de IoT de consumo no priorizan la seguridad, a menudo dejan las tareas de software en manos de ingenieros de hardware, y las apps y los backends en la nube están llenos de problemas.
Redes, IPv4/IPv6 y elección de direcciones
- Largo subhilo sobre gente que usa indebidamente rangos públicos de IPv4 (1.1.1.0/24, 5.0.0.0/8, varios /8 del DoD) como espacio “privado”, y el caos de enrutamiento que esto provoca.
- Se debate IPv6: algunos elogian las direcciones globalmente únicas y el enorme espacio; otros lo consideran ergonómicamente doloroso, poco entendido por administradores domésticos o pequeños, y difícil de adoptar.
- NAT frente a firewall: algunos echan de menos la “seguridad accidental” del NAT de IPv4; otros enfatizan que son los firewalls, no NAT, los que deben proporcionar protección.
Opciones abiertas / más seguras para cámaras
- Se mencionan varios proyectos: OpenIPC, Thingino, ESP32-CAM, Pine64 Pinecube, reflasheos de Wyze y el consejo general de usar cámaras ONVIF en redes aisladas.
- Se señala el compromiso entre querer firmware abierto y querer sistemas listos para usar y con soporte (por ejemplo, para calderas/alarma).
Meta: estilo y nivel de contenido del artículo
- Opiniones divididas sobre la concisión del blog: algunos quieren más explicación de herramientas y métodos; otros aprecian la ausencia de contenido “explicativo” relleno.
- Pequeñas críticas sobre el estilo de capitalización y el CSS para enlaces externos.