Phát hiện lỗ hổng nghiêm trọng trong macOS Recovery Mode: Ghi file tùy ý và truy cập Root

Một sự cố máy tính bất thường đã dẫn đến việc phát hiện ra hai lỗ hổng bảo mật nghiêm trọng trên macOS, cho phép kẻ tấn công có quyền truy cập vật lý có thể ghi dữ liệu tùy ý vào phân vùng hệ thống và duy trì quyền Root (quản trị viên cao nhất).

Câu chuyện bắt đầu khi chiếc MacBook Air M1 của tác giả bị treo do quá nhiều tab trình duyệt đang mở. Thay vì tắt máy bình thường, tác giả đã thực hiện khởi động lại cưỡng bức bằng cách giữ nút Touch ID quá lâu, vô tình đưa máy vào macOS Recovery Mode (Chế độ khôi phục).

Màn hình Recovery Mode trên macOS

Tò mò về lý do tại sao lại có ứng dụng Safari trong chế độ Recovery, tác giả đã mở nó ra và kết nối với Wi-Fi. Mọi chuyện vẫn bình thường cho đến khi tác giả thử tải xuống một hình ảnh từ Google. Safari thông báo lỗi "thiếu quyền ghi vào đĩa". Tuy nhiên, tác giả đã nhớ đến một cài đặt trong Safari cho phép người dùng chọn vị trí lưu file cho mỗi lần tải xuống.

Giao diện Safari trong Recovery Mode

Bằng cách thay đổi cài đặt tải xuống thành "Hỏi mỗi lần" (Ask for each download), tác giả nhận ra mình có thể lưu file vào bất kỳ đâu, bao gồm cả ổ đĩa hệ thống Macintosh HD. Đây là một vấn đề bảo mật lớn vì trong Recovery Mode, người dùng không cần mật khẩu để truy cập và ghi dữ liệu vào ổ cứng.

Lỗ hổng số 1: Ghi dữ liệu tùy ý và Root Persistence (CVSS 8.5)

Để kiểm tra mức độ nghiêm trọng, tác giả đã thiết lập một máy chủ web chứa các file độc hại và sử dụng tính năng "Save As" (Lưu thành) của Safari để lưu file mà không cần đuôi mở rộng. Mục tiêu là ghi một file cấu hình LaunchDaemon vào thư mục /Library/LaunchDaemons/.

LaunchDaemon là một cơ chế của macOS cho phép chạy các tập lệnh tự động khi khởi động với quyền của hệ thống (root). Bằng cách lưu file .plist độc hại vào thư mục hệ thống, tác giả đã chứng minh rằng mã độc sẽ được thực thi ngay khi máy tính khởi động lại.

Bằng chứng thực thi mã với quyền Root

Sau khi khởi động lại, lệnh sudo cat /var/root/proof_of_vulnerability.txt đã trả về kết quả cho thấy script đã chạy dưới quyền user "root". Điều này có nghĩa là kẻ tấn công có thể cài đặt phần mềm gián điệp, phá hủy hệ thống hoặc sửa đổi các tệp khởi động quan trọng một cách âm thầm.

Lỗ hổng này được đánh giá mức độ nghiêm trọng là 8.5/10 theo thang điểm CVSS, với yêu cầu là kẻ tấn công phải có truy cập vật lý vào máy tính.

Lỗ hổng số 2: Đọc file không giới hạn (CVSS 4.6)

Khi macOS Tahoe 26.0 được phát hành, Apple đã thay đổi Safari trong Recovery Mode thành một phiên bản bị khóa gọi là "Web Browser". Người dùng không còn thể thay đổi cài đặt tải xuống để khai thác lỗ hổng ghi file đầu tiên.

Tuy nhiên, tác giả nhanh chóng phát hiện ra một lỗ hổng mới. Mặc dù trình duyệt bị hạn chế, nhưng tính năng "Open File..." (Mở file) với phím tắt ⌘+O vẫn hoạt động bình thường. Điều này cho phép bất kỳ ai cũng có thể duyệt và mở toàn bộ hệ thống tệp tin trên máy tính để xem các file HTML, TXT, PDF và hình ảnh.

Lỗ hổng này dẫn đến việc mất hoàn toàn tính bảo mật của dữ liệu, vì kẻ tấn công có thể đọc tài liệu, cấu hình hệ thống và mã nguồn mà không cần mật khẩu. Nó được đánh giá mức độ 4.6/10 trên thang CVSS.

Phản hồi từ Apple và bản vá

Sau khi báo cáo hai lỗ hổng này cho chương trình Bug Bounty của Apple, phản hồi ban đầu mà tác giả nhận được khá thờ ơ. Apple cho rằng đây không phải là vấn đề bảo mật nghiêm trọng vì người dùng nên sử dụng FileVault (tính năng mã hóa ổ đĩa).

Tuy nhiên, tác giả lập luận rằng FileVault chỉ là một tùy chọn trong quá trình cài đặt Mac ban đầu và nhiều người dùng (bao gồm cả gia đình tác giả) thường bỏ qua nó do thiếu kiến thức. Việc dựa vào FileVault để biện minh cho lỗ hổng trong Recovery Mode là không hợp lý, bởi nó giảm đáng kể nỗ lực cần thiết để duy trì mã độc trên hệ thống chưa mã hóa so với các phương pháp khác.

Tin vui là vào ngày 3/1/2026, phiên bản macOS Tahoe 26.3 đã âm thầm khắc phục cả hai vấn đề này. Người dùng không còn thể mở file bằng phím tắt Cmd+O, và ngay cả khi lỡ mở được trình quản lý file, các thư mục quan trọng như /Library hay /Users giờ đây hiển thị trống rỗng.

Tác giả đã chờ đợi 6 tháng (gấp đôi thời gian tiêu chuẩn 90 ngày) trước khi công bố chi tiết kỹ thuật để đảm bảo Apple có đủ thời gian để triển khai bản vá, đồng thời nhấn mạnh đây là một bài học kinh nghiệm quý giá về bảo mật hệ điều hành.