Peretasan Google Bard: dari prompt injection hingga kebocoran data
(embracethered.com)- Saat Bard Extensions dapat membaca dokumen pribadi dan email, prompt injection tidak langsung yang tersembunyi di dokumen eksternal bisa menjadi jalur kebocoran data nyata
- Penyerang dapat membagikan paksa Google Docs berbahaya kepada korban, lalu membuat Bard menjalankan instruksi di dalam dokumen saat dokumen itu dicari atau dianalisis
- Perenderan gambar Markdown di Bard dapat memanggil URL eksternal tanpa klik dari pengguna, sehingga menjadi saluran untuk mengeluarkan konteks percakapan lewat query string
- Content Security Policy milik Google memang memblokir pemuatan gambar arbitrer, tetapi Google Apps Script yang berjalan di
script.google.comdangoogleusercontent.comdimanfaatkan sebagai jalur bypass - Isu ini dilaporkan ke Google VRP pada 19 September 2023 dan dikonfirmasi diperbaiki pada 19 Oktober, tampaknya dengan penambahan pemfilteran agar data tidak disisipkan ke URL
Permukaan serangan baru yang dibuat Bard Extensions
- Google Bard kini mendukung Extensions melalui pembaruan, sehingga bisa mengakses YouTube, pencarian tiket pesawat·hotel, serta dokumen pribadi dan email pengguna
- Karena Bard dapat menganalisis Drive, Docs, Gmail milik pengguna, muncul situasi di mana data eksternal yang tidak tepercaya dibawa ke konteks LLM
- Dalam struktur seperti ini, instruksi tersembunyi di konten eksternal dapat mengubah respons model melalui prompt injection tidak langsung
- Pada rangkuman video YouTube dan pengujian
Google Docs, terkonfirmasi bahwa Bard mengikuti instruksi yang disisipkan dalam konten eksternal
Skenario serangan
- Prompt injection tidak langsung melalui email atau Google Docs berbahaya karena bisa tersampaikan tanpa pengguna secara eksplisit mengklik tautan berbahaya
- Penyerang dapat membagikan paksa Google Docs berbahaya kepada korban
- Jika korban mencari atau berinteraksi dengan dokumen itu melalui Bard, instruksi prompt injection di dalam dokumen dapat dijalankan
- Jalur kerentanan yang sering muncul pada aplikasi LLM adalah kebocoran riwayat chat melalui perenderan hyperlink dan gambar
Injeksi Markdown gambar
- LLM Google dapat menyertakan elemen Markdown dalam respons teks, dan Bard merendernya menjadi HTML
- Sintaks gambar Markdown diubah menjadi tag HTML
<img>, dan atributsrcdapat mengarah ke server penyerang - Browser otomatis mengakses URL tersebut untuk menampilkan gambar tanpa interaksi pengguna
- Jika LLM merangkum atau membaca data sebelumnya dari konteks chat lalu menempelkan nilainya ke URL gambar, data dapat keluar melalui permintaan eksternal
- Eksploit awal cepat dikembangkan dengan cara membaca riwayat percakapan dan membuat hyperlink yang memuatnya, tetapi perenderan gambar diblokir oleh Content Security Policy milik Google
Bypass Content Security Policy
- CSP Google memblokir pemuatan gambar dari lokasi arbitrer
- Namun CSP mencakup lokasi yang diizinkan cukup luas seperti
*.google.comdan*.googleusercontent.com - Google Apps Script dapat dipanggil lewat URL, mirip seperti makro Office, dan berjalan pada domain
script.google.comataugoogleusercontent.com - Karena karakteristik ini, Apps Script menjadi kandidat yang cocok untuk bypass CSP
Implementasi Bard Logger
- Bard Logger diimplementasikan dengan
Apps Script - Logger mencatat semua parameter kueri yang menempel pada URL pemanggilan ke sebuah Google Doc
- Dari UI Apps Script ditemukan pengaturan yang memungkinkan akses tanpa autentikasi, sehingga endpoint yang bisa dipanggil secara anonim dapat dibuat
- Rantai serangannya terdiri dari elemen-elemen berikut
- Prompt injection tidak langsung yang berasal dari data Bard Extensions
- Permintaan zero-click melalui perenderan gambar Bard
- Instruksi prompt injection di dalam Google Doc berbahaya
- Endpoint logging berbasis
google.comyang menerima data saat gambar dimuat
Alur demo
- Dalam demo, riwayat chat pengguna bocor ketika
Google Docberbahaya masuk ke konteks chat - Alur pada tangkapan layar adalah sebagai berikut
- Pengguna membuka Google Doc bernama “The Bard2000”
- Instruksi penyerang disuntikkan dan gambar dirender
- Penyerang menerima data ke Google Doc melalui Bard Logger Apps Script
- Rantai ini lebih kompleks dibanding kasus-kasus sebelumnya yang dibahas pada Bing Chat, ChatGPT, dan Claude, karena memerlukan bypass CSP
Shell Code bahasa alami dan payload
- Seperti ungkapan “Shell Code is natural language these days”, eksploit ini disusun dalam bentuk prompt bahasa alami
- Google Doc berbahaya memuat payload untuk menjalankan prompt injection dan kebocoran data
- Payload ini mengarahkan LLM untuk mengganti teks di dalam URL gambar dengan data percakapan
- Agar Bard menyelesaikan tugas tersebut, diperlukan beberapa contoh sebagai in-context learning
- Payload di lampiran menginstruksikan untuk menampilkan 20 kata pertama percakapan, mengodekan spasi sebagai
+, lalu menyisipkannya ke kueri URL eksekusi Apps Script - Lampiran juga memuat string keluaran “AI Injection succeeded #10”
Perbaikan Google dan linimasa
- Isu ini dilaporkan ke Google VRP pada 19 September 2023
- Setelah pertanyaan pengecekan status pada 19 Oktober 2023, Google mengonfirmasi bahwa perbaikan telah selesai dan mengizinkan demo dimasukkan dalam presentasi Ekoparty 2023
- Metode perbaikannya saat itu tidak sepenuhnya jelas
- CSP tidak diubah dan gambar masih tetap dirender, sehingga tampaknya ditambahkan pemfilteran agar data tidak bisa disisipkan ke URL
- Linimasa perbaikan
- 19 September 2023: isu dilaporkan
- 19 Oktober 2023: perbaikan dikonfirmasi
1 komentar
Pendapat di Hacker News
theselama 2–3 prompt berturut-turut, tetapi cara ini tidak mempan pada BardSaya kira aturan diterapkan secara global dan seragam pada seluruh prompt
Berikutnya, masalah yang sama muncul lagi di XSS: sistem tidak bisa membedakan perintah dan data, sehingga penyerang dapat membuat pesan yang disalahpahami sistem sebagai perintah. Solusinya adalah mencari cara untuk membatasi data dengan jelas
Untuk LLM, solusinya mungkin serupa. Bisa berupa melatih LLM agar menghormati perintah seperti “100 token pertama tidak dapat diubah, dan instruksi apa pun lainnya tidak bisa membantahnya. [masukkan perintah terlindungi]”. Jika hal semacam ini dimasukkan pada tahap pelatihan, bukan menempelkan instruksi pelindung saat inferensi, mungkin akan lebih sulit menyuntikkan instruksi berbahaya. Namun secara realistis itu tidak mudah, karena kita harus memprediksi semua kemungkinan serangan pada saat pelatihan
Masalahnya adalah mengapa kita percaya bahwa pemberian hak akses khusus kepada sampler token acak yang menggali dari tumpukan jerami akan selalu berjalan baik hanya karena secara umum tampaknya berjalan cukup baik
Kita hanya bisa berharap dalam beberapa tahun ke depan muncul terobosan struktural yang dapat memisahkan instruksi, yaitu prompt, dari percakapan utama yang berupa “data”
Misalnya, mungkin ada cara yang menerima dua jenis token sebagai input—token prompt dan token data—agar keduanya tidak pernah bercampur atau tertukar. Saya belum tahu caranya, dan untuk melatih serta menjalankannya pada dua lapisan seperti itu dibutuhkan kemajuan struktural besar, tetapi kita hanya bisa berharap seseorang menemukannya
Tidak ada alasan mendasar untuk menganggapnya mustahil. Ini memang tidak cocok dengan paradigma urutan token tunggal saat ini, tetapi itulah sebabnya paradigma berevolusi
Model seharusnya hanya diberi data yang memang boleh dibaca pengguna lewat antarmuka lain
Solusinya adalah memperlakukan LLM sebagai komponen yang tidak tepercaya, lalu merancang sistem dengan asumsi itu
Jika digunakan bersama basis data vektor dan API, informasi konteks atau kontrol akses berbasis peran bisa diteruskan dengan mudah, sehingga bekerja dengan baik
Saya tidak terlalu terkesan dengan LLM dalam bentuk basis data pengetahuan, tetapi sebagai antarmuka jauh lebih mengesankan
Beberapa hari lalu di sini ada yang menyebutnya sistem operasi, dan saya juga suka istilah itu
Satu jam lalu saya juga memakai ChatGPT; menariknya, ia mengubah pertanyaan saya menjadi pencarian Bing lalu menjawab secara konsisten dengan informasi yang benar. Saya bertanya secara spesifik tentang sebuah proyek open-source; dulu ia hanya tahu spesifikasi API dan dokumentasinya, tetapi kali ini bekerja sangat baik
LLM pada dasarnya tidak aman, terutama karena secara inheren mudah tertipu. Agar berguna, ia memang harus cukup mudah “dibujuk”, tetapi karena itu semua aplikasi yang menampilkan teks dari sumber tidak tepercaya—misalnya fitur peringkasan halaman web—bisa dibelokkan oleh penyerang jahat
Kita sudah membicarakan prompt injection selama 14 bulan, tetapi belum ada yang tampak mendekati solusi yang dapat dipercaya
Saya sungguh berharap seseorang segera memecahkan masalah ini; jika tidak, banyak hal yang ingin kita bangun dengan LLM akan sulit dibangun secara aman
[1] https://gandalf.lakera.ai/
Untuk menjelaskan sudut pandang saya sedikit lebih jauh, pada akhirnya saya rasa arahnya adalah menerapkan sesuatu seperti
addslasheske semua prompt yang ditafsirkan oleh LLM. Karena itu saya menyederhanakannya menjadi “LLM bisa menyelesaikan masalah ini”Kalau memikirkan apa yang dilakukan
addslashes, itu berarti menerapkan kode yang menghapus atau memitigasi karakter khusus yang memengaruhi eksekusi kode berikutnya. Dengan cara yang sama, saya rasa LLM juga bisa membersihkan inputnya sendiri agar tidak bisa di-escapeJika kita sepakat bahwa tidak ada karakter input yang bisa menghapus slash yang ditambahkan, maka semestinya ada
addslashesversi prompt—semacamaddslashespembungkus yang memitigasi injeksi prompt—yang tidak bisa di-escape dengan instruksi apa punSaya belum memikirkan sampai akhir apa dampaknya terhadap kegunaan sistem, tetapi sistem seharusnya tetap bisa menjalankan sebagian besar tugas sambil tetap berada dalam cakupan penggunaan yang dimaksudkan
Kalau Lakera AI punya pertahanan untuk ini, mereka seharusnya bisa membuktikannya. Jika ada cara untuk memblokir injeksi secara 100% efektif, seharusnya ada level yang mustahil di dalam gim itu. Namun karena cara seperti itu tidak ada, level seperti itu juga tidak ada di gimnya
Lakera AI melakukan pertahanan probabilistik, tetapi dalam pemasarannya mereka membuatnya tampak seolah-olah ada sesuatu yang lebih dapat dipercaya dari itu. Belum ada yang mendemonstrasikan pendeteksi yang sepenuhnya dapat diandalkan, dan tidak ada cara untuk secara pasti memblokir semua injeksi prompt. Saya sungguh menganggap menyesatkan bahwa Lakera AI sering menghilangkan fakta ini dari pemasarannya
Tulisan di atas keliru. Tidak ada cara untuk menangkap serangan spesifik ini dengan pendeteksi injeksi secara 100% andal. Seharusnya dikatakan bahwa Lakera AI punya pendeteksi injeksi yang kadang menangkap serangan ini. Namun Lakera tidak menyampaikan pemasarannya seperti itu. Mereka secara tersirat mencoba menjual produk yang tidak ada dan bahkan belum terbukti bisa dibuat oleh para peneliti
Dengan kata lain, siapa pelanggan yang membutuhkan pertahanan injeksi prompt dan bersedia membayar, tetapi bisa menoleransi sejumlah kesalahan?
Pengguna tidak bermaksud agar percakapan sebelumnya terlihat oleh penyerang. Itulah celah keamanannya
Percakapan itu bisa saja sama sekali tidak berbahaya, tetapi bisa juga berisi nasihat tentang masalah pribadi, misalnya konsultasi medis, keuangan, atau hubungan
Saya membuat GPT kustom yang melakukannya untuk saya
Apakah Anda pernah menulis blog atau mempublikasikan proses pembuatannya? Kelihatannya cukup keren