Cámaras Flock: Android sin parches desde 2018 y credenciales hard-coded
DDoSecrets publica imágenes de particiones de una cámara ALPR en uso: Android 8.1 con parches de 2018, un kernel de 2017 y una clave API incrustada en el firmware.
DDoSecrets ha publicado las imágenes de las particiones extraídas de una cámara Flock ALPR en uso, y el análisis de esos datos deja a la vista dos cosas difíciles de defender: un sistema operativo caducado hace años y credenciales incrustadas en el propio firmware. La filtración la recogieron 404 Media y Wired en una investigación conjunta, y los datos los recopiló un colectivo que se hace llamar stegan0gram, que según contó a ambos medios se dedicó a desarmar el hardware en campo y hacer ingeniería inversa.
Android de 2017 sobre un kernel de 2017
La cámara corre una versión modificada de Android. El build concreto es de junio de 2025, pero por debajo hay Android 8.1, publicado en 2017 y sin soporte de Google desde 2021. El parche de seguridad declarado en build.prop es del 5 de junio de 2018, así que la imagen arrastra ocho años sin actualizaciones. Debajo, Linux 3.18.71, de 2017. La serie 3.18 se mantuvo hasta mayo de 2019 y terminó en la 3.18.140, de modo que esta imagen se queda 69 versiones por detrás del final de su propia rama.
El autor de la nota, que ha revisado las imágenes por su cuenta y avisa de que no tiene la cámara delante para confirmar los ataques, enumera dos vulnerabilidades conocidas a las que el nivel de parcheo antecede: CVE-2021-1905, un use-after-free en el driver de la GPU Adreno de Qualcomm que permite a cualquier app sin privilegios corromper memoria del kernel y tomar el control del dispositivo, y CVE-2018-9568, también llamada WrongZone, una confusión de tipos en el manejo de sockets IPv6 que permite escalar a root. De esta última hay exploit público.
Una clave API para pedir credenciales
El firmware incluye 20 apps de Flock, de las que 19 comparten una librería, com.flocksafety.android.common.lib. Al descompilarla aparece un método CameraSettings.getHpnotiqApiKey() que devuelve una clave API escrita a mano en el código. Esa clave sirve para llamar a hpnotiq.flocksafety.com y pedir credenciales de dispositivo indicando solo una dirección MAC. La cámara analizada usa la suya, F4:6A:DD:57:46:FB, y la hipótesis del autor es que la misma clave vale para cualquier otra con solo cambiar ese dato.
La respuesta trae un clientId y un clientSecret de Auth0 que el dispositivo guarda en texto plano. Enviados a device-login.flocksafety.com permiten acuñar tokens para hablar con el backend haciéndose pasar por esa cámara. El autor aclara que no ha probado esas credenciales y no puede confirmar si siguen activas, y recuerda que usarlas sin permiso es delito. Flock respondió a los dos medios que mantiene una política pública de divulgación de vulnerabilidades, que no ha recibido ningún informe por ese cauce y que con la información limitada disponible no tiene detalle suficiente para evaluar las afirmaciones.
Lo interesante no es la cámara concreta, sino el patrón: hardware de reconocimiento de matrículas desplegado en la vía pública con una pila de software de hace casi una década y secretos que salen de una imagen de particiones. Quien opere o compre este tipo de sistemas tiene ya una pregunta que hacer: cómo se actualiza ese parque, si existe un plan y quién responde cuando algo falla.
