Bisakah Popup Izin macOS Dipercaya?

• CVE-2025-31250 adalah kerentanan yang membuat popup persetujuan izin TCC di macOS sulit dipercaya, karena bisa membuat aplikasi yang terlihat di layar berbeda dari aplikasi yang benar-benar menerima izin
• Masalahnya ada pada pemrosesan TCCAccessRequestIndirect di tccd; target_path digunakan untuk nama aplikasi yang ditampilkan di popup, sedangkan target_identifier digunakan sebagai pengenal aplikasi yang benar-benar menerima izin
• Tidak seperti bypass sebelumnya, ini tidak memerlukan aplikasi palsu, pintasan Dock, atau rekayasa agar pengguna mengklik; jika pengguna menekan Allow pada popup yang dipalsukan, serangan bisa berhasil
• Apple telah menambalnya di macOS Sequoia 15.5, tetapi mengonfirmasi bahwa Ventura 13.7.6 dan Sonoma 14.7.6 yang dirilis pada hari yang sama tidak ditambal, dan tidak ada rencana patch untuk versi sebelumnya
• Penyerang dapat mencoba pemalsuan popup izin pada saat aplikasi seperti FaceTime, Voice Memos, atau System Settings dibuka, sehingga pengguna berisiko salah memahami pihak yang sebenarnya diberi izin

---

Cara kerja inti CVE-2025-31250

• CVE-2025-31250 adalah kerentanan yang memungkinkan aplikasi yang ditampilkan pada popup izin TCC macOS dibuat berbeda dari aplikasi yang benar-benar menerima izin
• Sebelum patch, konfigurasi berikut dimungkinkan
  • Application A meminta macOS menampilkan popup persetujuan izin
  • Popup terlihat seolah berasal dari Application B
  • Hasil persetujuan pengguna diterapkan ke Application C
• Ketiga aplikasi itu bisa saling berbeda, meski dalam penggunaan normal kemungkinan besar biasanya merupakan aplikasi yang sama
• Masalah utamanya adalah kurangnya verifikasi yang memadai ketika aplikasi yang ditampilkan di popup berbeda dari aplikasi penerima izin yang sebenarnya

Cakupan patch dan koreksi

• Berbeda dari penjelasan awal, patch hanya diterapkan pada macOS Sequoia 15.5
• macOS Ventura 13.7.6 dan macOS Sonoma 14.7.6 yang dirilis pada hari yang sama tidak ditambal
• Saat PoC dikompilasi dan dijalankan di mesin virtual Sonoma 14.7.6, kerentanan masih berfungsi
• Apple Product Security mengubah status laporan menjadi “We’ve addressed the issue in all planned releases.”, lalu kemudian mengonfirmasi bahwa tidak ada rencana patch untuk kerentanan ini di Ventura dan Sonoma
• Akibatnya, Ventura dan Sonoma tetap berada dalam kondisi rentan terhadap kerentanan ini

Titik temu TCC dan Apple Events

• TCC adalah sistem izin inti pada sistem operasi Apple, dan secara internal bekerja melalui daemon tccd serta framework private TCC
• Developer tidak memanggil private API secara langsung, tetapi public API secara internal memanggil fungsi TCC saat diperlukan
• tccd menerima pesan menggunakan XPC API milik Apple
• Sebelum patch, aplikasi yang dapat mengirim pesan XPC ke tccd bisa mengirim pesan yang dimanipulasi untuk memisahkan aplikasi yang ditampilkan pada popup izin dari aplikasi yang benar-benar menerima izin

Apple Events dan model data TCC

• Apple Events adalah mekanisme komunikasi antaraproses di macOS, dan saat ini terutama digunakan untuk otomasi
• Otomasi Apple Events dapat dibuat sebagai skrip melalui Open Scripting Architecture milik Apple
  • Bahasa utamanya adalah AppleScript
  • JavaScript juga dapat digunakan
• Sejak macOS Mojave 10.14, aplikasi yang ingin mengirim Apple Events memerlukan persetujuan pengguna melalui TCC
• Hasil persetujuan pengguna di TCC disimpan dalam database SQLite Application Support/com.apple.TCC/TCC.db di bawah folder home pengguna
• Baris TCC biasa berisi aplikasi peminta, layanan yang diminta, dan hasil persetujuan pengguna
• Karena Apple Events harus membatasi izin per aplikasi penerima, kolom indirect object digunakan
  • Kolom ini berisi pengenal aplikasi yang akan menerima Apple Events
  • Selain Apple Events, layanan FileProviderDomain juga menggunakan kolom ini

Struktur pesan XPC yang rentan

• Masalahnya ada pada bug logika di fungsi TCCAccessRequestIndirect
• Fungsi ini menangani permintaan akses yang harus menggunakan kolom indirect object pada TCC.db
• Inti PoC adalah cara memisahkan dua field saat target_prompt bernilai 2
  • target_path: digunakan untuk memperoleh nama aplikasi yang akan ditampilkan di popup izin GUI
  • target_identifier: digunakan sebagai bundle ID aplikasi yang benar-benar dicatat ke database dan menerima izin
• Meskipun TCCAccessRequestIndirect adalah fungsi untuk indirect object, dengan memasukkan string kosong sebagai indirect object, fungsi ini juga bisa digunakan pada beberapa layanan TCC yang tidak memakai kolom tersebut
• Bug ini tidak ada pada fungsi permintaan akses lainnya

Syarat eksploitasi dan batasan

• Eksploitasi kerentanan hanya berhasil jika pengguna menekan Allow pada popup izin
• Layanan TCC yang bisa digunakan terbatas, tetapi mencakup layanan penting seperti Microphone dan Camera
• Popup izin akses ke direktori tertentu juga bisa dipalsukan, tetapi kegunaannya rendah karena adanya lapisan keamanan tambahan di sekitar file
• Aplikasi berbahaya juga bisa membuat izin diterapkan bukan ke dirinya sendiri, melainkan ke aplikasi lain
  • Ini adalah jalur yang dapat dimanfaatkan ketika penyerang dapat mengendalikan aplikasi lain tetapi aplikasi tersebut memerlukan izin TCC

Trik menggunakan timing popup

• Jika popup izin muncul secara acak, pengguna mungkin curiga dan menekan Don’t Allow
• Aplikasi macOS dapat memeriksa daftar aplikasi yang sedang berjalan dan aplikasi yang sedang berada paling depan
  • Memeriksa aplikasi yang berjalan: NSWorkspace runningApplications
  • Memeriksa aplikasi paling depan: NSWorkspace frontmostApplication
• Aplikasi berbahaya dapat menunggu hingga aplikasi tertentu dijalankan atau menjadi aplikasi paling depan, lalu menampilkan popup izin yang dipalsukan dengan nama aplikasi tersebut
• Misalnya, saat FaceTime dijalankan, popup izin Camera dapat dipalsukan; saat Voice Memos dijalankan, popup izin Microphone dapat dipalsukan
• Pengguna bisa salah mengira popup yang muncul tepat setelah membuka atau berpindah aplikasi sebagai permintaan izin normal dari aplikasi tersebut

Kaitan dengan jalur bypass TCC sebelumnya

• Sebelumnya, karena tccd menentukan folder home pengguna berdasarkan variabel lingkungan HOME, bypass TCC dapat dilakukan dengan menanam folder home palsu dan TCC.db palsu
• Masalah ini ditambal pada pembaruan pertengahan Juli 2020, dan sejak itu tccd mengambil folder home dari direktori informasi pengguna sistem operasi
• Setelah itu pun ada kasus bypass yang menyalahgunakan perubahan folder home pengguna
  • Wojciech Reguła memublikasikan CVE-2020-27937 yang menyalahgunakan sistem plugin editor direktori informasi pengguna GUI di macOS
  • Tim Microsoft Threat Intelligence memublikasikan bypass powerdir yang menggunakan perintah import/export
• Untuk mengubah folder home pengguna, umumnya diperlukan dua hal
  • Hak akses root
  • Persetujuan pengguna untuk layanan TCC tertentu
• CVE-2025-31250 tidak dapat melewati kebutuhan hak akses root, tetapi dapat menggiring pengguna memberikan persetujuan TCC yang diperlukan melalui popup yang dipalsukan
• Jika aplikasi berbahaya menipu pengguna hingga memberikan persetujuan dan juga berhasil memperoleh eskalasi hak akses root, jalur untuk mengubah direktori informasi pengguna dan menanam TCC.db palsu menjadi mungkin
• REG.db melacak TCC.db yang valid, tetapi TCC memiliki fungsi yang memungkinkan aplikasi menambahkan entri ke REG.db, sehingga jalur TCC.db yang ditanam dapat ditambahkan

Batasan manajemen izin yang terlihat oleh pengguna

• TCC adalah sistem yang bekerja di balik panel Privacy & Security pada System Settings
• Hasil persetujuan terkait Apple Events ditampilkan di bagian Automation
• Di panel Privacy & Security, pengguna dapat memeriksa persetujuan yang telah diberikan dan, dalam banyak kasus, mencabut persetujuan tertentu
• Namun, jika penyerang menipu pengguna agar mengizinkan izin Apple Events, hasil persetujuan tersebut tidak muncul di System Settings
• Pengguna dapat mencabut persetujuan dengan tool CLI tccutil, tetapi dokumentasi tool ini terbatas dan sulit diketahui oleh sebagian besar pengguna
  • Dokumentasi Apple mencakup Technical Q&A lama dan IT training page

Endpoint Security dan kemungkinan deteksi

• Framework Endpoint Security milik Apple baru-baru ini mulai mendukung pemantauan perubahan database TCC
• Tulisan Objective-See membahas perubahan ini: Endpoint Security TCC database monitoring
• Jika fitur ini bekerja sesuai harapan, aplikasi yang menggunakan framework tersebut dapat memberi notifikasi setelah kejadian kepada pengguna tentang aplikasi mana yang sebenarnya diberi izin
• Namun, kemungkinan deteksi ini hanya punya makna langsung selama periode singkat antara saat Apple menambahkan event Endpoint Security dan saat kerentanan ditambal

Cara Apple memperbaikinya

• Berdasarkan analisis terhadap binary tccd di macOS Sequoia 15.5, patch final ternyata lebih kompleks daripada perkiraan awal
• Setelah patch, popup TCC tidak dapat dipalsukan dengan cara yang sama
• Perilaku menggunakan TCCAccessRequestIndirect untuk layanan TCC lain dengan memasukkan string kosong pada indirect object juga tampaknya telah dibatasi
• Pesan dalam bentuk yang rentan kini diamati dibuang secara senyap oleh tccd dan tidak melakukan apa pun
• Dalam verifikasi sederhana, patch ini terlihat bagus, tetapi diperlukan analisis tambahan untuk memahami seluruh perilakunya sepenuhnya

Alur pelaporan hingga patch

• Kerentanan ini adalah bug kedua yang dilaporkan ke Apple, dan merupakan kasus laporan yang ditambal Apple dengan waktu terlama hingga patch dirilis
• Proses pelaporan mencakup laporan awal, permintaan penjelasan tambahan dari Apple Product Security, pembagian jalur potensial bypass TCC penuh, pembaruan pengujian PoC, konfirmasi status reproduksi, serta beberapa kali permintaan perkembangan status
• Patch sederhana yang diusulkan adalah memverifikasi apakah kedua field menunjuk ke aplikasi yang sama
• Apple beberapa kali membalas bahwa mereka sedang menyelidiki, lalu kemudian meminta nama untuk kredit sebelum merilis patch
• Kerentanan ini diberi nama “TCC, Who?”