En este artículo, vamos a tratar el proceso seguido por nuestro equipo de hackers éticos para saltarse las protecciones de unos dispositivos de control de acceso identificados durante una auditoría de seguridad realizada a la red interna de un cliente.
Hace unos días, nuestro equipo de hackers éticos estaba realizando una auditoría de seguridad en la red interna de un cliente y descubrió algunos dispositivos de ZKTeco que eran utilizados para el control de acceso de los empleados. Como es habitual, cuando nuestro equipo detecta un nuevo dispositivo, sigue su metodología de auditoría para tratar de identificar los servicios que el dispositivo proporciona y luego, tratan de explotar cada uno de ellos. El resultado es que estos dispositivos pueden suponer una grave amenaza para la seguridad debido a problemas de autenticación y podría ser posible hacerse con el control total de los dispositivos.
Los dispositivos fueron descubiertos después de un primer escaneo realizado con nmap. El escáner fue capaz de identificar dos servicios en los dispositivos: telnet (puerto 23) y un servidor web (puerto 80). Ambos servicios son considerados inseguros debido a la falta de encriptación en las comunicaciones, la falta de servicios encriptados como SSH o HTTPS nos dan una pista sobre las consideraciones de seguridad del fabricante, si no implementan protocolos seguros es muy probable que su código sea pobre en términos de seguridad.
Este primer escaneo también fue capaz de extraer alguna información útil de los dispositivos, por ejemplo, uno de ellos fue capaz de detectarlo como un lector de huellas dactilares de ZKSoftware modelo ZEM500 y está ejecutando un kernel de Linux versión 2.4.20.
Después de identificar que se trata de un dispositivo de control de acceso, se realizó un escaneo completo del dispositivo con el fin de detectar todos los puertos TCP y UDP en uso, esto llevó al descubrimiento de dos puertos UDP adicionales, los puertos UDP 4370 y 4371. Aparentemente, estos puertos se utilizan para la comunicación con el software de control.
El dispositivo utiliza un protocolo personalizado para la comunicación utilizando el puerto 4370, debido a esto, nuestro equipo tuvo que analizar el software de comunicación con el fin de identificar cómo se realizan las comunicaciones, el análisis demostró que la comunicación no requiere de autenticación y por lo tanto, fuimos capaces de crear algunos paquetes UDP personalizados utilizando Scapy.
Estos paquetes contienen mensajes detectados analizando el software y fuimos capaces de recibir respuestas de los dispositivos sin autenticarnos! Fue posible extraer información como, por ejemplo, los identificadores de los empleados. A pesar de poder obtener información, esta era difícil de leer debido a la necesidad de utilizar una herramienta como Wireshark para capturar las respuestas y al análisis manual de los datos.
Con toda esta información, nuestro equipo comenzó a buscar implementaciones del protocolo de comunicación utilizado por el dispositivo y descubrió una biblioteca no oficial para Python llamada pyzk. La biblioteca es muy completa y con sólo algunas modificaciones en el código, fuimos capaces de realizar cualquier acción en el dispositivo sin autenticarnos, por ejemplo, fue posible desactivar el dispositivo, añadir usuarios, borrar datos...
Un atacante con intenciones maliciosas podría, por ejemplo, crear un nuevo usuario, lo que le permitiría acceder al edificio como un empleado, o causar problemas con el dispositivo desactivándolo o eliminando los datos de los usuarios.
Después de descubrir este problema de seguridad nuestro equipo no se detuvo, el descubrimiento del protocolo inseguro nos motivó a encontrar algunas vulnerabilidades en el servidor web.
Cuando accedimos por primera vez acceder al servidor web, apareció una página de inicio de sesión, la primera impresión fue buena, al menos el servidor web implementaba un mecanismo de autenticación.
La página de login era https://
La idea inicial fue que el servidor web podría proporcionar esta información sin autenticación por tratarse de información no confidencial, sin embargo, se intentó solicitar algunos de los recursos que eran referenciados en el menú y como resultado se pudo obtener información privada del dispositivo sin ser autenticados, por ejemplo, los datos de los usuarios.
El siguiente paso consistió en tratar de realizar acciones no autenticadas, y el servidor web lo permitió. Durante el escaneo del sitio web, se descubrieron dos secciones interesantes, la sección backup y la sección restore. En la sección de backup, pudimos encontrar dos opciones que podrían ser llamadas mediante el envío de unas peticiones de tipo POST, se intentó realizar la copia de seguridad sin autenticar y como resultado, ¡se obtuvieron dos ficheros!
La sección de backup del servidor web no proporciona ninguna información del formato de estos respaldos, debido a eso, tuvimos que analizar los archivos descargados utilizando binwalk, este identificó ambos archivos como datos comprimidos en gzip, conociendo el mecanismo de compresión pudimos descomprimirlos utilizando tar. Los archivos extraídos eran registros y archivos de configuración con información sensible que no debería ser accesible sin autenticación.
La sección restore del servidor web proporciona una función para restaurar las copias de seguridad generadas en la sección de backup, sin embargo, los ficheros no tienen ningún control de integridad para verificar que las copias de seguridad no han sido modificadas, esto podría permitir la carga de copias de seguridad modificadas con archivos manipulados o archivos adicionales.
Un atacante podría explotar este hecho para extraer archivos en el sistema. Por ejemplo, podría ser usado para crear un archivo shadow personalizado con una contraseña conocida para el usuario root y comprimirlo junto con el resto de ficheros de las copias de seguridad de manera que cuando el servidor descomprima la copia de seguridad, el archivo shadow original sería reemplazado. Esto permitiría a un atacante usar el servicio telnet del dispositivo para iniciar sesión como root con la contraseña creada y ejecutar comandos de manera arbitraria.
Nuestro equipo determinó que al tratar de explotar esta vulnerabilidad se podría provocar una denegación de servicio en el dispositivo si hubiera algún problema analizando el nuevo fichero shadow y por lo tanto, no fue probado. A pesar de ello, después de todos los análisis realizados en estos dispositivos, la falta de seguridad en las otras funciones parece indicar que podría ser vulnerable.
Tras la auditoría de estos dispositivos, las conclusiones obtenidas fueron que estos dispositivos son muy inseguros y deben ser aislados para evitar acciones no autenticadas realizadas por un atacante.
