- Apple đã vá CVE-2024-54471 trong macOS Sequoia 15.1, Sonoma 14.7.1, Ventura 13.7.1 phát hành ngày 28/10/2024; trên các môi trường chưa cập nhật, thông tin đăng nhập đã lưu có thể bị lộ thông qua NetAuthAgent
- Cốt lõi của vấn đề là máy chủ MIG của NetAuthAgent không xác minh người gửi thông điệp, đồng thời để mở các routine tra cứu, tạo và ghi đè một phần thông tin đăng nhập máy chủ tệp
- Kẻ tấn công có thể gửi thông điệp tới dịch vụ Mach
com.apple.netauth.user.gui, khiến nó thay mặt tra cứu các mụcinternet passwordtrong Keychain và nhận được tên người dùng cùng mật khẩu - Tác động không chỉ dừng ở thông tin đăng nhập FTP, Samba, WebDAV, máy chủ in đã lưu bằng “Connect to Server” của Finder, mà thông qua một chuỗi riêng còn có thể dẫn tới lộ thông tin tài khoản iCloud và token API
- Sau bản vá, NetAuthAgent kiểm tra entitlement của tiến trình gửi bằng audit token trong thông điệp Mach, và sẽ không phản hồi nếu không có
com.apple.private.netauth.useragent.allow=true
Phạm vi vá CVE-2024-54471
- CVE-2024-54471 là một lỗ hổng macOS đã được sửa trong bản cập nhật bảo mật của Apple
- Các phiên bản có chứa bản vá đều được phát hành vào 28/10/2024
- macOS Sequoia 15.1
- macOS Sonoma 14.7.1
- macOS Ventura 13.7.1
- Các thiết bị macOS chưa cập nhật lên những phiên bản này cần cập nhật ngay
IPC của macOS và kiến trúc dựa trên Mach
- Kernel của macOS và phần lớn hệ điều hành Apple là XNU, một hybrid kernel gồm các thành phần họ BSD và một biến thể kernel Mach đã được sửa đổi đáng kể
- Mach trên macOS hiện đại vẫn dựa trên bốn khái niệm trừu tượng
- task: môi trường thực thi nơi thread chạy, đồng thời là đơn vị cơ bản để cấp phát tài nguyên
- thread: đơn vị cơ bản sử dụng CPU
- port: kênh liên lạc tương ứng với hàng đợi thông điệp được kernel bảo vệ
- message: tập hợp các đối tượng dữ liệu có kiểu dùng để liên lạc giữa các thread
- Port của Mach không phải là hàng đợi được phơi trực tiếp ra user space, mà được xử lý dưới dạng port right trong không gian tên port của từng task
- Có hai quyền chính
- send right: nhiều task có thể cùng có quyền này đối với một port
- receive right: chỉ một task có thể có quyền này
- Cấu trúc này tạo nên mô hình client-server, trong đó một task máy chủ nhận thông điệp từ nhiều task client
- bootstrap server của macOS nhận một port mà mọi task đều có send right, cho phép client yêu cầu send right của một Mach service đã đăng ký bằng tên chuỗi
Khoảng trống xác thực trong máy chủ MIG
- MIG là công cụ bọc việc gửi nhận thông điệp Mach thành giao diện dạng hàm
- MIG gồm pseudo-C IDL và trình biên dịch; từ tệp IDL, nó tạo ra các tệp sau
- Mã nguồn C cho client
- Mã nguồn C cho server
- Header C dùng ở cả hai phía
- Mỗi hàm được gọi là routine, tập hợp routine được gọi là subsystem, và số subsystem cùng chỉ mục routine được phản ánh trong ID thông điệp
- Trong giao tiếp user space của macOS, MIG phần lớn đã nhường chỗ cho XPC API, nhưng XPC cũng được xây dựng trên thông điệp Mach
- Bản thân máy chủ MIG không có cơ chế xác thực bắt buộc, nên nếu server không xác minh người gửi thì bất kỳ task nào có send right cũng có thể gọi routine từ xa
- Để dò tìm máy chủ MIG, ipsw CLI của blacktop rất hữu ích; phương pháp được dùng là tìm các binary import symbol
NDR_record- Cách này có thể tìm thấy cả client MIG chứ không chỉ máy chủ MIG
- Mã server và client có thể được phân biệt tương đối dễ trong disassembler hoặc decompiler
Thông tin đăng nhập mà NetAuthAgent xử lý
- NetAuthAgent là user agent trên macOS xử lý thông tin đăng nhập máy chủ tệp như FTP, Samba, WebDAV
- Hộp thoại xác thực xuất hiện khi kết nối tới máy chủ tệp bằng “Go → Connect To Server” trong Finder được cung cấp bởi NetAuthAgent hoặc các tiến trình liên quan
- Khi người dùng chọn ô lưu mật khẩu, thông tin đăng nhập được lưu vào Keychain của macOS
- NetAuthAgent không trực tiếp lưu mật khẩu, mà dùng Keychain như một kho bí mật tập trung
- Các mục Keychain có danh sách kiểm soát truy cập riêng, thường ngăn ứng dụng truy cập các bí mật mà chúng không được phép truy cập
- Tuy nhiên, nếu một tiến trình cụ thể phơi ra cơ chế thay mặt tiến trình khác tra cứu Keychain, toàn bộ mô hình bảo mật có thể bị suy yếu
Dịch vụ MIG dễ tổn thương của NetAuthAgent
- NetAuthAgent đã phơi ra một máy chủ MIG có thể tra cứu qua bootstrap server
- Tên dịch vụ là
com.apple.netauth.user.gui - Máy chủ này cung cấp các routine để đọc, tạo và trong một số trường hợp ghi đè thông tin đăng nhập máy chủ tệp
- Trước bản vá, các routine này không xác minh người gửi thông điệp
- Routine 19, ID thông điệp 40219, có thể proxy việc tra cứu các mục thuộc lớp
internet passwordtrong Keychain - Routine này nhận dictionary tùy chọn đã tuần tự hóa dưới dạng out-of-line data descriptor, và trả về tên người dùng cùng mật khẩu dưới dạng hai out-of-line data descriptor
Luồng tấn công và cấu trúc PoC
- PoC dùng Kass, công cụ nghiên cứu bảo mật viết bằng Swift, để xử lý thông điệp Mach và client MIG
- Client NetAuthAgent được định nghĩa với các giá trị sau
- Tên dịch vụ:
com.apple.netauth.user.gui - ID routine cơ sở của subsystem: 40200
- Tên dịch vụ:
- Tùy chọn tra cứu được tuần tự hóa ở dạng Property List và có thể gồm các trường như
Scheme,Host,AlternatePort,Path - API Keychain của macOS
SecItemCopyMatchingcó thể được dùng để lấy metadata của mục Keychain ngay cả với tiến trình không có quyền, nếu không yêu cầu giá trị bí mật - Danh sách kiểm soát truy cập cũng có thể được truy cập như metadata, nên có thể kiểm tra danh sách trusted application của mục có chứa
/System/Library/CoreServices/NetAuthAgent.apphay không - Mã tấn công có thể duyệt các mục
internet passwordmà NetAuthAgent có thể truy cập và trích xuất các thông tin sau- Tên hiển thị
- Giao thức
- Host
- Cổng
- Đường dẫn
- Tên người dùng
- Mật khẩu
Tác động của rò rỉ thông tin đăng nhập máy chủ tệp
- Trước bản vá, một tiến trình độc hại có được send right tới NetAuthAgent có thể làm rò rỉ toàn bộ thông tin đăng nhập máy chủ tệp
- Trong môi trường doanh nghiệp, các thông tin đăng nhập này có thể là thông tin đăng nhập SSO, tạo khả năng kẻ tấn công truy cập nhiều tài nguyên trong hệ thống công ty
- Không rõ mức độ sử dụng tính năng Connect to Server của Finder, nhưng tài liệu trợ giúp của nhiều trường đại học và cơ sở giáo dục đã hướng dẫn sinh viên và nhân viên dùng tính năng này, một số còn khuyến nghị chọn ô lưu vào Keychain
- Cũng đã tìm thấy hướng dẫn kết nối máy in từ các nhà cung cấp máy chủ in, và NetAuthAgent cũng xử lý thông tin đăng nhập máy chủ in
- Ít nhất một tài liệu khuyên không chọn ô lưu vì ứng dụng Keychain Access khó dùng với người dùng phổ thông khi cần cập nhật mật khẩu đã lưu
- Nếu trên thiết bị được quản lý, cùng thông tin đăng nhập cũng được dùng làm thông tin đăng nhập superuser, có thể dẫn tới leo thang đặc quyền, nhưng điều này chưa được xác nhận do không có thử nghiệm trên thiết bị được quản lý
- Với người dùng cá nhân kết nối NAS bằng Finder và lưu thông tin đăng nhập, thông tin đăng nhập NAS cũng có thể bị lộ cho kẻ tấn công
- Nếu cùng thông tin đăng nhập được tái sử dụng cho tài khoản Internet khác, các tài khoản đó cũng có thể bị xâm phạm
- FTP, Samba, WebDAV có giao diện được định nghĩa rõ, nên sau khi thông tin đăng nhập bị lộ, việc tự động hóa duyệt và trích xuất tệp trên máy chủ khá dễ dàng
Khai thác bổ sung bằng Keychain
- Vì NetAuthAgent cũng phơi ra routine tạo mục Keychain, tiến trình độc hại có thể nhét dữ liệu tùy ý vào trường
passwordđể che giấu - Cách này có thể tránh hành vi ghi trực tiếp xuống đĩa, trở thành phương tiện ẩn dữ liệu để né phần mềm bảo mật
- Chưa có thông tin về phần mềm bảo mật nào kiểm tra rõ ràng các mục đáng ngờ trong Keychain
- Tiến trình độc hại cũng có thể lưu thông tin đăng nhập hợp pháp vào Keychain
- Hành vi này riêng lẻ có thể có tác dụng hạn chế, nhưng có thể được dùng trong tấn công kết hợp: lưu thông tin đăng nhập của máy chủ tệp do kẻ tấn công kiểm soát rồi dụ người dùng bằng social engineering
Chuỗi khai thác dẫn tới token API iCloud
- Ngay cả người dùng không dùng Connect to Server cũng không hoàn toàn thoát khỏi tác động của lỗ hổng này
- Trên phần lớn thiết bị macOS tồn tại các mục Keychain có ACL đủ rộng để NetAuthAgent truy cập được
- Mục Keychain này chứa khóa giải mã dùng để giải mã một tệp cụ thể trên đĩa
- Tệp đó chứa thông tin tài khoản iCloud và token API của người dùng
- Kẻ tấn công có thể dùng mục Keychain và tệp ở vị trí đã biết để lấy các thông tin sau
- Tên và họ
- Địa chỉ email
- Bí danh email
- Các tính năng và endpoint đang bật
- Nhiều token API tồn tại dài hạn
Những việc có thể làm bằng token iCloud
- Nghiên cứu trước đây của Wojciech Reguła cho thấy có thể tìm cùng loại token API bằng phương pháp khác và làm rò rỉ dữ liệu sau
- Contacts
- Calendars
- Reminders
- Vị trí người dùng thông qua Find My
- Các kết quả trên đã được tái hiện, ngoại trừ Reminders
- Reminders của tài khoản mới và tài khoản đã di trú đã được Apple chuyển sang CloudKit an toàn hơn, chỉ có thể truy cập ở dạng mã hóa
- Các thao tác bổ sung có thể thực hiện gồm
- Rò rỉ ảnh liên hệ
- Truy vấn CloudKit, nhưng không thể giải mã
- Rò rỉ dữ liệu iCloud key-value store
- Rò rỉ metadata bản sao lưu iCloud, bao gồm số serial thiết bị
- Rò rỉ vị trí các thiết bị khác của người dùng qua Find My
- Rò rỉ vị trí bạn bè của người dùng qua Find My
- Thực hiện thao tác khóa, xóa, phát âm thanh qua Find My
- Việc giải mã dữ liệu CloudKit đã được điều tra nhưng chưa hoàn tất
- Không thể loại trừ khả năng các hãng forensic thương mại dùng token API này, cùng với PIN thiết bị iOS khi cần, để giải mã dữ liệu CloudKit hoặc dữ liệu CloudKit trong bản sao lưu iCloud
Cách Apple sửa lỗi
- Sau bản vá, khi nhận thông điệp, NetAuthAgent trước tiên kiểm tra entitlement của người gửi
- Entitlement là các cặp key-value được gắn vào binary khi ký mã
- Trên macOS với thiết lập bảo mật tiêu chuẩn, Apple Mobile File Integrity kiểm tra restricted entitlement khi tiến trình chạy, và chấm dứt tiến trình nếu không có provisioning profile phù hợp
- Provisioning profile phải được Apple ký, nên cơ chế kiểm tra này được thiết kế để khó bị vượt qua
- Entitlement mà NetAuthAgent yêu cầu như sau
- Khóa:
com.apple.private.netauth.useragent.allow - Giá trị: boolean
true
- Khóa:
- NetAuthAgent không phản hồi người gửi không có entitlement này
- Trailer do kernel gắn khi nhận thông điệp Mach có chứa audit token
- Task nhận có thể dùng audit token để định danh task gửi, yêu cầu kernel cung cấp dictionary entitlement của task đó, rồi kiểm tra giá trị
Mắt xích yếu trong kiến trúc bảo mật
- Ngay cả khi thông tin đăng nhập máy chủ tệp được lưu để chỉ ứng dụng cụ thể có thể truy cập, nếu ứng dụng đó chấp nhận lệnh tra cứu từ ứng dụng khác thì nó trở thành mắt xích yếu
- Ngay cả khi token API iCloud được lưu trong một tệp mã hóa trên đĩa, nếu khóa giải mã nằm trong mục Keychain có ACL rộng thì ACL đó trở thành mắt xích yếu
- macOS có các cơ chế bảo mật khiến việc tiêm tiến trình trở nên khó hơn, và hạ tầng bảo mật tổng thể được đánh giá là khá mạnh
- Tuy nhiên, như lỗ hổng này cho thấy, chỉ một lỗi đơn giản là thiếu xác minh người gửi cũng có thể dẫn tới lộ thông tin đăng nhập máy chủ tệp và token API iCloud
Khuyến nghị cho người dùng
- Nếu vẫn có thể, nên bật Advanced Data Protection
- Nếu không dùng iCloud bằng trình duyệt web, tắt truy cập web vào dữ liệu iCloud cũng là một lựa chọn
- Trang web iCloud đôi khi dùng endpoint API khác với ứng dụng iCloud của Apple
- Lỗ hổng này không còn cho phép truy cập token nữa, nhưng token đã từng bị lộ bởi các lỗ hổng trước đây và cũng có thể bị lộ bởi lỗ hổng khác trong tương lai
- Không có bằng chứng cho thấy khai thác này đã được tác nhân độc hại sử dụng hoặc phát hiện
- Dù vậy, nếu đặc biệt lo ngại việc thông tin đăng nhập bị lạm dụng, nên đổi mật khẩu
- Các thiết bị chưa cập nhật macOS kể từ tháng 10/2024 cần cập nhật ngay
1 bình luận
Ý kiến trên Hacker News
Bài viết rất hay, và làm tôi nhớ đến zero-day từng cho phép bỏ qua đăng nhập root bằng cách thử mật khẩu trống hai lần, thứ mà Apple dường như đã cố che đậy phần nào. Khoảng năm 2017, hoặc có thể là 2018
Ở bất cứ hộp đăng nhập root nào, nếu nhập tên người dùng quản trị và để trống mật khẩu rồi đăng nhập, lần đầu sẽ báo sai mật khẩu, nhưng sau khi đóng cảnh báo và bấm lần thứ hai thì đăng nhập được với người dùng đó
Hôm đó lỗi tái hiện 100% và được vá nhanh sau khi lan trên mạng xã hội, nhưng dù vậy trông vẫn như một oversight nghiêm trọng. Có vẻ quanh cơ chế xác thực của Mac vẫn còn những tàn dư cũ, và việc bài viết nhắc đến hệ thống port của nhân Mach cũng rất thú vị
Khi bộ đệm tên người dùng đạt 256 ký tự bất kỳ, XDM bị crash và mở shell root. Nhưng đó là chuyện đầu thập niên 90, khi mọi người còn ngây thơ hơn nhiều về bảo mật
grep, và hoạt động 100%“ACLs don't”: https://waterken.sourceforge.net/aclsdont/current.pdf
Bài viết có một chỉnh sửa nhỏ: kiểm tra entitlement không nằm trong tầng Mach của kernel
https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3
Đây là thay đổi một từ để sửa lỗi factual trong phần mô tả cách XNU hoạt động
Phần nói rằng “nếu một tiến trình để lộ cơ chế cho phép tiến trình khác gần như proxy truy vấn keychain, điều đó có thể làm suy yếu bảo mật toàn hệ thống” trông giống vấn đề confused deputy: https://en.wikipedia.org/wiki/Confused_deputy_problem
Một thiết kế dựa trên capability đáng lẽ phải ngăn được loại vấn đề này một cách có hệ thống
Tôi tò mò tác giả đã cung cấp mã PoC thực tế ở đâu. Tôi muốn thử kiểm tra một vài biện pháp giảm thiểu, nhưng mã ví dụ thấy có vẻ chưa hoàn chỉnh
Rủi ro thực tế ở mức nào?
Về mặt rủi ro, một ứng dụng có thể lấy send right tới NetAuthAgent, tức gần như mọi ứng dụng không bị sandbox, có thể âm thầm yêu cầu NetAuthAgent cung cấp thông tin xác thực đã lưu của các ổ đĩa tệp như FTP, WebDAV, Samba. Điều này còn có thể dẫn đến rò rỉ toàn bộ danh bạ và lịch iCloud, cũng như các dữ liệu liên quan đến iCloud khác
Sandbox làm việc này khó hơn nhưng không khiến nó bất khả thi. Nếu hệ thống đã cập nhật thì rủi ro là 0, và bản vá đã có từ tháng 10 năm ngoái, nên thật lòng là đáng ra máy đã phải được cập nhật rồi. Nếu bạn chưa cập nhật và cũng không định cập nhật, rủi ro sẽ lớn hơn nhiều trừ khi bạn kiểm tra không sót bất kỳ tiến trình nào đang chạy trên thiết bị
Một bài viết rất chi tiết, tôi thích việc nó còn đề cập cả lịch sử của nhiều kernel. Tuy nhiên, với một bài về vấn đề bảo mật nghiêm trọng, sẽ tốt hơn nếu đầu bài có một phần giải thích rất ngắn về phạm vi ảnh hưởng, điều kiện tấn công, và đây là lỗi logic hay lỗi hỏng bộ nhớ
Chỉ cần đủ ngắn để quyết định có nên đọc phần còn lại hay không là được
Bài viết thật sự thú vị. Tôi không biết quá trình hình thành Mach và kernel Darwin lại có nhiều câu chuyện hậu trường như vậy
Đến giờ, Mach có cảm giác như một nguồn cung lỗi macOS khá ổn định. Tôi biết Apple đang rất nỗ lực khóa chặt, nhưng có con đường nào để thoát hoàn toàn khỏi Mach không?
Nếu daemon không kiểm tra entitlement thì không an toàn. Nên trách cách sử dụng cơ chế messaging hơn là trách chính cơ chế đó
Thực ra bất kỳ hệ thống messaging bị khóa nào cũng cần nhiều hơn việc chỉ chuyển tiếp thông điệp đơn thuần, chẳng hạn như xác minh người gửi. Đó không phải thứ tự nhiên có được từ một giao thức giao tiếp cấp thấp như Mach. Trừ khi Apple cải tổ trình biên dịch MIG để thêm kiểm tra entitlement
Mach rất tuyệt khi dùng cùng với kiểm tra entitlement
Về mặt kỹ thuật, việc nhiều thành phần khác nhau cùng tồn tại hơn cũng có thể làm tăng bề mặt tấn công tiềm năng. Nhưng các bề mặt chuyên biệt hơn có thể làm việc kiểm soát đơn giản hơn, và cuối cùng giúp bảo vệ các bề mặt đó tốt hơn