2 poin oleh GN⁺ 2025-05-13 | 1 komentar | Bagikan ke WhatsApp
  • Sistem izin TCC di macOS memiliki celah yang memungkinkan munculnya popup permintaan izin yang menyesatkan bagi pengguna
  • Kerentanan ini terdaftar sebagai CVE-2025-31250, dengan masalah bahwa persetujuan pengguna diterapkan ke aplikasi lain
  • Ada kemungkinan serangan spoofing di mana aplikasi berbahaya menampilkan jendela permintaan izin atas nama aplikasi tepercaya untuk mendorong persetujuan pengguna
  • Sudah ditambal di Apple macOS Sequoia 15.5, tetapi pada versi lain masih belum ditambal
  • Selain sulitnya memeriksa dan mencabut riwayat pemberian izin, ada juga kemungkinan kerentanan serupa muncul lagi di masa mendatang

Koreksi penting

  • Kerentanan ini telah ditambal di macOS Sequoia 15.5, tetapi pada macOS Ventura 13.7.6 dan macOS Sonoma 14.7.6 masih belum ditambal
  • Dikonfirmasi bahwa pelapor tidak disebutkan dalam catatan rilis keamanan Apple
  • Pengujian langsung di mesin virtual pada macOS Sonoma 14.7.6 memverifikasi bahwa kerentanan ini masih dapat dieksploitasi
  • Diperkirakan Ventura 13.7.6 juga berada dalam kondisi yang sama
  • Saat ini masih menunggu jawaban resmi dari Apple

Pengantar

  • Kerentanan CVE-2025-31250 adalah kondisi yang memungkinkan aplikasi menampilkan popup permintaan izin palsu di macOS
  • Saat "Application A" memunculkan popup, di popup itu dapat ditampilkan sebagai "Application B", dan pada akhirnya persetujuan izin pengguna diterapkan ke "Application C"
  • Biasanya ketiga aplikasi itu sama, tetapi celah ini memungkinkan penetapan aplikasi yang berbeda-beda
  • Akibatnya, timbul masalah besar pada keandalan jendela permintaan izin
  • Metode "spoofing" serupa sebelumnya pernah diperkenalkan di HackTricks dan tempat lain, tetapi kerentanan ini menggunakan cara yang lebih sederhana

TCC

  • TCC adalah sistem inti pengelolaan izin yang tertanam di Apple OS
  • Izin dikelola dengan mengirim pesan ke daemon "tccd", dan API publik memanggil fungsi framework TCC privat
  • Daemon tersebut berkomunikasi menggunakan XPC API milik Apple
  • Sebelum kerentanan ini ditambal, dengan mengirim pesan arbitrer, aplikasi yang ditampilkan pada popup permintaan izin dan aplikasi yang benar-benar menerima izin dapat ditentukan berbeda
  • Untuk memahami mengapa celah seperti ini muncul, perlu melihat Apple Events

Apple Events

Apa itu Apple Events

  • Apple Events adalah mekanisme komunikasi proses antar aplikasi di macOS
  • Ini adalah protokol yang telah berlanjut sejak era buku klasik yang diterbitkan pada 1993
  • Setelah hadirnya macOS X, protokol ini didesain ulang agar sesuai dengan arsitektur baru dan tetap digunakan
  • Di era modern, utamanya dipakai untuk otomasi (Automation), dengan skrip melalui AppleScript dan JavaScript
  • Mirip dengan Script Host di Windows, dan juga pernah disalahgunakan sebagai vektor malware

Apple Events dan TCC

  • Sejak macOS Mojave 10.14, pengiriman Apple Events memerlukan persetujuan pengguna
  • Di basis data penyimpanan izin TCC (TCC.db), tercatat aplikasi peminta, layanan, dan informasi respons persetujuan
  • Karena Apple Events perlu mengelola izin per aplikasi penerima secara terpisah, kolom indirect object di TCC.db digunakan
  • Fungsi TCCAccessRequestIndirect pada daemon TCC memproses pesan yang memanfaatkan kolom tersebut
  • Ada bug logika pada fungsi itu, sehingga aplikasi yang ditampilkan ke pengguna dan aplikasi yang benar-benar menerima izin bisa dibuat berbeda

Proof-of-Concept

  • Contoh kode Swift memanipulasi pesan permintaan izin sebagai berikut
    • Nama aplikasi pada jalur "spoofedBundle" diekspos ke popup persetujuan pengguna
    • Bundle ID dari "actualBundle" ditetapkan sebagai target penerima izin yang sebenarnya
  • Hasilnya, bagi pengguna tampak seolah aplikasi tepercaya yang meminta izin, tetapi izin sebenarnya diberikan ke aplikasi berbahaya
  • Bahkan dengan mengosongkan nilai "indirect_object", beberapa layanan TCC tetap bisa disasar
  • Hal ini menyebabkan runtuhnya keandalan persetujuan izin pengguna
  • Penyerang dapat menipu pengguna untuk mendorong aplikasi arbitrer memperoleh izin

Eksploitasi kerentanan

Batasan dan hal yang perlu diperhatikan

  • Hanya layanan TCC tertentu yang rentan terhadap serangan, tetapi layanan penting seperti Microphone dan Camera termasuk target
  • Untuk izin file/folder, dampaknya tidak terlalu besar karena ada perlindungan tambahan
  • Dapat dipakai bersama teknik rekayasa sosial agar pengguna menyetujui atas nama aplikasi lain yang sebenarnya membutuhkan izin

Pentingnya timing

  • Waktu untuk memunculkan popup sangat penting
  • Aplikasi berbahaya dapat mendeteksi aplikasi yang sedang berjalan dan aplikasi yang sedang berada di depan, lalu menampilkan popup pada waktu yang tepat agar pengguna bingung
  • Misalnya, saat FaceTime dijalankan, menampilkan popup izin Camera dapat membuat pengguna salah mengira itu permintaan izin yang sah
  • Skenario spoofing permintaan izin Microphone saat Voice Memos dijalankan juga dimungkinkan
  • Jika disalahgunakan dengan membidik waktu yang sesuai dengan konteks, tingkat keberhasilannya meningkat

Menyoroti kembali kerentanan lama

  • Ada kerentanan yang memanfaatkan fakta bahwa jalur TCC.db ditentukan berdasarkan folder home pengguna
  • Hingga 2020, cukup dengan mengubah variabel lingkungan HOME, TCC.db palsu bisa digunakan ($HOMERun)
  • Bahkan setelah ditambal, meskipun memerlukan hak root dan persetujuan pengguna, bypass izin masih dimungkinkan bila digabungkan dengan spoofing rekayasa sosial
  • Aplikasi berbahaya dapat mengakali dengan membujuk persetujuan pengguna, lalu mengubah folder home dan menambahkan basis data terdaftar untuk melewati ke TCC.db palsu
  • Pengujian nyata mengonfirmasi bahwa metode seperti ini dapat memengaruhi perilaku TCC

Timeline

1.

  • 2024-05-02 : Laporan awal dan pesan tambahan dikirim ke Apple Product Security

2.

  • 2024-05-03 : Apple Product Security meminta penjelasan tambahan dan menerima jawaban
  • Pada hari yang sama, kemungkinan bypass TCC secara menyeluruh ditemukan dan dilaporkan kembali ke Apple

3.

  • 2024-05-04 : Pengujian PoC berlanjut dan pesan pembaruan tambahan dikirim

4.

  • 2024-05-06 : Apple Product Security menyampaikan terima kasih atas informasi yang diberikan

5.

  • Setelah itu, status patch terus ditanyakan dan diperiksa secara berkala; dari 2024-06 hingga 2025-02 komunikasi dengan Apple terus berlanjut, tetapi perbaikannya lama tidak dilakukan

6.

  • 2025-05-12 : Rilis patch untuk bug ini dipublikasikan

Kesimpulan

Hal lainnya

  • TCC ditampilkan pada bagian Privacy & Security (sebelumnya Security & Privacy) di aplikasi System Settings serta pada bagian Automation terkait
  • Namun, karena riwayat persetujuan terkait Apple Events tidak terlihat di GUI, pengguna sulit mencabutnya secara langsung
  • Pembatalan bisa dilakukan dengan alat CLI tccutil, tetapi hampir tidak dikenal
  • Belakangan, framework Apple Endpoint Security menambahkan kemampuan pemantauan perubahan basis data TCC
  • Jika berfungsi sebagaimana mestinya, ini dapat membantu mencegah penyalahgunaan dengan memberi tahu pengguna aplikasi mana yang benar-benar menerima izin

Patch dari Apple

  • Isi patch yang sebenarnya cukup kompleks; pesan dari luar yang menentukan indirect object secara arbitrer kini diubah agar diam-diam diabaikan oleh tccd
  • Verifikasi perilaku menunjukkan bahwa spoofing tidak lagi dimungkinkan
  • Jika patch ini tidak lengkap, pembaruan berikutnya mungkin memerlukan langkah tambahan

Pemikiran terakhir

  • Kerentanan ini diberi nama "TCC, Who?"
  • Dari sudut pandang peneliti keamanan, ini kembali menegaskan pentingnya keandalan sistem izin
  • Ini juga mengisyaratkan bahwa celah serupa masih mungkin ditemukan di masa depan
  • Hal ini menyiratkan bahwa pengguna tidak boleh sepenuhnya mempercayai popup izin macOS

1 komentar

 
GN⁺ 2025-05-13
Pendapat Hacker News
  • Dengan harapan yang sangat kecil bahwa seseorang di Apple akan melihat tulisan ini, saya akan mengulangi permintaan yang selalu ingin saya sampaikan—semoga Apple berhenti memunculkan dialog 'masukkan kata sandi (admin lokal) sekarang' secara acak kapan saja, hanya karena komputer merasa ingin melakukan pembaruan atau memasang sesuatu. Dengan kemampuan teknis yang sangat dasar pun, orang bisa dengan mudah membuat popup palsu yang tampilannya hampir sama persis di web, dan sebagian besar pengguna di luar kira-kira 20% teratas secara teknis bahkan tidak akan terpikir untuk membedakan apakah ini asli atau palsu yang dibuat di dalam browser. Untuk mencegah masalah seperti ini dari akarnya, pengguna perlu dibiasakan bahwa perangkat lunak yang sah tidak tiba-tiba memunculkan dialog kata sandi di tengah pekerjaan tanpa peringatan apa pun, tetapi UI keamanan macOS saat ini justru kebalikannya. Harusnya diubah, misalnya dengan menampilkan ikon yang mencolok dan berwarna di menu bar, atau seperti Windows yang sesaat menampilkan layar keamanan terpisah. Desain UI yang sekarang benar-benar bermasalah

    • Hal yang paling saya benci dari popup semacam ini adalah saya sama sekali tidak tahu kenapa ini diminta, apa yang terjadi kalau saya menolak, dan kalau nanti saya ingin mengubah pengaturan ini, saya harus melakukan apa. Saat aplikasi memberi instruksi seperti 'buka panel pengaturan dan berikan izin XXX', kita bisa melihat dengan jelas aplikasi, izin, dan toggle yang dimaksud, tetapi popup kata sandi tidak memberi UX seperti itu. Karena itu saya jadi kurang menyukai konsep capabilities, UX-nya terlalu tidak nyaman dan nyaris tidak terhindarkan. Nanti pasti akan muncul sesuatu seperti 'agar dapat menggunakan aplikasi sepenuhnya, izinkan <root my computer>', karena kalau vendor yang menentukan pesannya, hasilnya selalu akan seperti itu. UX yang sama sekali tidak membantu

    • Kalau macOS masih menampilkan jendela modal yang menempel pada window, mungkin situasi ini akan sedikit lebih baik. Tidak sepenuhnya menyelesaikan masalah, tapi setidaknya agak membaik. Saat modal menutupi area di atas toolbar seperti sekarang, kesannya jelas terasa sebagai 'bagian dari aplikasi'. Saat Steve Jobs mendemokan Aqua pun dia menekankan bahwa modal yang melayang terpisah seperti ini menurunkan kegunaan, tetapi sekarang saya rasa Apple jadi begini karena obsesi aneh untuk memakai UI mobile di semua layar

    • Keluarga saya yang tidak paham teknologi bahkan tidak bisa membedakan kata sandi perangkat lokal dengan kata sandi iCloud/Apple ID, jadi mereka memasukkan apa saja sampai ada yang berhasil (dan ini terjadi karena UI-nya tidak jelas dan tidak konsisten). Dulu Apple mengejek UAC milik Vista, tetapi sekarang mereka sendiri dipenuhi notifikasi mendadak dan UI yang serampangan

    • Saya baru-baru ini pindah dari Linux ke Mac, dan popup kata sandi root yang muncul acak benar-benar membingungkan. Tidak ada penjelasan aplikasi atau perintah mana yang meminta hak root, atau kenapa itu diperlukan, jadi setelah beberapa kali saya izinkan, saya mulai menolak saja. Setelah itu popup-nya tidak muncul lagi. Tapi saya tetap sama sekali tidak tahu popup itu sebenarnya untuk apa, atau kenapa sekarang sudah tidak muncul

    • Saya ingin merekomendasikan lagi tulisan klasik ini: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/

    • Popup Passkey sama sekali tidak bisa dibedakan dari popup JavaScript, jadi ini kesalahan yang sangat serius dari sisi keamanan

    • Dalam situasi seperti ini, pemindai sidik jari bawaan benar-benar terasa sangat membantu. Biasanya layar laptop saya tutup dan saya pakai monitor eksternal saja, tetapi saat perlu autentikasi sistem, saya sengaja membukanya untuk autentikasi dengan sidik jari

    • Plot twist: sebenarnya dialog seperti itu tidak pernah ada sejak awal! Anda sudah tertipu

    • Saya ingin menumpang pada komentar yang paling populer saat ini untuk memberi tahu bahwa ada pembaruan penting pada artikel ini: https://news.ycombinator.com/item?id=43969087

    • Saya penasaran apa model ancamannya saat orang mengklik popup palsu. Jika itu bukan benar-benar dari sistem, bukankah itu hanya manipulasi yang tidak berarti?

    • Saat login ke iCloud, muncul popup yang meminta kata sandi lokal komputer, dan jika Anda memasukkannya, kata sandi itu diunggah ke server iCloud

  • Baru-baru ini saya tahu bahwa aplikasi Mac sebaiknya dipasang di Applications milik direktori home saya, bukan di Applications tingkat sistem (~/Applications), tentu saja ini hanya masuk akal untuk komputer yang dipakai satu orang. Jika saya menurunkan diri saya menjadi pengguna non-admin, lalu memasang aplikasi di Applications dalam home directory, permintaan izin saat update tidak akan mengganggu. Sebagian besar aplikasi bisa memperbarui diri sendiri meski bukan admin. Pengecualiannya hanya aplikasi yang butuh integrasi dengan OS seperti Tailscale, yang memang memerlukan izin terpisah. Sebagai catatan, ini adalah pendekatan yang direkomendasikan oleh aplikasi bernama Pareto Security

    • Sayangnya, hampir semua pengembang aplikasi juga tidak tahu cara ini, dan banyak aplikasi bahkan hanya mau dipasang di jalur /Applications sehingga tidak berfungsi di lokasi lain

    • Jika aplikasi dipasang di ~/Applications, auto-update bisa berjalan tanpa root, tetapi itu juga berarti kode mencurigakan bisa lebih mudah menimpa aplikasi tanpa hak root

    • Saya memakai macOS 15.4.1 dan folder ~/Applications itu sendiri tidak ada

    • Menarik sekali! Saya sendiri sulit memakai cara ini karena dalam penggunaan sehari-hari saya memang perlu akun admin, tetapi bagi yang cocok, ini benar-benar trik yang layak dipakai

  • Tulisan ini perlu koreksi penting. Sebelumnya disebutkan bahwa CVE ini sudah ditambal di macOS Sequoia 15.5, tetapi kenyataannya patch itu tidak diterapkan di macOS Ventura 13.7.6 dan macOS Sonoma 14.7.6 yang dirilis pada hari yang sama. Saya menuliskannya begitu karena mengira Apple tentu memasukkan patch ke semua versi, tetapi setelah melihat nama saya tidak tercantum pada catatan rilis keamanan untuk dua versi lainnya, saya langsung menghubungi Apple. Sampai sekarang belum ada jawaban. Untuk pengujian langsung, saya menjalankan mesin virtual, memasang patch di macOS Sonoma 14.7.6, lalu menjalankan PoC saya, dan kerentanannya masih tetap berfungsi. Saya menduga Ventura 13.7.6 juga sama. Saya tidak mengerti kenapa Apple tidak memasukkan patch-nya. Kalau ada informasi tambahan, saya akan memperbarui tulisan ini lagi

  • Sistem TCC di macOS punya reputasi sebagai mekanisme privasi yang kuat, tetapi rasanya pahit jika diingat bahwa pada praktiknya itu bisa dilewati dengan mudah hanya lewat satu entri database. Popup persetujuan pengguna tidak banyak berarti di hadapan manipulasi database yang sebenarnya, terutama di lingkungan pengembangan dengan SIP dimatikan. Ini pada akhirnya soal kepercayaan. Apakah persetujuan di level UX masih benar-benar merupakan batas keamanan yang nyata, patut dipertanyakan. Kita makin bergantung pada popup izin di level OS, tetapi jika batas itu pada kenyataannya hanyalah ilusi (atau sekadar pertunjukan), maka kita perlu memikirkan ulang bagaimana kepercayaan atas izin dipertahankan secara nyata, bukan sekadar 'ditampilkan'

    • Saya setuju bahwa akan jauh lebih baik jika sistem capabilities yang sesungguhnya benar-benar diimplementasikan. Tapi kalau akhirnya tetap berupa database, ada dilema apakah itu harus disimpan di user space atau di kernel. Dan terus terang, saya tidak benar-benar suka kedua pilihannya
  • Saya ingat dulu iklan 'I'm a Mac and I'm a PC' mengejek elemen-elemen Vista seperti ini. Tetapi sekarang Mac saya malah lebih buruk daripada Vista. Sangat menjengkelkan

    • Kompromi antara keamanan dan ekstensibilitas rasanya memang tak terhindarkan. Meski begitu, ada juga sisi bahwa batas dasarnya sudah bergeser dibanding dulu. Setidaknya macOS tidak dibanjiri proses jahat seperti Windows lama. Atau mungkin saya cuma beruntung dan cukup hati-hati

    • Ini hanya rasa penasaran, tapi saya ingin tahu bagian mana yang khususnya terasa sangat menjengkelkan bagi Anda

  • Sistem TCC sejak awal memang dibangun dengan arsitektur yang amat rapuh. Yang diganggu justru para pengembang sah, sementara pengguna dibombardir popup permintaan izin, dan aplikasi jahat tetap melewati 'pertunjukan keamanan' ini lewat berbagai jalur, seperti yang terus ditemukan para peneliti. Saya bukan peneliti keamanan, tetapi sebagai pengembang Mac saya juga telah menemukan beberapa cara bypass. Saya bahkan meragukan apakah para engineer Apple sendiri benar-benar memahami teknologi yang mereka pakai. Saya penasaran sebenarnya berapa banyak pengembang Mac tradisional yang masih tersisa

    • Karena fungsi-fungsi sistem dasar terus ditambahkan ke TCC, gesekan dalam deployment software manajemen enterprise di Mac jadi sangat besar (terutama di bidang pendidikan). Sampai membuat saya mempertanyakan nilainya sendiri. Ini kesan saya setelah bekerja sebagai pengembang macOS (Cocoa) sejak 2003
  • Saya memakai Mac kantor, dan secara berkala muncul notifikasi 'Slack sedang mencoba memasang helper tool baru'. Saya sama sekali tidak tahu apa ini atau kenapa muncul. Saya bertanya ke tim IT dan mereka juga tidak tahu cara mengeceknya. Saya cukup sering berpikir ini bisa disalahgunakan, karena terus meminta kata sandi, dan walaupun saya selalu menekan batal, itu tetap muncul lagi setiap waktu

    • Dialog itu dikirim oleh framework System Management. Itu adalah proses untuk memasang helper tool berhak istimewa agar Slack bisa memperbarui dirinya sendiri terlepas dari di mana ia dipasang atau pengguna mana yang menginstalnya

    • Setiap kali popup seperti ini muncul, saya selalu hanya menekan batal karena tidak ada cara untuk tahu informasi apa yang harus saya lihat agar bisa memutuskan boleh atau tidak

    • Saya memakai Slack sebagai web app (tetapi bukan di dalam browser, melainkan di jendela terpisah) https://support.apple.com/en-us/104996 Discord juga bisa dipakai dengan cara yang sama. Menurut pengalaman saya, ini jauh lebih nyaman daripada aplikasi Electron. Untuk kebanyakan aplikasi Electron, cara ini lebih baik

    • Saya sendiri belum pernah melihat popup 'helper tool', tetapi saya tidak mengerti kenapa aplikasi pesan sederhana seperti Slack membutuhkan izin semacam itu. Mungkin sebaiknya tanya ke tim dukungan Slack (dan semoga kali ini Anda benar-benar mendapat jawaban yang layak)

    • Seperti aplikasi yang memerlukan kata sandi pada umumnya (misalnya biner yang di Linux hanya berjalan sebagai root), potensi penyalahgunaan jelas ada. Pada akhirnya ini soal apakah Anda bisa mempercayai pengembang dan keaslian aplikasi tersebut. Pada hari Apple benar-benar memblokir aplikasi eksternal agar sama sekali tidak bisa mendapat hak root, hari itu Mac akan menjadi walled garden sepenuhnya, dan tempat ini (HN) akan dipenuhi komentar keluhan. Kesimpulannya, penting untuk punya 'ketidakpercayaan yang sehat' dan tidak memberi hak root pada aplikasi yang kebutuhannya tidak jelas seperti Slack

    • Dia merebut fokus input secara paksa, sehingga teks yang sedang saya ketik untuk pesan tiba-tiba mulai masuk ke kolom kata sandi. Pengalaman yang sangat menjengkelkan

    • Popup-nya menumpuk dengan jeda waktu. Kalau saya menyalakan komputer setelah akhir pekan, popup itu terus muncul berulang sampai saya akhirnya menutup Slack begitu saja. Sudah 1 tahun seperti ini. Saya tidak tahu bagaimana mencabut izin ini dari Slack, rasanya agak bernuansa jahat

    • Alat pemblokir 'keamanan' seperti ini benar-benar terasa bodoh. Malah melatih orang menjadi lebih bodoh. Hari ini mungkin asli, besok belum tentu. Saya terus mendapat telepon dari bank yang meminta data pribadi saya atas nama 'perlindungan identitas', dan perangkat-perangkat seperti ini pada akhirnya melatih orang untuk menyerahkan informasi pribadi kepada orang asing

    • Saya bukan pengembang macOS, tetapi saya penasaran apakah aplikasi apa pun (yang berniat jahat) bisa meniru gaya jendela popup sistem untuk mencuri kata sandi pengguna

    • VSCode juga memunculkan popup yang sama di Mac kantor yang diberikan perusahaan. Sudah saya abaikan begitu saja selama bertahun-tahun

    • Di semua aplikasi berbasis Electron, popup seperti ini muncul kalau Anda memakai beberapa akun pengguna OS

    • nordVPN juga mengalami hal yang sama

  • Apple butuh tepat 1 tahun untuk merilis patch. Rasanya cukup lama. <i>2024-05-04 meninggalkan beberapa pesan pembaruan, masih terus menguji PoC</i> <i>2025-05-12 patch dirilis</i>

    • Saya juga setuju 1 tahun itu sangat lama. Saya rasa mungkin memang ada alasan yang sah (internal?) untuk perilaku yang saya temukan, lalu mereka butuh waktu lama untuk menyeimbangkannya dengan kasus penyalahgunaan, atau mungkin memang prioritasnya rendah. Bagaimanapun juga, fakta bahwa patch-nya butuh 1 tahun terasa mengejutkan
  • Adobe Creative Cloud tetap menjalankan banyak proses di latar belakang meskipun eksekusi latar belakang sudah dimatikan secara eksplisit di pengaturan sistem

  • Saya sangat menyukai riset orang ini, dan presentasinya juga terasa sangat bagus

    • Terima kasih! Sebagai catatan, saya bukan laki-laki, hanya ingin memberi tahu bahwa saya adalah seorang perempuan