Command injection trong jc21 Nginx Proxy Manager cho phép thực thi mã từ xa

Một lỗ hổng command injection trong requestLetsEncryptSsl của NginxProxyManager 2.11.3 cho phép kẻ tấn công thực hiện RCE thông qua Add Let's Encrypt Certificate.

• jc21 Nginx Proxy Manager 2.11.3: bị ảnh hưởng theo bản ghi chuẩn hóa.
• v2.12.0: release chứa commit sửa lỗi được dự án liên kết với CVE này; bản sửa bổ sung validation tên miền và kiểm thử các trường hợp PoC.
• Trạng thái của các nhánh phát hành song song hoặc các release khác chưa được bằng chứng đã kiểm tra xác nhận. Không nên mặc định rằng mọi nhánh sau v2.12.0 đều đã được xác minh.

Thành phần bị ảnh hưởng là requestLetsEncryptSsl trong backend/internal/certificate.js. Mã bị ảnh hưởng xây dựng lệnh shell cho certbot, đưa dữ liệu certificate.domain_names vào lệnh rồi truyền lệnh hoàn chỉnh cho utils.exec. Luồng này cho phép dữ liệu được kiểm soát từ yêu cầu Add Let's Encrypt Certificate đi vào một lệnh được thực thi bởi tiến trình Nginx Proxy Manager. Commit sửa lỗi của dự án bổ sung kiểm tra schema cho tên miền, từ chối các ký tự đặc biệt trong shell, đồng thời thêm kiểm thử tích hợp cho các ví dụ PoC. Bằng chứng hiện có chưa mô tả đầy đủ route HTTP cụ thể, điều kiện phân quyền của từng deployment, hoặc tiến trình chạy trong container hay trên host. Nếu thực thi thành công, lệnh sẽ chạy với quyền của service Nginx Proxy Manager.

Lỗ hổng có thể bị tiếp cận qua mạng và bản ghi chuẩn hóa mô tả độ phức tạp thấp, không yêu cầu quyền và không cần tương tác người dùng. Bản ghi cũng xác nhận đã có public exploit, trong khi README của PoC công khai mô tả một luồng có nhập thông tin đăng nhập và lấy token, vì vậy điều kiện xác thực thực tế cần được kiểm tra theo từng deployment. Bằng chứng được cung cấp chưa xác lập việc khai thác thực tế đang diễn ra, chiến dịch cụ thể, nạn nhân cụ thể hoặc chỉ báo xâm nhập. Không tái hiện payload hay các bước khai thác trong mục này.

Kết quả kỹ thuật là thực thi lệnh trong ngữ cảnh của service Nginx Proxy Manager, với khả năng ảnh hưởng cao đến tính bí mật, toàn vẹn và sẵn sàng của tài nguyên mà service có quyền truy cập. Đánh giá chuẩn hóa mô tả phạm vi ảnh hưởng không thay đổi, nhưng tác động thực tế vẫn phụ thuộc vào quyền của process, container isolation và các mount hoặc secret được cấp cho deployment. Một instance bị chiếm quyền có thể bị dùng để sửa cấu hình reverse proxy, truy cập dữ liệu chứng chỉ hoặc làm gián đoạn dịch vụ. Việc vượt ra ngoài ranh giới host hoặc container không được bằng chứng hiện có xác nhận.

Khai thác thành công có thể làm mất quyền kiểm soát đối với tiến trình Nginx Proxy Manager và cho phép thay đổi dữ liệu hoặc cấu hình mà service có quyền truy cập. Tùy quyền của service và mức độ cô lập, kẻ tấn công có thể làm lộ thông tin chứng chỉ, secret, cấu hình reverse proxy hoặc dữ liệu liên quan đến các upstream service. Việc sửa cấu hình proxy hoặc thao tác với quy trình cấp chứng chỉ có thể gây gián đoạn truy cập, định tuyến sai hoặc buộc tổ chức phải cấp lại chứng chỉ. Bằng chứng hiện có không xác nhận một vụ xâm nhập cụ thể, nên mức độ ảnh hưởng thực tế cần được đánh giá từ quyền của service và nhật ký triển khai.

1. Nâng cấp Nginx Proxy Manager từ 2.11.3 lên v2.12.0, là release được repository liên kết với bản sửa cho lỗi này.
2. Xác nhận sau nâng cấp rằng deployment thực sự sử dụng code có validation tên miền và kiểm thử sửa lỗi tương ứng, thay vì chỉ thay đổi image hoặc package không đúng.
3. Nếu chưa thể nâng cấp ngay, hạn chế quyền truy cập giao diện quản trị và API vào mạng hoặc nhóm quản trị tin cậy. Đây là biện pháp giảm phơi nhiễm tạm thời, không phải bản sửa đã được xác nhận.
4. Rà soát các yêu cầu tạo chứng chỉ gần đây. Nếu phát hiện hoạt động trái phép, coi credential, token, certificate private key và secret mà service có thể truy cập là có khả năng bị lộ, sau đó thay thế chúng theo quy trình ứng phó sự cố.
5. Không suy luận trạng thái an toàn của các nhánh phát hành khác chỉ từ việc v2.12.0 có bản sửa.

1. Kiểm kê mọi instance Nginx Proxy Manager và đối chiếu release với các mốc bị ảnh hưởng và đã sửa trong affected_summary.
2. Rà soát audit log cho các sự kiện tạo chứng chỉ bất thường, đặc biệt các yêu cầu không do quản trị viên hoặc automation hợp lệ tạo ra.
3. Kiểm tra application log quanh các thông báo Requesting Let'sEncrypt certificates và Command: để tìm hoạt động cấp chứng chỉ ngoài dự kiến. Đây là telemetry phòng ngừa, không phải IOC đã được xác nhận.
4. Đối chiếu các lần gọi certbot, tên miền yêu cầu và thời điểm tạo chứng chỉ với ticket, thay đổi cấu hình và người vận hành tương ứng.
5. Xác minh hệ thống đã chạy release có bản sửa. Không có log đáng ngờ không chứng minh instance an toàn.