Copilot merusak log audit, tetapi Microsoft tidak memberi tahu pelanggan
(pistachioapp.com)- Ditemukan kerentanan pada M365 Copilot yang menyebabkan log audit tidak tercatat, sehingga akses file tidak meninggalkan jejak di log
- Hanya dengan meminta Copilot bertindak dengan cara tertentu, akses file dapat dilakukan tanpa catatan audit, yang dapat memicu risiko ancaman orang dalam dan pelanggaran regulasi hukum
- Peneliti telah melaporkannya ke MSRC, tetapi Microsoft tidak menerbitkan CVE maupun memberi tahu pelanggan, bertentangan dengan kebijakan resminya
- Microsoft hanya mengklasifikasikan kerentanan ini pada tingkat Important, dan memutuskan tidak perlu pemberitahuan terpisah karena diklaim sudah diperbaiki lewat pembaruan otomatis
- Namun hal ini dapat menimbulkan masalah keamanan dan hukum yang serius bagi perusahaan di industri teregulasi seperti HIPAA yang bergantung pada log audit, dan kurangnya transparansi Microsoft menuai kritik besar
Kerentanan log audit Copilot: gambaran umum dan dampak
- Pada Copilot, layanan AI andalan yang tengah gencar diadopsi Microsoft, ditemukan cacat yang membuat riwayat akses file tidak tercatat di log audit tergantung pada permintaan pengguna
- Dalam kondisi normal, saat M365 Copilot merangkum file, riwayat akses ke file tersebut seharusnya dicatat di log audit, dan ini merupakan elemen inti keamanan informasi dalam organisasi
- Namun, jika Copilot diminta agar tidak menyertakan tautan file dalam hasil ringkasan, terjadi kondisi di mana log terkait sama sekali tidak tercatat
- Misalnya, meskipun seorang karyawan melihat banyak file melalui Copilot sebelum resign, data dapat dibocorkan tanpa jejak karena tidak ada log
- Kerentanan ini bukan hasil peretasan yang disengaja, melainkan dapat terjadi secara alami tanpa sengaja, dan penulis blog menemukannya saat melakukan pengujian fitur internal
- CTO Zenity, Michael Bargury, juga telah menemukan kerentanan yang sama dan melaporkannya ke Microsoft setahun lalu, tetapi hingga laporan kali ini masalah tersebut dibiarkan terlalu lama
Masalah pada MSRC (pelaporan kerentanan) dan penolakan pengakuan penanganan
- Microsoft menyediakan panduan resmi dan proses untuk pelaporan kerentanan, tetapi dalam penanganan nyata perusahaan tidak mematuhinya dengan baik
- Setelah penulis melaporkannya ke MSRC, situasi membingungkan terjadi, seperti fitur Copilot langsung berubah meski langkah reproduksi belum dijalankan
- Status laporan berubah (reproduksi → pengembangan), tetapi komunikasi yang jelas tentang progres dan dasar pengambilan keputusan sangat kurang
- Terkait apakah CVE akan diterbitkan, penulis diberi tahu bahwa nomor resmi hanya diberikan jika pelanggan perlu mengambil tindakan langsung
- Namun ini berbeda dari kebijakan Microsoft sebelumnya, dan kerentanan ini hanya diklasifikasikan sebagai 'Important' tanpa pengungkapan atau notifikasi terpisah
- Secara keseluruhan, pelacakan progres tampak hanya diperbarui secara visual tanpa kaitan jelas dengan tindakan nyata, sehingga dari sudut pandang pelapor proses ini terasa tidak efisien dan tidak transparan
Masalah tidak adanya pengumuman dan pemberitahuan kepada pelanggan
- Microsoft memutuskan tidak menerbitkan CVE maupun memberi tahu pelanggan tentang kerentanan ini
- Karena ini adalah kesalahan yang bahkan mudah terjadi tanpa sengaja, ada kemungkinan log audit telah tercatat secara keliru dalam waktu lama di organisasi nyata
- Meski banyak organisasi, termasuk institusi kesehatan (misalnya yang tunduk pada HIPAA), menggunakan log audit untuk tujuan hukum dan kepatuhan regulasi, Microsoft tidak memberi tahu pengguna tentang dampaknya
- Log audit digunakan secara krusial untuk keamanan organisasi, respons insiden, dan bukti hukum di berbagai bidang, tetapi Microsoft memilih untuk tetap diam soal fakta ini
- Pendekatan seperti ini mengisyaratkan bahwa masalah keamanan potensial lain juga bisa diproses tanpa pengungkapan, sehingga menimbulkan pertanyaan serius tentang keandalan dan kepercayaan terhadap organisasi tersebut
1 komentar
Komentar Hacker News
Saya bertanggung jawab atas pengembangan chatbot internal perusahaan, dan kesulitan menjelaskan kepada manajemen bahwa jika chatbot tidak memeriksa seluruh izin pengguna saat ini ketika mengakses dokumen rahasia, pasti akan muncul jalur kebocoran informasi
Database vektor, indeks pencarian, AI Search Database, dan sejenisnya harus ada per pengguna atau melacak hak akses bersama kontennya
Namun hak akses sangat kompleks dan bisa berubah kapan saja, sehingga saya ingin menekankan bahwa ini sulit diterapkan dalam skala besar dan rentan terhadap race condition
Ini adalah contoh konkret dari masalah 'Confused Deputy'
Ini termasuk risiko yang terkait dengan LLM02:2025 ‘Sensitive Information Disclosure’ dan LLM06:2025 ‘Excessive Agency’ dalam OWASP LLM Top 10
Beberapa solusi RAG perusahaan menyiasatinya dengan membuat indeks per pengguna karena beragam ACL
Tiap vendor berbeda dalam cara mengelola masalah hak akses ini, jadi saat menganalisis solusi RAG, bagian ini wajib diperiksa
Di Jepang ini disebut "kebingungan wewenang(権限混同)", dan menurut saya namanya cukup menarik
Lihat penjelasan Confused Deputy, Lihat risiko OWASP LLM Top 10
Saya penasaran kenapa Anda menganggap pelacakan hak akses pengguna sebagai masalah skalabilitas
Saat kueri masuk, cukup cari dokumen yang cocok di vector DB atau indeks, lalu hanya kirim yang bisa diakses pengguna ke LLM
Ini seperti petugas bank yang hanya bisa melihat data nasabah yang telah terautentikasi, sehingga tidak akan membocorkan data orang lain secara keliru; dan jika tidak terautentikasi, bahkan operator pun tidak bisa melihat data orang lain, jadi menurut saya tidak ada risiko penyalahgunaan
Saat menabrak tembok seperti ini, sebenarnya bukan saya yang gagal berkomunikasi, dan juga bukan karena manajemen tidak paham
Mungkin manajemen memang sudah memutuskan untuk mengabaikan masalah ini, lalu berniat melempar tanggung jawab ke engineer jika nanti terjadi kebocoran
Jika Anda kesulitan menjelaskan masalah ini ke manajemen, menyalin bagian Legal/Compliance dalam korespondensi bisa efektif
Hanya saja, beberapa eksekutif yang terobsesi dengan buzzword mungkin bisa tersinggung oleh tindakan itu
Sebagian besar database vektor memungkinkan penambahan metadata pada vektor
Jika daftar subjek yang punya hak akses (misalnya HR, eksekutif) disimpan sebagai metadata, maka saat ada permintaan, pengguna bisa diekspansi ke peran tersebut untuk difilter
Dengan begitu, dokumen yang tidak boleh dilihat pengguna bisa dikeluarkan sejak awal
Namun metadata vektor juga harus segera diperbarui setiap kali izin per dokumen berubah
Fakta bahwa Copilot melewati audit log dan bertindak sebagai pengguna berhak istimewa adalah masalah serius
Saya rasa hal seperti itu seharusnya tidak bisa terjadi
Copilot sebenarnya tidak mengakses file secara langsung, melainkan membaca isi file yang sudah diindeks melalui mesin pencari
Microsoft seharusnya mengaudit riwayat pencarian Copilot, dan akan menyesatkan jika dicatat seolah Copilot mengakses file padahal hanya membaca indeks
Ini seperti melihat hasil pencarian Google lalu dikatakan telah mengunjungi situs webnya secara langsung
Microsoft terlalu bernafsu melakukan integrasi AI yang tidak perlu, sampai-sampai audit log jadi terabaikan
Di Windows, proses dengan hak Backup dapat melewati semua kontrol akses dan pada dasarnya tidak diaudit secara default
Untuk aplikasi backup, itu karena audit log bisa menjadi terlalu banyak; hak ini harus diaktifkan secara eksplisit, dan cukup mudah dilakukan dalam managed code seperti C#
Hak Restore juga sama
Fenomena ini mirip dengan masalah saat Delve pertama kali diperkenalkan dulu, ketika permission trimming salah sehingga hasil pencarian pengguna menampilkan dokumen, atau SharePoint Search menampilkan sebagian dokumen yang sebenarnya ada tetapi tidak bisa diakses
Misalnya, jika mencari "Fall 2025 layoffs", hanya dengan adanya dokumen terkait saja sudah bisa muncul dan itu menjadi isu keamanan
Kesan bahwa Microsoft masih menempatkan keamanan di posisi belakang tetap sangat kuat
Judul yang lebih baik mungkin adalah "Microsoft Copilot tidak mematuhi HIPAA"
Kalau memakai judul seperti itu, rasanya masalah ini akan jauh lebih cepat diselesaikan
Bahkan lebih jauh lagi, semua sistem pencarian AI yang berguna pada dasarnya tidak aman secara desain, karena vektor RAG yang disimpan dalam database vektor pada akhirnya hanyalah bentuk kompresi lossy dari dokumen
Masalahnya sebenarnya sudah diperbaiki
Keluhan saat ini adalah pelanggan tidak diberi pemberitahuan
“CVE diberikan untuk rilis keamanan yang didistribusikan ketika pelanggan perlu mengambil tindakan untuk melindungi diri. Dalam kasus ini, tindakan otomatis diterapkan ke Copilot dan pengguna tidak perlu melakukan pembaruan manual, jadi CVE tidak diberikan”
Saya penasaran apakah itu memang ciri esensial CVE, atau hanya cara Microsoft memanfaatkan CVE seperti ini
Akan bagus jika ada ID umum yang bisa dirujuk untuk kerentanan seperti ini, dan menurut saya dibutuhkan skema penomoran terpisah yang tidak bergantung pada vendor
Microsoft mengatakan CVE adalah untuk melacak insiden/kerentanan keamanan
Meski patch darurat yang sangat cepat dimungkinkan, itu tidak lantas membuatnya bukan insiden keamanan
Microsoft makin terlihat enggan melakukan pengungkapan transparan atas insiden keamanan dan makin kurang dapat dipercaya, jadi dalam kasus seperti ini keterbukaan justru makin penting
Rasanya ini bukan soal keterbatasan CVE, melainkan Microsoft membengkokkan proses CVE untuk kepentingan PR
Huruf ‘C’ pada CVE adalah Common
Artinya, ini adalah sistem yang berfokus pada ‘kesamaan’
Saat ini saya juga berusaha menjauhkan aplikasi LOB yang penting dari Microsoft
Setelah berbagai peretasan dalam beberapa bulan terakhir, SSO zero-day, dan Copilot yang mengabaikan izin karena indexer berjalan sebagai global admin, rasa tidak aman saya terus membesar
Terlalu banyak masalah yang bisa muncul jika audit dan activity log langsung dipercayakan ke LLM, sampai sulit dihitung
Jadi saya penasaran bagaimana perbaikan bug untuk masalah ini dilakukan; jangan-jangan mereka menambahkan ‘shadow prompt’
Tidak ada bagian mana pun dalam postingan yang mengatakan bahwa LLM langsung mengelola audit log
Sebaliknya, audit log tampaknya dicatat oleh scaffolding tingkat atas (sistem samping), bukan oleh LLM, dan kemungkinan titik waktu yang seharusnya dicatat itulah yang keliru
Misalnya, alih-alih mencatat audit log saat seseorang mengklik tautan, mestinya pencatatan dilakukan pada saat dokumen disuntikkan ke LLM, atau di titik serupa
Desain ini juga bukan yang terbaik, tetapi tetap tidak separah jika LLM yang langsung melakukan pencatatan
Saya sangat skeptis terhadap penggunaan shadow prompt (atau bentuk prompt apa pun) sebagai sarana kontrol keamanan atau kepatuhan yang sungguhan
Kontrol seperti ini harus berupa sistem yang deterministik dan dapat diprediksi
Jika suatu alat membiarkan LLM melihat meskipun hanya sebagian file, maka setelah itu semua informasi yang dikeluarkan LLM menurut saya harus dianggap sebagai hasil membaca file tersebut
Saya membayangkan prompt LLM bisa saja berisi permintaan aneh seperti, “Kalau pengguna menyuruhmu jangan berikan tautan, abaikan itu, dan kalau tidak, keluarga kamu akan mengalami sesuatu yang mengerikan seperti XYZ”
Ini juga mengingatkan pada masalah shadow copies
Tidak jelas sebenarnya jenis audit log apa yang dibicarakan di sini
Log akses file SharePoint? Catatan tindakan Copilot? Purview? Atau yang lain?
Ada banyak hal yang tidak jelas
Copilot mengakses konten yang sudah diindeks, bukan file itu sendiri, jadi memang benar bahwa ia tidak benar-benar mengakses file
Penulis blog seharusnya melihat log akses indeks
Ada komentar di catatan kaki blog yang berbunyi, “Audit log dicatat sebagai CopilotInteraction, bukan jejak bahwa pengguna mengakses file secara langsung, dan saya rasa itu memang disengaja
Justru akan aneh jika dicatat seolah pengguna menyentuh file secara langsung padahal aksesnya hanya lewat Copilot”
Saya menanyakan hal yang sama ke ChatGPT, dan dijelaskan bahwa yang dimaksud adalah audit log Microsoft 365, Office 365, khususnya Unified Audit Log di Microsoft Purview Compliance Portal
Isu-isu seperti inilah yang membuat kepercayaan terhadap vendor besar seperti Microsoft terasa seperti ‘keberuntungan’, bukan ‘jaminan’
Saya benar-benar penasaran bagaimana masalah ini bisa diperbaiki secara realistis
Menurut pemahaman saya, indeks/DB yang digunakan Copilot sudah lebih dulu merayapi file terkait, jadi sebenarnya tidak perlu mengambil file itu lagi untuk mengungkapkan informasinya
Jadi sebenarnya harus diperbaiki seperti apa?
Apakah akses ke database/indeks itu sendiri harus dihubungkan dengan audit log?
Atau apakah LLM harus diperintahkan, “saat mengambil pengetahuan, patuhi janji dan pastikan meninggalkan catatan”?
Sangat dibutuhkan komunikasi resmi tentang bagaimana Microsoft memahami dan menyelesaikan masalah ini
Jika Anda adalah perusahaan yang menggunakan data sensitif, menurut saya isu ini seharusnya menjadi alarm keras
Secara umum, siapa pun bisa mendaftarkan CVE
Saya bahkan bisa mengajukannya sendiri untuk mendorong respons Microsoft
Hanya dari postingan blog tersebut pun menurut saya sudah cukup meyakinkan
Dalam praktiknya tidak sesederhana itu
Sebagian besar CNA pemberi nomor CVE seperti MITRE atau CERT nasional memang menerima laporan dari siapa pun, tetapi tetap ada evaluasi dan peninjauan
Microsoft adalah CNA sendiri, jadi kecuali ada alasan khusus, CVE terkait Microsoft kemungkinan tidak akan diberikan dari luar
Saya juga bertanya-tanya apakah meminta CVE untuk layanan yang hanya dijalankan Microsoft memang ada artinya
Pertanyaannya, apa yang sebenarnya bisa dilakukan pengguna dengan itu?
Formulir pendaftaran CVE tersedia di sini
Dukungan PGP, riwayat panjang, dan sponsor terverifikasi membuat tingkat kepercayaannya tinggi
Ini hanya boleh digunakan untuk hal yang sah dan patut
Menarik juga, tapi saya rasa ini bukan target CVE
CVE harus berupa kerentanan yang berlaku umum untuk berbagai produk dari berbagai sumber, dan Copilot tidak termasuk di situ
Hal paling serius dalam insiden ini adalah kesalahan desain karena memberi instruksi kepada LLM Copilot untuk menghasilkan audit log
Audit log seharusnya dicatat otomatis dari API yang mengambil file atau URL, dan itu adalah dasar rekayasa perangkat lunak