AuthMask là tên nghiên cứu mô tả một lỗ hổng trong Microsoft Authenticator cho Android, nơi ứng dụng độc hại không cần khai báo quyền vẫn có thể mạo danh Teams hoặc một ứng dụng Microsoft khác để yêu cầu token tài khoản công việc. Microsoft theo dõi lỗi này với mã CVE-2026-80097, chấm 8,6/10 điểm CVSS và đã sửa trong Authenticator 6.2606.4246. Vụ việc cho thấy ứng dụng xác thực không chỉ lưu mã OTP: khi hoạt động như một broker đăng nhập, nó còn nắm quyền cấp “vé thông hành” tới email, tệp, lịch và các tài nguyên doanh nghiệp.
Authenticator đóng vai trò broker như thế nào?
Trên Android, Microsoft Authenticator có thể làm môi giới danh tính cho các ứng dụng như Teams hoặc Outlook. Thay vì từng ứng dụng tự xử lý toàn bộ phiên đăng nhập, ứng dụng gửi yêu cầu tới broker; broker xác minh tài khoản đã đăng nhập rồi trả về access token phù hợp. Token là bằng chứng để dịch vụ Microsoft Graph hoặc một API khác cho phép ứng dụng hành động trong phạm vi đã cấp.
Mô hình này giúp đăng nhập một lần thuận tiện hơn, nhưng cũng đặt Authenticator vào vị trí đặc biệt nhạy cảm. Nếu broker nhầm danh tính ứng dụng gọi, kẻ tấn công không cần phá mật khẩu hay đánh cắp mã OTP. Chúng chỉ cần thuyết phục broker rằng yêu cầu độc hại đến từ một ứng dụng Microsoft hợp lệ.
Điểm yếu nằm ở một Activity được xuất công khai
Nhà nghiên cứu Ofek Levin của chương trình Enclave Fellowship phát hiện Authenticator để lộ activity com.microsoft.identity.client.AccountChooserActivity với thuộc tính android:exported="true". Vì vậy, mọi ứng dụng trên thiết bị đều có thể khởi chạy thành phần này. Điều kiện ban đầu chỉ kiểm tra lời gọi có đi qua cơ chế nhận kết quả của Android hay không, chứ chưa chứng minh ứng dụng gọi là ai.
Nguy hiểm hơn, nhiều trường nhận dạng trong yêu cầu broker lại do chính bên gọi cung cấp: UID, tên gói, client ID, redirect URI và scope. Authenticator biết tên gói thật của ứng dụng gọi thông qua Android, nhưng dữ liệu đó chỉ được dùng cho việc quản lý yêu cầu song song, không tham gia quyết định tin cậy.
Phép kiểm tra chữ ký vì sao vẫn bị qua mặt?
Authenticator có kiểm tra redirect URI dựa trên chữ ký của gói ứng dụng được khai báo. Bề ngoài đây là một hàng rào hợp lý: redirect URI phải khớp với giá trị được tạo từ tên gói và chữ ký số. Tuy nhiên, phần mềm lại kiểm tra ứng dụng mà kẻ tấn công tự nhận, thay vì đối chiếu với ứng dụng thực sự gửi lời gọi.
Nếu Teams đã được cài trên thiết bị, ứng dụng độc hại có thể đọc thông tin gói và chữ ký công khai qua PackageManager, tạo đúng redirect URI của Teams rồi đưa giá trị đó vào yêu cầu. Phép kiểm tra xác nhận bộ dữ liệu giả mạo nhất quán với Teams, nhưng không trả lời câu hỏi quan trọng nhất: tiến trình đang yêu cầu token có thực sự là Teams hay không. Microsoft phân loại nguyên nhân theo CWE-287, tức xác thực không đúng cách.
Chuỗi khai thác AuthMask diễn ra ra sao?
Trong thử nghiệm, ứng dụng không khai báo bất kỳ quyền Android nào vẫn có thể khởi chạy activity, tự nhận là Teams, cung cấp client ID và redirect URI hợp lệ, rồi yêu cầu token Microsoft Graph. Kết quả xác thực được trả thẳng về ứng dụng đã mở activity. Gói phản hồi chứa access token, refresh token, ID token và thông tin client ở dạng mà ứng dụng gọi có thể đọc.
Chuỗi tấn công đòi hỏi thiết bị đã cài Authenticator và có một tài khoản công việc đăng nhập. Kẻ tấn công cũng phải đưa được ứng dụng độc hại lên thiết bị. Tuy nhiên, bản thân ứng dụng không cần xin quyền nhạy cảm, giúp giảm dấu hiệu cảnh báo trong lúc cài đặt. Báo cáo gốc cho biết quá trình lấy token trong thử nghiệm không cần thêm tương tác từ người dùng.
Token bị lấy có thể mở những quyền nào?
Khi mạo danh Teams và yêu cầu Microsoft Graph, nhóm nghiên cứu nhận được các phạm vi ủy quyền cho phép đọc, gửi thư; đọc, sửa tệp, lịch và site SharePoint; cũng như gửi tin nhắn Teams. Khi mạo danh backend trò chuyện của Teams, họ nhận scope user_impersonation. Khi tự nhận là client của Authenticator, ứng dụng thử nghiệm còn nhận quyền liên quan đến phương thức đăng nhập, gồm tạo hoặc xóa passkey.
Phạm vi thực tế phụ thuộc ứng dụng bị mạo danh, cấu hình tenant, sự đồng ý đã tồn tại và chính sách truy cập. Vì vậy, không nên hiểu CVE này là mọi thiết bị đều tự động trao toàn bộ dữ liệu Microsoft 365. Điểm đã được chứng minh là ranh giới tin cậy của broker bị phá vỡ, cho phép một ứng dụng cục bộ yêu cầu token dưới danh tính của ứng dụng khác.
Mốc công bố và phạm vi ảnh hưởng
Enclave báo cáo lỗ hổng cho Microsoft theo quy trình tiết lộ có trách nhiệm. Microsoft xác nhận, phát hành bản sửa và công bố CVE-2026-80097 ngày 8/9/2026. Báo cáo kỹ thuật AuthMask được Enclave phát hành ngày 23/10, sau khi bản vá đã sẵn sàng, giúp quản trị viên có thời gian cập nhật trước khi chi tiết khai thác được phổ biến.
Theo Enclave và Microsoft, các phiên bản Microsoft Authenticator cho Android trước 6.2606.4246 bị ảnh hưởng. Lỗ hổng được đánh giá mức High với CVSS 8,6. Nghiên cứu không nói rằng Authenticator trên iOS chịu cùng chuỗi lỗi, do cơ chế activity, package và broker được phân tích là đặc thù của ứng dụng Android.
Người dùng và tổ chức cần làm gì?
Người dùng nên mở thông tin ứng dụng hoặc Google Play để xác nhận Microsoft Authenticator đạt phiên bản 6.2606.4246 trở lên. Đồng thời, chỉ cài ứng dụng từ nguồn đáng tin cậy, hạn chế sideload và gỡ phần mềm không còn sử dụng. Việc một ứng dụng không yêu cầu quyền không đồng nghĩa nó vô hại, bởi AuthMask khai thác giao diện liên ứng dụng thay vì camera, danh bạ hay bộ nhớ.
Doanh nghiệp nên dùng MDM hoặc nền tảng quản lý thiết bị để đặt phiên bản tối thiểu, kiểm kê thiết bị chưa cập nhật và chặn truy cập từ thiết bị không tuân thủ. Nếu nghi ngờ đã cài ứng dụng độc hại khi còn dùng phiên bản dễ tổn thương, quản trị viên cần thu hồi phiên đăng nhập, rà soát nhật ký Entra ID và Microsoft 365, kiểm tra thay đổi phương thức xác thực, passkey, quy tắc hộp thư và hoạt động truy cập tệp bất thường.
Bài học thiết kế từ CVE-2026-80097
AuthMask là ví dụ điển hình của lỗi “nhầm đại diện”: hệ thống có đủ thông tin để biết bên gọi thật, nhưng lại ra quyết định dựa trên danh tính do bên gọi khai báo. Với thành phần broker, mọi trường nhận dạng từ intent hoặc IPC phải được xem là không đáng tin cho tới khi được gắn với UID và chữ ký của tiến trình gọi bằng dữ liệu do hệ điều hành cung cấp.
Bài học rộng hơn là mô hình quyền của Android không bao quát toàn bộ bề mặt tấn công. Một ứng dụng có thể mang nhãn “không yêu cầu quyền” nhưng vẫn tiếp cận component được xuất công khai của ứng dụng khác. Các nhà phát triển cần giảm số component exported, yêu cầu permission ở cấp chữ ký khi phù hợp, xác thực caller thực và kiểm thử các luồng IPC bằng dữ liệu giả mạo. Với tổ chức, quản lý phiên bản ứng dụng xác thực phải được xem là một phần của kiểm soát danh tính, không chỉ là công việc cập nhật ứng dụng di động thông thường.
VNCyberS tổng hợp từ Enclave, Microsoft và Help Net Security
Tiếng Việt
English