Chuỗi lỗ hổng lời mời Calendar zero-click trên macOS

• Đã phát hiện lỗ hổng zero-click trong Calendar trên macOS
• Kẻ tấn công có thể thêm hoặc xóa tệp tùy ý bên trong môi trường sandbox của Calendar
• Khi kết hợp với việc thực thi mã độc và né tránh các cơ chế bảo vệ bảo mật, lỗ hổng này có thể làm tổn hại dữ liệu iCloud Photos nhạy cảm của người dùng
• Apple đã vá toàn bộ các lỗ hổng trong khoảng từ tháng 10/2022 đến tháng 9/2023

Chi tiết lỗ hổng

Giai đoạn 1: Lỗ hổng ghi và xóa tệp tùy ý trong Calendar (CVE-2022-46723)

• Kẻ tấn công có thể đính kèm tệp trong một lời mời lịch độc hại
• Tên tệp của tệp đính kèm không được kiểm tra đúng cách
• Có thể thực hiện tấn công directory traversal bằng cách đặt đường dẫn tùy ý trong phần ATTACH
• Ví dụ: FILENAME=../../../PoC.txt
• Tệp sẽ được thêm vào ~/Library/Calendar/PoC.txt
• Nếu tệp đã tồn tại, nó sẽ được lưu thành PoC.txt-2
• Khi sự kiện/tệp đính kèm do kẻ tấn công gửi bị xóa, tệp gốc (PoC.txt) cũng sẽ bị xóa
• Lỗ hổng này có thể bị dùng để xóa các tệp hiện có trong hệ thống tệp
• Lỗ hổng tồn tại trên macOS Montrey 12.5. macOS 13.0 beta4 không bị ảnh hưởng

Giai đoạn 2: Giành thực thi mã từ xa (RCE) bằng lỗ hổng ghi tệp tùy ý

• Được phát hiện ngay trước khi macOS Ventura ra mắt
• Có thể lợi dụng quy trình nâng cấp phiên bản macOS để giành thực thi mã từ xa thông qua tính năng Open File của Calendar
• Khai thác RCE được kích hoạt bằng cách lây nhiễm nhiều tệp

Tệp bị chèn #1: 000Hacked-$RANDOM.calendar

• Chứa dữ liệu lịch trông giống dữ liệu lịch do Siri đề xuất
• Bao gồm sự kiện lặp lại và tính năng nhắc nhở

Tệp bị chèn #2: tệp CalendarTruthFileMigrationInProgress

• Nâng cấp và hợp nhất lịch hiện có sang cơ sở dữ liệu mới

Tệp bị chèn #3: CalPoCInit.dmg

• Thông báo có trong sự kiện lịch sẽ mở tệp này
• CalPoCInit.dmg chứa tham chiếu trỏ tới một máy chủ Samba bên ngoài

Tệp bị chèn #4: stage1.url

• Thông báo thứ hai có trong sự kiện lịch sẽ mở tệp này
• Chứa URL trỏ tới ứng dụng trên điểm mount Samba

Tệp bị chèn #5: stage2.url

• Thông báo thứ ba có trong sự kiện lịch sẽ mở tệp này
• Chạy ứng dụng độc hại mà không cần tương tác của người dùng

Giai đoạn 3: Truy cập dữ liệu Photos nhạy cảm

• Có thể truy cập ảnh được lưu trên iCloud bằng cách thay đổi cấu hình của Photos
• Có thể vượt qua cơ chế bảo vệ TCC để rò rỉ dữ liệu người dùng nhạy cảm

Truy cập tệp iCloud thông qua thay đổi cấu hình Photos

• Kẻ tấn công tạo tệp cấu hình đặt System Photo Library của Photos sang một đường dẫn khác
• Khi chạy PhotosPoC.sh, tệp cấu hình mới sẽ được nạp vào
• Cấu hình gốc được sao lưu và cấu hình mới được lưu tại /var/tmp/mypictures/
• Khởi chạy Photos với System Photo Library mới và bật đồng bộ iCloud

Toàn bộ chuỗi

• Phải vượt qua mọi rào cản bảo mật của macOS qua nhiều bước
• Vượt qua sandbox và dùng thủ thuật SMB để né các biện pháp giảm thiểu của Gatekeeper
• Vượt qua bảo vệ TCC để truy cập dữ liệu nhạy cảm

Dòng thời gian

• 2022-08-08: Báo cáo khả năng ghi và xóa tệp tùy ý trong sandbox của Calendar
• 2022-10-24: Đã vá trên macOS Monterey 12.6.1 và Ventura 13
• 2022-11-14: Gửi PoC, phương pháp thực thi mã tùy ý qua lỗ hổng Calendar
• 2022-12-04: Gửi PoC, phương pháp truy cập ảnh iCloud
• 2023-02-20: Bổ sung credit và CVE cho CVE-2022-46723
• 2023-03-27: Vá lỗi vượt qua Gatekeeper trên macOS Ventura 13.3
• 2023-09-26: Vá lỗ hổng Photos CVE-2023-40434 và bổ sung credit
• 2023-10-09: Công bố bug bounty liên quan đến lỗi vượt qua Gatekeeper và lỗ hổng Photos
• 2023-12-21: Credit cho lỗi vượt qua Gatekeeper CVE-2023-40433

Tổng hợp của GN⁺

• Bài viết này nói về lỗ hổng zero-click trong macOS Calendar, và giải thích cách kẻ tấn công có thể dùng nó để truy cập dữ liệu iCloud Photos nhạy cảm của người dùng
• Chuỗi lỗ hổng này vượt qua sandbox qua nhiều bước, né bảo vệ Gatekeeper và TCC để cho phép thực thi mã từ xa và truy cập dữ liệu nhạy cảm
• Bài viết cung cấp thông tin quan trọng cho các nhà nghiên cứu bảo mật và người dùng macOS, đồng thời nhấn mạnh rằng Apple đã vá các lỗ hổng này
• Một số dự án khác có chức năng tương tự gồm các ứng dụng lịch khác như Google Calendar

[GN⁺]

Ý kiến trên Hacker News

• Nếu một công ty công nghệ lớn không trả tiền thưởng, rất có thể họ có lý do chính đáng

  • Chương trình tiền thưởng được thiết kế để trả thưởng cho các báo cáo hợp lệ
  • Việc không trả thưởng đi ngược lại mục tiêu của chương trình
  • Đội ngũ vận hành chương trình được khuyến khích chi trả nhiều tiền thưởng hơn

• Tôi không dùng iCloud Photo Library, nhưng thật kỳ lạ khi nếu vị trí thư viện ảnh thay đổi thì vị trí mới lại không được bảo vệ

  • Sau khi thay đổi thư viện ảnh hệ thống, ứng dụng Photos lẽ ra phải bảo vệ thư mục đó
  • Kết quả thử nghiệm trên hệ thống Sonoma 14.6.1 cho thấy, nếu thư viện ảnh mới được tạo tại ~ /Pictures thì quyền truy cập bị từ chối
  • Nhưng nếu được tạo trong /tmp thì quyền truy cập lại được cho phép
  • Nếu Apple hỗ trợ tính năng di chuyển thư viện ảnh đến bất kỳ đâu trong hệ thống tệp, họ cần áp dụng cơ chế bảo vệ phù hợp

• Có một cách khác để thao túng cờ cách ly

  • Quá nhiều hệ thống có khả năng sửa các cờ này

• Bản thân bước đầu tiên đã là một lỗ hổng nghiêm trọng

  • Kẻ tấn công có thể đặt đường dẫn tùy ý trong phần ATTACH để thực hiện tấn công directory traversal

• Kẻ tấn công có thể đánh cắp iCloud Photos của nạn nhân thông qua lời mời lịch độc hại

  • Tôi tự hỏi liệu người dùng macOS có thể gửi lời mời ngẫu nhiên cho bất kỳ ai hay không

• Nếu tệp do kẻ tấn công chỉ định đã tồn tại thì nó sẽ được lưu thành "PoC.txt-2"

  • Sau đó khi sự kiện/tệp đính kèm bị xóa, tệp gốc sẽ bị xóa theo
  • Lỗ hổng này có thể được dùng để xóa các tệp hiện có trên hệ thống tệp

• Tôi không thích trạng thái tiền thưởng này

  • Tôi tự hỏi liệu việc chờ lâu như vậy với Apple hay các công ty FAANG khác có phải là chuyện bình thường đối với các nhà nghiên cứu bảo mật hay không

• Mỗi khi xuất hiện lỗ hổng bảo mật không liên quan đến an toàn bộ nhớ, tôi lại thấy phấn khích

  • Thật thú vị khi nghĩ rằng thời gian và công sức đổ vào Rust lại có thể bị lãng phí bởi một lỗi path traversal

• Tôi tự hỏi liệu Lockdown Mode có ngăn được việc này không

• Đây là một exploit khá cũ

  • Tôi nhớ là khoảng 10 năm trước đã từng đọc về việc tên tệp có chứa đường dẫn