- Hệ thống quyền TCC của macOS từng có lỗ hổng khiến người dùng thấy popup yêu cầu quyền bị hiển thị sai lệch
- Lỗ hổng này được đăng ký là CVE-2025-31250, trong đó sự đồng ý của người dùng lại được áp dụng cho một ứng dụng khác
- Có khả năng xảy ra tấn công giả mạo khi ứng dụng độc hại hiển thị cửa sổ yêu cầu quyền dưới tên của một ứng dụng đáng tin để dụ người dùng chấp thuận
- Đã được vá trong Apple macOS Sequoia 15.5, nhưng các phiên bản khác vẫn chưa được vá
- Ngoài khó khăn trong việc kiểm tra và thu hồi lịch sử cấp quyền, vẫn có khả năng các lỗ hổng tương tự sẽ tiếp tục xuất hiện trong tương lai
Đính chính quan trọng
- Lỗ hổng này đã được vá trong macOS Sequoia 15.5, nhưng macOS Ventura 13.7.6 và macOS Sonoma 14.7.6 vẫn chưa được vá
- Đã xác nhận rằng ghi chú phát hành bảo mật của Apple không nhắc đến người báo cáo
- Đã trực tiếp thử nghiệm macOS Sonoma 14.7.6 trên máy ảo và xác minh rằng lỗ hổng vẫn có thể bị khai thác
- Suy đoán rằng Ventura 13.7.6 cũng ở trong tình trạng tương tự
- Đang chờ phản hồi chính thức từ phía Apple
Giới thiệu
- Lỗ hổng CVE-2025-31250 cho phép ứng dụng hiển thị popup yêu cầu quyền giả trên macOS
- Khi "Application A" tạo popup, popup có thể hiển thị là "Application B", trong khi sự đồng ý quyền của người dùng thực tế lại được áp dụng cho "Application C"
- Thông thường ba ứng dụng này là một, nhưng do lỗ hổng này nên có thể chỉ định chúng thành các ứng dụng khác nhau
- Điều này tạo ra vấn đề nghiêm trọng với độ tin cậy của cửa sổ yêu cầu quyền
- Trước đây cũng từng có các cách "spoofing" tương tự được giới thiệu trên HackTricks và nơi khác, nhưng lỗ hổng này dùng cách đơn giản hơn
TCC
- TCC là hệ thống quản lý quyền cốt lõi được tích hợp trong các hệ điều hành Apple
- Quyền được quản lý bằng cách gửi thông điệp tới daemon "tccd", còn public API sẽ gọi các hàm trong framework TCC riêng tư
- Daemon này dùng XPC API của Apple để giao tiếp thông điệp
- Trước khi lỗ hổng được vá, nếu gửi thông điệp tùy ý thì có thể chỉ định khác nhau giữa ứng dụng hiển thị popup yêu cầu quyền và ứng dụng thực sự nhận được quyền
- Để hiểu vì sao lỗ hổng này xuất hiện, cần tìm hiểu về Apple Events
Apple Events
Apple Events là gì
- Apple Events là cơ chế giao tiếp liên tiến trình giữa các ứng dụng trên macOS
- Đây là giao thức đã tồn tại từ thời những cuốn sách kinh điển xuất bản năm 1993
- Sau khi macOS X ra mắt, nó vẫn được thiết kế lại để phù hợp với kiến trúc mới và tiếp tục được sử dụng
- Ngày nay nó chủ yếu được dùng cho tự động hóa (Automation), thông qua script bằng AppleScript và JavaScript
- Nó tương tự Script Host trên Windows và cũng từng bị lạm dụng làm vector cho mã độc
Apple Events và TCC
- Từ macOS Mojave 10.14, việc gửi Apple Events bắt buộc phải có sự đồng ý của người dùng
- Trong cơ sở dữ liệu lưu quyền của TCC (TCC.db), sẽ ghi lại ứng dụng yêu cầu, dịch vụ và phản hồi chấp thuận
- Vì Apple Events cần quản lý quyền theo từng ứng dụng nhận riêng lẻ, nên cột indirect object trong TCC.db được sử dụng
- Hàm TCCAccessRequestIndirect của daemon TCC xử lý các thông điệp dùng cột này
- Có một lỗi logic trong hàm đó, khiến ứng dụng hiển thị cho người dùng và ứng dụng thực sự nhận quyền có thể bị chỉ định khác nhau
Bằng chứng khái niệm (Proof-of-Concept)
- Ví dụ mã Swift thao tác thông điệp yêu cầu quyền như sau
- Tên ứng dụng ở đường dẫn "spoofedBundle" sẽ được hiển thị trong popup xin phép người dùng
- Bundle ID của "actualBundle" sẽ được chỉ định là đối tượng thực sự nhận quyền
- Kết quả là người dùng tưởng một ứng dụng đáng tin đang yêu cầu quyền, nhưng quyền thực tế lại được cấp cho ứng dụng độc hại
- Ngay cả khi để trống giá trị "indirect_object", vẫn có thể nhắm đến nhiều dịch vụ TCC
- Điều này dẫn đến sự sụp đổ về độ tin cậy của việc người dùng chấp thuận quyền
- Kẻ tấn công có thể lừa người dùng để một ứng dụng tùy ý giành được quyền
Khai thác lỗ hổng
Giới hạn và điểm đáng chú ý
- Chỉ một số dịch vụ TCC cụ thể dễ bị tấn công, nhưng các dịch vụ quan trọng như Microphone và Camera nằm trong phạm vi bị ảnh hưởng
- Với các quyền tệp/thư mục, do có thêm lớp bảo vệ nên tác động không quá lớn
- Có thể kết hợp với kỹ thuật xã hội để khiến người dùng chấp thuận thay cho một ứng dụng khác thực sự cần quyền
Tầm quan trọng của thời điểm
- Thời điểm hiển thị popup là yếu tố quan trọng
- Ứng dụng độc hại có thể phát hiện ứng dụng nào đang chạy và ứng dụng nào đang ở tiền cảnh, rồi hiển thị popup vào đúng lúc để khiến người dùng nhầm lẫn
- Ví dụ, khi FaceTime đang chạy, nếu hiện popup xin quyền Camera thì người dùng có thể tưởng đó là yêu cầu hợp lệ
- Một kịch bản khác là giả mạo yêu cầu quyền Microphone khi Voice Memos đang chạy
- Nếu nhắm vào thời điểm phù hợp với ngữ cảnh, tỷ lệ thành công sẽ cao hơn
Nhìn lại các lỗ hổng trước đây
- Từng tồn tại các lỗ hổng lợi dụng việc đường dẫn của TCC.db được quyết định theo thư mục home của người dùng
- Cho đến năm 2020, chỉ cần đổi biến môi trường
HOME là có thể dùng TCC.db giả ($HOMERun)
- Sau khi được vá, dù vẫn cần quyền root và sự đồng ý của người dùng, nhưng nếu kết hợp với giả mạo bằng kỹ thuật xã hội thì vẫn có thể vượt qua kiểm soát quyền
- Ứng dụng độc hại có thể dụ người dùng chấp thuận, sau đó đổi thư mục home và thêm cơ sở dữ liệu đăng ký để né qua TCC.db giả
- Đã xác nhận bằng thử nghiệm thực tế rằng cách này có thể ảnh hưởng đến cách TCC hoạt động
Dòng thời gian
1.
- 2024-05-02: Gửi báo cáo ban đầu và thông điệp bổ sung tới Apple Product Security
2.
- 2024-05-03: Apple Product Security yêu cầu giải thích thêm và đã phản hồi
- Cùng ngày, phát hiện khả năng vượt qua toàn bộ TCC và báo cáo lại cho Apple
3.
- 2024-05-04: Tiếp tục thử nghiệm PoC và để lại thêm thông tin cập nhật
4.
- 2024-05-06: Apple Product Security gửi lời cảm ơn vì đã cung cấp thông tin
5.
- Sau đó vẫn liên tục hỏi về tình trạng vá và xác nhận trạng thái; từ 2024-06 đến 2025-02 vẫn trao đổi thường xuyên với Apple nhưng lỗi không được sửa trong thời gian dài
6.
- 2025-05-12: Bản vá cho lỗi này được phát hành
Kết luận
Các điểm khác
- TCC được hiển thị trong mục Privacy & Security (trước đây là Security & Privacy) của ứng dụng System Settings, cùng với mục Automation liên quan
- Tuy nhiên, lịch sử chấp thuận liên quan đến Apple Events không hiện trên GUI, nên người dùng rất khó tự hủy
- Có thể hủy bằng công cụ CLI
tccutil, nhưng điều này hầu như ít được biết đến
- Gần đây, framework Apple Endpoint Security đã được bổ sung khả năng giám sát thay đổi cơ sở dữ liệu TCC
- Nếu tính năng này hoạt động đúng như mong đợi, nó có thể giúp cảnh báo cho người dùng ứng dụng nào thực sự đã nhận quyền và góp phần ngăn việc khai thác
Bản vá của Apple
- Nội dung bản vá thực tế khá phức tạp; các thông điệp bên ngoài có indirect object được chỉ định tùy ý giờ đây sẽ bị tccd lặng lẽ bỏ qua
- Kết quả kiểm tra cho thấy việc giả mạo không còn khả thi nữa
- Nếu bản vá chưa hoàn chỉnh, có thể sẽ cần thêm biện pháp trong các bản cập nhật sau
Suy nghĩ cuối cùng
- Lỗ hổng này được đặt tên là "TCC, Who?"
- Từ góc nhìn của nhà nghiên cứu bảo mật, bài viết một lần nữa nhấn mạnh tầm quan trọng của độ tin cậy trong hệ thống quyền
- Nó cũng ngụ ý rằng các lỗ hổng tương tự vẫn có thể tiếp tục được phát hiện trong tương lai
- Người dùng không nên tuyệt đối tin tưởng các popup quyền trên macOS
1 bình luận
Ý kiến Hacker News
Đánh cược vào khả năng rất nhỏ là có ai đó ở Apple sẽ đọc bài này, tôi xin lặp lại điều mình luôn muốn nói—mong Apple ngừng việc thỉnh thoảng lại bật ngẫu nhiên các hộp thoại kiểu “hãy nhập mật khẩu (quản trị viên cục bộ) ngay bây giờ”, chỉ vì máy tính nảy ra ý muốn cập nhật hay cài thứ gì đó. Chỉ cần có chút kiến thức cơ bản là có thể dễ dàng làm một popup giả trông gần như y hệt trên web, và hầu hết người dùng ngoại trừ khoảng 20% rành công nghệ nhất thậm chí còn không nghĩ đến chuyện phân biệt đây là thật hay giả được dựng trong trình duyệt. Muốn chặn tận gốc kiểu vấn đề này thì phải tạo cho người dùng thói quen rằng phần mềm bình thường sẽ không đột ngột hiện hộp thoại yêu cầu mật khẩu giữa chừng mà không báo trước, nhưng UI bảo mật hiện tại của macOS lại hoàn toàn đi ngược điều đó. Nó nên được thay bằng kiểu hiển thị biểu tượng nhiều màu nổi bật trên thanh menu, hoặc như Windows là hiện tạm một màn hình bảo mật riêng. Thiết kế UI hiện tại thực sự có quá nhiều vấn đề
Điều tôi ghét nhất ở các popup kiểu này là hoàn toàn không biết vì sao nó yêu cầu, nếu từ chối thì chuyện gì sẽ xảy ra, và nếu sau này muốn đổi lại cài đặt thì phải làm gì. Cách mà ứng dụng hướng dẫn “hãy mở bảng cài đặt và cấp quyền XXX” cho phép nhìn rõ ứng dụng nào, quyền nào, công tắc nào, còn popup mật khẩu thì không cho trải nghiệm như vậy. Vì thế tôi ngày càng không thích khái niệm “capabilities”, đây gần như là chuyện không tránh khỏi vì UX quá tệ. Nó sẽ thành kiểu “để dùng ứng dụng đầy đủ, hãy cho phép <root my computer>”, mà một khi nhà cung cấp tự viết thông điệp thì kiểu gì cũng sẽ thành như vậy. UX hoàn toàn không giúp ích gì
Nếu macOS vẫn còn hiển thị cửa sổ modal gắn với cửa sổ ứng dụng thì có lẽ hiện tượng này đã bớt hơn. Không giải quyết hoàn toàn nhưng chắc chắn sẽ khá hơn. Khi modal đè lên phía trên thanh công cụ như bây giờ, nhìn vào là thấy cảm giác như nó “ở bên trong ứng dụng”. Ngay từ lúc Steve Jobs demo Aqua cũng đã nhấn mạnh rằng các modal nổi riêng như vậy làm giảm tính dễ dùng, nhưng giờ tôi nghĩ Apple làm thế chỉ vì một sự ám ảnh kỳ lạ muốn dùng UI di động trên mọi màn hình
Người thân không rành kỹ thuật của tôi còn chẳng phân biệt nổi mật khẩu máy cục bộ với mật khẩu iCloud/Apple ID, nên cuối cùng cứ gõ thử tất cả cho đến khi cái nào được thì thôi (mà chuyện này là do UI mơ hồ và thiếu nhất quán). Ngày xưa Apple từng chế giễu UAC của Vista, nhưng giờ chính họ cũng chất đầy những thông báo bật ra bất ngờ và UI cẩu thả
Tôi mới chuyển từ Linux sang Mac gần đây, và các popup mật khẩu root hiện ngẫu nhiên thực sự khiến tôi bối rối. Không hề có giải thích ứng dụng hay lệnh nào đang xin quyền root, cũng không nói vì sao lại cần, nên tôi đã cho phép vài lần rồi chuyển hẳn sang từ chối. Từ sau đó thì không thấy popup nữa. Nhưng đến giờ tôi vẫn hoàn toàn không biết nó từng hiện lên để làm gì, và vì sao giờ lại không hiện nữa
Tôi muốn giới thiệu lại bài kinh điển này một lần nữa: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/
Popup Passkey hoàn toàn không thể phân biệt với popup JavaScript, đây là một sai lầm đặc biệt nghiêm trọng về mặt bảo mật
Trong những tình huống như vậy, cảm biến vân tay tích hợp thực sự rất đáng quý. Bình thường tôi đóng màn hình laptop và chỉ dùng màn hình ngoài, nhưng mỗi khi cần xác thực hệ thống thì cố tình mở máy ra để xác thực bằng vân tay
Cú lật: thật ra ngay từ đầu chẳng hề có hộp thoại nào cả! Bạn đã bị lừa rồi!
Tôi muốn tranh thủ gắn vào bình luận đang được ưa thích nhất lúc này để báo một thông tin—bài viết này có một cập nhật quan trọng: https://news.ycombinator.com/item?id=43969087
Tôi tò mò về mô hình đe dọa khi bấm vào popup giả. Nếu nó không phải popup hệ thống thật thì chẳng phải đây chỉ là một thao tác vô nghĩa sao?
Khi đăng nhập vào iCloud sẽ hiện popup yêu cầu mật khẩu cục bộ của máy tính, và nếu nhập vào thì mật khẩu đó sẽ được tải lên máy chủ iCloud
Gần đây tôi mới biết rằng nên cài ứng dụng Mac vào thư mục Applications trong home của mình (~/Applications) thay vì Applications của hệ thống, tất nhiên điều này chỉ có ý nghĩa khi máy chỉ có một người dùng. Hạ tài khoản của bản thân xuống thành người dùng không quản trị viên, rồi cài ứng dụng vào Applications trong thư mục home thì sẽ không còn bị làm phiền bởi các yêu cầu quyền khi cập nhật nữa. Đa số ứng dụng có thể tự cập nhật bình thường mà không cần quyền quản trị. Ngoại lệ là những ứng dụng cần tích hợp với OS như Tailscale mới cần quyền riêng. Nhân tiện thì đây là cách được ứng dụng Pareto Security khuyến nghị
Đáng tiếc là gần như đa số nhà phát triển ứng dụng cũng không biết cách này, và nhiều ứng dụng thậm chí còn chỉ chấp nhận cài ở đường dẫn /Applications nên sẽ không chạy ở nơi khác
Cài ứng dụng vào ~/Applications thì có thể tự động cập nhật mà không cần root, nhưng đồng thời mã đáng ngờ cũng có thể dễ dàng bị ghi đè mà không cần quyền root
Tôi đang dùng macOS 15.4.1 và bản thân thư mục ~/Applications còn không tồn tại
Nghe thật thú vị! Bình thường tôi vẫn cần tài khoản admin nên khó áp dụng cách này, nhưng với người phù hợp thì đây đúng là một mẹo rất đáng dùng
Nội dung bài này cần một đính chính quan trọng. Trước đó có nói CVE đã được vá trong macOS Sequoia 15.5, nhưng thực tế bản vá không được áp dụng cho macOS Ventura 13.7.6 và macOS Sonoma 14.7.6 được công bố cùng ngày. Tôi đã viết như vậy vì mặc nhiên nghĩ Apple sẽ vá cho tất cả các phiên bản, nhưng sau khi kiểm tra ghi chú phát hành bảo mật và thấy tên mình không xuất hiện ở hai phiên bản còn lại, tôi đã liên hệ trực tiếp với Apple. Tôi vẫn chưa nhận được phản hồi. Để tự kiểm tra, tôi đã chạy máy ảo, áp dụng bản vá trên macOS Sonoma 14.7.6 rồi chạy PoC của mình, và lỗ hổng vẫn còn hoạt động. Có lẽ Ventura 13.7.6 cũng vậy. Tôi không hiểu vì sao Apple lại không đưa bản vá vào. Nếu có thêm thông tin, tôi sẽ cập nhật bài viết lần nữa
Hệ thống TCC của macOS có tiếng là một cơ chế bảo vệ quyền riêng tư vững chắc, nhưng nghĩ đến chuyện trên thực tế nó có thể bị vượt qua dễ dàng chỉ bằng một mục nhập cơ sở dữ liệu thì thật chua chát. Các popup xin đồng ý của người dùng chẳng còn nhiều ý nghĩa khi đứng trước thao tác sửa cơ sở dữ liệu thực tế, đặc biệt là trong môi trường phát triển có tắt SIP. Rốt cuộc đây là vấn đề niềm tin. Liệu sự đồng ý ở tầng UX có còn là một ranh giới bảo mật thực chất hay không là điều đáng nghi ngờ. Chúng ta ngày càng dựa vào các popup quyền ở cấp OS, nhưng nếu ranh giới đó trên thực tế chỉ là ảo ảnh (hay chỉ là màn trình diễn), thì đã đến lúc phải nghĩ lại việc duy trì niềm tin vào quyền hạn theo cách “thực sự vận hành ra sao” chứ không phải chỉ “trông như thế nào”
Tôi nhớ ngày trước trong quảng cáo "I'm a Mac and I'm a PC" họ từng chế nhạo đúng kiểu tính năng này của Vista. Thế mà giờ Mac của tôi còn tệ hơn cả Vista. Rất bực mình
Sự đánh đổi giữa bảo mật và khả năng mở rộng có vẻ là số phận không tránh khỏi. Dù vậy, cũng phải nói là mức nền đã thay đổi so với trước đây. Ít nhất thì macOS không ngập tràn các tiến trình độc hại như Windows ngày xưa. Hoặc cũng có thể là do tôi may mắn và cẩn thận
Tôi chỉ hỏi vì tò mò thôi, cụ thể điều gì khiến bạn bực đến vậy?
Hệ thống TCC ngay từ đầu đã là một cấu trúc lỏng lẻo đến mức nực cười. Nó chỉ làm khổ các nhà phát triển hợp pháp và bắt người dùng chịu trận trước hàng loạt popup xin quyền, trong khi các ứng dụng độc hại thì như các nhà nghiên cứu liên tục chỉ ra, vẫn đi vòng qua màn “bảo mật (biểu diễn)” này bằng đủ loại con đường. Tôi không phải nhà nghiên cứu bảo mật, nhưng là một lập trình viên Mac, và tôi cũng đã tự tìm ra vài cách vượt qua. Thậm chí tôi còn nghi ngờ không biết các kỹ sư Apple có thực sự hiểu công nghệ mà họ đang dùng hay không. Không biết trong số các lập trình viên Mac truyền thống thì còn lại được bao nhiêu người nữa
Tôi dùng Mac công ty, và định kỳ lại hiện thông báo kiểu “Slack đang cố cài một helper tool mới”. Tôi hoàn toàn không biết nó là gì hay vì sao nó xuất hiện. Tôi đã hỏi đội IT nhưng họ cũng không biết cách kiểm tra. Tôi thường nghĩ chuyện này có thể bị lạm dụng, vì nó cứ liên tục đòi mật khẩu, và dù lần nào tôi cũng bấm hủy thì nó vẫn hiện lại
Hộp thoại này được gửi từ framework System Management. Đây là quá trình Slack cài một helper tool có đặc quyền cao để có thể tự cập nhật, bất kể Slack được cài ở đâu hay do người dùng nào cài
Mỗi lần popup kiểu này hiện lên, tôi chẳng có cách nào biết phải nhìn vào thông tin nào để quyết định cho phép hay từ chối, nên lúc nào cũng chỉ bấm hủy
Tôi dùng Slack như một ứng dụng web (nhưng không chạy trong trình duyệt mà ở cửa sổ riêng) https://support.apple.com/en-us/104996 Discord cũng có thể dùng theo cách này. Cảm giác dùng dễ chịu hơn hẳn so với ứng dụng Electron. Đa số ứng dụng Electron đều nên dùng theo cách này thì tốt hơn
Tôi chưa từng tự mình thấy popup “helper tool”, nhưng tôi không hiểu tại sao một ứng dụng nhắn tin đơn giản như Slack lại cần quyền kiểu đó. Có lẽ nên hỏi bộ phận hỗ trợ của Slack (và hy vọng nhận được một câu trả lời thực sự tử tế)
Cũng như các ứng dụng cần mật khẩu khác (ví dụ: binary trên Linux chỉ chạy được với root), rõ ràng vẫn có khả năng bị lạm dụng. Cuối cùng đây là vấn đề bạn có tin nhà phát triển và ứng dụng đó là thật hay không. Ngày Apple chặn hoàn toàn việc cấp quyền root cho ứng dụng bên ngoài sẽ là ngày Mac trở thành một hệ sinh thái đóng kín hoàn toàn, và nơi này (HN) sẽ tràn ngập bình luận phàn nàn. Tóm lại, điều quan trọng là phải có một mức “nghi ngờ lành mạnh” và không cấp quyền root cho các ứng dụng như Slack, nơi nhu cầu đó không hề rõ ràng
Nó cưỡng ép lấy mất focus nhập liệu, khiến đoạn chữ tôi đang gõ dở trong tin nhắn bỗng bắt đầu bị nhập vào ô mật khẩu. Trải nghiệm cực kỳ khó chịu
Các popup chồng hàng đợi theo thời gian. Sau cuối tuần bật máy lên là nó cứ hiện lặp đi lặp lại, cuối cùng tôi toàn phải tắt hẳn Slack. Tình trạng này đã kéo dài một năm rồi. Tôi không biết làm cách nào để thu hồi quyền này từ Slack, cảm giác hơi độc hại
Những công cụ chặn kiểu “bảo mật” này thật sự quá ngớ ngẩn. Chúng chỉ huấn luyện con người trở nên ngu hơn. Hôm nay có thể là thật nhưng ngày mai thì chưa chắc. Tôi còn liên tục nhận các cuộc gọi từ ngân hàng đòi thông tin cá nhân của tôi với danh nghĩa “bảo vệ danh tính”, và tất cả những cơ chế này đều đang huấn luyện con người giao dữ liệu cá nhân cho người lạ
Tôi không phải lập trình viên macOS, nhưng tôi vẫn tò mò liệu bất kỳ ứng dụng (độc hại) nào cũng có thể bắt chước kiểu dáng popup hệ thống để đánh cắp mật khẩu người dùng hay không
VSCode cũng hiện y hệt popup đó trên chiếc Mac do công ty cấp cho tôi. Tôi đã phớt lờ nó suốt nhiều năm
Nếu dùng nhiều tài khoản người dùng OS với các ứng dụng dựa trên Electron thì kiểu popup này sẽ xuất hiện
nordVPN cũng bị hiện tượng tương tự
Apple mất tròn một năm mới tung ra bản vá. Cảm giác là khá lâu. <i>2024-05-04 đã để lại nhiều cập nhật, vẫn đang tiếp tục thử PoC</i> <i>2025-05-12 bản vá được phát hành</i>
Adobe Creative Cloud vẫn chạy nhiều tiến trình nền ngay cả khi đã tắt rõ ràng quyền chạy nền trong cài đặt hệ điều hành
Tôi thực sự rất thích nghiên cứu của người này, và cảm giác như họ thuyết trình cũng cực kỳ hay