Rantai Kerentanan Undangan Calendar Zero-Click di macOS

 (medium.com/@mikko-kenttala)
1 poin oleh GN⁺ 2024-09-14 | 1 komentar | Bagikan ke WhatsApp
  • Karena cacat dalam penanganan lampiran undangan di macOS Calendar, penyerang dapat melakukan penulisan dan penghapusan file arbitrer di dalam sandbox Calendar, dan masalah ini berujung pada rantai eksekusi kode jarak jauh serta akses ke data Photos
  • Tahap 1, CVE-2022-46723, tidak membersihkan dengan benar input traversal path seperti FILENAME=../../../PoC.txt di bagian ATTACH, sehingga lampiran bisa disimpan di luar lokasi yang dimaksud
  • Rantai eksekusi kode jarak jauh memanfaatkan perilaku Open File Calendar dalam proses upgrade dari Monterey ke Ventura untuk menyuntikkan beberapa file, lalu menggabungkan DMG, mount SMB, dan skema URL kustom
  • Pada tahap Photos, pengaturan berbahaya diterapkan dengan defaults import untuk mengubah System Photo Library menjadi /var/tmp/mypictures/Syndication.photoslibrary, sehingga foto asli iCloud disinkronkan ke direktori yang tidak dilindungi TCC
  • Apple telah memperbaiki semua kerentanan terkait antara Oktober 2022 dan September 2023; kerentanan Photos ditangani sebagai CVE-2023-40434, sedangkan bypass Gatekeeper sebagai CVE-2023-40433

Traversal path pada lampiran Calendar

  • Undangan Calendar berbahaya dapat memuat lampiran file, dan kurangnya validasi nama file lampiran memungkinkan traversal direktori
  • Penyerang dapat menentukan path arbitrer di bagian ATTACH, seperti FILENAME=../../../PoC.txt
    • Lokasi penyimpanan normal adalah ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/
    • Dalam perilaku yang rentan, file disimpan di ~/Library/Calendar/PoC.txt
  • Jika sudah ada file dengan nama yang sama, file baru disimpan sebagai PoC.txt-2, tetapi ketika event atau lampiran yang dikirim penyerang kemudian dihapus, PoC.txt dengan nama asli dapat ikut terhapus
  • Perilaku ini juga dapat digunakan untuk menghapus file yang sudah ada di dalam sandbox Calendar pada filesystem
  • Kerentanan ini setidaknya ada pada versi terbaru macOS Monterey 12.5, dan terkonfirmasi tidak lagi rentan di macOS 13.0 beta4

Rantai yang diperluas menjadi eksekusi kode jarak jauh

  • Kerentanan yang ditemukan tepat sebelum rilis macOS Ventura diperluas menjadi eksekusi kode jarak jauh dengan memanfaatkan proses upgrade versi dan fitur Open File di Calendar
  • Penyerang menyuntikkan beberapa file melalui kerentanan penulisan file arbitrer Calendar, lalu mengonfigurasikannya agar rantai RCE berjalan saat upgrade dari Monterey ke Ventura

  • Komposisi file yang disuntikkan

    • 000Hacked-$RANDOM.calendar
      • Berisi data Calendar yang tampak seperti Calendar “Siri Suggested”
      • Mencakup event berulang dan fitur notifikasi, serta berperilaku untuk membuka file lain yang disuntikkan
    • CalendarTruthFileMigrationInProgress
      • File yang membuat Calendar yang sudah ada di-upgrade dan digabungkan dari format lama ke database baru
    • CalPoCInit.dmg
      • Notifikasi Calendar pertama membuka ~/Library/Calendars/CalPoCInit.dmg
      • Bookmark dalam .DS_Store di dalam DMG memuat referensi gambar latar dari server Samba eksternal
      • Meskipun CalPoCInit.dmg sendiri berada dalam status karantina, proses mount terjadi tanpa quarantine flag
    • stage1.url
      • Notifikasi Calendar kedua membuka ~/Library/Calendars/stage1.url
      • File ini memuat URL file:///Volumes/CalPoCPayload/MyMidiTest.app yang menunjuk ke aplikasi di dalam volume Samba yang di-mount pada tahap sebelumnya
      • Saat Finder membuka /Volumes/CalPoCPayload/, indexing terjadi otomatis dan MyMidiTest.app ikut terindeks
      • Info.plist pada app bundle mendaftarkan handler skema URL kustom mymiditest
    • stage2.url
      • Notifikasi Calendar ketiga membuka ~/Library/Calendar/stage2.url
      • File ini mereferensikan mymiditest:// untuk menjalankan aplikasi berbahaya tanpa interaksi pengguna

Bypass Gatekeeper dan eksekusi aplikasi

  • Eksekusi mymiditest:// dimungkinkan karena aplikasi berada di dalam mount Samba yang dibuat oleh exploit, dan lokasi tersebut tidak memiliki quarantine flag
  • Aplikasi mymiditest menulis file yang diperlukan untuk tahap 3 ke /var/tmp/, lalu menjalankan skrip di Terminal dengan open /var/tmp/PhotosPoC.sh
  • Seluruh rantai dikonfigurasi untuk menyuntikkan beberapa file demi keluar dari sandbox Calendar, melewati mitigasi Gatekeeper dengan trik SMB, lalu menjalankan kode arbitrer

Akses foto iCloud melalui perubahan pengaturan Photos

  • Tahap setelah eksekusi kode jarak jauh berfokus pada perubahan pengaturan Photos untuk mengakses data foto sensitif pengguna, terutama iCloud Photos
  • Biasanya akses ke file sensitif seperti Photos seharusnya dibatasi oleh TCC, tetapi dengan mengubah pengaturan Photos, System Photo Library dapat diarahkan ke path yang tidak dilindungi TCC
  • Penyerang dapat membuat file pengaturan Photos yang menggunakan System Photo Library lain, lalu mengimpornya dengan defaults import
  • Dalam rantai PoC, tahap 2 secara otomatis menyiapkan pengaturan yang menggunakan /var/tmp/mypictures/Syndication.photoslibrary sebagai System Photo Library
    • File pengaturan berbahaya terkait dibuat di /var/tmp/mypictures/*.plist
    • Aplikasi terkait Photos yang sedang berjalan dihentikan
    • Pengaturan asli dicadangkan ke /var/tmp/mypictures/*-orig.plist
    • Pengaturan berbahaya diimpor dari /var/tmp/mypictures/
    • Library foto baru dibuka di Photos dengan open /var/tmp/mypictures/Syndication.photoslibrary
  • Syndication.photoslibrary adalah library template kosong, dan ketika Photos berjalan dengan library ini sebagai System Photo Library baru, sinkronisasi iCloud diaktifkan dan file asli diunduh ke direktori yang tidak dilindungi
  • File yang tersinkronisasi ke disk disalin ke direktori baru di bawah /var/tmp/PoCLoot$RANDOM/
  • Dengan sedikit modifikasi, PoC dapat menyalin data ke resource eksternal atau memublikasikannya ke server web eksternal menggunakan perintah curl

Jadwal perbaikan dan isu bounty yang tersisa

  • Seluruh rantai harus melewati penghalang keamanan macOS secara berurutan
    • Menyuntikkan beberapa file ke Calendar untuk melewati sandbox dan mengaktifkan tahap berikutnya
    • Melewati mitigasi Gatekeeper dengan trik SMB untuk menjalankan kode arbitrer
    • Melewati perlindungan TCC untuk mengakses data sensitif seperti iCloud Photos
  • Sebelum diperbaiki, undangan Calendar berbahaya dapat dikirim ke pengguna Apple iCloud dan mencuri iCloud Photos tanpa interaksi pengguna
  • Apple memperbaiki semua kerentanan terkait antara Oktober 2022 dan September 2023

  • Timeline

    • 2022-08-08: Penulisan dan penghapusan file arbitrer di dalam sandbox Calendar dilaporkan
    • 2022-10-24: Diperbaiki di macOS Monterey 12.6.1 dan Ventura 13
      • Item ini tidak memiliki CVE, dan Ventura beta3 masih rentan
    • 2022-11-14: PoC yang memperluas kerentanan Calendar menjadi eksekusi kode arbitrer dan bypass Gatekeeper dikirimkan
    • 2022-12-04: PoC akses iCloud Photos dikirimkan
    • 2023-02-20: Kredit dan CVE CVE-2022-46723 ditambahkan untuk kerentanan Calendar
    • 2023-03-27: Bypass Gatekeeper diperbaiki di macOS Ventura 13.3
      • Pada saat itu belum ada CVE maupun kredit
    • 2023-09-26: Kerentanan Photos CVE-2023-40434 diperbaiki dan kredit diberikan
    • 2023-10-09: Bug bounty terkait bypass Gatekeeper dan kerentanan Photos diumumkan
    • 2023-12-21: Kredit CVE-2023-40433 diberikan untuk bypass Gatekeeper
    • 2024-09-12: Masih belum ada bounty terkait kerentanan penulisan dan penghapusan file arbitrer Calendar asli, CVE-2022-46723
    • Pembaruan 2024-10-20: Apple memutuskan bahwa kerentanan penulisan dan penghapusan file arbitrer Calendar CVE-2022-46723 bukan対象 bounty karena hanya berdampak pada macOS Monterey dan Ventura sudah tidak memiliki masalah ini sejak tahap beta

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-14
Komentar Hacker News

  • Untung saya tidak memakai iCloud Photo Library, tetapi aneh bahwa jika lokasi pustaka foto diubah, lokasi baru itu sama sekali tidak mendapat perlindungan apa pun
    Jika /var/tmp/mypictures/Syndication.photoslibrary ditetapkan sebagai pustaka foto sistem lalu Photos dibuka, saya mengira eksploitnya akan gagal karena aplikasi Photos seharusnya melindungi direktori ini
    Saat saya coba cepat di Sonoma 14.6.1, jika membuka Photos sambil menekan tombol Option dan membuat pustaka foto baru di ~/Pictures, aplikasi tanpa izin Full Disk Access maupun izin Photos akan ditolak mengakses folder tersebut
    Namun jika pustaka foto baru dibuat di /tmp, aplikasi yang sama bisa mengaksesnya, dan perilaku ini membingungkan serta tidak konsisten
    Jika Apple benar-benar ingin mendukung fitur memindahkan pustaka foto ke mana saja di sistem file, perlindungannya juga harus diterapkan dengan benar

    • Sampai batas tertentu ini bisa dimengerti. Secara historis, /tmp adalah lokasi dalam hierarki direktori yang bisa dibaca dan ditulis siapa saja, dan bukan pilihan yang baik untuk menyimpan data privat
    • Sejak dulu TCC memang cenderung agak aneh dan banyak celah seperti ini
    • Di Linux, sekarang jauh lebih mudah mengisolasi semuanya dibandingkan macOS
      Bahkan tanpa AppArmor atau Firejail, sebagian besar layanan secara default mendapat direktori sementara khusus

  • Di thread ini ada banyak pembahasan soal pembayaran bug bounty, tetapi kalau perusahaan teknologi raksasa yang menjalankan program bounty permanen tidak membayar, biasanya besar kemungkinan ada alasan yang masuk akal
    Insentif program seperti ini hampir semuanya selaras ke arah memberi bounty untuk submission yang sah
    Ini salah satu kasus langka ketika insentifnya cukup selaras: perusahaan membuat program bounty untuk mendorong jenis riset tertentu, dan tidak membayar imbalan yang sah bertentangan dengan tujuan itu
    Penanggung jawab di sisi vendor juga bukan memakai uang pribadi, dan jumlahnya pun tidak signifikan bagi perusahaan
    Biasanya anggota tim pengelola program lebih termotivasi untuk membayar lebih banyak, bukan lebih sedikit

    • Tidak. Ini karena tim product security Apple yang menyelidiki dan membayar bug bounty dikelola dengan buruk dan tidak efisien
      Baru-baru ini dipindahkan dari kantor program SWE ke SEAR (security engineering & arch), dan manajernya juga baru-baru ini didepak lalu pindah ke AirBNB
      Sebagian besar anggota tim adalah ICT2·ICT3 setingkat lulusan baru, orang-orang yang bahkan tidak akan lolos wawancara coding di bagian lain perusahaan, dan terutama bekerja seperti penyortir bug
      Mereka menghabiskan lebih banyak waktu pergi ke konferensi dan bergaul dengan para hacker daripada bekerja di depan komputer
      Grafik di portal ‘investigasi berjalan’ terus naik saja, yang berarti email hanya menumpuk dan mereka bahkan tidak berusaha mengejarnya
      Orang-orang yang seharusnya menerima bounty tetapi belum menerimanya harus menekan Ivan secara publik di Twitter, kepala SEAR, agar melihat kemajuan
    • Bisa jadi benar. Program bug bounty Apple yang buruk mungkin akibat ketidakmampuan, bukan niat jahat yang disengaja
      Namun apakah itu penting bagi peneliti keamanan atau publik? Tidak. Apa pun alasan kerusakannya, Apple harus memperbaiki program bounty-nya
      Pada akhirnya tulisan blog ini hanyalah satu contoh lagi yang ditambahkan ke tumpukan besar yang sudah ada[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-...
    • Kecuali maksudnya penulis memelintir situasi, saya tidak tahu “alasan yang sangat baik” apa yang mungkin ada ketika ada catatan jelas bahwa seseorang sudah melaporkan bug itu jauh sebelum diperbaiki
      Paling baik pun ini tampak seperti birokrasi lamban yang klasik, dan itu bukan alasan yang terlalu baik
      Jika perusahaan benar-benar mendorong hal seperti ini, tidak ada alasan persetujuannya memakan waktu lebih dari setahun
      Logikanya mungkin benar, tetapi melihat situasi seperti ini, sulit mengatakan bahwa “perusahaan pelit atau terlalu birokratis seperti hampir selalu terjadi di semua situasi lain” kurang masuk akal dibanding “ada alasan yang sah untuk tidak membayar bounty yang dari luar tampaknya sudah memenuhi syarat”
      Jika penulis menggambarkan kasusnya secara akurat, jauh lebih masuk akal bahwa insentif yang berlaku di semua tempat lain juga merembes ke ranah ini
    • Pernah melaporkan masalah keamanan dan privasi ke Apple? Saya pernah. Saat ini pun masih ada setidaknya satu kasus yang terbuka di Apple
      Salah satunya bisa diperbaiki dengan satu baris kode tanpa efek samping, tetapi sudah terbuka selama 2 tahun
      Tim keamanan Apple entah tidak peduli atau tidak kompeten, dan keduanya sama-sama buruk
      Itu salah satu pengalaman paling membuat marah dan frustrasi yang pernah saya alami di dunia komputasi
      Mereka jelas ingin masalahnya tidak dibagikan secara publik, tetapi hanya mengulur-ulurnya tanpa batas
      Jujur saja saya hampir mencapai batas
      Saya sama sekali tidak peduli soal bounty, saya hanya ingin bug-nya diperbaiki
      Kalau saya bisa percaya bahwa mereka menangani kasus ini dengan serius, saya akan memberi kelonggaran semaksimal mungkin, tetapi sulit untuk percaya begitu
    • Ada banyak kasus terdokumentasi ketika perusahaan teknologi raksasa sama sekali menolak membayar
      Caranya dengan mengubah aturan partisipasi setelah kejadian, diam-diam memblokir peneliti keamanan dari program bounty yang sedang berjalan, menyerahkan pengungkapan beritikad baik ke aparat penegak hukum, atau para manajernya bersikap luar biasa picik
      Justru karena “jumlahnya tidak berarti bagi perusahaan”, penanganan yang kacau seperti ini semakin sulit dipahami

  • Ini cara lain untuk mengutak-atik flag karantina. Yang satu lagi adalah tautan ini: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
    Tampaknya terlalu banyak sistem berbeda yang bisa memodifikasi flag karantina ini

  • “Penyerang dapat mengirim undangan kalender berbahaya yang menyertakan lampiran file kepada korban… sebelum diperbaiki, mereka bisa mengirim undangan kalender berbahaya ke pengguna Apple iCloud mana pun dan mencuri iCloud Photos tanpa interaksi pengguna.”
    Seberapa luas cakupannya? Apakah ini berarti siapa pun di mana saja di macOS bisa mengirim undangan arbitrer ke siapa pun yang memakai iCloud? Siapa yang tidak menginginkan itu?

    • Bukan bermaksud sinis, tapi memangnya undangan seharusnya bekerja seperti apa lagi?
    • Saya tidak paham. Apa bedanya menerima undangan kalender dengan menerima email lain? Apakah macOS secara desain memproses sesuatu secara otomatis untuk undangan kalender?
    • Bukankah Google Calendar juga sama?
    • Sepertinya ini tidak khusus iCloud saja. Secara umum, undangan memang otomatis ditangkap dari email
      Undangan kalender sudah lama menjadi sumber spam, jadi tidak mengejutkan kalau ada kerentanan juga

  • “Jika file yang ditentukan penyerang sudah ada, file yang ditentukan akan disimpan dengan nama PoC.txt-2. Namun jika event/lampiran yang dikirim penyerang kemudian dihapus, file dengan nama asli (PoC.txt) akan dihapus. Kerentanan ini dapat digunakan untuk menghapus file yang sudah ada di dalam ‘sandbox’ sistem file.”
    Ini rekayasa yang buruk

  • Saya kurang suka dengan status bounty di sini. Dari sisi peneliti keamanan, apakah menunggu selama ini pada Apple atau perusahaan sekelas FAANG lainnya merupakan hal yang umum?

    • Sangat umum

  • Tahap 1 saja sudah merupakan kerentanan yang tidak masuk akal. Bagaimana Apple bisa tidak mempertimbangkan ini?
    “Penyerang dapat menetapkan path arbitrer untuk file di bagian ATTACH, seperti FILENAME=../../../PoC.txt, sehingga berhasil melakukan serangan directory traversal.”

    • Ini menunjukkan masalah yang lebih besar yang mungkin ada di semua perusahaan. Seseorang di Apple pasti pernah menulis fungsi library yang menangani ini dengan aman, tetapi bagaimana cara memaksa orang memakai fungsi itu?
      Terutama kalau code reviewer pun tidak tahu soal library tersebut, sulit mencegah orang mengimplementasikannya ulang dari awal dengan cara yang tidak aman
      Apakah ada solusi modern untuk masalah seperti ini?

  • Setiap kali muncul celah keamanan besar yang bukan terkait memory safety, entah kenapa saya agak senang
    Saya tahu ini agak picik, tetapi saya suka gagasan bahwa semua waktu dan energi yang dicurahkan ke Rust pada akhirnya bisa menjadi sia-sia hanya karena satu bug path traversal

  • Apakah Lockdown Mode mencegah ini?

    • Tebakan murni, tapi saya harap begitu
      Kalau mengingat eksploit zero-click lama terkait lampiran gambar, Lockdown Mode tampaknya dibuat untuk mencegah hal semacam itu, dan sepertinya semua file akan diperlakukan dengan cara seperti itu

  • Wow. Eksploit yang cukup jadul ya
    Hal seperti path di dalam nama file rasanya pernah saya baca sekitar 10 tahun lalu