Carta o cara: diferencias fundamentales
El algoritmo de operación de un sistema de control de acceso clásico se ve así:
- la persona lleva la tarjeta al lector;
- el lector recibe el número de tarjeta y lo envía al servidor;
- el servidor comprueba los permisos de esta clave y, si se permite el acceso, devuelve el estado "OK";
- .
Si aplicamos este algoritmo, reemplazando el número de la tarjeta con una imagen de la cara, se producirá un apocalipsis local, porque la imagen es mucho más grande que el número de la tarjeta. Esto significa que su transferencia al servidor tomará más tiempo, y las imágenes coincidentes en la base de datos del servidor es mucho más que encontrar el número de clave. Si hay muchos empleados en la oficina que se mueven constantemente, existe una probabilidad distinta de cero de que tenga que sonreír a la cerradura mientras espera que la puerta se abra durante varios minutos.
Para evitar esto, en lugar de una simple cámara IP, utilizan un dispositivo inteligente que es lo suficientemente potente para el reconocimiento facial, y la base de datos de rostros se almacena en el dispositivo. Por lo general, dicho dispositivo es un potente dispositivo Android o una PC compacta con Windows o Linux.
En este caso, el servidor central se utiliza para sincronizar las bases de datos de visitantes, actualizar el software del lector y administrar todo el sistema.
Mover la carga de procesamiento del servidor al borde externo elimina la necesidad de enviar datos confidenciales como imágenes para su procesamiento. Los tiempos de respuesta son aceptables y los requisitos de ancho de banda se reducen.
Sin embargo, junto con la potencia de procesamiento, otras tareas se trasladan a los nodos de borde. Este cambio agrega dos problemas notables:
- en los nodos fronterizos, además de las operaciones primitivas de leer una tarjeta y abrir una puerta, se agrega una lógica comercial completa, que es una fuente de vulnerabilidad potencial;
- , .
También queremos estar en el futuro lo antes posible, donde sea suficiente sonreír al torniquete para comprar un boleto, pero consideramos necesario excluir la situación en que alguien más sonrió y se le debitó el dinero.
Como muestra nuestra investigación sobre Identified and Authorized: Sneaking Past Edge-Based Access Control Devices , los sistemas de control de acceso basados en la cara tienen muchas vulnerabilidades desagradables: se pueden piratear, engañar, presentar una foto de una persona en la pantalla del iPhone en lugar de la cara de una persona, e incluso convertirse en administrador y eliminarse. todos los jefes de la lista de admitidos al local.
Considere uno de los dispositivos más vulnerables de nuestro estudio: ZKTeco FaceDepot 7B
Sistema de control de acceso ZKTeco FaceDepot. Fuente: Trend Micro
El dispositivo viene en una robusta carcasa de metal con una pantalla y una cámara frontal dirigida al visitante. El reconocimiento facial se realiza dentro del dispositivo. Las fotos tomadas durante la autenticación no se envían al servidor central: la potencia del procesador de la tableta es suficiente para realizar el reconocimiento por sí sola.
Una implementación típica de ZKTeco FaceDepot ACS incluye varios de estos dispositivos y un servidor central a través del cual la base de usuarios se sincroniza entre dispositivos.
Puerto USB no seguro
La carcasa de metal protege el ACS de las interferencias físicas, pero el puerto USB abierto en la parte inferior del dispositivo lo estropea todo. Está diseñado para reparar el dispositivo.
Vulnerabilidad n. ° 1: puerto USB abierto. Fuente: Trend Micro
Versión de Android desactualizada
Otra vulnerabilidad global de ZKTeco es el firmware del dispositivo, que se basa en Android Lollipop 5.1.1, lanzado en abril de 2016. Hoy, la versión actual de Android es la décima. A lo largo de los años, el sistema operativo ha recibido muchas mejoras relacionadas con la seguridad. Evidentemente, en la quinta versión no se proporciona nada por el estilo.
Pantalla con versión de Android en ZKTeco FaceDepot SKD. Fuente: Trend Micro
La capacidad de instalar paquetes APK
Dado que se trata de Android, el usuario puede ir a la pantalla de inicio e iniciar la aplicación. Por ejemplo, puede iniciar ApkInstaller e instalar cualquier paquete APK de Android desde un medio conectado a un puerto USB.
Instalador de APK que se ejecuta en ACS. Fuente: Trend Micro
El fabricante del dispositivo limitó la capacidad de acceder a menús y aplicaciones solo para usuarios con derechos de administrador, pero una investigación más profunda del dispositivo mostró que esto no es un problema, porque el dispositivo aún se comunica con el servidor y lo hace a través de HTTP.
Intercambio no cifrado con el servidor
El dispositivo se comunica con el servidor a través de HTTP. Toda la información se transmite en texto claro y se puede interceptar fácilmente. Lo peor de todo es que los comandos administrativos se transmiten en texto sin cifrar: registro de usuario, asignación de un rol de administrador a un usuario, eliminación de un usuario y sincronización.
Un atacante que acceda a la red a la que está conectada la tableta podrá escuchar el tráfico de red entre el ACS y el servidor y obtener la información necesaria para llevar a cabo los ataques.
Lamentablemente, los desarrolladores del dispositivo lograron fortalecer aún más la vulnerabilidad asociada con la falta de cifrado de datos: hicieron un procedimiento de autenticación del dispositivo completamente con fugas.
Autenticación de dispositivos vulnerables
El único signo de la legitimidad de un dispositivo en el servidor es el token que se pasa en la cookie. El token se establece cuando el dispositivo se registra por primera vez en el servidor y, según nuestros datos, nunca cambia.
El valor del token se almacena como una cookie. Fuente: Trend Micro
Dado que el token "secreto" se transmite en texto sin cifrar, cualquier cliente HTTP puede hacerse pasar por un ACS legítimo. En nuestros experimentos, usamos curl, una sencilla utilidad de línea de comandos.
Por ejemplo, así es como registramos un nuevo usuario en el sistema y configuramos una imagen para él:
el primer comando registra un usuario con el nombre Bogus en el servidor, el segundo configura una foto para él. Fuente: Trend Micro
El archivo userdata.post contiene los datos que hemos enviado al servidor a través de POST. En nuestro caso, el archivo contiene los siguientes datos: Contenido del archivo de imagen
a enviar al servidor. Fuente: Trend Micro
Registrar un administrador con curl
Un administrador existente puede promover un nuevo usuario a administrador usando la consola en el dispositivo. El administrador actual primero debe iniciar sesión en el dispositivo a través del reconocimiento facial y luego acceder a la consola del sistema para iniciar el proceso de promoción. Tan pronto como el usuario asciende al nivel de administrador, el dispositivo envía un informe al servidor, notificándole el cambio de estado.
Pero dado que cualquier usuario que posea el token puede simular el tráfico de red legítimo entre el dispositivo y el servidor, nada le impide ejecutar el siguiente comando y convertir a cualquier usuario en administrador:
Establecer privilegio = 14 convierte al usuario en administrador. Fuente: Trend Micro
Después de la próxima sincronización del servidor y todos los dispositivos ACS registrados en él, el nuevo administrador será reconocido en toda la red de la oficina.
Cargar todas las fotos de usuario
Las URL de las fotos almacenadas en el servidor son predecibles, por lo que enumerar todas las URL y cargar las fotos es muy sencillo. No se requiere autenticación para acceder a estas URL.
Por ejemplo, en la siguiente URL, el servidor enviará una foto de un usuario con el ID "11111":
Para recopilar imágenes, puede hacer un script simple que iterará a través de los ID de usuario desde "00000" a cualquier número y descargará todas las fotos disponibles en el sistema.
Inyección de servidor falso
Dado que toda la comunicación entre el dispositivo y el servidor se realiza a través de HTTP, es relativamente fácil redirigir todos los dispositivos de CA a un servidor falso mediante el envenenamiento por ARP (Protocolo de resolución de direcciones).
Después de que conseguimos que el dispositivo de destino se comunicara con nuestro servidor falso, pudimos enviarle al dispositivo las actualizaciones que necesitábamos durante una de sus sesiones de sincronización regulares. Esta técnica se puede utilizar para una variedad de ataques. Por ejemplo, puede deslizar dispositivos finales con una foto de un usuario para el que desea organizar el acceso ilegal a las instalaciones de una empresa.
Acceso mediante foto de visitante legal
Dada la cantidad de posibles opciones de ataque, probar este método ya era algo exagerado. Pero dada la simplicidad y disponibilidad de un ataque de este tipo incluso para una persona que está lejos de la tecnología, verificamos sin embargo si sería posible engañar al ACS utilizando una fotografía de una persona registrada en el sistema con acceso a la oficina. Y se sorprendieron mucho cuando, después de pasar por varias opciones, el ataque funcionó: la cámara ZKTeco FaceDepot resultó ser compatible con las fotos mostradas en el iPhone X y iPhone XS, pero se negó a omitir la misma foto en la pantalla de los teléfonos inteligentes iPhone 6, Samsung A10, Samsung S8, Samsung S9. , Samsung S10, Samsung S10 + y Samsung Note 10.
Recomendaciones a los fabricantes
El dispositivo de control de acceso ZKTeco FaceDepot no es el único probado en nuestro estudio. Desafortunadamente, otros dispositivos también contenían serias vulnerabilidades que arrojan serias dudas sobre si podrían usarse para crear un perímetro verdaderamente seguro de acceso físico a las instalaciones de la empresa.
Todas las vulnerabilidades encontradas en los dispositivos se incluyen en los 10 principales riesgos de seguridad de aplicaciones web , compilados por el proyecto OWASP:
- sin cifrado predeterminado y desactivación del cifrado del lado del servidor;
- sistema de gestión de sesiones y autenticación vulnerable;
- versiones obsoletas del sistema operativo.
Para que los dispositivos de control de acceso sean más seguros, los fabricantes deben seguir estas pautas:
- — , ;
- ;
- — USB- ;
- , .