Help desk là một trong những hộp thư đáng tin cậy nhất mà một tổ chức vận hành. Khách hàng dán thông tin tài khoản, nhật ký lỗi, tên, và đôi khi cả tài liệu, với giả định rằng dữ liệu nằm an toàn phía sau nền tảng. Một chuỗi zero-day thực thi mã từ xa trên Zammad được báo cáo, đã bị sử dụng để tấn công Viện Tiết lộ Lỗ hổng Hà Lan (DIVD), là lời nhắc nhở rằng sự tin cậy này phụ thuộc hoàn toàn vào phần mềm đang lưu giữ các ticket.
Theo báo cáo, hai lỗ hổng zero-day của Zammad cho phép chiếm đoạt phiên, thực thi lệnh từ xa, và khả năng truy cập root trên máy chủ bên dưới. Zammad là một nền tảng ticketing và help desk mã nguồn mở. Chi tiết từ bài viết nguồn còn hạn chế, vì vậy bài viết này chỉ bám sát những gì đã được báo cáo và tránh suy đoán về các chi tiết kỹ thuật.
Cách các zero-day của Zammad được kết nối thành chuỗi
Câu chuyện cốt lõi là về việc kết nối chuỗi. Không nhất thiết mỗi lỗ hổng phải tàn phá khi đứng riêng, nhưng sự kết hợp có thể trở nên nghiêm trọng. Dựa trên báo cáo, điểm yếu đầu tiên cho phép kẻ tấn công chiếm đoạt phiên, nghĩa là chiếm quyền truy cập của một người dùng đã xác thực mà không cần biết mật khẩu của họ. Điểm yếu thứ hai cho phép thực thi lệnh từ xa, cho phép kẻ tấn công chạy lệnh trên máy chủ đang vận hành Zammad. Từ đó, quyền truy cập root được mô tả là kết quả tiềm năng, nghĩa là kẻ tấn công có thể giành toàn quyền kiểm soát máy.
Mô thức này phổ biến trong các vụ xâm nhập nghiêm trọng: một lỗi tạo được chỗ đứng, một lỗi khác biến chỗ đứng đó thành quyền kiểm soát. Điều này cũng giải thích tại sao các chuyên gia phòng thủ được khuyến khích xử lý nghiêm túc các vấn đề mức độ trung bình, vì chúng có thể trở thành mắt xích đầu tiên trong một chuỗi.
Để có tường thuật đầy đủ về cuộc tấn công, bao gồm cách vụ xâm phạm DIVD diễn ra, xem các bài viết trước của chúng tôi: AI Agent Chains Two Zammad Zero-Days to Breach DIVD và DIVD: AI Agent Exploits Two Zammad Zero-Days in Breach.
Help desk bị xâm phạm phơi bày những gì
Một máy chủ help desk lưu giữ nhiều hơn những gì người ta thường nhận ra. Tùy thuộc vào cách một tổ chức sử dụng nó, một phiên bản bị xâm phạm có thể phơi bày:
- Các ticket hỗ trợ và toàn bộ lịch sử hội thoại gắn với chúng
- Tên khách hàng, địa chỉ email, và các chi tiết liên hệ khác
- Tệp đính kèm như ảnh chụp màn hình, nhật ký, hoặc tài liệu mà khách hàng đã tải lên
- Ghi chú nội bộ mà nhân viên viết về khách hàng hoặc sự cố
- Thông tin đăng nhập, token API, hoặc cài đặt tích hợp được lưu trên máy chủ
Quyền truy cập root càng làm tăng mức độ nghiêm trọng. Kẻ tấn công kiểm soát máy chủ không chỉ giới hạn ở dữ liệu của ứng dụng. Chúng có thể truy cập các dịch vụ khác trên cùng máy, đọc tệp cấu hình, và sử dụng máy chủ làm bàn đạp đến nơi khác trong mạng. Đó là lý do tại sao một vụ xâm phạm help desk có thể trở thành sự cố rộng hơn thay vì bị cô lập.
Trường hợp DIVD cũng đáng chú ý vì bản thân DIVD là một tổ chức bảo mật giúp báo cáo và sửa chữa lỗ hổng. Nếu một nhóm tập trung vào công việc này có thể bị ảnh hưởng, thì bất kỳ tổ chức nào đang vận hành các công cụ tự lưu trữ nên giả định rằng mình là mục tiêu tiềm năng. Bài viết của chúng tôi về chuỗi zero-day Zammad đã tạo điều kiện cho vụ xâm phạm do AI dẫn dắt đề cập đến bối cảnh đó.
Quản trị viên Zammad nên làm gì ngay bây giờ
Nếu bạn đang vận hành Zammad, hãy coi đây là một cuộc rà soát ưu tiên thay vì một nhiệm vụ thường lệ.
- Kiểm tra các bản vá chính thức. Theo dõi các khuyến cáo bảo mật của dự án Zammad và áp dụng mọi bản vá hoặc cập nhật ngay khi có sẵn. Không dựa vào các bản tóm tắt của bên thứ ba để biết chi tiết phiên bản.
- Hạn chế phơi bày. Nếu phiên bản của bạn không cần phải truy cập được từ internet mở, hãy hạn chế truy cập bằng VPN, danh sách IP cho phép, hoặc quy tắc reverse proxy cho đến khi bạn đã vá.
- Vô hiệu hóa phiên. Vì chiếm đoạt phiên là một phần của chuỗi được báo cáo, hãy cân nhắc buộc đăng xuất và xoay vòng bí mật phiên sau khi cập nhật.
- Xoay vòng thông tin đăng nhập. Thay đổi mật khẩu quản trị, token API, và mọi bí mật được lưu trên máy chủ, đặc biệt nếu bạn nghi ngờ bị xâm phạm.
- Xem xét nhật ký. Tìm kiếm các đăng nhập quản trị bất thường, lệnh không mong đợi, tài khoản mới, hoặc kết nối ra ngoài kỳ lạ.
- Chạy với đặc quyền tối thiểu. Đảm bảo ứng dụng không chạy với quyền hệ thống nhiều hơn mức cần thiết, và giữ bản sao lưu được lưu trữ tách khỏi máy chủ.
Khách hàng có thể làm gì để hạn chế phơi bày
Điều Này Có Ý Nghĩa Gì Với Bạn
Hầu hết mọi người không thể vá phần mềm help desk mà các tổ chức sử dụng, nhưng bạn có thể giảm những gì bị đe dọa nếu một hệ thống bị xâm phạm.
- Chia sẻ ít hơn trong ticket. Tránh gửi mật khẩu, số ID đầy đủ, chi tiết thanh toán, hoặc tài liệu nhạy cảm qua ticket hỗ trợ. Nếu một yêu cầu thực sự cần chúng, hãy hỏi xem có kênh an toàn hơn không.
- Che thông tin trước khi đính kèm. Làm mờ hoặc xóa chi tiết cá nhân khỏi ảnh chụp màn hình và nhật ký.
- Sử dụng mật khẩu duy nhất. Nếu một nền tảng hỗ trợ từng lưu giữ thông tin đăng nhập bạn đã gửi, một mật khẩu duy nhất sẽ hạn chế thiệt hại.
- Chú ý thông báo vi phạm. Đọc email từ các dịch vụ bạn sử dụng về sự cố bảo mật, và cẩn thận với các tin nhắn tiếp theo yêu cầu bạn nhấp vào liên kết hoặc xác nhận chi tiết.
- Đề phòng lừa đảo. Chi tiết liên hệ và ngữ cảnh ticket có thể khiến tin nhắn lừa đảo trông thuyết phục. Xác minh qua trang web chính thức của tổ chức.
Kết luận
Chuỗi zero-day thực thi mã từ xa trên Zammad được báo cáo cho thấy một nền tảng help desk duy nhất có thể biến thành cửa ngõ dẫn đến dữ liệu khách hàng và quyền kiểm soát máy chủ như thế nào. Quản trị viên nên vá, hạn chế truy cập, và xoay vòng bí mật. Mọi người khác có thể gửi ít thông tin nhạy cảm hơn qua ticket và luôn cảnh giác với thông báo vi phạm. Để có tường thuật đầy đủ về cách cuộc tấn công DIVD diễn ra, hãy đọc các bài viết hiện có của chúng tôi được liên kết ở trên.
