Leo thang đặc quyền cục bộ lên root trong các gói DEB và RPM của Zammad từ Zammad GmbH

Các gói Zammad được xây dựng bằng packager.io (DEB và RPM) có thể đã cho phép kẻ tấn công cục bộ, vốn đã có quyền ghi vào hệ thống tệp với tư cách tài khoản dịch vụ không đặc quyền zammad, nâng đặc quyền lên toàn quyền root trên máy chủ. Các tiến trình dịch vụ bắt đầu chạy với quyền root và thực thi các tệp do tài khoản zammad sở hữu và có thể ghi trước khi hạ danh tính xuống tài khoản đó. Kẻ tấn công đã có foothold này có thể nâng đặc quyền trong vài giây, vì các dịch vụ bị ảnh hưởng được tự động khởi động lại mỗi khi chúng dừng; không cần quản trị viên tương tác. Chỉ các cài đặt từ các gói DEB và RPM bị ảnh hưởng; các cài đặt từ mã nguồn hoặc official container images thì không. Tất cả các phiên bản đóng gói đã phát hành đều bị ảnh hưởng.

• Zammad trên Linux được cài đặt từ các gói DEB hoặc RPM của packager.io bị ảnh hưởng ở các phiên bản >= 1.5.0 và < 7.2.2. Hồ sơ ảnh hưởng mô tả toàn bộ các phiên bản đóng gói đã phát hành trong phạm vi này là bị ảnh hưởng.
• Các phiên bản < 1.5.0 và >= 7.2.2 được đánh dấu không bị ảnh hưởng trong dữ liệu có cấu trúc.
• Các bản cài đặt từ mã nguồn và các official container images không bị ảnh hưởng bởi lỗi đóng gói này.
• GitHub advisory của nhà cung cấp xác định 7.2.2 là phiên bản đã được vá.

Zammad GmbH Zammad được đóng gói bằng packager.io có lỗi trong cách các dịch vụ được khởi chạy và xử lý tệp thực thi. Tiến trình dịch vụ bắt đầu chạy với quyền root, thực thi các tệp do tài khoản dịch vụ zammad sở hữu và có thể ghi, sau đó mới hạ quyền xuống tài khoản zammad. Vì vậy, kẻ tấn công đã có quyền thực thi hoặc quyền ghi tệp trong ngữ cảnh zammad có thể thay đổi tệp được tiến trình đặc quyền sử dụng rồi chờ dịch vụ khởi động lại. Các dịch vụ bị ảnh hưởng tự động khởi động lại khi dừng, nên không cần quản trị viên tương tác. Public material không xác định tên dịch vụ, đường dẫn cụ thể hoặc chi tiết unit/service manager nào; các chi tiết đó cần được xác minh trong từng hệ thống.

Đây là lỗi leo thang đặc quyền cục bộ. Kẻ tấn công phải có quyền truy cập trước vào máy chủ và quyền ghi vào hệ thống tệp với tư cách tài khoản dịch vụ zammad; lỗi không thể tự khai thác từ xa theo đánh giá của nhà cung cấp. Sau khi có foothold này, việc thay đổi tệp và kích hoạt cơ chế tự khởi động lại của dịch vụ không yêu cầu quản trị viên tương tác và có thể hoàn tất trong vài giây. DIVD cho biết lỗi đã bị lợi dụng trong vụ xâm nhập vào hệ thống Zammad của chính tổ chức này, vì vậy trạng thái khai thác không chỉ là lý thuyết. Hồ sơ được cung cấp đánh dấu lỗi là đã bị khai thác và có public exploit; các tài liệu đã xem không xác định một công cụ, payload hoặc exploit artifact cụ thể.

• Kết quả kỹ thuật là leo thang từ quyền ghi hoặc thực thi trong ngữ cảnh tài khoản zammad lên quyền root trên cùng máy chủ.
• Quyền root có thể cho phép đọc, sửa hoặc xóa dữ liệu và tệp mà hệ điều hành cho phép, thay đổi cấu hình, kiểm soát dịch vụ Zammad và làm mất tính sẵn sàng của máy chủ.
• Phạm vi ảnh hưởng trực tiếp được mô tả là máy chủ chứa bản cài đặt; các tài liệu hiện có không chứng minh rằng lỗi này tự động xâm phạm các hệ thống khác.
• Do cần foothold ban đầu trên máy chủ, lỗi không phải là một remote takeover độc lập. Tuy nhiên, nếu foothold đó đến từ một lỗi hoặc kênh khác, việc leo lên root có thể biến quyền truy cập hạn chế thành quyền kiểm soát toàn host.

Một lần khai thác thành công có thể dẫn đến quyền root trên máy chủ chạy Zammad, cho phép kẻ tấn công thay đổi tệp hệ thống, kiểm soát tiến trình dịch vụ và làm gián đoạn máy chủ hoặc dịch vụ hỗ trợ khách hàng. Dữ liệu, cấu hình và các tài nguyên cục bộ mà tài khoản root có thể truy cập có thể bị đọc, sửa hoặc xóa. Tổ chức có thể phải xử lý sự cố máy chủ, điều tra tính toàn vẹn của bản cài đặt và khôi phục dịch vụ. Bằng chứng hiện có không xác định phạm vi dữ liệu bị truy cập trong từng môi trường cụ thể.

1. Cập nhật các bản cài đặt từ gói DEB hoặc RPM lên Zammad 7.2.2, phiên bản được advisory của nhà cung cấp xác định là đã vá. Sau khi cập nhật, xác minh lại nguồn gói và phiên bản thực tế đang chạy.
2. Nếu chưa thể cập nhật ngay, hạn chế quyền truy cập vào máy chủ nền tảng chỉ cho các quản trị viên đáng tin cậy. Đây chỉ là biện pháp giảm thiểu, không loại bỏ lỗi hoặc quyền ghi mà kẻ tấn công có thể đã có.
3. Vì lỗi đã được báo cáo là bị khai thác, hãy điều tra các máy chủ có bản cài đặt bị ảnh hưởng trước khi coi chúng là an toàn. Rà soát log Zammad, tính toàn vẹn của tệp cài đặt và các thay đổi đặc quyền trên máy chủ; có thể sử dụng log check script do DIVD công bố.
4. Nếu phát hiện dấu hiệu xâm nhập, xử lý máy chủ theo quy trình ứng phó sự cố của tổ chức, bao gồm đánh giá thông tin xác thực và dữ liệu có thể đã bị lộ. Không có workaround cụ thể nào được DIVD công bố ngoài việc cập nhật hoặc hạn chế truy cập máy chủ.

1. Kiểm kê các hệ thống Zammad và xác định nguồn cài đặt là gói DEB/RPM, mã nguồn hay container image chính thức. Chỉ các bản cài đặt từ DEB/RPM thuộc phạm vi ảnh hưởng được mô tả.
2. Kiểm tra phiên bản của mọi bản cài đặt từ DEB/RPM và đối chiếu với ranh giới trong affected_summary.
3. Kiểm tra quyền sở hữu và quyền ghi của thư mục cài đặt, các tệp được dịch vụ thực thi, cùng các tệp cấu hình liên quan. Tìm các tệp mà tài khoản zammad có thể sửa nhưng tiến trình dịch vụ đặc quyền có thể thực thi.
4. Kiểm tra service definition và hành vi tiến trình để xác định liệu dịch vụ có khởi chạy với quyền root rồi hạ xuống zammad hay không, đồng thời xem xét cơ chế tự động khởi động lại.
5. Rà soát log Zammad bằng log check script do DIVD công bố nếu cần điều tra dấu hiệu xâm nhập. Có thể xem các lần khởi động lại bất thường và thay đổi ngoài dự kiến trong tệp cài đặt là tín hiệu cần điều tra, nhưng đây là biện pháp giám sát phòng ngừa chứ không phải IOC đã được xác nhận.
6. Không coi việc không tìm thấy dấu hiệu trong log là bằng chứng hệ thống an toàn.