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

 (medium.com/@mikko-kenttala)
1 điểm bởi GN⁺ 2024-09-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Lỗi trong cách xử lý tệp đính kèm lời mời của macOS Calendar cho phép kẻ tấn công ghi·xóa tệp tùy ý bên trong sandbox của Calendar, và vấn đề này dẫn tiếp tới chuỗi thực thi mã từ xa cùng truy cập dữ liệu Photos
  • Giai đoạn 1, CVE-2022-46723, không chuẩn hóa đúng đầu vào path traversal như FILENAME=../../../PoC.txt trong phần ATTACH, khiến tệp đính kèm có thể được lưu ra ngoài vị trí dự kiến
  • Chuỗi thực thi mã từ xa lợi dụng hành vi Open File của Calendar trong quá trình nâng cấp từ Monterey lên Ventura, kết hợp việc chèn nhiều tệp với DMG, mount SMB và custom URL scheme
  • Ở giai đoạn Photos, kẻ tấn công dùng defaults import để áp dụng cấu hình độc hại, đổi System Photo Library thành /var/tmp/mypictures/Syndication.photoslibrary, khiến ảnh gốc iCloud được đồng bộ vào thư mục không được TCC bảo vệ
  • Apple đã vá toàn bộ các lỗ hổng liên quan trong giai đoạn từ tháng 10/2022 đến tháng 9/2023; lỗ hổng Photos được gán CVE-2023-40434, còn bypass Gatekeeper là CVE-2023-40433

Path traversal trong tệp đính kèm Calendar

  • Lời mời Calendar độc hại có thể chứa tệp đính kèm, và việc xác thực tên tệp không đầy đủ đã cho phép directory traversal
  • Kẻ tấn công có thể chỉ định đường dẫn tùy ý trong phần ATTACH như FILENAME=../../../PoC.txt
    • Vị trí lưu hợp lệ là ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/
    • Trong hành vi dễ bị tấn công, tệp được lưu tại ~/Library/Calendar/PoC.txt
  • Nếu đã có tệp cùng tên, tệp mới sẽ được lưu thành PoC.txt-2, nhưng khi sự kiện hoặc tệp đính kèm do kẻ tấn công gửi bị xóa về sau, tệp gốc PoC.txt có thể bị xóa
  • Hành vi này cũng có thể bị dùng để xóa các tệp sẵn có bên trong sandbox của Calendar trên hệ thống tệp
  • Lỗ hổng được xác nhận tồn tại ít nhất trên macOS Monterey 12.5 bản mới nhất, và không còn xuất hiện trên macOS 13.0 beta4

Chuỗi mở rộng thành thực thi mã từ xa

  • Lỗ hổng được phát hiện ngay trước khi macOS Ventura phát hành đã được mở rộng thành thực thi mã từ xa bằng cách lợi dụng quá trình nâng cấp phiên bản và tính năng Open File của Calendar
  • Kẻ tấn công dùng lỗ hổng ghi tệp tùy ý của Calendar để chèn nhiều tệp, rồi sắp xếp để chuỗi RCE hoạt động khi hệ thống được nâng cấp từ Monterey lên Ventura

  • Thành phần các tệp được chèn

    • 000Hacked-$RANDOM.calendar
      • Chứa dữ liệu Calendar ngụy trang như lịch “Siri Suggested”
      • Bao gồm sự kiện lặp lại và tính năng nhắc nhở, đồng thời được thiết kế để mở các tệp đã chèn khác
    • CalendarTruthFileMigrationInProgress
      • Tệp buộc Calendar cũ phải nâng cấp và hợp nhất từ định dạng cũ sang cơ sở dữ liệu mới
    • CalPoCInit.dmg
      • Nhắc nhở Calendar đầu tiên sẽ mở ~/Library/Calendars/CalPoCInit.dmg
      • Bookmark trong .DS_Store bên trong DMG chứa tham chiếu tới ảnh nền trên máy chủ Samba bên ngoài
      • Dù bản thân CalPoCInit.dmg đang bị cô lập, việc mount vẫn diễn ra không có quarantine flag
    • stage1.url
      • Nhắc nhở Calendar thứ hai sẽ mở ~/Library/Calendars/stage1.url
      • Tệp này chứa URL file:///Volumes/CalPoCPayload/MyMidiTest.app trỏ tới ứng dụng nằm trong volume Samba được mount ở bước trước
      • Khi Finder mở /Volumes/CalPoCPayload/, quá trình indexing diễn ra tự động và MyMidiTest.app được lập chỉ mục
      • Info.plist của app bundle đăng ký handler cho custom URL scheme mymiditest
    • stage2.url
      • Nhắc nhở Calendar thứ ba sẽ mở ~/Library/Calendar/stage2.url
      • Tệp này tham chiếu mymiditest://, giúp chạy ứng dụng độc hại mà không cần người dùng tương tác

Bypass Gatekeeper và chạy ứng dụng

  • Lý do mymiditest:// có thể chạy là vì ứng dụng nằm trong mount Samba do exploit tạo ra, và vị trí đó không có quarantine flag
  • Ứng dụng mymiditest ghi các tệp cần cho giai đoạn 3 vào /var/tmp/, rồi chạy script trong Terminal bằng open /var/tmp/PhotosPoC.sh
  • Toàn bộ chuỗi được thiết kế để thoát khỏi sandbox của Calendar bằng cách chèn nhiều tệp, sau đó dùng thủ thuật SMB để bypass các biện pháp giảm thiểu của Gatekeeper và thực thi mã tùy ý

Thay đổi cấu hình Photos để truy cập ảnh iCloud

  • Giai đoạn sau khi thực thi mã từ xa tập trung vào việc thay đổi cấu hình Photos để truy cập dữ liệu ảnh nhạy cảm của người dùng, đặc biệt là iCloud Photos
  • Thông thường quyền truy cập các tệp nhạy cảm như của Photos phải bị TCC hạn chế, nhưng nếu thay đổi cấu hình Photos, System Photo Library có thể trỏ tới một đường dẫn không được TCC bảo vệ
  • Kẻ tấn công có thể tạo tệp cấu hình Photos dùng một System Photo Library khác và nhập nó bằng defaults import
  • Trong chuỗi PoC, giai đoạn 2 tự động chuẩn bị cấu hình dùng /var/tmp/mypictures/Syndication.photoslibrary làm System Photo Library
    • Tệp cấu hình độc hại liên quan được tạo tại /var/tmp/mypictures/*.plist
    • Các ứng dụng liên quan tới Photos đang chạy sẽ bị tắt
    • Cấu hình gốc được sao lưu vào /var/tmp/mypictures/*-orig.plist
    • Cấu hình độc hại được import từ /var/tmp/mypictures/
    • Thư viện ảnh mới được mở trong Photos bằng open /var/tmp/mypictures/Syndication.photoslibrary
  • Syndication.photoslibrary là một thư viện mẫu trống; khi Photos chạy với nó làm System Photo Library mới, đồng bộ iCloud được kích hoạt và các tệp gốc sẽ được tải xuống một thư mục không được bảo vệ
  • Các tệp đã đồng bộ xuống đĩa được sao chép vào thư mục mới dưới /var/tmp/PoCLoot$RANDOM/
  • PoC có thể được sửa đổi rất nhỏ để sao chép dữ liệu sang tài nguyên bên ngoài hoặc đăng lên máy chủ web bên ngoài bằng lệnh curl

Lịch vá và vấn đề bounty còn tồn đọng

  • Toàn bộ chuỗi phải lần lượt vượt qua các hàng rào bảo mật của macOS
    • Chèn nhiều tệp vào Calendar để bypass sandbox và kích hoạt giai đoạn kế tiếp
    • Dùng thủ thuật SMB để bypass biện pháp giảm thiểu của Gatekeeper và chạy mã tùy ý
    • Bypass bảo vệ TCC để truy cập dữ liệu nhạy cảm như iCloud Photos
  • Trước khi được vá, chỉ cần gửi lời mời Calendar độc hại tới người dùng Apple iCloud là có thể đánh cắp iCloud Photos mà không cần tương tác người dùng
  • Apple đã vá toàn bộ các lỗ hổng liên quan trong giai đoạn từ tháng 10/2022 đến tháng 9/2023

  • Dòng thời gian

    • 2022-08-08: Báo cáo lỗi ghi·xóa tệp tùy ý bên trong sandbox Calendar
    • 2022-10-24: Được vá trong macOS Monterey 12.6.1 và Ventura 13
      • Mục này không có CVE, và Ventura beta3 vẫn còn bị ảnh hưởng
    • 2022-11-14: Gửi PoC mở rộng lỗ hổng Calendar thành thực thi mã tùy ý và bypass Gatekeeper
    • 2022-12-04: Gửi PoC truy cập iCloud Photos
    • 2023-02-20: Lỗ hổng Calendar được bổ sung credit và CVE CVE-2022-46723
    • 2023-03-27: Bypass Gatekeeper được vá trong macOS Ventura 13.3
      • Tại thời điểm này chưa có CVE hay credit
    • 2023-09-26: Lỗ hổng Photos CVE-2023-40434 được vá và được ghi nhận credit
    • 2023-10-09: Công bố bug bounty liên quan tới bypass Gatekeeper và lỗ hổng Photos
    • 2023-12-21: Bypass Gatekeeper được bổ sung credit CVE-2023-40433
    • 2024-09-12: Bounty cho lỗ hổng ghi·xóa tệp tùy ý gốc của Calendar CVE-2022-46723 vẫn chưa có
    • Cập nhật 2024-10-20: Apple quyết định CVE-2022-46723 không thuộc diện nhận bounty vì lỗ hổng ghi·xóa tệp tùy ý của Calendar chỉ ảnh hưởng tới macOS Monterey, còn Ventura đã không còn vấn đề này ngay từ giai đoạn beta

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-09-14
Ý kiến trên Hacker News

  • May là tôi không dùng iCloud Photo Library, nhưng thật kỳ lạ khi nếu đổi vị trí thư viện ảnh thì vị trí mới lại không được bảo vệ gì cả
    Tôi từng nghĩ rằng nếu đặt /var/tmp/mypictures/Syndication.photoslibrary làm thư viện ảnh hệ thống rồi mở Photos, ứng dụng Photos sẽ phải bảo vệ thư mục này nên exploit sẽ thất bại
    Thử nhanh trên Sonoma 14.6.1: nếu nhấn phím Option và mở Photos để tạo một thư viện ảnh mới trong ~/Pictures, thì một ứng dụng không có quyền Truy cập toàn bộ ổ đĩa cũng như quyền Ảnh sẽ bị từ chối truy cập thư mục đó
    Nhưng nếu tạo thư viện ảnh mới trong /tmp, cùng ứng dụng đó lại có thể truy cập, và hành vi này khó hiểu và không nhất quán
    Nếu Apple thực sự muốn hỗ trợ khả năng di chuyển thư viện ảnh tới bất kỳ đâu trong hệ thống tệp, họ cũng cần áp dụng cơ chế bảo vệ cho đúng

    • Ở một mức nào đó thì cũng hiểu được. Về mặt lịch sử, /tmp là nơi trong cây thư mục mà ai cũng có thể đọc và ghi, và không phải lựa chọn tốt để lưu dữ liệu riêng tư
    • TCC từ trước đến nay vẫn hơi kỳ lạ kiểu này và có khá nhiều lỗ hổng
    • Trên Linux, giờ đây có thể cô lập mọi thứ dễ hơn macOS rất nhiều
      Ngay cả không cần AppArmor hay Firejail, hầu hết dịch vụ mặc định cũng được cấp thư mục tạm riêng

  • Trong thread này có nhiều bàn về việc chi trả tiền thưởng lỗi, nhưng nếu một công ty công nghệ khổng lồ vận hành chương trình thưởng thường trực mà không trả thưởng, thì thường có khả năng là họ có lý do nào đó hợp lý
    Gần như toàn bộ incentive của các chương trình như vậy đều được căn chỉnh theo hướng trả thưởng cho các báo cáo chính đáng
    Đây là một trường hợp hiếm mà incentive được căn chỉnh khá tốt: công ty lập chương trình thưởng để khuyến khích một số loại nghiên cứu nhất định, và việc không chi trả phần thưởng chính đáng sẽ đi ngược mục tiêu đó
    Người phụ trách phía nhà cung cấp cũng đâu phải tự bỏ tiền túi, và số tiền đó cũng không phải quy mô đáng kể đối với công ty
    Thông thường các thành viên đội vận hành chương trình có động lực để trả nhiều hơn, chứ không phải trả ít đi

    • Không phải. Đó là vì đội product security điều tra và chi trả bug bounty của Apple được quản lý tệ và kém hiệu quả
      Gần đây đội này được chuyển từ SWE program office sang SEAR (security engineering & arch), và manager cũng vừa bị đẩy đi, chuyển sang AirBNB
      Phần lớn thành viên đội chỉ ở mức sinh viên mới ra trường ICT2·ICT3, là những người không qua nổi phỏng vấn coding ở các bộ phận khác trong công ty, và chủ yếu làm việc như người phân loại lỗi
      Họ dành nhiều thời gian đi hội nghị và giao du với hacker hơn là ngồi làm việc trước máy tính
      Biểu đồ trên cổng “đang điều tra” cứ liên tục tăng, nghĩa là email chỉ chất đống và họ thậm chí không cố bắt kịp
      Những người đáng lẽ phải nhận tiền thưởng mà chưa nhận được, nếu muốn thấy tiến triển thì cần công khai gây áp lực lên Ivan, người phụ trách SEAR, trên Twitter
    • Có thể đúng. Chương trình bug bounty tệ hại của Apple có lẽ là kết quả của sự bất tài chứ không phải ác ý có chủ đích
      Nhưng điều đó có quan trọng với các nhà nghiên cứu bảo mật hay công chúng không? Không. Bất kể lý do vì sao nó hỏng, Apple cần sửa chương trình thưởng
      Rốt cuộc bài blog này cũng chỉ là thêm một ví dụ nữa trong một đống lớn vốn đã tồn tại[1][2][3][4][5]
      1: https://arstechnica.com/information-technology/2021/09/three...
      2: https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
      3: https://medium.com/macoclock/apple-security-bounty-a-persona...
      4: https://theevilbit.github.io/posts/experiences_with_asb/
      5: https://shail-official.medium.com/accessing-apples-internal-...
    • Nếu không phải ý nói tác giả đã bóp méo tình hình, thì tôi không biết có “lý do rất chính đáng” nào có thể tồn tại khi có hồ sơ rõ ràng rằng ai đó đã báo cáo lỗi từ rất lâu trước khi nó được sửa
      Nhìn theo hướng tích cực nhất thì đây giống kiểu bộ máy quan liêu chậm chạp điển hình, và đó không phải là lý do hay ho gì
      Nếu công ty thực sự khuyến khích những việc như thế này thì không có lý do gì việc phê duyệt lại mất hơn một năm
      Lập luận có thể đúng, nhưng nhìn vào tình huống này thì khó mà nói “công ty keo kiệt hoặc, như hầu hết mọi tình huống khác, quá quan liêu” kém hợp lý hơn so với “có lý do chính đáng để không trả khoản thưởng mà bề ngoài có vẻ đã đáp ứng điều kiện”
      Nếu tác giả mô tả chính xác sự việc, thì có vẻ hợp lý hơn nhiều rằng các incentive vốn vận hành ở mọi nơi khác cũng đã thấm vào lĩnh vực này
    • Bạn đã từng báo cáo vấn đề bảo mật/quyền riêng tư cho Apple chưa? Tôi thì có. Hiện vẫn còn ít nhất một vấn đề đang mở với Apple
      Một trong số đó có thể được sửa bằng một dòng code mà không có tác dụng phụ nào, nhưng đã mở suốt 2 năm
      Đội bảo mật của Apple hoặc là không quan tâm, hoặc là bất tài; dù thế nào cũng đều không tốt
      Đó là một trong những trải nghiệm khiến tôi tức giận và bức bối nhất trong ngành điện toán
      Họ rõ ràng không muốn tôi chia sẻ vấn đề công khai, nhưng lại cứ kéo dài vô thời hạn
      Thành thật mà nói, tôi đang gần chạm giới hạn rồi
      Tôi chẳng quan tâm đến tiền thưởng, chỉ muốn lỗi được sửa
      Nếu có thể tin rằng họ đang xử lý vấn đề nghiêm túc, tôi sẽ cho họ nhiều thời gian nhất có thể, nhưng rất khó để tin như vậy
    • Đã có nhiều trường hợp được ghi nhận về việc các công ty công nghệ khổng lồ thẳng thừng từ chối chi trả
      Chẳng hạn như thay đổi quy tắc tham gia sau sự việc, lặng lẽ chặn nhà nghiên cứu bảo mật khỏi chương trình thưởng đang diễn ra, chuyển việc công bố thiện chí sang cơ quan điều tra, hoặc quản lý hành xử cực kỳ nhỏ nhen
      Chính vì “số tiền đó không đáng kể đối với công ty” nên kiểu xử lý lộn xộn này càng khó hiểu hơn

  • Lại thêm một cách khác để động vào quarantine flag. Cách kia là liên kết này: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
    Có vẻ như có quá nhiều hệ thống khác nhau có thể chỉnh sửa quarantine flag này

  • “Kẻ tấn công có thể gửi cho nạn nhân một lời mời lịch độc hại có đính kèm tệp… Trước khi được sửa, họ có thể gửi lời mời lịch độc hại cho bất kỳ người dùng Apple iCloud nào và đánh cắp iCloud Photos mà không cần người dùng tương tác.”
    Phạm vi này đến mức nào? Có nghĩa là bất kỳ ai, từ bất kỳ đâu trên macOS, cũng có thể gửi lời mời tùy ý cho bất kỳ người nào dùng iCloud sao? Ai lại không muốn thứ đó chứ?

    • Không có ý mỉa mai đâu, nhưng lời mời thì còn phải hoạt động kiểu gì nữa?
    • Tôi không hiểu. Nhận một lời mời lịch khác gì so với nhận email khác? Theo thiết kế, macOS có tự động xử lý gì đó đối với lời mời lịch không?
    • Google Calendar cũng vậy không phải sao?
    • Cái này có vẻ không chỉ đặc thù với iCloud. Nói chung lời mời được tự động nhận diện từ email
      Lời mời lịch từ lâu đã là nguồn spam, nên cũng không ngạc nhiên khi có cả lỗ hổng

  • “Nếu tệp do kẻ tấn công chỉ định đã tồn tại, tệp được chỉ định sẽ được lưu dưới tên PoC.txt-2. Tuy nhiên, nếu sự kiện/tệp đính kèm do kẻ tấn công gửi bị xóa sau đó, tệp có tên gốc (PoC.txt) sẽ bị loại bỏ. Lỗ hổng này có thể được dùng để xóa các tệp hiện có bên trong ‘sandbox’ hệ thống tệp.”
    Đây là kỹ thuật tệ hại

  • Tôi không thích lắm tình trạng tiền thưởng ở đây. Với các nhà nghiên cứu bảo mật, việc phải chờ lâu như vậy ở Apple hay các công ty tầm FAANG khác có phổ biến không?

    • Rất phổ biến

  • Chỉ riêng bước 1 đã là một lỗ hổng vô lý rồi. Làm sao Apple lại không tính đến chuyện này nhỉ?
    “Kẻ tấn công có thể thiết lập đường dẫn tùy ý tới tệp trong phần ATTACH, chẳng hạn FILENAME=../../../PoC.txt, để thực hiện thành công tấn công directory traversal.”

    • Điều này cho thấy một vấn đề lớn hơn có thể tồn tại ở mọi công ty. Chắc chắn có ai đó ở Apple đã viết một hàm thư viện để xử lý việc này an toàn, nhưng làm sao có thể bắt buộc mọi người dùng hàm đó?
      Đặc biệt nếu người review code cũng không biết thư viện đó, thì khó ngăn việc họ tự triển khai lại từ đầu theo cách không an toàn
      Có giải pháp hiện đại nào cho vấn đề kiểu này không?

  • Mỗi lần xuất hiện một lỗ hổng bảo mật lớn không liên quan đến an toàn bộ nhớ, tôi lại thấy phấn khích một cách kỳ lạ
    Tôi biết là hơi nhỏ nhen, nhưng tôi thích viễn cảnh tất cả thời gian và công sức đổ vào Rust cuối cùng lại thành công cốc chỉ vì một lỗi path traversal

  • Lockdown Mode có chặn được cái này không?

    • Hoàn toàn chỉ là phỏng đoán, nhưng hy vọng là có
      Nghĩ đến các exploit không cần nhấp trước đây liên quan đến tệp đính kèm hình ảnh, có vẻ Lockdown Mode được tạo ra để chặn những thứ như vậy và mọi tệp chắc cũng sẽ được xử lý theo cách đó

  • Chà. Một exploit khá cổ điển nhỉ
    Những thứ như đường dẫn nằm trong tên tệp thì tôi nhớ đã đọc từ khoảng 10 năm trước rồi