Flock Camera Hackeada: 1,6 Millones de Imágenes y la Lección de Seguridad de 2026
Hola HaWkers, una cámara de Flock Safety retirada de una vía pública reveló mucho más que matrículas. El 16 de septiembre de 2026, una investigación conjunta de WIRED y 404 Media informó que el colectivo stegan0gram copió casi todo el almacenamiento del equipo y recuperó vídeos, imágenes, aplicaciones y registros. En apenas 21 días, el dispositivo había producido 1,6 millones de imágenes de aproximadamente 50 mil vehículos.
Pero el caso no fue una intrusión remota en la nube: hubo acceso físico al hardware. Entonces, ¿qué demuestra realmente sobre cifrado, privacidad y seguridad de sistemas en el borde? En este artículo separaremos los hechos de las conclusiones precipitadas y convertiremos la investigación en una práctica útil para cualquier equipo que instale cámaras, sensores, tótems u otros dispositivos fuera de su propia oficina.
Qué Ocurrió con la Flock Camera
Según la investigación de WIRED, integrantes de stegan0gram retiraron una cámara automática de lectura de matrículas, desmontaron el conjunto e hicieron ingeniería inversa del almacenamiento y del software. El material fue compartido con 404 Media y con la organización de transparencia Distributed Denial of Secrets antes de que los periodistas lo analizaran.
Los investigadores encontraron un sistema Android dividido en particiones. Algunas áreas siguieron cifradas e inaccesibles, incluida parte del contenido más sensible. Sin embargo, una partición llamada media contenía una clave que permitió abrir otra área y visualizar miles de vídeos e imágenes. Este matiz es esencial: no hubo pruebas de que toda la plataforma de Flock quedara abierta, pero la promesa de que el acceso físico no permitiría acceder a las imágenes dejó de parecer suficiente.
La cámara ejecutaba cerca de 20 aplicaciones creadas por Flock. Se encargaban del movimiento, la captura, la clasificación de objetos, el envío de datos y las actualizaciones remotas. Los archivos también mostraron que el software detectaba personas, vehículos, matrículas y bicicletas. El análisis no encontró reconocimiento facial activo, y Flock sigue afirmando que su sistema de lectura de matrículas no utiliza esa tecnología.
El incidente exige otra precisión. Retirar o manipular equipos instalados en la vía pública puede ser un delito, y la empresa declaró que no recibió el material a través de su programa de divulgación de vulnerabilidades. Estudiar el resultado periodístico es legítimo; reproducir la retirada de una cámara no es una recomendación técnica ni ética.
Cómo una Cámara Produjo 1,6 Millones de Imágenes
Una Flock Camera no necesita transmitir vídeo continuo en alta resolución durante todo el día. Puede detectar movimiento localmente, grabar clips cortos, hacer ráfagas de fotos cuando pasa un vehículo, clasificar el contenido y enviar solo los eventos relevantes. Este diseño reduce el ancho de banda, pero concentra la responsabilidad en el equipo instalado en la calle.
En los 21 días recuperados, los registros indicaban cerca de 50.200 vehículos y 1,6 millones de imágenes. El promedio simple queda cerca de 32 imágenes por vehículo y 76 mil imágenes por día. Eso no significa que cada vehículo genere siempre exactamente 32 archivos: la posición, la velocidad, la iluminación, la repetición, los errores y las políticas de eliminación cambian el resultado. El cálculo sirve para revelar la escala.
const periodo = {
dias: 21,
veiculos: 50_200,
imagens: 1_600_000,
}
const imagensPorVeiculo = periodo.imagens / periodo.veiculos
const imagensPorDia = periodo.imagens / periodo.dias
// Los promedios describen el conjunto; no son una regla fija de la cámara.
console.log(`Imagens por veículo: ${imagensPorVeiculo.toFixed(1)}`)
console.log(`Imagens por dia: ${Math.round(imagensPorDia).toLocaleString('pt-BR')}`)Los periodistas también ejecutaron los modelos recuperados sobre 27.321 clips MP4, cada uno de uno a dos segundos y con una resolución de 1.024 por 768 píxeles. Aparecieron personas en 11 clips, todas en motocicletas. La posición de la cámara, apuntada hacia la calzada, ayuda a explicar la pequeña cifra. Aun así, el código tenía una clase explícita para personas y registraba la posición y la confianza de cada detección.
El detector de matrículas también produjo falsos positivos. En algunos casos, recortó pegatinas, marcos e incluso una bandera estadounidense en una bolsa de motocicleta como si fueran matrículas. Esto muestra por qué una salida probabilística debe tratarse como una pista, no como una verdad. La propia Flock dice que las alertas necesitan confirmación humana.
El Cifrado No Resuelve Nada Cuando la Clave Viaja Junto con los Datos
Cifrar el disco es indispensable, pero no basta con escribir «datos protegidos en reposo» en una presentación. Un dispositivo autónomo necesita iniciarse sin que un operador introduzca una contraseña. En algún momento, recibe o deriva una clave. Si el almacenamiento, la clave y el proceso de apertura están todos en el mismo equipo y pueden extraerse, el cifrado se convierte en una barrera que retrasa, no en una frontera absoluta.
El problema se parece a guardar la llave de la caja fuerte en un cajón pegado a ella. La cerradura sigue siendo real, pero el modelo de amenazas ignoró al atacante que se lleva el mueble entero. Para los dispositivos en el borde, el equipo debe suponer que alguien podrá tocar, abrir, apagar o transportar el hardware.
Una revisión sencilla puede convertir esa hipótesis en requisitos verificables:
const controles = [
{ nome: 'boot verificado', presente: true, peso: 3 },
{ nome: 'chave em secure element', presente: false, peso: 5 },
{ nome: 'apagamento após violação física', presente: false, peso: 4 },
{ nome: 'rotação remota de credenciais', presente: true, peso: 3 },
{ nome: 'dados locais com vida curta', presente: true, peso: 5 },
]
const riscoResidual = controles
.filter((controle) => !controle.presente)
.reduce((total, controle) => total + controle.peso, 0)
// Puntuación interna: úsala para priorizar el trabajo, no como certificación pública.
console.log({ riscoResidual, ausentes: controles.filter((c) => !c.presente) })En la práctica, un proyecto robusto combina un arranque verificado, una clave vinculada a un componente seguro, identidad única por dispositivo, rotación de credenciales, revocación rápida y retención local mínima. Los datos efímeros reducen el premio disponible para quien obtenga el hardware. Y ninguna clave del equipo debería abrir datos de otras unidades o de la nube.
Esta es una versión física del problema de la cadena de suministro discutido en el artículo sobre el zero-day de V8 en Chrome y Electron: la frontera de confianza debe incluir el runtime, las actualizaciones, las credenciales y el lugar donde el software se ejecuta realmente.
Los Registros Revelaron Fallos Operativos Además de Problemas de Privacidad
El almacenamiento no solo contenía datos; mostraba la salud del producto. La investigación encontró más de 27 mil mensajes «no space left on device» mientras la cámara intentaba guardar imágenes en resolución completa, además de decenas de miles de errores relacionados, bloqueos y reinicios. Un proceso comprobaba la actividad aproximadamente cada dos minutos y registró más de 12 mil mensajes de funcionamiento.
Registros así son útiles durante el desarrollo, pero ocupan espacio, generan ruido y pueden revelar detalles internos. En un equipo remoto, el sistema debe limitar archivos, exportar métricas agregadas y reaccionar antes de alcanzar una capacidad crítica. Reiniciar después de llenar el disco puede restablecer el servicio durante poco tiempo sin resolver la causa.
Este pequeño analizador ilustra cómo un equipo podría resumir eventos sin conservar indefinidamente todas las líneas en bruto:
function resumirEventos(linhas) {
const resumo = { discoCheio: 0, reinicios: 0, saudavel: 0 }
for (const linha of linhas) {
if (linha.includes('no space left on device')) resumo.discoCheio++
if (linha.includes('reboot was requested')) resumo.reinicios++
if (linha.includes("who's a good boy")) resumo.saudavel++
}
// En producción, envía contadores y conserva solo una muestra necesaria para el diagnóstico.
return resumo
}
console.log(resumirEventos([
'no space left on device',
"who's a good boy",
'a reboot was requested',
]))La alerta importante no es solo discoCheio > 0. Es la combinación del crecimiento de la cola, el espacio restante, la tasa de fallos y los reinicios. Una política puede reducir temporalmente la resolución, interrumpir nuevas capturas no esenciales, confirmar el envío antes de eliminar los datos y abrir un incidente. El comportamiento debe definirse antes de que la unidad se quede sin espacio sobre el terreno.
El Conflicto Entre el Discurso y lo Que Detecta el Software
En su Trust Center, Flock afirma que el producto de lectura de matrículas captura imágenes de matrículas, características del vehículo, hora y ubicación, y que no recopila información del conductor ni datos de reconocimiento facial. El análisis recuperado no mostró reconocimiento facial. Sin embargo, sí mostró una categoría computacional de persona y la capacidad de registrar dónde apareció una persona en la imagen.
Detectar a una persona no es lo mismo que identificarla. Esta diferencia técnica importa, pero no cierra el debate sobre la privacidad. Un sistema puede seguir ropa, trayectos, asociaciones entre vehículos y patrones de movimiento sin conocer el nombre de alguien. WIRED ya había reconstruido herramientas de búsqueda de Flock que permiten buscar personas por su descripción en algunos productos de vídeo, aunque la empresa afirma que esa búsqueda no funciona por atributos personales en las cámaras de matrículas.
Por eso, los documentos públicos deben describir capacidades, no solo finalidades. «No lo usamos para vigilar a personas» es una política; «el modelo posee una clase person» es una propiedad del software. Las buenas prácticas conectan ambas con controles: quién puede buscar, por qué motivo, en qué producto, durante cuánto tiempo y con qué auditoría.
En agosto de 2026, Flock anunció cambios: la recomendación y el valor predeterminado de retención se redujeron de 30 a 7 días para las nuevas configuraciones, además de códigos de caso, detección de uso indebido, autenticación multifactor y una revisión independiente de Bishop Fox. Los clientes existentes pueden mantener períodos definidos localmente. Associated Press informó que miles de organismos en 49 estados utilizan o comparten datos de la red, lo que hace que la configuración y la gobernanza sean tan importantes como el algoritmo.
Cómo Probar un Dispositivo en el Borde sin Tocar Hardware Ajeno
No necesitas desmontar equipos ajenos para aplicar la lección. Empieza en un laboratorio autorizado con una unidad de prueba, datos sintéticos y un guion de pérdida física. El objetivo es responder qué ocurre cuando el dispositivo desaparece, no demostrar habilidades de intrusión.
Una matriz mínima debe cubrir un apagado inesperado, la retirada del almacenamiento, una copia bit a bit, la restauración de firmware antiguo, la ausencia de red y una credencial revocada. Cada escenario debe tener un resultado esperado, pruebas y un responsable. «No conseguimos leer el volumen» es mejor que «usamos AES-256», porque pone a prueba el efecto, no la etiqueta.
const cenarios = [
{ evento: 'armazenamento removido', esperado: 'dados ilegíveis', passou: true },
{ evento: 'dispositivo roubado', esperado: 'credencial revogada em 15 min', passou: false },
{ evento: 'firmware antigo', esperado: 'boot bloqueado', passou: true },
{ evento: 'rede ausente', esperado: 'retenção local limitada a 24 h', passou: true },
]
const falhas = cenarios.filter((cenario) => !cenario.passou)
if (falhas.length) {
process.exitCode = 1
console.error('Gate de segurança reprovado:', falhas)
} else {
console.log('Todos os cenários físicos passaram')
}La prueba también debe confirmar que una unidad comprometida no permite suplantar a otra. Los certificados únicos, el alcance reducido y la revocación individual evitan que un incidente local se convierta en un acceso sistémico. Las actualizaciones necesitan firma, protección contra downgrades e inventario de versiones. La telemetría debe alertar de aperturas, cambios de orientación, reinicios inusuales y silencios prolongados.
Por último, simula el plazo de respuesta. ¿Quién recibe la alerta? ¿Quién puede revocar la identidad? ¿Cómo se conservan las pruebas sin guardar datos personales innecesarios? ¿Cuánto se tarda en informar al cliente? La seguridad operativa aparece en estas respuestas, no solo en una lista de algoritmos.
Checklist para Comprar Cámaras, Sensores y Tótems Conectados
Los equipos públicos y privados deberían exigir pruebas antes de instalar miles de unidades. Primero, ¿cuál es el modelo de amenaza física? La respuesta debe explicar la protección de claves, el arranque, la depuración, los puertos expuestos y el destino de los datos cuando se interrumpe la conectividad. «La carcasa está en alto» no es un control criptográfico.
Segundo, ¿cuál es la retención real en cada capa? La nube, la caché local, los registros, las copias de seguridad, las pruebas conservadas y los entornos de soporte pueden tener plazos diferentes. La política de 7 días anunciada por Flock es un paso medible, pero los clientes antiguos pueden mantener otra configuración y los casos activos pueden conservar registros. El contrato debe indicar quién autoriza excepciones y quién puede auditarlas.
Tercero, exige transparencia sobre los modelos de visión. ¿Qué clases se detectan? ¿Qué atributos pueden buscarse? ¿Qué falsos positivos se han medido? Un modelo entrenado para matrículas puede recortar pegatinas; un modelo que detecta personas puede tener usos futuros más allá del flujo actual. Las actualizaciones que amplíen las categorías deberían activar una nueva evaluación de privacidad.
Cuarto, verifica el proceso de vulnerabilidades: canal público, plazo de respuesta, protección para la investigación de buena fe, actualización firmada e historial de correcciones. La divulgación coordinada no elimina los conflictos, pero crea una alternativa responsable a la publicación por sorpresa.
Por último, trata el intercambio como un producto, no como una casilla marcada. El acceso entre miles de organismos aumenta el valor para las investigaciones y el impacto de un abuso. Los privilegios mínimos, MFA, el código de caso, la justificación, las alertas de comportamiento anómalo y la revisión humana deben estar activos de forma predeterminada.
Perspectivas: la Seguridad Comienza Cuando el Dispositivo Sale del Edificio
El caso de la Flock Camera no demuestra que cualquier persona en internet pueda ver todas las cámaras. Tampoco puede reducirse a «alguien robó el equipo, así que no cuenta». Los dispositivos instalados en postes y vías públicas viven en un entorno hostil por definición. El acceso físico forma parte del modelo de amenazas.
El hallazgo más útil es la distancia entre el cifrado declarado y la resistencia demostrada. Una parte sensible siguió siendo inaccesible, lo que demuestra que algunos controles funcionaron. Al mismo tiempo, una clave local abrió miles de registros, los logs revelaron fallos de almacenamiento y el software mostró capacidades más amplias que la imagen pública de un simple lector de matrículas.
Para los desarrolladores, la respuesta no es abandonar el procesamiento en el borde. Es diseñar como si la caja pudiera desaparecer mañana: reducir datos, separar claves, limitar credenciales, registrar lo necesario, probar la pérdida física y dar al operador medios rápidos de revocación. La privacidad no depende de un control heroico, sino de capas que siguen siendo útiles cuando una de ellas falla.
En 2026, la pregunta madura no es «¿el disco está cifrado?». Es: «¿qué datos siguen expuestos cuando el atacante posee el dispositivo, cuánto tiempo viven y hasta dónde puede llegar una identidad comprometida?». Si tu equipo puede responder con una prueba repetible, ya ha aprendido la principal lección de esta cámara.
¡Vamos con todo! 🦅
📚 ¿Quieres Seguir lo Que Viene Por Delante?
Este artículo cubrió la intrusión física en una Flock Camera y la seguridad de los dispositivos en el borde, pero el ecosistema cambia cada semana y no todo se convierte en un artículo aquí.
En X comparto lo que estoy probando, lo que ocurre entre bastidores en mis proyectos y las novedades que aparecen antes de convertirse en un post.
Sígueme Allí
💡 Contenido diario sobre desarrollo, carrera y las herramientas que realmente utilizo