Herramienta de Recuperación de Contraseñas ETS5

Tabla de Contenidos

• Introducción
• Instalación
• Requisitos
• ¿Cómo funciona la recuperación de contraseñas?
• ¿Cómo se descubrió el fallo de diseño?
• ¿Cómo se puede mitigar el riesgo?
• Divulgación Coordinada de Vulnerabilidades
• Licencia
• Registro de cambios

Introducción

¿Has olvidado la contraseña de uno de tus proyectos de ETS5 y ya no puedes acceder a la configuración de la instalación KNX? La Herramienta de Recuperación de Contraseñas ETS5 te permite recuperar la contraseña del proyecto y otros secretos guardados en el almacén de proyectos del ETS5. Esto es posible porque el ETS5 tiene un fallo de diseño significativo: utiliza una contraseña y una sal fijas en el código para cifrar la información del proyecto (CVE-2021-36799).

Almacenar secretos criptográficos en el código fuente es desaconsejable porque pueden recuperarse mediante ingeniería inversa del software, ofreciendo así poca más protección que almacenar la información en texto claro. Esto puede suponer una amenaza para la seguridad de las instalaciones KNX. Si un atacante logra acceder a los archivos del almacén de proyectos, puede descifrarlos a pesar de no conocer la contraseña del proyecto. La información contenida permite espiar, suplantar y reconfigurar dispositivos KNX. Esto es particularmente problemático porque el ETS5 da a los usuarios la impresión de que la contraseña del proyecto se usaría para cifrar la información del proyecto, no solo para proyectos exportados. Por lo tanto, es probable que muchos usuarios e integradores de sistemas no hayan tomado medidas adicionales para garantizar la confidencialidad del almacén de proyectos. Si el ETS5 implementara correctamente el cifrado y se eligiera una contraseña de proyecto fuerte, supondría un desafío mucho mayor para un atacante, incluso si lograra acceso remoto al ordenador.

La siguiente información confidencial está cifrada de manera inadecuada:

• Contraseñas de proyecto
• FDSKs
• Claves de backbone
• Códigos de autenticación de dispositivos y claves derivadas
• Contraseñas de gestión de dispositivos y claves derivadas
• Contraseñas de usuario/túnel y claves derivadas
• Claves de herramienta

La Herramienta de Recuperación de Contraseñas ETS5 es una prueba de concepto que demuestra el problema descifrando y mostrando la información sensible. Se desarrolló como parte de la divulgación coordinada de vulnerabilidades y se publica con permiso de la KNX Association. La publicación de la herramienta tiene los siguientes propósitos:

1. Documenta públicamente el problema de seguridad, permitiendo así a los usuarios tomar precauciones para mitigar los riesgos.
2. La KNX Association no planea corregir el problema en versiones actuales o futuras del ETS. Aumentar la conciencia sobre el fallo de diseño podría cambiar su opinión. (ver la sección de divulgación coordinada de vulnerabilidades para una actualización)
3. La divulgación del fallo de diseño espera alentar a la KNX Association y a cualquier persona que lea este documento a adoptar mejores prácticas de ingeniería de software.
4. La Herramienta de Recuperación de Contraseñas ETS5 podría ser realmente útil en caso de que alguien haya olvidado la contraseña de su propio proyecto.

ADVERTENCIA: Use esta herramienta solo si está legalmente autorizado para ver la información del proyecto. Eludir las medidas de seguridad, incluso las ineficaces, para acceder a información que no tiene permiso de ver, puede ser un delito en su jurisdicción.

Instalación

El ejecutable se puede descargar desde la sección de lanzamientos. No necesita instalación y se puede colocar en cualquier directorio de su elección.

Alternativamente, si no desea ejecutar un binario no confiable en su sistema, puede descifrar atributos individuales de los archivos XML del proyecto en el sitio web CyberChef.

Requisitos

El software depende de .NET Framework 4.6 o posterior. Windows 10 ya incluye una versión adecuada de .NET por defecto. Los usuarios de versiones anteriores de Windows deberán instalar una versión actual de .NET Framework para ejecutar el software.

¿Cómo funciona la recuperación de contraseñas?

Contrariamente a lo que sugiere la interfaz de usuario, el ETS5 no cifra sus archivos de proyecto almacenados localmente en C:\ProgramData\KNX\ETS5\ProjectStore con la contraseña del proyecto. En su lugar, utiliza la contraseña fija ETS5Password y la sal Ivan Medvedev para ofuscar atributos específicos en los archivos XML del proyecto. Los secretos criptográficos fijos en el código van en contra de las mejores prácticas, como se explica en CWE-798 y CWE-321.

El proceso de desofuscación es:

1. El atributo ofuscado está codificado en Base64 y debe ser decodificado, ver RFC 4648.
2. Obtener la representación en bytes de Ivan Medvedev como cadena codificada en ASCII o UTF-8.
3. Usar la función de derivación de clave implementada por PasswordDeriveBytes en .NET Framework. Está basada en PBKDF1, pero añade un contador al algoritmo de derivación de clave. En el ETS5 se usa con SHA-1 como función hash, 100 iteraciones, ETS5Password como contraseña y la representación en bytes de Ivan Medvedev como sal. Los primeros 32 bytes de la salida de la derivación de clave se usarán como clave y los siguientes 16 bytes como IV.
4. Descifrar el atributo decodificado usando AES-256 en modo CBC con la clave y el IV del paso 3.
5. Eliminar el relleno PKCS#7 y el resultado es el valor original del atributo.

Se puede encontrar una implementación de la desofuscación en el archivo Deobfuscator.cs. Dado que la contraseña y la sal son constantes, sería posible precalcular la clave y el IV para omitir la derivación de clave. Esto no se hace en la implementación de este software, ya que pretende mostrar todos los pasos de la desofuscación. Sin embargo, si necesita la clave y el IV, se muestran a continuación.

Los archivos de proyecto exportados (.knxproj) no se ven afectados por este fallo de diseño, por lo que esta herramienta no puede usarse para recuperar la contraseña del proyecto en ellos. El archivo .knxproj es un archivo ZIP que contiene otro archivo ZIP con la información sensible. Este último usa compresión Deflate, cifrado ZipCrypto / PKWARE y la contraseña del proyecto para la derivación de la clave de cifrado.

¿Cómo se descubrió el fallo de diseño?

Durante la preparación de mi tesis "Security Analysis of the KNXnet/IP Secure Protocol", investigué cómo el ETS5 almacena la información del proyecto. Dado que el ETS genera y almacena claves criptográficas y contraseñas que utilizan los dispositivos KNX IP Secure para autenticarse entre sí, proporcionar confidencialidad en la comunicación multicast y asegurar la configuración de los dispositivos, es importante mantener la información en secreto. Si un atacante lograra acceder a la información del proyecto almacenada por el ETS, comprometería por completo la seguridad de la instalación KNX.

Por esta razón, se inspeccionó el almacén de proyectos del ETS5 para verificar si los datos se almacenan de manera que garantice la confidencialidad. Los archivos de proyecto en C:\ProgramData\KNX\ETS5\ProjectStore son legibles por cualquier cuenta de usuario, no se requieren derechos de administrador. Se encontraron los siguientes indicios que hicieron sospechar que los datos no estaban correctamente cifrados:

1. Los archivos de configuración XML no están cifrados en su totalidad. Solo los atributos sensibles, como los códigos de autenticación de dispositivos, las contraseñas de gestión de dispositivos, los FDSK y las claves de herramienta, han sido modificados para no contener su valor en texto claro.
2. En uno de los archivos XML se almacena un atributo para la contraseña del proyecto. Esto parecía un poco extraño, ya que con una implementación adecuada, el cifrado derivaría la clave de la contraseña del proyecto, por lo que almacenarla no habría sido estrictamente necesario. Sin embargo, hipotéticamente, podría haberse usado para verificar si la contraseña ingresada es correcta antes de intentar descifrar otros atributos.
3. Dos proyectos con diferentes contraseñas de proyecto, pero con dispositivos idénticos, tenían los mismos valores para algunos atributos específicos del dispositivo, como el FDSK.

El último punto indicaba claramente que la contraseña del proyecto no se usaba en el algoritmo que modifica los valores de los atributos. A continuación se puede ver un ejemplo, donde los códigos de autenticación de dispositivos en dos proyectos P-02FB y P-0117 se establecieron en valores idénticos. Las salidas ofuscadas también son las mismas, a pesar de que se usan contraseñas de proyecto diferentes. Dado que no hay un aviso para ingresar nada más que la contraseña del proyecto al abrir el proyecto en el ETS5, esto significaba que la clave tenía que estar almacenada en algún lugar o que se trataba de un algoritmo de ofuscación simple que no requiere ninguna clave. Parecía probable que la solución no fuera ideal para garantizar la confidencialidad y potencialmente poner en riesgo las instalaciones KNX.

Los archivos de configuración no están cifrados en su totalidad.```xml

``` #### Una contraseña de proyecto diferente no cambia la salida si los valores de atributo originales son idénticos```xml ``` Como las observaciones apuntaban fuertemente al uso de un enfoque inseguro, posiblemente debido al uso de una clave criptográfica codificada, era necesario investigar cómo se modificaban los valores de los atributos. La intención era identificar una posible falla de seguridad, que luego pudiera ser reportada al proveedor y corregida, mejorando la seguridad para todos los usuarios. Evaluar si la implementación proporcionaba una confidencialidad adecuada significó que el ETS5 tuvo que ser sometido a ingeniería inversa.

Dado que el ETS5 está basado en el framework .NET, lo cual era evidente de inmediato por las DLL utilizadas, la descompilación podía realizarse fácilmente mediante ILSpy. El binario había sido ofuscado con Dotfuscator, presumiblemente para dificultar los esfuerzos de ingeniería inversa. Sin embargo, los nombres de clases y funciones sorprendentemente se mantuvieron mayormente intactos. Por lo tanto, el enfoque elegido fue buscar clases y funciones que parecieran relacionadas con el procesamiento de archivos XML, cifrado, descifrado, ofuscación, desofuscación, claves o contraseñas. Esto llevó al descubrimiento de Knx.Ets.ObjectModel.Import.PasswordDescrambler.Scramble y Knx.Ets.ObjectModel.Import.Encryption.EncryptString, que son llamadas sobre los valores ofuscados de atributos almacenados en los archivos XML. No se estaba pasando material de clave a las funciones, solo utilizaba valores constantes para derivar una clave que luego se utilizaba para cifrar/descifrar los atributos usando AES-256 en modo CBC. Era evidente que se usaban credenciales codificadas para derivar una clave. Dotfuscator cambió el flujo de control e insertó operaciones superfluas, pero las llamadas a las funciones del framework .NET no podían ocultarse. Así, fue posible escribir una especificación para la (des)ofuscación en esta etapa para un enfoque semi-clean-room. La única parte faltante era la cadena utilizada en la derivación de clave que había sido ocultada por Dotfuscator. Se eligió De4dot para revertir la ofuscación de cadenas, lo que reveló la contraseña ETS5Password. El IV ya era legible antes de aplicar De4dot, ya que había sido definido como una secuencia de bytes. Por curiosidad personal, se descubrió que esos no eran bytes aleatorios, sino la representación en bytes ASCII/UTF-8 de la cadena Ivan Medvedev.

Como el defecto de diseño representa un riesgo para las instalaciones KNX, el problema debía ser reportado a la Asociación KNX. Se necesitaba una implementación de prueba de concepto para asegurar que el problema pudiera ser demostrado, en caso de que se solicitara. Para evitar cualquier violación de derechos de autor, la prueba de concepto se implementó basándose en la especificación que se había anotado. Esto se hizo para evitar cualquier reutilización de código del software original. La aplicación de Dotfuscator también aseguró que el código original e incluso el no ofuscado no fueran utilizables para una implementación limpia de todos modos, lo que garantizó que incluso una copia involuntaria del original fuera improbable.

Para obtener detalles sobre la divulgación coordinada tras el desarrollo de la prueba de concepto, consulte la sección Divulgación coordinada de vulnerabilidades.

¿Cómo se puede mitigar el riesgo?

Desafortunadamente, al 2021-07-18, no hay una versión parcheada de ETS disponible. Por lo tanto, se necesitan medidas adicionales fuera del ETS5 para abordar los riesgos. Las subsecciones a continuación explican diferentes enfoques que se pueden tomar según el modelo de amenaza que se esté asumiendo y contra el cual se intente proteger.

Cifrado completo del disco

• Solución:
  • Cifrar todo el disco duro con Windows BitLocker o un software de terceros como VeraCrypt.
• Ventajas:
  • Todos los datos en el disco duro están cifrados e inaccesibles para los atacantes mientras el dispositivo esté apagado. Esto supone que se utilizó una contraseña compleja.
  • Windows ya proporciona una solución fácil de usar con BitLocker en ciertas versiones de Windows, y también hay soluciones de software de código abierto disponibles.
• Desventajas:
  • No proporciona confidencialidad mientras la computadora está en funcionamiento. Si un atacante logra acceder a una de las cuentas de usuario / explotar un RCE, puede acceder a la información del proyecto como texto plano.

Cifrado de archivos / carpetas

• Solución:
  • Cifrar el directorio C:\ProgramData\KNX\ETS5\ProjectStore y todos los archivos contenidos en él utilizando el Sistema de Cifrado de Archivos (EFS) de Windows.
• Ventajas:
  • La información del proyecto está cifrada e inaccesible para los atacantes mientras el dispositivo esté apagado.
  • Si el EFS es configurado por la cuenta de administrador o una cuenta dedicada para ejecutar ETS, otras cuentas de usuario no pueden acceder a los archivos. Esto debería proporcionar protección si un atacante obtiene acceso a una cuenta de usuario en la computadora pero no a la que configuró el EFS. Se necesita una contraseña fuerte para la cuenta de administrador o de ETS, ya que se usa para proteger el material de la clave.
• Desventajas:
  • No siempre proporciona confidencialidad mientras la computadora está en funcionamiento. Si un atacante logra acceder a la cuenta de usuario que configuró el EFS o puede ejecutar código en el contexto de ese usuario, aún puede acceder a la información del proyecto como texto plano.

Volumen cifrado

• Solución:
  • Crear un volumen cifrado con un software de terceros como VeraCrypt y almacenar solo la información del proyecto allí.
• Ventajas:
  • La información del proyecto está cifrada e inaccesible para los atacantes mientras el volumen no esté montado. Esto supone que se utilizó una contraseña compleja o un token de hardware para el cifrado del volumen.
  • Proporciona protección limitada incluso en el caso de que el atacante pueda obtener derechos de administrador. Siempre que el volumen no esté montado mientras el atacante tenga acceso al sistema, los datos en el volumen cifrado deberían permanecer confidenciales.
• Desventajas:
  • Los archivos del proyecto original deben transferirse al volumen cifrado y luego eliminarse de forma segura, para que los archivos originales sin cifrar no puedan recuperarse.
  • Es necesario crear un enlace simbólico para que el volumen montado aparezca bajo C:\ProgramData\KNX\ETS5\ProjectStore.
  • En general, es más complicado de configurar.

Divulgación coordinada de vulnerabilidades

• 2021-06-26 - Problema reportado a la Asociación KNX
• 2021-07-09 - La Asociación KNX confirmó el problema
• 2021-07-12 - La Asociación KNX permitió la divulgación inmediata
• 2021-07-18 - Divulgación pública
• 2021-07-19 - Asignado CVE-2021-36799

Según Joost Demarest, CTO y CFO de la Asociación KNX, ETS5 no recibirá parches ya que el desarrollo de esa versión ya ha concluido. Permitió la publicación inmediata del problema el 2021-07-12, renunciando al plazo ofrecido de 90 días para la divulgación.

Actualización 2021-11-08

Debido a un malentendido, el README anteriormente afirmaba que la Asociación KNX planeaba abordar el problema en ETS6. Este no es el caso. La Asociación KNX aclaró el 2021-10-25 que no planea solucionar este problema, ya que no lo consideran responsabilidad de ETS almacenar de forma segura el material de la clave criptográfica cuando no se está exportando.

Actualización 2021-11-10

La Asociación KNX se ha puesto en contacto conmigo y me ha explicado que han revisado sus planes. Ahora tienen la intención de documentar las deficiencias de la versión actual de ETS y cifrar adecuadamente el almacén de proyectos en una versión futura de ETS6.

Licencia

El proyecto se distribuye bajo la licencia MIT.

Registro de cambios

1.0.0 - 2021-07-18

Hash del commit:

• c6a3750cefa74d84c5886097cdd0f30dc1bd0dd1

Descarga:

• Código fuente
• Ejecutable

Cambios:

• Versión inicial