Người dùng Dify tự host có thể vẫn chia sẻ khóa bí mật công khai sau khi nâng cấp

Nhiều bản cài đặt Dify tự host đang hoạt động với một lỗ hổng bảo mật nghiêm trọng do lỗi cấu hình tồn tại dai dẳng. Những người dùng đã cài đặt nền tảng ứng dụng AI này trước phiên bản 1.15.0 và sau đó nâng cấp phần mềm rất có thể vẫn đang sử dụng một khóa bí mật mặc định đã được công khai trong lịch sử dự án. Sự sơ suất này cho phép bất kỳ ai biết khóa đều có thể giả mạo token xác thực và truy cập vào dữ liệu nhạy cảm.

Chuyện gì đã xảy ra

Vấn đề bắt nguồn từ cách Dify xử lý các tệp cấu hình trong quá trình cài đặt và nâng cấp. Khi người dùng thiết lập Dify lần đầu, họ thường sao chép một tệp môi trường mẫu để tạo cấu hình đang hoạt động. Thao tác sao chép này chỉ diễn ra một lần. Các lần nâng cấp tiếp theo sẽ thay thế các image container và tệp Docker Compose, nhưng tệp môi trường cục bộ vẫn không bị thay đổi. Do đó, các thiết lập bảo mật trong tệp đó phản ánh trạng thái của phần mềm tại thời điểm cài đặt ban đầu, chứ không phải phiên bản hiện tại.

Cho đến phiên bản 1.14.x, tệp cấu hình mẫu đi kèm với một SECRET_KEY cố định, được hardcode. Khóa này là một chuỗi dài bắt đầu bằng sk-9f73s3lj. Mặc dù tài liệu hướng dẫn gợi ý tạo một khóa duy nhất, hầu hết người dùng đều bỏ qua bước này. Bắt đầu từ phiên bản 1.15.0, tệp mẫu đã được thay đổi để để trống trường SECRET_KEY, yêu cầu hệ thống tự động tạo một khóa bền vững trong thư mục lưu trữ. Tuy nhiên, những người dùng đã cài đặt các phiên bản cũ hơn vẫn giữ lại khóa cũ, công khai trong cấu hình cục bộ của họ ngay cả sau khi nâng cấp lên các phiên bản phần mềm mới hơn, an toàn hơn.

Khóa bí mật này đóng vai trò quan trọng đối với bảo mật. Nó được sử dụng để ký cookie phiên, tạo token xác thực JWT, tạo chữ ký URL tệp thông qua HMAC-SHA256 và mã hóa thông tin đăng nhập OAuth của bên thứ ba. Vì giá trị khóa cũ hiển thị trong lịch sử GitHub công khai của Dify, bất kỳ kẻ tấn công nào cũng có thể đọc nó. Việc sở hữu khóa này cho phép đối thủ ký các token mà instance Dify sẽ chấp nhận là hợp lệ, về cơ bản vượt qua các cơ chế xác thực.

Chi tiết chính

• Phiên bản dễ bị tổn thương: Bất kỳ instance Dify nào được cài đặt trước phiên bản 1.15.0 đã được nâng cấp nhưng chưa cập nhật thủ công tệp .env.
• Dấu hiệu nhận biết: Sự hiện diện của một SECRET_KEY bắt đầu bằng sk-9f73s3lj trong tệp docker/.env.
• Tác động: Kẻ tấn công có thể ký các JWT hợp lệ, truy cập phiên người dùng và có khả năng giải mã thông tin đăng nhập OAuth đã lưu trữ.
• Lệnh khắc phục: Người dùng có thể kiểm tra khóa dễ bị tổn thương bằng cách sử dụng grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env.
• Tác dụng phụ khi sửa lỗi: Việc xoay vòng (rotate) khóa sẽ ngay lập tức đăng xuất tất cả người dùng, làm vô hiệu hóa các URL tệp hiện có và phá vỡ tích hợp plugin OAuth, đòi hỏi phải ủy quyền lại.
• Rủi ro bổ sung: Vấn đề cấu hình tĩnh tương tự ảnh hưởng đến các cổng mở, thiết lập CORS và mật khẩu cơ sở dữ liệu mặc định.

Bối cảnh

Trong các ứng dụng container hóa như Dify, biến môi trường thường được quản lý thông qua tệp .env. Tệp này chứa các bí mật và tham số cấu hình tùy chỉnh ứng dụng cho một triển khai cụ thể. Khi các nhà phát hành cập nhật, họ thường cung cấp các tệp mẫu mới (.env.example) với các giá trị mặc định cải tiến hoặc các trường bắt buộc mới. Tuy nhiên, trình quản lý gói và Docker Compose không tự động gộp những thay đổi này vào tệp .env đang hoạt động của người dùng để tránh ghi đè các thiết lập tùy chỉnh. Điều này đặt gánh nặng lên người quản trị viên phải xem xét và cập nhật thủ công các tệp cấu hình sau các lần nâng cấp lớn.

SECRET_KEY đóng vai trò là gốc rễ của niềm tin (root of trust) cho nhiều thao tác mật mã trong ứng dụng. Nếu khóa này bị xâm phạm, tính toàn vẹn của toàn bộ hệ thống quản lý phiên sẽ bị suy yếu. Trong các kịch bản tự host, nơi người vận hành chịu trách nhiệm cho cả hạ tầng lẫn bảo mật ứng dụng, việc duy trì vệ sinh cấu hình trong các tệp này quan trọng ngang với việc vá các binary phần mềm.

Tại sao điều này quan trọng

Đối với các đội ngũ chạy phần mềm riêng, sự cố này làm nổi bật một điểm mù phổ biến trong quy trình bảo trì. Nhiều quản trị viên cho rằng việc kéo image Docker mới nhất hoặc chạy lệnh nâng cấp compose đảm bảo an toàn đầy đủ. Trên thực tế, sự trôi dạt cấu hình (configuration drift) có thể để lại các lỗ hổng đáng kể ngay cả trên các phiên bản phần mềm mới nhất. Điều này đặc biệt nguy hiểm đối với các nền tảng AI như Dify, vốn có thể xử lý dữ liệu doanh nghiệp nhạy cảm, prompt độc quyền hoặc cơ sở tri thức nội bộ.

Tác động vượt ra ngoài quyền truy cập trái phép tức thì. Vì khóa mã hóa thông tin đăng nhập OAuth của bên thứ ba, một vụ xâm phạm có thể dẫn đến di chuyển ngang (lateral movement) sang các dịch vụ kết nối khác. Hơn nữa, nhu cầu xoay vòng khóa gây ra gián đoạn vận hành. Tất cả người dùng bị đăng xuất và các tích hợp phải được thiết lập lại. Đối với trưởng nhóm IT và kỹ sư DevOps, điều này có nghĩa là khắc phục bảo mật không chỉ là một bản vá kỹ thuật mà còn là một sự kiện quản lý thay đổi, đòi hỏi giao tiếp với các bên liên quan và lựa chọn thời điểm cẩn thận để giảm thiểu thời gian ngừng hoạt động.

Bạn có thể làm gì

• Kiểm tra cấu hình của bạn: Chạy grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env trong terminal của bạn. Kết quả là 1 nghĩa là bạn đang dễ bị tổn thương.
• Tạo khóa mới: Nếu dễ bị tổn thương, hãy sao lưu tệp .env và sử dụng openssl rand -base64 42 để tạo một khóa ngẫu nhiên mới, sau đó cập nhật tệp.
• Khởi động lại dịch vụ: Áp dụng thay đổi bằng cách chạy docker compose up -d để khởi động lại các container với bí mật mới.
• Hạn chế phơi bày cổng: Liên kết các cổng nginx và debug với 127.0.0.1 trong tệp .env của bạn để ngăn chặn truy cập từ bên ngoài, sử dụng các biến như EXPOSE_NGINX_PORT=127.0.0.1:8080.
• Bảo mật thiết lập CORS: Đặt rõ ràng CONSOLE_CORS_ALLOW_ORIGINS thành URL bảng điều khiển cụ thể của bạn thay vì để nó ở dạng wildcard mặc định *.
• Cập nhật lên phiên bản mới nhất: Đảm bảo bạn đang chạy ít nhất Dify 1.17.1 để giải quyết các khuyến nghị bảo mật khác có thể chưa có ID CVE.