amir20 Dozzle bị bypass SSRF trong webhook, cho phép truy cập mục tiêu cục bộ bị chặn

Dozzle là trình xem log theo thời gian thực cho các container docker. Từ 10.5.2 cho đến 10.6.15, SSRF guard isBlockedIP trong internal/notification/dispatcher/webhook.go, được safeDialContext sử dụng cho các URL webhook notification, không kiểm tra các địa chỉ IPv4 được nhúng trong địa chỉ IPv6 dạng 6to4, NAT64, Teredo hoặc IPv4-compatible, cho phép người dùng đã xác thực tiếp cận các mục tiêu loopback hoặc link-local mà guard dự định chặn. Lỗi này được khắc phục trong phiên bản 10.6.15.

• Sản phẩm: amir20 Dozzle, thành phần webhook notification dispatcher.
• Phạm vi được mô tả: narrative description xác định khoảng dễ bị lỗi bắt đầu từ 10.5.2 và kéo dài đến trước 10.6.15.
• Fact có cấu trúc: affected product record đánh dấu < 10.6.15 là affected, nhưng không nêu rõ trong chính trường version rằng 10.5.2 là cận dưới. Các bản phát hành sớm hơn 10.5.2 vì vậy chưa được narrative description xác lập rõ.
• Bản sửa: 10.6.15. Release notes và security commit của dự án cho biết bản phát hành này bao gồm thay đổi chặn các địa chỉ IPv6 transition trong webhook SSRF guard.
• GitHub advisory được kiểm tra trong quá trình nghiên cứu vẫn hiển thị v10 là affected và chưa liệt kê patched version, mâu thuẫn với structured record, release notes và security commit. Trạng thái của các nhánh hoặc bản phát hành ngoài các cận nêu trên chưa được xác minh.

Lỗi nằm trong isBlockedIP thuộc internal/notification/dispatcher/webhook.go, được safeDialContext sử dụng trước khi mở kết nối cho HTTP client của webhook. Guard kiểm tra các địa chỉ loopback, link-local, multicast, unspecified và một số dải IPv4 không thể định tuyến, nhưng không kiểm tra IPv4 được nhúng bên trong các địa chỉ IPv6 chuyển tiếp.

Các dạng bị bỏ sót gồm 6to4, NAT64, Teredo và IPv4-compatible IPv6. Vì vậy, một địa chỉ IPv6 bề ngoài có thể không bị chặn dù nó biểu diễn một địa chỉ IPv4 loopback hoặc link-local. Bản sửa đổi bổ sung logic tách các IPv4 nhúng rồi kiểm tra lại chúng bằng các quy tắc chặn hiện có, bao gồm cả các biến thể NAT64 local-use và địa chỉ Teredo có phần IPv4 bị obfuscate.

Người tấn công cần tài khoản Dozzle có quyền cấu hình URL webhook và một notification trigger để đường dẫn này được thực thi. Các điều kiện mạng cần thiết để từng cơ chế chuyển tiếp thực sự định tuyến đến mục tiêu cục bộ có thể khác nhau giữa các môi trường và không được xác lập đầy đủ trong bằng chứng công khai.

Đường tấn công có thể thực hiện qua mạng và yêu cầu xác thực Dozzle với quyền cấu hình notification webhook. Bản ghi đánh giá mô tả độ phức tạp thấp, quyền yêu cầu thấp và không cần người dùng khác tương tác sau khi webhook đã được cấu hình.

Người dùng đã xác thực có thể đặt URL webhook chứa địa chỉ IPv6 chuyển tiếp, sau đó chờ notification kích hoạt yêu cầu. safeDialContext sẽ phân giải địa chỉ và kiểm tra bằng isBlockedIP, nhưng phiên bản bị lỗi có thể cho phép kết nối đến mục tiêu loopback hoặc link-local được nhúng.

Bản ghi đánh dấu public exploit là có và advisory của dự án chứa thông tin proof of concept. Bằng chứng được cung cấp không nêu một chiến dịch, nạn nhân hoặc hoạt động khai thác cụ thể ngoài môi trường kiểm thử.

Về kỹ thuật, lỗi biến webhook dispatcher thành một đường SSRF có thể tiếp cận các dịch vụ loopback và link-local thông qua địa chỉ IPv6 chuyển tiếp. Tác động chính là lên confidentiality, vì mục tiêu có thể là dịch vụ nội bộ hoặc cloud metadata endpoint; khả năng lấy dữ liệu thực tế phụ thuộc vào response handling, network routing và quyền của dịch vụ đích.

Người tấn công cần xác thực và quyền cấu hình webhook, nên đây không phải đường tấn công unauthenticated. Record không xác lập tác động trực tiếp lên integrity hoặc availability. Response body chỉ được ghi ở debug level theo advisory, nên đường tấn công có thể bị giới hạn thành semi-blind SSRF, với status code là tín hiệu phản hồi chính.

Các địa chỉ IPv4 riêng RFC 1918 được guard cho phép có chủ đích, vì vậy không nên diễn giải lỗi này thành khả năng truy cập mọi mạng riêng. Khả năng khai thác thực tế cũng phụ thuộc việc môi trường có định tuyến hoặc hỗ trợ các cơ chế 6to4, NAT64 hay Teredo tương ứng hay không.

• Người dùng Dozzle đã xác thực có thể lạm dụng máy chủ webhook như một proxy đến dịch vụ loopback hoặc các endpoint link-local bị hạn chế.
• Nếu môi trường cung cấp cloud metadata service qua địa chỉ link-local, việc truy cập có thể dẫn đến lộ thông tin hoặc credential của workload, tùy cấu hình hạ tầng và quyền của credential đó.
• Lỗi có tính chất semi-blind SSRF: advisory cho biết response body được ghi ở debug level nhưng không trả trực tiếp cho người dùng, trong khi status code được trả về. Điều này có thể hạn chế khả năng đọc dữ liệu nhưng vẫn cho phép suy luận về khả năng kết nối.
• Guard cố ý cho phép các dải RFC 1918 phục vụ webhook self-hosted, vì vậy phạm vi lỗi tập trung vào các dải bị chặn như loopback và link-local, không phải mọi địa chỉ mạng riêng.
• Không có bằng chứng trong record cho thấy lỗi trực tiếp dẫn đến thay đổi dữ liệu hoặc làm gián đoạn dịch vụ.

1. Nâng cấp Dozzle lên đúng phiên bản 10.6.15, bản phát hành được record và release notes xác nhận có security fix cho webhook SSRF guard.
2. Kiểm tra inventory để bảo đảm không còn triển khai nằm trong khoảng affected đã nêu, đồng thời xác minh artifact thực tế chứa thay đổi xử lý IPv6 transition addresses. Không nên suy ra trạng thái an toàn của nhánh song song chỉ từ việc 10.6.15 đã được sửa.
3. Nếu chưa thể nâng cấp, hạn chế quyền tạo hoặc sửa webhook notification URL cho các tài khoản thực sự cần thiết và áp dụng outbound network policy ngăn tiến trình Dozzle truy cập loopback, link-local và cloud metadata endpoint. Đây là biện pháp phòng thủ bổ sung, không phải bản sửa thay thế đã được vendor xác nhận.
4. Rà soát các webhook hiện có để loại bỏ các địa chỉ IPv6 transition có thể biểu diễn mục tiêu bị chặn, sau đó kiểm thử lại sau khi nâng cấp. Không có một workaround tạm thời cụ thể nào được nguồn cung cấp xác nhận.

• Kiểm kê các triển khai amir20 Dozzle, trạng thái bật của webhook notification và nhóm người dùng có thể tạo hoặc sửa URL webhook.
• Rà soát URL webhook để tìm các địa chỉ IPv6 thuộc dạng 6to4, NAT64, Teredo hoặc IPv4-compatible, đặc biệt khi phần IPv4 nhúng tương ứng với loopback hoặc link-local.
• Kiểm tra internal/notification/dispatcher/webhook.go trong mã nguồn hoặc artifact triển khai để xác nhận địa chỉ IPv4 nhúng được tách ra và kiểm tra lại, thay vì chỉ gọi các predicate trực tiếp trên địa chỉ IPv6.
• Rà soát telemetry mạng của tiến trình Dozzle cho các kết nối webhook đến loopback, link-local hoặc cloud metadata endpoint thông qua địa chỉ IPv6. Đây là biện pháp giám sát phòng ngừa, không phải IOC đã được xác nhận.
• Nếu bật debug logging, kiểm tra các bản ghi liên quan đến response body của webhook và trạng thái request. Việc không có log không chứng minh rằng hệ thống an toàn.