Một **lỗ hổng zero-day** nghiêm trọng loại zero-click đã được phát hiện trong SDK Android của Zendesk, cho phép kẻ tấn công **chiếm quyền điều khiển** tài khoản hỗ trợ hàng loạt và truy cập vào mọi ticket mà không cần bất kỳ tương tác nào từ người dùng. Lỗ hổng này được phát hiện trong quá trình thực hiện chương trình bug bounty riêng tư, xuất phát từ cơ chế tạo và lưu trữ token yếu kém bên trong ứng dụng di động của Zendesk.

Lỗ Hổng Zendesk Zero-Click: Chiếm Quyền Điều Khiển Toàn Bộ Tài Khoản

Cơ Chế Khai Thác Điểm Yếu Của Token

Client Android của Zendesk tạo ra các **mã token xác thực** bằng cách kết hợp ba yếu tố có thể dự đoán được: **Account ID** của nạn nhân, một **secret hardcoded** tĩnh, và giá trị **SHA-1** của chuỗi kết hợp đó. Cụ thể, ứng dụng sẽ xây dựng một chuỗi theo định dạng COMPANY-<AccountID>-<Secret>, áp dụng SHA-1 cho chuỗi này, sau đó thêm tiền tố là Account ID vào kết quả để tạo thành một mã token kiểu JWT.

Vì các Account ID thường có tính tuần tự và secret được nhúng trực tiếp vào mã nhị phân của ứng dụng, kẻ tấn công hoàn toàn có thể thực hiện **brute-force** để tìm ra các mã token hợp lệ cho bất kỳ người dùng nào. Một khi mã token được tạo, chúng sẽ được gửi qua một yêu cầu **POST** đơn giản tới điểm cuối /access/sdk/jwt để nhận lại một mã truy cập (access token). Mã truy cập này cấp quyền truy cập API không hạn chế, mở ra cánh cửa cho việc khai thác tiếp theo.

Quá Trình Phát Hiện Lỗ Hổng

Các nhà nghiên cứu đã sử dụng kết hợp các kỹ thuật **phân tích tĩnh** và **phân tích động** để khám phá lỗ hổng. Bằng cách sử dụng **JADX** để đảo ngược mã nguồn (reverse-engineer) của SDK, họ đã xác định được các phương thức quan trọng: ZendeskHelper.g(), có chức năng xây dựng và lưu trữ mã token định danh, cùng với các API lưu trữ liên quan trong ZendeskIdentityStorage và ZendeskIdentityManager.

Kiểm thử thời gian chạy thông qua các hook bằng **Frida** đã xác nhận rằng secret không bao giờ được xoay vòng hoặc dành riêng cho thiết bị. Hơn nữa, danh tính người dùng vẫn được duy trì qua các phiên làm việc cho đến khi bộ nhớ đệm của ứng dụng bị xóa một cách rõ ràng. Việc kiểm thử động cũng bao gồm việc chặn lưu lượng mạng bằng **Burp Suite** sau khi bỏ qua **SSL pinning** với một script Frida. Yêu cầu POST bị chặn chỉ bao gồm mã token người dùng và trả về một mã truy cập có thể tái sử dụng. Không có giới hạn tốc độ (rate limits) hoặc hạn chế sử dụng một lần nào được áp dụng, cho phép làm mới token không giới hạn. Chi tiết về khám phá này có thể tham khảo tại nguồn thông tin đáng tin cậy.

Tác Động và Kịch Bản Tấn Công

Khai Thác Tự Động và Không Yêu Cầu Tương Tác Người Dùng

Bằng cách viết script quy trình bằng **Python**, các nhà nghiên cứu đã tự động hóa việc tạo token, truy xuất mã truy cập và liệt kê các ticket. Một vòng lặp đơn giản trên các Account ID có thể xâm phạm hàng trăm nghìn tài khoản cùng lúc. Hoạt động khai thác này không yêu cầu bất kỳ hành động nào từ người dùng – không phishing, không kỹ thuật xã hội – biến nó thành một cuộc tấn công **zero-click compromise** thực sự, làm tăng mức độ nghiêm trọng của **lỗ hổng zero-day** này.

Rủi Ro Chiếm Đoạt Dữ Liệu và Quyền Hạn

Khai thác thành công cấp quyền **đọc và ghi** đối với tất cả các ticket hỗ trợ của bất kỳ người dùng mục tiêu nào. Kẻ tấn công có thể **rò rỉ dữ liệu nhạy cảm** từ các yêu cầu của khách hàng, chèn các ticket giả mạo, hoặc **leo thang đặc quyền** trong hệ sinh thái hỗ trợ của Zendesk. Tác động này đặc biệt nghiêm trọng vì nó có thể dẫn đến việc đánh cắp thông tin cá nhân khách hàng, gian lận, và làm suy yếu lòng tin vào dịch vụ hỗ trợ.

Bài Học Về Bảo Mật SDK Di Động

Tầm Quan Trọng Của Quản Lý Token Mạnh Mẽ

Lỗ hổng zero-click này nhấn mạnh tầm quan trọng cốt lõi của việc tạo và quản lý token mạnh mẽ trong các **SDK di động**. Ngay cả những nền tảng được tin cậy rộng rãi như Zendesk cũng có thể mắc phải các lỗi có tác động cao khi sử dụng các giá trị có thể dự đoán và secret tĩnh. Đây là một rủi ro bảo mật đáng kể mà các nhà phát triển cần phải đặc biệt lưu ý.

Các Biện Pháp Phòng Ngừa và Thực Tiễn Tốt Nhất

Các nhóm bảo mật phải **kiểm toán chặt chẽ các thư viện bên thứ ba** và thực thi các thực tiễn tốt nhất để phòng chống các cuộc **chiếm quyền điều khiển** tài khoản thầm lặng nhưng tàn khốc. Các biện pháp này bao gồm:

• **Xoay vòng secret** thường xuyên thay vì sử dụng secret tĩnh.
• Sử dụng cơ chế **lưu trữ dựa trên phần cứng** (hardware-backed storage) để bảo vệ các secret nhạy cảm.
• Áp dụng **giới hạn tốc độ xác thực** (rate-limiting authentication flows) để ngăn chặn các cuộc tấn công brute-force.

Việc triển khai các biện pháp này không chỉ giúp giảm thiểu rủi ro từ các **lỗ hổng zero-day** tương tự mà còn tăng cường tổng thể **bảo mật thông tin** cho ứng dụng di động và người dùng.