Thiếu xác thực trong kiểm tra chứng chỉ của NginxProxyManager nginx-proxy-manager

Một lỗ hổng đã được phát hiện trong NginxProxyManager nginx-proxy-manager đến phiên bản 2.15.1. Lỗ hổng ảnh hưởng đến hàm internalCertificate.validate của tệp backend/internal/certificate.js thuộc thành phần Validate Route. Việc thao túng dẫn đến thiếu xác thực. Cuộc tấn công có thể được thực hiện từ xa. Exploit hiện đã công khai và có thể được sử dụng. Endpoint chỉ xử lý rồi phản hồi lại chứng chỉ do caller gửi (không làm lộ dữ liệu đã lưu); rủi ro thực sự là việc xử lý openssl không xác thực đối với dữ liệu đầu vào do kẻ tấn công cung cấp. Dự án đã được thông báo sớm về vấn đề thông qua một issue report nhưng vẫn chưa phản hồi.

• Mô tả của CNA xác định NginxProxyManager nginx-proxy-manager bị ảnh hưởng đến và bao gồm phiên bản 2.15.1.
• Dữ liệu affected có cấu trúc đánh dấu rõ các phiên bản 2.0, 2.1, 2.1.0, 2.1.1, 2.1.2, 2.2, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.3, 2.3.0, 2.3.1, 2.4, 2.4.0, 2.5, 2.5.0, 2.6 và 2.6.0 là bị ảnh hưởng.
• Danh sách cấu trúc không liệt kê từng bản phát hành trong khoảng từ 2.6.0 đến 2.15.1; phạm vi này được hỗ trợ bởi cách diễn đạt rộng hơn của CNA chứ không phải bởi danh sách từng phiên bản hoàn chỉnh.
• Chưa có bản sửa lỗi hoặc ranh giới phiên bản cố định nào được xác định; trạng thái cung cấp bản vá vẫn chưa rõ.

Lỗ hổng nằm ở hàm internalCertificate.validate trong tệp backend/internal/certificate.js của thành phần Validate Route. Ứng dụng không yêu cầu xác thực trước khi tiếp nhận và xử lý dữ liệu chứng chỉ do caller cung cấp. Theo bằng chứng hiện có, chứng chỉ do kẻ tấn công kiểm soát được đưa vào quá trình xử lý bằng OpenSSL, sau đó endpoint xử lý và phản hồi lại chứng chỉ đó. Cuộc tấn công có thể thực hiện từ xa, không cần xác thực hoặc tương tác của người dùng, và bản ghi chuẩn hóa đánh giá độ phức tạp là thấp. URL endpoint chính xác, schema của request, lời gọi OpenSSL cụ thể và cách xử lý các chứng chỉ malformed chưa được công bố. Vì vậy, các hậu quả vượt quá việc xử lý chứng chỉ không xác thực, chẳng hạn làm gián đoạn dịch vụ hoặc kích hoạt lỗi trong thư viện, mới chỉ là khả năng chưa được xác nhận.

• Khả năng tiếp cận: Có thể tấn công từ xa qua mạng.
• Xác thực: Không cần tài khoản hoặc thông tin xác thực.
• Tương tác người dùng: Không cần người dùng thực hiện hành động.
• Độ phức tạp: Bản ghi chuẩn hóa mô tả độ phức tạp là thấp.
• Trạng thái khai thác: VulDB báo cáo exploit hoặc proof of concept đã công khai. Issue GitHub được trả về khi nghiên cứu chỉ cho thấy người báo cáo đã thông báo vấn đề và không chứa các bước khai thác kỹ thuật.
• Bằng chứng hiện có không nêu chiến dịch, nạn nhân hoặc nhóm tấn công cụ thể, nên không thể kết luận về việc khai thác trong thực tế.

Kết quả kỹ thuật được xác nhận là caller không xác thực có thể vượt qua kiểm soát truy cập của chức năng kiểm tra chứng chỉ và đưa dữ liệu do mình kiểm soát vào quá trình xử lý OpenSSL. Phạm vi được mô tả cụ thể chỉ bao gồm việc xử lý và echo chứng chỉ do caller gửi; chưa có bằng chứng xác nhận truy cập vào chứng chỉ, private key hoặc cơ sở dữ liệu đã lưu. Việc xử lý input được tạo riêng có thể gây tiêu thụ tài nguyên hoặc làm thư viện và dịch vụ hoạt động không ổn định, nhưng hành vi cụ thể chưa được xác định. Về tổ chức, sự cố có thể buộc đội vận hành giảm phơi bày mạng, rà soát log và chuẩn bị khôi phục dịch vụ nếu xảy ra bất ổn; chưa có breach, nạn nhân hoặc tác nhân cụ thể nào được nêu.

Vấn đề cho phép caller không xác thực sử dụng chức năng xử lý chứng chỉ của dịch vụ, làm tăng rủi ro đối với các triển khai có giao diện hoặc backend bị phơi bày ra mạng không tin cậy. Việc xử lý input chứng chỉ qua OpenSSL có thể làm tăng mức tiêu thụ CPU hoặc memory và có khả năng gây mất ổn định dịch vụ, nhưng denial of service hoặc code execution chưa được xác nhận. Mô tả nguồn nêu rõ endpoint chỉ xử lý và echo chứng chỉ do caller gửi, không làm lộ dữ liệu đã lưu. Tác động được xác nhận hiện tập trung vào việc vượt qua ranh giới xác thực và buộc dịch vụ xử lý dữ liệu do kẻ tấn công kiểm soát.

1. Áp dụng bản sửa lỗi chính thức của vendor ngay khi được phát hành. Bản ghi và tài liệu CNA được nghiên cứu không xác định bản phát hành đã sửa lỗi, vì vậy không được coi một nhánh mới hơn hoặc nhánh song song chưa được xác minh là đã khắc phục.
2. Trong thời gian chờ bản sửa lỗi được xác nhận, hạn chế Validate Route hoặc giao diện quản trị khỏi mạng không tin cậy nếu có thể. Đặt quyền truy cập sau ranh giới mạng tin cậy hoặc thêm lớp xác thực và allowlist ở reverse proxy hoặc gateway.
3. Rà soát các kiểm soát tại reverse proxy và ứng dụng để ngăn request chưa xác thực tiếp cận chức năng xử lý chứng chỉ. Đây là biện pháp bù trừ, không phải bản sửa lỗi ở cấp mã nguồn.
4. Cập nhật hệ điều hành và package OpenSSL để tăng cường phòng thủ, nhưng không xem việc cập nhật thư viện là biện pháp sửa lỗi cho thiếu xác thực ở cấp ứng dụng.
5. Sau khi áp dụng bản sửa lỗi đã được xác nhận, kiểm kê lại image và package version, đồng thời rà soát log về request không xác thực và các bất thường về tài nguyên.

1. Kiểm kê mọi triển khai NginxProxyManager, bao gồm image tag và phiên bản package, rồi đối chiếu với ranh giới phiên bản bị ảnh hưởng do CNA công bố. Do dữ liệu có cả mô tả CNA bao quát và danh sách phiên bản được liệt kê chi tiết hẹp hơn, không nên suy ra rằng một nhánh không được liệt kê là an toàn.
2. Xác định Validate Route và chức năng kiểm tra chứng chỉ có thể được truy cập từ mạng không tin cậy hay không, trực tiếp hoặc thông qua reverse proxy.
3. Kiểm tra log ứng dụng và reverse proxy để tìm request đến chức năng kiểm tra chứng chỉ không có authenticated session, đặc biệt khi client chưa xác thực gửi payload chứng chỉ. URL và tên trường log chính xác chưa được công bố, vì vậy không nên giả định một path hoặc event signature cụ thể.
4. Correlate các request này với spike về CPU hoặc memory, worker restart và lỗi OpenSSL như một biện pháp rà soát thận trọng. Đây là tín hiệu kiểm tra chung, không phải indicator khai thác đã được xác nhận.
5. Không xem việc endpoint phản hồi lại chứng chỉ bình thường hoặc không đọc dữ liệu đã lưu là bằng chứng endpoint an toàn. Rủi ro được ghi nhận là xử lý input của kẻ tấn công mà không xác thực.