Los usuarios de Dify autoalojado pueden seguir compartiendo una clave secreta pública tras las actualizaciones

Muchas instalaciones autoalojadas de Dify funcionan con una vulnerabilidad de seguridad crítica debido a un error de configuración persistente. Los usuarios que instalaron la plataforma de aplicaciones de IA antes de la versión 1.15.0 y posteriormente actualizaron su software probablemente aún poseen una clave secreta predeterminada que está disponible públicamente en el historial del proyecto. Esta omisión permite que cualquier persona que conozca la clave falsifique tokens de autenticación y acceda a datos sensibles.

Qué ocurrió

El problema radica en cómo Dify gestiona los archivos de configuración durante la instalación y las actualizaciones. Cuando los usuarios configuran Dify por primera vez, suelen copiar un archivo de entorno de ejemplo para crear su configuración activa. Esta operación de copia se realiza solo una vez. Las actualizaciones posteriores reemplazan las imágenes de contenedor y el archivo Docker Compose, pero el archivo de entorno local permanece intacto. En consecuencia, los ajustes de seguridad en ese archivo reflejan el estado del software en el momento de la instalación inicial, no la versión actual.

Hasta la versión 1.14.x, el archivo de configuración de ejemplo incluía una SECRET_KEY fija y codificada en el código fuente (hardcoded). Esta clave era una cadena larga que comenzaba con sk-9f73s3lj. Aunque la documentación sugería generar una clave única, la mayoría de los usuarios no tomaron esta medida. A partir de la versión 1.15.0, se modificó el archivo de ejemplo para dejar vacío el campo SECRET_KEY, instruyendo al sistema para que genere automáticamente una clave persistente en el directorio de almacenamiento. Sin embargo, los usuarios que instalaron versiones anteriores conservaron la antigua clave pública en su configuración local incluso después de actualizar a versiones más nuevas y seguras del software.

Esta clave secreta es vital para la seguridad. Se utiliza para firmar cookies de sesión, generar tokens de autenticación JWT, crear firmas de URL de archivos mediante HMAC-SHA256 y cifrar credenciales OAuth de terceros. Dado que el valor antiguo de la clave es visible en el historial público de GitHub de Dify, cualquier atacante puede leerlo. La posesión de esta clave permite a un adversario firmar tokens que la instancia de Dify aceptará como válidos, eludiendo efectivamente los mecanismos de autenticación.

Detalles clave

• Versiones vulnerables: Cualquier instancia de Dify instalada antes de la versión 1.15.0 que haya sido actualizada sin haber modificado manualmente su archivo .env.
• El indicador: La presencia de una SECRET_KEY que comience con sk-9f73s3lj en el archivo docker/.env.
• Impacto: Los atacantes pueden firmar JWTs válidos, acceder a sesiones de usuario y potencialmente descifrar credenciales OAuth almacenadas.
• Comando de remediación: Los usuarios pueden comprobar si tienen la clave vulnerable utilizando grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env.
• Efectos secundarios de la corrección: Rotar la clave cerrará inmediatamente la sesión de todos los usuarios, invalidará las URL de archivos existentes y romperá las integraciones de plugins OAuth, requiriendo una nueva autorización.
• Riesgos adicionales: El mismo problema de configuración estática afecta a los puertos expuestos, los ajustes CORS y las contraseñas predeterminadas de la base de datos.

Contexto

En aplicaciones contenerizadas como Dify, las variables de entorno suelen gestionarse a través de un archivo .env. Este archivo contiene secretos y parámetros de configuración que personalizan la aplicación para un despliegue específico. Cuando los desarrolladores lanzan actualizaciones, a menudo proporcionan nuevos archivos de ejemplo (.env.example) con valores predeterminados mejorados o campos nuevos obligatorios. Sin embargo, los gestores de paquetes y Docker Compose no fusionan automáticamente estos cambios en el archivo .env activo del usuario para evitar sobrescribir configuraciones personalizadas. Esto recae sobre el administrador, quien debe revisar y actualizar manualmente los archivos de configuración tras las actualizaciones importantes.

La SECRET_KEY actúa como la raíz de confianza para muchas operaciones criptográficas dentro de la aplicación. Si esta clave se ve comprometida, se socava la integridad de todo el sistema de gestión de sesiones. En escenarios autoalojados, donde el operador es responsable tanto de la infraestructura como de la seguridad de la aplicación, mantener la higiene en estos archivos de configuración es tan crítico como parchear los binarios del software.

Por qué importa

Para los equipos que ejecutan su propio software, este incidente destaca un punto ciego común en las rutinas de mantenimiento. Muchos administradores asumen que extraer la última imagen de Docker o ejecutar un comando de actualización de compose garantiza una seguridad completa. En realidad, la deriva de configuración puede dejar vulnerabilidades significativas abiertas incluso en las últimas versiones del software. Esto es particularmente peligroso para plataformas de IA como Dify, que pueden manejar datos corporativos sensibles, prompts propietarios o bases de conocimiento internas.

El impacto va más allá del acceso no autorizado inmediato. Dado que la clave cifra credenciales OAuth de terceros, una brecha podría derivar en movimientos laterales hacia otros servicios conectados. Además, la necesidad de rotar la clave causa interrupciones operativas. Todos los usuarios son desconectados y las integraciones deben restablecerse. Para los líderes de TI e ingenieros DevOps, esto significa que la remediación de seguridad no es solo una solución técnica, sino un evento de gestión del cambio que requiere comunicación con las partes interesadas y una planificación cuidadosa para minimizar el tiempo de inactividad.

Qué puedes hacer

• Revisa tu configuración: Ejecuta grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env en tu terminal. Un resultado de 1 significa que eres vulnerable.
• Genera una nueva clave: Si eres vulnerable, haz una copia de seguridad de tu archivo .env y usa openssl rand -base64 42 para generar una nueva clave aleatoria, luego actualiza el archivo.
• Reinicia los servicios: Aplica el cambio ejecutando docker compose up -d para reiniciar los contenedores con el nuevo secreto.
• Restringe la exposición de puertos: Vincula los puertos de nginx y depuración a 127.0.0.1 en tu archivo .env para prevenir el acceso externo, utilizando variables como EXPOSE_NGINX_PORT=127.0.0.1:8080.
• Protege los ajustes CORS: Establece explícitamente CONSOLE_CORS_ALLOW_ORIGINS a tu URL de consola específica en lugar de dejarla como el comodín predeterminado *.
• Actualiza a la última versión: Asegúrate de estar ejecutando al menos Dify 1.17.1 para abordar otros avisos de seguridad que pueden no tener IDs CVE.