Có thể tin vào popup quyền trên macOS không?

• CVE-2025-31250 là lỗ hổng khiến khó có thể tin tưởng popup xin quyền TCC trên macOS, vì có thể làm cho ứng dụng hiển thị trên màn hình khác với ứng dụng thực sự nhận quyền
• Vấn đề nằm ở cách tccd xử lý TCCAccessRequestIndirect; target_path được dùng cho tên ứng dụng hiển thị trên popup, còn target_identifier được dùng cho định danh của ứng dụng thực sự nhận quyền
• Không cần ứng dụng giả, lối tắt Dock hay dụ người dùng nhấp như các cách vượt qua trước đây; nếu người dùng nhấn Allow trên popup bị giả mạo thì cuộc tấn công có thể thành công
• Apple đã vá trong macOS Sequoia 15.5, nhưng Ventura 13.7.6 và Sonoma 14.7.6 phát hành cùng ngày thì không được vá, đồng thời cũng xác nhận không có kế hoạch vá cho các phiên bản cũ hơn
• Kẻ tấn công có thể nhắm vào thời điểm các ứng dụng như FaceTime, Voice Memos hoặc System Settings được mở để thử giả mạo popup quyền, khiến người dùng có nguy cơ hiểu nhầm ứng dụng thực sự được cấp quyền

---

Cơ chế cốt lõi của CVE-2025-31250

• CVE-2025-31250 là lỗ hổng cho phép làm khác nhau giữa ứng dụng được hiển thị trong popup quyền TCC của macOS và ứng dụng thực sự nhận quyền
• Trước khi có bản vá, có thể tạo ra cấu hình như sau
  • Application A yêu cầu macOS hiển thị popup xin quyền
  • Popup trông như thể đến từ Application B
  • Kết quả đồng ý của người dùng lại được áp dụng cho Application C
• Ba ứng dụng này có thể hoàn toàn khác nhau; trong cách dùng bình thường, nhiều khả năng chúng sẽ là cùng một ứng dụng
• Vấn đề cốt lõi là dù ứng dụng hiển thị trên popup và ứng dụng thực sự nhận quyền khác nhau, việc kiểm tra vẫn không đủ chặt chẽ

Phạm vi áp dụng bản vá và thông tin đính chính

• Khác với mô tả ban đầu, bản vá chỉ được áp dụng cho macOS Sequoia 15.5
• macOS Ventura 13.7.6 và macOS Sonoma 14.7.6 phát hành cùng ngày không được vá
• Khi biên dịch và chạy PoC trên máy ảo Sonoma 14.7.6, lỗ hổng vẫn còn hoạt động
• Apple Product Security đã đổi trạng thái báo cáo thành “We’ve addressed the issue in all planned releases.”, sau đó xác nhận Ventura và Sonoma không có kế hoạch vá lỗ hổng này
• Kết quả là Ventura và Sonoma vẫn ở trạng thái dễ bị ảnh hưởng bởi lỗ hổng này

Điểm giao giữa TCC và Apple Events

• TCC là hệ thống quyền cốt lõi của các hệ điều hành Apple, hoạt động nội bộ thông qua daemon tccd và framework private TCC
• Nhà phát triển không gọi trực tiếp private API, nhưng public API sẽ gọi nội bộ các chức năng TCC khi cần
• tccd nhận thông điệp bằng XPC API của Apple
• Trước bản vá, ứng dụng có thể gửi thông điệp XPC tới tccd có thể gửi thông điệp bị thao túng để tách ứng dụng hiển thị trên popup quyền khỏi ứng dụng thực sự nhận quyền

Apple Events và mô hình dữ liệu TCC

• Apple Events là cơ chế giao tiếp giữa các tiến trình trên macOS, hiện chủ yếu được dùng cho mục đích tự động hóa
• Tự động hóa Apple Events có thể được script hóa thông qua Open Scripting Architecture của Apple
  • Ngôn ngữ tiêu biểu là AppleScript
  • JavaScript cũng có thể sử dụng
• Từ macOS Mojave 10.14, ứng dụng muốn gửi Apple Events phải có sự đồng ý của người dùng thông qua TCC
• Kết quả đồng ý của người dùng trong TCC được lưu trong cơ sở dữ liệu SQLite Application Support/com.apple.TCC/TCC.db dưới thư mục home của người dùng
• Một bản ghi TCC thông thường gồm ứng dụng yêu cầu, dịch vụ được yêu cầu và kết quả đồng ý của người dùng
• Vì Apple Events cần giới hạn quyền theo từng ứng dụng nhận, nó sử dụng cột indirect object
  • Cột này chứa định danh của ứng dụng sẽ nhận Apple Events
  • Ngoài Apple Events, dịch vụ FileProviderDomain cũng dùng cột này

Cấu trúc thông điệp XPC dễ bị tấn công

• Vấn đề nằm ở lỗi logic trong hàm TCCAccessRequestIndirect
• Hàm này xử lý các yêu cầu truy cập cần dùng cột indirect object trong TCC.db
• Điểm mấu chốt của PoC là khi target_prompt bằng 2, hai trường có thể được đưa vào tách rời
  • target_path: dùng để lấy tên ứng dụng hiển thị trên popup quyền GUI
  • target_identifier: dùng làm bundle ID của ứng dụng thực sự nhận quyền và được ghi vào cơ sở dữ liệu
• Dù là hàm dành cho indirect object, TCCAccessRequestIndirect vẫn có thể được dùng cho nhiều dịch vụ TCC không dùng cột đó bằng cách truyền chuỗi rỗng làm indirect object
• Lỗi này không tồn tại trong các hàm yêu cầu truy cập khác

Điều kiện và giới hạn khi khai thác

• Khai thác lỗ hổng chỉ thành công nếu người dùng nhấn Allow trên popup quyền
• Các dịch vụ TCC có thể dùng bị giới hạn, nhưng vẫn bao gồm những dịch vụ quan trọng như Microphone và Camera
• Cũng có thể giả mạo popup xin quyền truy cập một số thư mục nhất định, nhưng mức hữu dụng thấp hơn do có thêm các lớp bảo mật quanh tệp
• Cũng có thể khiến quyền được áp dụng cho ứng dụng khác thay vì chính ứng dụng độc hại
  • Đây là hướng có thể dùng khi kẻ tấn công kiểm soát được ứng dụng khác nhưng ứng dụng đó lại cần quyền TCC

Đánh lừa bằng cách canh thời điểm popup

• Nếu popup quyền xuất hiện ngẫu nhiên, người dùng có thể nghi ngờ và nhấn Don’t Allow
• Ứng dụng macOS có thể kiểm tra danh sách ứng dụng đang chạy và ứng dụng hiện ở foreground
  • Kiểm tra ứng dụng đang chạy: NSWorkspace runningApplications
  • Kiểm tra ứng dụng ở foreground: NSWorkspace frontmostApplication
• Ứng dụng độc hại có thể đợi đến khi một ứng dụng cụ thể được chạy hoặc trở thành ứng dụng foreground, rồi hiển thị popup quyền giả mạo bằng tên của ứng dụng đó
• Ví dụ, khi FaceTime khởi chạy có thể giả mạo popup quyền Camera, còn khi Voice Memos khởi chạy có thể giả mạo popup quyền Microphone
• Người dùng có thể hiểu nhầm popup xuất hiện ngay sau khi mở hoặc chuyển ứng dụng là yêu cầu quyền hợp lệ từ chính ứng dụng đó

Liên hệ với các đường vòng bypass TCC trước đây

• Trước đây, tccd xác định thư mục home của người dùng theo biến môi trường HOME, nên có thể bypass TCC bằng cách cài thư mục home giả và TCC.db giả
• Vấn đề này đã được vá trong bản cập nhật giữa tháng 7/2020, sau đó tccd tra cứu thư mục home từ user information directory của hệ điều hành
• Sau đó vẫn có những trường hợp bypass bằng cách lợi dụng thay đổi thư mục home của người dùng
  • Wojciech Reguła đã công bố CVE-2020-27937, khai thác hệ thống plugin của trình chỉnh sửa GUI user information directory trên macOS
  • Nhóm Microsoft Threat Intelligence công bố bypass powerdir dùng lệnh import/export
• Để thay đổi thư mục home của người dùng, thông thường cần hai điều kiện
  • quyền root
  • sự đồng ý của người dùng đối với một số dịch vụ TCC nhất định
• CVE-2025-31250 không vượt qua được yêu cầu quyền root, nhưng có thể dụ người dùng cấp đồng ý TCC cần thiết bằng popup giả mạo
• Nếu ứng dụng độc hại lừa được người dùng đồng ý và còn giành được cả đặc quyền leo thang lên root, thì có thể đi theo hướng thay đổi user information directory và cài TCC.db giả
• REG.db theo dõi các TCC.db hợp lệ, nhưng trong TCC có hàm cho phép ứng dụng thêm mục vào REG.db, nhờ đó có thể thêm đường dẫn của TCC.db đã cài sẵn

Giới hạn của quản lý quyền nhìn từ phía người dùng

• TCC là hệ thống hoạt động phía sau bảng Privacy & Security trong System Settings
• Kết quả đồng ý liên quan đến Apple Events được hiển thị trong mục Automation
• Trong bảng Privacy & Security, người dùng có thể xem các quyền đã cấp và trong nhiều trường hợp có thể thu hồi từng quyền cụ thể
• Tuy nhiên, nếu kẻ tấn công lừa người dùng cho phép quyền Apple Events, kết quả đồng ý đó lại không xuất hiện trong System Settings
• Người dùng có thể thu hồi đồng ý bằng công cụ CLI tccutil, nhưng công cụ này ít tài liệu và hầu hết người dùng khó biết đến
  • Tài liệu của Apple gồm Technical Q&A cũ và IT training page

Endpoint Security và khả năng phát hiện

• Framework Endpoint Security của Apple gần đây đã bắt đầu hỗ trợ giám sát các thay đổi trong cơ sở dữ liệu TCC
• Bài viết của Objective-See có đề cập tới thay đổi này: Endpoint Security TCC database monitoring
• Nếu chức năng này hoạt động đúng như kỳ vọng, các ứng dụng dùng framework đó có thể thông báo hậu kiểm cho người dùng biết thực sự quyền đã được cấp cho ứng dụng nào
• Tuy nhiên, khả năng phát hiện này chỉ có ý nghĩa trực tiếp trong khoảng thời gian ngắn giữa lúc Apple thêm sự kiện Endpoint Security và lúc lỗ hổng được vá

Cách Apple sửa lỗi

• Kết quả phân tích binary tccd của macOS Sequoia 15.5 cho thấy bản vá cuối cùng phức tạp hơn nhận định ban đầu
• Sau bản vá, không còn có thể giả mạo popup TCC theo cùng cách đó
• Có vẻ hành vi dùng TCCAccessRequestIndirect cho các dịch vụ TCC khác bằng cách truyền chuỗi rỗng vào indirect object cũng đã bị hạn chế
• Quan sát cho thấy các thông điệp ở dạng dễ bị tấn công giờ sẽ bị tccd âm thầm loại bỏ và không thực hiện hành động nào
• Qua kiểm tra đơn giản, đây có vẻ là một bản vá tốt, nhưng cần phân tích thêm để hiểu đầy đủ toàn bộ hành vi

Diễn biến từ lúc báo cáo đến khi vá

• Đây là lỗi thứ hai được báo cáo cho Apple, đồng thời là trường hợp mất nhiều thời gian nhất để được vá trong số các báo cáo mà Apple đã xử lý
• Quá trình báo cáo bao gồm thông báo ban đầu, yêu cầu giải thích thêm từ Apple Product Security, chia sẻ con đường bypass TCC tiềm năng ở mức toàn phần, cập nhật thử nghiệm PoC, xác nhận khả năng tái hiện và nhiều lần hỏi tiến độ
• Bản vá đơn giản được đề xuất là kiểm tra hai trường có cùng trỏ tới một ứng dụng hay không
• Apple nhiều lần phản hồi rằng họ đang điều tra, sau đó hỏi tên để ghi credit rồi phát hành bản vá
• Lỗ hổng được đặt tên là “TCC, Who?”