Rantai eksekusi kode jarak jauh di Google Chrome, yang memungkinkan seorang penyerang untuk menjalankan kode pada mesin host, dapat dihargai mulai dari $250,000 hingga $500,000. Saat ini, kekuatan seperti ini umumnya hanya tersedia untuk pemerintah dan agen intelijen. Namun, tidak lama yang lalu, kemampuan serupa dapat diakses oleh siapa saja, bahkan script kiddie biasa.
Java Drive-By
Ketika saya baru mulai belajar coding dan keamanan pada tahun 2008, saya mempelajari sebuah teknik yang dikenal sebagai “drive-by download,” khususnya “Java drive-by.” Pada saat itu, Anda dapat menyematkan applet Java, yang merupakan aplikasi kecil yang ditulis dalam bahasa pemrograman Java, ke dalam halaman web. Meskipun applet ini dimaksudkan untuk meningkatkan fungsionalitas web, mereka juga memungkinkan penyerang untuk menjalankan kode sembarangan pada mesin pengguna.
Applet yang ditandatangani, dibandingkan dengan yang tidak ditandatangani, berbeda secara signifikan dalam hal sandbox keamanan dan tingkat hak aksesnya. Secara sederhana, applet yang ditandatangani dapat beroperasi dengan tingkat akses yang sama seperti aplikasi desktop, meskipun mereka dijalankan di dalam browser.
Namun, tanda tangan tersebut tidak diverifikasi karena tidak memiliki dukungan dari otoritas sertifikat terpercaya. Hal ini menyebabkan munculnya popup peringatan keamanan, yang memberikan pengguna setidaknya 50% kemungkinan untuk membuat pilihan yang salah. Mengklik tombol “jalankan” dapat langsung membahayakan sistem Anda.
Ini bukanlah kerentanannya, ini hanya ide yang buruk.
JavaScript Drive-By
Pada tahun 2022, saya mulai mempelajari File System Access API. API ini memungkinkan situs web untuk membaca dan menulis ke file yang dipilih oleh pengguna, dengan beberapa pengecualian penting seperti file sistem yang dianggap oleh Chrome. Saya bahkan melaporkan satu kerentanan terkait cara API ini menangani tautan simbolik (symlink), yang kemudian diperbaiki oleh Google.
Namun, meskipun kerentanannya telah diperbaiki, sesuatu masih mengganggu saya. API ini terlalu kuat. Untuk memahami mengapa, kita harus terlebih dahulu memahami batasan keamanan sistem operasi. API ini melewati mekanisme keamanan Windows dan macOS, tetapi untuk tujuan tulisan ini, saya akan fokus pada macOS.
Penting untuk dicatat bahwa masalah ini mempengaruhi tidak hanya Google Chrome, tetapi juga semua browser berbasis Chromium, seperti Microsoft Edge, Brave, dan Opera, karena mereka semua berbagi arsitektur dan API yang sama.
Gatekeeper
Gatekeeper di macOS adalah fitur keamanan yang mencegah pengguna menjalankan perangkat lunak yang tidak dipercaya. Fitur ini melibatkan tiga langkah utama:
- Quarantine File: Diperkenalkan pada 2007, memberikan peringatan kepada pengguna sebelum mengeksekusi file yang diunduh dari internet.
- Gatekeeper: Dibangun di atas Quarantine File pada OSX Lion (10.7), memeriksa apakah aplikasi yang diunduh berasal dari pengembang yang teridentifikasi, dan memblokir aplikasi yang tidak teridentifikasi.
- Notarisasi: Diperkenalkan pada macOS Catalina (10.15), mengharuskan aplikasi untuk dipindai dan disetujui oleh Apple sebelum dijalankan.
Selain itu, macOS juga memiliki App Sandbox untuk membatasi akses aplikasi ke sumber daya sistem dan data pengguna. Browser Chrome tidak menggunakan fitur sandbox ini, yang menjadi alasan mengapa File System Access API bisa sangat berbahaya.
Ketika pengguna berinteraksi dengan situs web yang menggunakan File System Access API, mereka diminta untuk menyetujui akses tulis. Pada titik ini, pengguna menjadi satu-satunya garis pertahanan. Jika mereka secara keliru memberikan akses ke file yang salah, semua batasan keamanan sebelumnya akan dilewati. Meskipun File System Access API dengan benar menambahkan atribut com.apple.quarantine, yang menunjukkan bahwa file tersebut diunduh dari internet dan tidak boleh dipercaya, keterbatasan dari Gatekeeper macOS adalah bahwa ia tidak memeriksa kembali binary ini ketika dijalankan oleh aplikasi lain, yang dalam hal ini adalah Google Chrome itu sendiri.
Ini mengingatkan saya pada masa lalu dengan Java drive-by download, di mana satu klik salah bisa menyebabkan sistem Anda terkompromi.
Mengabaikan Daftar Blokir Chrome
Chrome memang membatasi akses tulis ke file dan direktori berdasarkan daftar blokir. Namun, saya menemukan bahwa jika pengguna menarik dan melepaskan file, Chrome tampaknya tidak memeriksanya terhadap daftar blokir.
Namun, saya rasa perbaikan terhadap bypass ini tidak akan menyelesaikan masalah mendasar dengan File System Access API. Ada terlalu banyak file yang bisa ditimpa untuk mendapatkan eksekusi kode, dan Anda akan selalu melewatkan satu.
Mirip dengan applet Java, tidak ada kerentanannya yang bisa ditunjukkan, jadi sisa tulisan ini akan berfokus pada bagaimana File System Access API bisa disalahgunakan untuk meretas orang.
Eksploitasi & Symlink
Eksploitasi yang sukses bergantung pada kemampuan kita untuk meyakinkan pengguna untuk memberikan akses tulis ke file target tertentu. Banyak file yang bisa dimanfaatkan untuk mencapai eksekusi kode, tetapi favorit saya adalah Google Chrome Helper.
Google Chrome Helper bertindak sebagai perantara antara Chrome dan plugin yang diinstal, memfasilitasi operasional mereka dengan meluncurkan proses untuk konten eksternal seperti pemutar video, ekstensi, atau konten tertanam. Ketika beberapa aksi dilakukan, seperti perintah window.print(), proses Google Chrome Helper mungkin dibuat untuk mengelola interaksi dan sumber daya eksternal yang diperlukan untuk aksi tersebut. Itulah sebabnya menimpa file ini memberi kita eksekusi kode segera.
Langkah selanjutnya adalah membuat cerita yang meyakinkan atau alasan agar pengguna merasa aman saat memberikan akses ini. Metode terbaik yang saya temukan melibatkan penggunaan symlink – yang pada dasarnya adalah penunjuk yang mengarahkan ke file atau direktori lain. Symlink sangat ideal untuk tujuan ini karena kebanyakan orang tidak mengerti apa itu, dan bahkan mereka yang tahu sering mengabaikannya. Symlink menciptakan ilusi keamanan dari perspektif pengguna. Mudah untuk berasumsi bahwa tidak ada yang berisiko: “Saya hanya memberikan situs web akses tulis ke file yang saya unduh dari situs itu—apa yang bisa salah?”
Bukti Konsep
Seiring dengan berkembangnya platform web yang menawarkan aplikasi lebih canggih seperti IDE, editor 3D, dan lainnya, memberikan akses baca dan tulis ke file menjadi semakin diterima.
Untuk menunjukkan dampaknya, saya telah mengembangkan dua bukti konsep, dan dengan segala hype seputar AI, saya memilih yang pertama, yaitu situs web yang mengklaim sebagai asisten AI browser, yang bekerja dengan baik dengan file target kita, yaitu “Google Chrome Helper.”
PoC kedua adalah IDE berbasis web palsu yang disebut “Evil Code Editor.” Dalam demonstrasi ini, pengguna diminta untuk mengunduh proyek contoh dan membukanya untuk mengenal editor tersebut.
Anda bisa menemukan kode untuk kedua PoC di: https://github.com/ron-imperva/javascript-drive-by
Seperti yang ditunjukkan dalam video yang menyertai, jika pengguna mengikuti langkah-langkah ini, penyerang bisa menjalankan perintah sewenang-wenang pada mesin mereka. Dalam kasus kami, kami hanya membuka kalkulator, tetapi perintah apa pun dapat dieksekusi di luar Chrome dan sandbox macOS.
Satu-satunya kerentanannya yang kami manfaatkan di sini adalah bypass daftar blokir Chrome, yang biasanya memblokir akses baca dan tulis ke folder /Applications di macOS. Namun, banyak file lain yang tidak ada dalam daftar blokir dapat digunakan untuk mencapai hasil serupa.
Pengungkapan Tanggung Jawab dan Kesimpulan
Kami melaporkan bypass daftar blokir ini kepada Google, yang mengonfirmasi bug ini dan menyatakan bahwa mereka sudah mengetahui masalah ini dan sedang mengerjakan perbaikannya. Pada saat penulisan posting ini, bypass ini masih belum diperbaiki. Karena sudah lebih dari 10 bulan, kami memutuskan untuk mempublikasikan rincian kerentanannya dan kode bukti konsep.
Salah satu cara Google bisa menangani ini, menurut pandangan kami, adalah dengan menghapus izin eksekusi dari file yang dimodifikasi oleh File System Access API. Kami merekomendasikan solusi ini kepada tim Chromium, tetapi pada saat penulisan, hal ini masih ada dalam backlog untuk dipertimbangkan.
Google memberitahukan kami bahwa mereka berencana membatasi File System Access API hanya untuk bundle aplikasi Chrome, yang diharapkan dapat mengurangi serangan spesifik yang dibahas dalam posting blog ini. Perubahan ini diharapkan akan diterapkan di Chrome 132.
Kesimpulannya, kemajuan pesat teknologi web terus mendorong batasan apa yang bisa dilakukan secara online. Namun, seperti yang ditunjukkan oleh risiko yang terkait dengan File System Access API, kemajuan ini datang dengan serangkaian tantangannya sendiri, menyoroti keseimbangan yang rapuh antara fungsionalitas dan keamanan.
Seperti di masa lalu dengan Java drive-by downloads, bahkan hari ini, beberapa klik yang salah bisa membuka pintu bagi masalah keamanan serius. Tetap waspada dan berpikir dua kali sebelum memberikan akses ke file Anda.
