Rò rỉ mật khẩu và các vấn đề khác trên macOS

Rò rỉ mật khẩu (và còn nhiều hơn thế!) trên macOS

Giới thiệu

Bài viết này giải thích về lỗ hổng CVE-2024-54471 có trong bản cập nhật bảo mật của Apple. Lỗ hổng này đã được vá trong macOS Sequoia 15.1, macOS Sonoma 14.7.1, macOS Ventura 13.7.1. Nếu bạn đang sử dụng thiết bị macOS, bạn nên cập nhật lên phiên bản mới nhất.

Kernel là gì?

Trong hệ điều hành, đoạn mã giao tiếp với phần cứng và cung cấp mô hình đa nhiệm cho ứng dụng được gọi là kernel. Kernel của macOS là XNU, một hybrid kernel bao gồm các biến thể của BSD kernel và Mach kernel.

Lịch sử của Mach

Mach kernel gắn chặt với các cuộc chiến Unix trong thập niên 1980 và 1990. Mach bắt đầu như một dự án nghiên cứu hệ điều hành tại Đại học Carnegie Mellon, được dùng trong hệ điều hành NeXTSTEP, và cuối cùng trở thành nền tảng của macOS.

Vì sao là Mach?

Mach được phát triển để giảm độ phức tạp trong thiết kế và sử dụng hệ thống Unix. Mach gồm bốn lớp trừu tượng cơ bản, và chúng vẫn tiếp tục được sử dụng trong macOS hiện đại.

Kiến trúc của Mach

Bốn lớp trừu tượng

• Task: Môi trường nơi thread có thể chạy, là đơn vị cơ bản của việc cấp phát tài nguyên.
• Thread: Đơn vị cơ bản của việc sử dụng CPU, hoạt động với bộ đếm chương trình độc lập bên trong task.
• Port: Kênh giao tiếp cho message, được kernel bảo vệ.
• Message: Tập hợp các đối tượng dữ liệu dùng cho giao tiếp giữa các thread.

Task, port và quyền trên port

Port chỉ tồn tại trong kernel space và được lộ ra trong user space dưới dạng quyền trên port. Nhiều task có thể có quyền gửi tới một port, nhưng chỉ một task có thể có quyền nhận.

Cấu trúc của message

Mỗi Mach message gồm một header, các descriptor tùy chọn, một payload tùy ý và một trailer do kernel thêm vào.

Cách có được quyền gửi

macOS có một bootstrap server, nơi giữ quyền nhận đối với các port mà mọi task đều có quyền gửi. Client có thể yêu cầu bootstrap server cấp quyền gửi cho một Mach service có tên cụ thể.

Mach Interface Generator (MIG)

Giới thiệu

MIG là công cụ tạo ra giao diện chức năng cho việc gửi và nhận Mach message. Nó cung cấp giao diện kiểu RPC dựa trên message, giúp tăng độ an toàn bộ nhớ.

Chi tiết kỹ thuật

MIG là lớp bao bọc quanh Mach message; mỗi hàm được gọi là một routine, và tập hợp các routine được gọi là một subsystem. Subsystem được lập chỉ mục trong trường message ID.

Lỗ hổng trong MIG server

Bảo mật của MIG server

Nếu MIG server không xác thực bên gửi message, mọi task có quyền gửi đều có thể gọi các routine của server.

Tìm MIG server

Có thể dùng công cụ CLI ipsw để tìm các binary sử dụng symbol NDR_record. Cách này hữu ích để tìm cả MIG server lẫn client.

Lỗ hổng của NetAuthAgent

Giới thiệu về NetAuthAgent

NetAuthAgent là daemon xử lý thông tin xác thực cho file server trên macOS. Trước khi lỗ hổng này được vá, chỉ cần yêu cầu thông tin xác thực của server là nó sẽ cung cấp.

Cách NetAuthAgent hoạt động

NetAuthAgent sử dụng macOS Keychain để lưu trữ thông tin xác thực. Keychain là trình quản lý bí mật tập trung, và mỗi mục có danh sách kiểm soát truy cập riêng.

MIG server của NetAuthAgent

NetAuthAgent cung cấp một MIG server được đăng ký với bootstrap server dưới tên com.apple.netauth.user.gui. Server này cung cấp các routine có thể đọc, tạo và ghi đè thông tin xác thực.

Tác động của lỗ hổng

Lộ token API iCloud

Lỗ hổng này có thể làm lộ token API iCloud, cho phép kẻ tấn công đánh cắp thông tin người dùng hoặc theo dõi vị trí của thiết bị khác.

Điều Apple lẽ ra nên làm

Bài viết này cũng bao gồm thảo luận về những biện pháp Apple lẽ ra nên thực hiện để xử lý lỗ hổng này.

[GN⁺]

Ý kiến Hacker News

• Bài viết được chắp bút rất tốt. Nó khiến tôi nhớ đến vụ zero-day mà Apple dường như đã cố che giấu phần nào. Đó là vụ có thể vượt qua đăng nhập root bằng cách "thử mật khẩu trống hai lần". Vụ này diễn ra vào khoảng năm 2017 hoặc 2018

  • Nếu nhập tên người dùng quản trị viên và thử đăng nhập với mật khẩu trống, ban đầu sẽ hiện cảnh báo mật khẩu sai. Bỏ qua cảnh báo đó và nhấn nút đăng nhập lần thứ hai thì sẽ đăng nhập được vào tài khoản đó
  • Vấn đề này đã được vá ngay sau khi lan truyền trên mạng xã hội. Dù vậy, đây vẫn có vẻ là một sai sót rất lớn
  • Có vẻ cơ chế xác thực của Mac vẫn còn vấn đề. Việc hệ thống port được nhắc đến khá thú vị. Đây là một khía cạnh ít được biết đến của nhân Mach

• "ACLs don’t": <a href="https://waterken.sourceforge.net/aclsdont/current.pdf" rel="nofollow">https://waterken.sourceforge.net/aclsdont/current.pdf</a>;

• Việc phơi bày một cơ chế để tiến trình này có thể proxy truy vấn keychain cho tiến trình khác có thể làm suy yếu bảo mật của toàn bộ hệ thống

  • Đây có vẻ là một ví dụ của vấn đề confused deputy: <a href="https://en.wikipedia.org/wiki/Confused_deputy_problem" rel="nofollow">https://en.wikipedia.org/wiki/Confused_deputy_problem</a>;
  • Thiết kế dựa trên capability lẽ ra phải có thể ngăn chặn kiểu vấn đề này một cách có hệ thống

• Có một chỉnh sửa nhỏ trong bài viết

  • Việc kiểm tra quyền không nằm ở lớp Mach của kernel
  • <a href="https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3" rel="nofollow">https://github.com/nmggithub/wts/…;
  • Đó là thay đổi một từ để sửa lỗi thực tế về cách XNU hoạt động

• Mất 8 tiếng, nhưng giờ bài đăng này không còn nằm trong top 5 trang nhất nữa (hiện là #27, vẫn ở trang nhất nhưng ở phía dưới). Cảm ơn mọi người vì tất cả các bình luận

• Tôi tự hỏi liệu tác giả có cung cấp mã PoC thực tế hay không. Tôi muốn thử nghiệm các biện pháp giảm thiểu. Tôi đã thấy mã ví dụ nhưng có vẻ chưa hoàn chỉnh

  • Tôi tò mò về mức độ rủi ro thực tế

• Bài viết rất thú vị. Tôi không ngờ lại có nhiều câu chuyện như vậy đằng sau việc tạo ra Mach và kernel Darwin

• Hiện tại Mach tạo cảm giác như là một nguồn phát sinh lỗi đáng tin cậy trên macOS. Tôi biết Apple đang rất nỗ lực để khóa chặt mọi thứ, nhưng tôi tự hỏi liệu có con đường nào để thoát hẳn khỏi Mach hay không

• [dead]