Lỗ hổng directory traversal trong Syslog của VMware vCenter cho phép thực thi mã tùy ý

VMware vCenter chứa lỗ hổng directory traversal trong máy chủ Syslog. Tác nhân độc hại có quyền truy cập mạng tới vCenter có thể khai thác vấn đề này để thực thi mã tùy ý.

• VMware Cloud Foundation: các nhánh 9.1.x.x, 9.0.x.x và 5.x bị ảnh hưởng. Với nhánh 5.x, Broadcom hướng dẫn thực hiện async patch lên 8.0 U3k.
• VMware vSphere Foundation: các nhánh 9.1.x.x và 9.0.x.x bị ảnh hưởng.
• VMware vCenter: nhánh 9.1.x.x bị ảnh hưởng khi thấp hơn 9.1.0.0300; nhánh 9.0.x.x bị ảnh hưởng khi thấp hơn 9.0.2.0100; nhánh 8.0 bị ảnh hưởng khi thấp hơn 8.0 U3k. Broadcom cũng liệt kê 8.0 U2f là bản sửa cho nhánh triển khai tương ứng và cung cấp hướng dẫn cho nhánh 7.0 qua Broadcom Support nếu còn hợp đồng extended support.
• VMware Telco Cloud Infrastructure: phiên bản 3.0 bị ảnh hưởng; hướng dẫn sửa lỗi là KB449886.
• VMware Telco Cloud Platform: các nhánh 5.1.x, 5.0.x, 4.x và 3.0 bị ảnh hưởng; hướng dẫn sửa lỗi là KB449886.
• Broadcom không công bố workaround cho lỗ hổng này.

VMware vCenter bị lỗi CWE-22 do Syslog server xử lý đường dẫn không đúng giới hạn thư mục được phép. Kẻ tấn công có thể tiếp cận vCenter qua mạng, không cần quyền xác thực hoặc tương tác của người dùng; Broadcom xác nhận hậu quả có thể là thực thi mã tùy ý. Bằng chứng từ một chiến dịch được điều tra cho thấy nội dung đường dẫn do kẻ tấn công kiểm soát đã được đưa qua cơ chế xử lý Syslog để tạo tệp trong vị trí được cron thực thi, sau đó mã được chạy trong ngữ cảnh root. Đây là hành vi quan sát được trong chiến dịch, không phải mô tả đầy đủ về cách triển khai lỗi của VMware. Nhà cung cấp chưa công bố chi tiết về cơ chế kiểm tra đường dẫn, request cụ thể hoặc payload khai thác.

• Lỗ hổng có thể bị khai thác từ xa qua mạng tới vCenter.
• Bản ghi cho biết không yêu cầu quyền trước, không yêu cầu user interaction và độ phức tạp khai thác thấp.
• Bản ghi đánh dấu lỗ hổng đã bị khai thác và có public exploit.
• Một điều tra của bên thứ ba báo cáo hoạt động khai thác vCenter có thể truy cập Internet, với 361 địa chỉ IP nạn nhân tại 47 quốc gia. Điều tra này cũng ghi nhận reverse_ssh được dùng để duy trì truy cập sau xâm nhập.
• Không có quy trình khai thác hoàn chỉnh hoặc payload công khai nào được xác nhận trong nguồn của nhà cung cấp.

Lỗi cho phép tác nhân từ xa thực thi mã tùy ý trên VMware vCenter mà không cần quyền xác thực hoặc tương tác của người dùng. Hậu quả kỹ thuật có thể bao gồm chiếm quyền appliance, đọc hoặc thay đổi dữ liệu và làm gián đoạn dịch vụ quản trị. Trong một ca điều tra được báo cáo, mã được thực thi trong ngữ cảnh root, sau đó kẻ tấn công tạo persistence và tài khoản quản trị, cho thấy rủi ro vượt ra ngoài một thao tác Syslog đơn lẻ. Mức độ ảnh hưởng thực tế phụ thuộc vào quyền quản trị, khả năng kết nối tới các hệ thống do vCenter quản lý và các biện pháp phân đoạn mạng của từng tổ chức.

Việc khai thác thành công có thể làm mất tính bí mật, toàn vẹn và khả dụng của vCenter appliance. Vì vCenter là mặt phẳng quản trị tập trung, việc chiếm quyền có thể cho phép kẻ tấn công thay đổi cấu hình, duy trì truy cập hoặc gây gián đoạn hoạt động quản trị hạ tầng ảo hóa. Một điều tra sự cố đã ghi nhận việc tạo tài khoản quản trị, cơ chế persistence và hoạt động hướng tới các máy chủ ESXi sau khi xâm nhập, nhưng đây là bằng chứng của một chiến dịch cụ thể chứ không phải kết quả bắt buộc trong mọi trường hợp. Bản ghi không chứng minh rằng mọi hệ thống bị ảnh hưởng đều đã bị xâm nhập.

1. Xác định đúng nhánh sản phẩm và áp dụng bản sửa tương ứng: 9.1.0.0300 cho vCenter 9.1.x.x, 9.0.2.0100 cho vCenter 9.0.x.x, hoặc bản sửa phù hợp của nhánh vCenter 8.0 là 8.0 U3k hoặc 8.0 U2f theo response matrix của Broadcom.
2. Với VMware Cloud Foundation 5.x, thực hiện async patch lên 8.0 U3k theo hướng dẫn của Broadcom. Với VMware Telco Cloud Platform và VMware Telco Cloud Infrastructure, áp dụng hướng dẫn trong KB449886.
3. Với vCenter 7.0, liên hệ Broadcom Support nếu tổ chức có hợp đồng extended support; không tự suy diễn rằng nhánh này đã có một fixed release cụ thể.
4. Broadcom không cung cấp workaround. Trong thời gian chờ cập nhật, có thể hạn chế network access tới vCenter như một biện pháp giảm khả năng tiếp cận, nhưng đây không phải bản vá đã được nhà cung cấp xác nhận.
5. Nếu có dấu hiệu khai thác, xử lý hệ thống theo quy trình incident response, bảo toàn log và artifact liên quan, đồng thời kiểm tra tài khoản quản trị, scheduled tasks, dịch vụ persistence và các kết nối outbound bất thường trước khi kết luận hệ thống an toàn.

1. Kiểm kê toàn bộ vCenter, VMware Cloud Foundation, VMware vSphere Foundation và các nền tảng Telco Cloud, sau đó đối chiếu phiên bản với các nhánh bị ảnh hưởng.
2. Kiểm tra Syslog và hệ thống tệp để tìm các bản ghi có đường dẫn bất thường, dấu hiệu path traversal hoặc nội dung được đưa vào các vị trí đặc quyền như /etc/cron.d.
3. Rà soát log cron và crond cùng các tệp hoặc tên tác vụ đáng ngờ như zz-poc59310-syslog.log, zz-poc59310, vmware-vpxd-stats-*, vmware-perf-collect-* và vmware-perf-sync-*.
4. Kiểm tra các tệp, tiến trình và dịch vụ bất thường như linuxFile, systemlog, linux_x86, sys-9436d8.service, vmware-perf-update.jsp và cấu hình sudoers bất ngờ liên quan đến perfcharts.
5. Rà soát việc tạo tài khoản quản trị vSphere hoặc LDAP mới, các kết nối outbound bất thường và user agent như GoodMoodle-VCProbe/1.0 hoặc GoodMoodle-VCFleet/1.0 nếu các trường này được ghi nhận.
6. Có thể dùng việc phát hiện reverse_ssh như một dấu hiệu điều tra, nhưng đây là công cụ dual-use nên phải tương quan với cài đặt trái phép, thực thi trên vCenter và kết nối outbound bất thường. Không thấy các dấu hiệu trên không chứng minh hệ thống không bị xâm nhập.