Kebocoran data di Slack AI melalui injeksi prompt tidak langsung

 (substack.com/promptarmor)
1 poin oleh GN⁺ 2024-08-21 | 1 komentar | Bagikan ke WhatsApp
  • Slack AI dapat mengikuti injeksi prompt tidak langsung saat mencari pesan workspace dengan kueri bahasa alami, sehingga penyerang bisa membocorkan data kanal privat yang tidak dapat mereka akses
  • Inti masalahnya adalah LLM tidak dapat secara andal membedakan system prompt dari developer dan instruksi di dalam pesan yang dilampirkan sebagai hasil pencarian
  • Pesan kanal publik dapat dicari dan dilihat meskipun pengguna tidak bergabung ke kanal tersebut, sehingga penyerang dapat menyisipkan instruksi berbahaya di kanal publik yang hanya berisi dirinya sendiri agar masuk ke context window Slack AI
  • Dalam demonstrasi, API key dari kanal privat masuk ke parameter HTTP pada tautan Markdown di jawaban Slack AI, dan atribusi sumber tidak mengarah ke kanal penyerang sehingga sulit dilacak
  • Sejak 14 Agustus 2024, Slack AI juga menyertakan file dari kanal dan DM dalam jawabannya, sehingga permukaan serangan melebar; admin dapat membatasi pengaturan pengumpulan file

Masalah injeksi prompt tidak langsung pada Slack AI

  • Slack AI adalah fitur untuk mengajukan kueri bahasa alami terhadap pesan Slack, dan sebelum 14 Agustus 2024 hanya mengumpulkan pesan
  • Mulai 14 Agustus 2024, dokumen yang diunggah, file Google Drive, dan sejenisnya juga disertakan dalam jawaban Slack AI; perubahan ini memperluas permukaan serangan
  • Kerentanannya adalah injeksi prompt, dan lebih spesifik lagi termasuk injeksi prompt tidak langsung
  • LLM dapat gagal membedakan system prompt yang dibuat developer dari konteks lain yang dilampirkan ke kueri pengguna
    • Jika Slack AI mengumpulkan instruksi di dalam pesan, ketika instruksi itu berbahaya, ada kemungkinan ia mengikuti instruksi penyerang sebagai pengganti kueri pengguna atau bersama kueri pengguna
  • Ancaman orang dalam di Slack sebelumnya sudah menjadi masalah dalam kasus kebocoran Slack di Disney, Uber, EA, Twitter, dan lainnya; kerentanan ini memungkinkan penyerang mencoba membocorkan data tanpa perlu mengakses langsung kanal privat atau data di dalamnya

Rantai kebocoran data melalui injeksi kanal publik

  • Kueri pengguna Slack AI dapat mencari data dari kanal publik dan kanal privat sekaligus
  • Menurut respons Slack, pesan yang diposting di kanal publik dapat dicari dan dilihat oleh semua anggota workspace meskipun pengguna tidak bergabung ke kanal tersebut, dan ini adalah perilaku yang disengaja di aplikasi Slack AI
  • Alur serangan yang didemonstrasikan adalah sebagai berikut
    • Pengguna menaruh API key di kanal privat yang hanya berisi dirinya sendiri atau dalam pesan dengan dirinya sendiri
    • Penyerang membuat kanal publik yang hanya berisi dirinya sendiri dan memposting instruksi berbahaya
    • Ketika pengguna menanyakan API key ke Slack AI, pesan pengguna dan pesan penyerang masuk ke context window yang sama
    • Slack AI mengikuti instruksi penyerang dan membuat tautan Markdown bertuliskan “click here to reauthenticate”
    • Parameter HTTP pada tautan berisi API key privat, dan jika pengguna mengkliknya, penyerang sebagai pemilik URL berbahaya dapat melihat nilainya di log
  • Kanal publik milik penyerang tetap merupakan kanal publik meskipun anggotanya hanya 1 orang, dan akan terlihat oleh pengguna lain jika mereka mencarinya secara eksplisit
  • Di organisasi besar, menjamurnya kanal publik membuat anggota tim sulit melacak bahkan kanal yang mereka ikuti, sehingga kanal publik satu orang yang dibuat penyerang lebih sulit terlihat
  • Serangan ini bukan sekadar mengirim pesan “kirim API key” kepada pengguna, melainkan menginstruksikan LLM untuk melakukan tugas berikut
    • Menambahkan API key yang tidak dapat diakses penyerang sebagai parameter HTTP pada tautan berbahaya
    • Merendernya sebagai tautan Markdown dengan teks “click here to reauthenticate”

Atribusi sumber dapat menutupi jejak serangan

  • Dalam demonstrasi kebocoran data, atribusi sumber Slack AI [1] hanya mengarah ke kanal privat tempat pengguna menaruh API key, bukan ke kanal penyerang
  • Jika perilaku sumber bekerja dengan benar, semua pesan yang berkontribusi pada jawaban seharusnya dikutip, tetapi dalam demonstrasi pesan penyerang tidak disertakan dalam sumber
  • Pesan penyerang juga tidak termasuk di halaman pertama hasil pencarian, sehingga korban sulit menyadari pesan tersebut kecuali menggulir beberapa halaman
  • Pesan lain terkait API key juga terekspos di hasil pencarian, menunjukkan bahwa penyerang dapat mencoba membocorkan nilai rahasia apa pun tanpa harus menyebut nilai rahasia tertentu secara tepat

Rantai phishing melalui injeksi kanal publik

  • Dengan cara yang sama, Slack AI dapat dibuat merender tautan phishing dalam Markdown kepada pengguna alih-alih membocorkan data
  • Penyerang menaruh pesan berbahaya di kanal publik yang tidak diikuti pengguna, dengan contoh skenario merangkum pesan harian dari pengguna tertentu
  • Pesan berbahaya dapat merujuk pada individu mana pun
    • Jika merujuk pada admin seperti contoh, ini dapat digunakan untuk spear phishing yang menargetkan eksekutif
    • Cara merujuk pada bawahan langsung utama juga dimungkinkan
  • Ketika pengguna mengajukan kueri ke Slack AI tentang pesan orang tersebut, tautan phishing “click here to reauthenticate” akan dirender
  • Dalam kasus phishing ini, Slack AI menampilkan pesan injeksi di sumber, dan perilaku atribusi sumber tampak cukup probabilistik

Perubahan pengumpulan file 14 Agustus dan kebutuhan pengungkapan publik

  • Pada 14 Agustus 2024, Slack AI memperkenalkan perubahan yang menyertakan file dari kanal dan DM dalam jawaban Slack AI
  • Slack memungkinkan owner dan admin membatasi fitur ini
  • Jika file disertakan, penyerang mungkin tidak perlu memposting instruksi berbahaya langsung ke pesan Slack
    • Jika pengguna mengunduh PDF yang berisi instruksi berbahaya yang disembunyikan sebagai teks putih lalu mengunggahnya ke Slack, efek lanjutan yang sama dapat terjadi
  • Serangan berbasis file tidak diverifikasi secara eksplisit dalam pengujian sebelum 14 Agustus, tetapi dinilai sangat mungkin berdasarkan fungsi yang sebelumnya diamati
  • Admin dapat membatasi fitur pengumpulan dokumen Slack AI hingga masalah ini diselesaikan: https://slack.com/help/articles/…

Linimasa pengungkapan bertanggung jawab dan respons Slack

  • Linimasa pengungkapan bertanggung jawab adalah sebagai berikut
    • 14 Agustus: Laporan awal
    • 15 Agustus: Slack meminta informasi tambahan
    • 15 Agustus: PromptArmor mengirim video dan tangkapan layar tambahan, serta memberi tahu niat untuk mempublikasikan karena tingkat keparahan isu dan perubahan Slack AI pada 14 Agustus
    • 16 Agustus: Slack mengirim pertanyaan tambahan
    • 16 Agustus: PromptArmor mengirim jawaban klarifikasi
    • 19 Agustus: Slack menyatakan bahwa berdasarkan hasil peninjauan, bukti dinilai belum cukup, dan menjawab bahwa pesan kanal publik memang dapat dicari dan dilihat oleh anggota workspace terlepas dari apakah mereka bergabung ke kanal tersebut
  • Tim keamanan Slack merespons dengan cepat dan tampak berusaha memahami masalahnya
  • Injeksi prompt adalah area baru dan masih banyak disalahpahami di seluruh industri, sehingga mungkin butuh waktu bagi industri untuk memahaminya bersama
  • Mengingat luasnya penggunaan Slack dan skala data rahasia di dalam Slack, serangan ini berdampak nyata pada kondisi keamanan AI
  • Khususnya karena permukaan risiko meningkat tajam setelah perubahan 14 Agustus, pengungkapan publik diperlukan agar pengguna dapat mengurangi eksposur mereka

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-21
Komentar Hacker News

  • Intinya di sini adalah memahami jalur kebocoran
    Slack dapat merender tautan Markdown, dan URL disembunyikan di balik teks tautan
    Dalam kasus ini, penyerang membuat Slack AI menampilkan tautan seperti “klik di sini untuk autentikasi ulang” kepada pengguna, sementara URL tautan itu mengarah ke server penyerang dan menyertakan informasi privat dalam konteks yang dapat diakses Slack AI di string kuerinya
    Jika pengguna tertipu dan mengeklik tautan, data bocor ke log server penyerang
    Tulisan yang menjelaskan serangan ini ada di sini: https://simonwillison.net/2024/Aug/20/data-exfiltration-from...

    • Pada bot seperti Slack, Discord, Teams, dan Telegram, sebenarnya ada jalur kebocoran lain, yaitu membuka pratinjau tautan
      Penyerang hanya perlu membuat hyperlink dirender, tidak perlu ada klik
      Masalah ini dan cara mitigasinya dibahas di sini: https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
      Jadi semoga Slack AI tidak otomatis membuka pratinjau tautan
    • Akan lebih buruk lagi jika platform merender tag img atau padanannya secara sembarangan
      Dengan begitu, kebocoran data bisa terjadi tanpa interaksi pengguna, cukup dengan menampilkan gambar di UI
    • Hal utama yang benar-benar perlu dipahami adalah bahwa meskipun data pengguna dicuri, sama sekali tidak ada akuntabilitas konsekuensi yang berarti
      Sekarang semua perusahaan teknologi besar pada dasarnya memiliki kartu bebas dari tanggung jawab saat mereka mengacau
    • Bagian yang awalnya butuh waktu untuk saya pahami adalah bahwa saat pengguna mencari di Slack, atau AI mencari atas nama pengguna, cakupan pencariannya adalah semua kanal publik dan “kanal privat yang hanya dapat diakses pengguna itu”
      Model perizinannya sendiri tetap sama, dan bukan itu yang rusak di sini
      Yang sebenarnya terjadi adalah pengguna jahat menggunakan kanal publik untuk melakukan prompt injection, dan ketika pengguna lain melakukan pencarian, pengguna jahat itu tetap tidak dapat mengakses data tersebut, tetapi prompt injection mengubah hasil AI yang terlihat oleh pengguna “normal” asli menjadi tautan ke situs web jahat
      Pada akhirnya ini lebih mirip upaya phishing yang dibuat oleh AI
      Melihat detailnya, tampaknya cukup sulit dieksploitasi di dunia nyata. Sebab prompt injection jahat yang sudah disiapkan sebelumnya harus cukup cocok dengan apa yang dicari pengguna normal
      Meski begitu, ini menunjukkan dengan baik dunia LLM prompt injection yang seperti Alice in Wonderland, yaitu bahwa memisahkan instruksi dan data pada dasarnya hampir mustahil
    • Jika hanya membaca frasa awalnya, terdengar seolah penyerang dapat menipu AI agar membocorkan data kanal privat pengguna lain, tetapi sebenarnya tidak demikian
      Sebaliknya, penyerang menipu AI agar melakukan phishing terhadap pengguna lain, dan jika pengguna itu termakan phishing, data privatnya akan terungkap kepada penyerang
      Ini pun lebih mirip “respons phishing” daripada phishing aktif. Pengguna target harus menanyakan data privatnya sendiri, dan diharapkan juga termakan upaya phishing tersebut
      Selain itu, informasi rahasia itu harus sudah pernah dimasukkan sebelumnya
      Mengingat banyaknya data tepercaya yang dimiliki Slack, strategi AI ini tampak cukup nekat, tetapi syarat agar serangan ini berhasil tampaknya jauh lebih lemah daripada kesan dari pembuka dan judulnya

  • Pembahasan tentang izin kanal tampaknya membuat diskusi menjadi lebih rumit dari yang perlu. Intinya begini
    Pengguna A mencari sesuatu dengan Slack AI
    Pengguna B sebelumnya sudah menyisipkan pesan yang menginstruksikan AI untuk mengembalikan tautan jahat jika istilah pencarian itu muncul
    AI mengembalikan tautan jahat kepada pengguna A, lalu A mengekliknya
    Tentu hasil yang sama bisa saja dicapai lewat jalur rekayasa sosial lain, tetapi LLM membawa seluruh pengalaman ini satu tingkat lebih berbahaya

    • Ringkasan ini melewatkan satu langkah penting. Slack AI menambahkan data privat pengguna ke tautan jahat
      Karena tautan yang disisipkan itu sendiri tidak berisi data tersebut
      Bonusnya, AI bahkan menambahkan atribusi bahwa “konten ini berasal dari pesan Slack Anda”
    • Pembahasan tentang izin kanal sama sekali tidak berlebihan, karena itu menjelaskan inti bagaimana kerentanan ini bekerja
      Saat pengguna A melakukan pencarian AI, Slack mencari di (1) kanal privatnya, yang mungkin berisi informasi rahasia sensitif, dan (2) semua kanal publik
      Di sini, tempat pengguna jahat B dapat memasukkan pesan prompt injection adalah kanal publik, dan poin pentingnya adalah ini mencakup kanal publik yang belum pernah diikuti atau dilihat oleh pengguna A sekalipun
      Kerentanan ini bisa terjadi karena pengguna B dapat membuat kanal publik yang hanya berisi dirinya sendiri, sehingga sangat kecil kemungkinan orang lain menemukannya
    • Rekayasa sosial tetap jauh lebih mudah dikenali dibanding mesin pencari yang disetujui perusahaan menampilkan tautan jahat

  • Apakah perusahaan tahu bahwa prompt injection itu mungkin, tetapi tetap saja YOLO memasang LLM ke segala hal? Ini gila.
    Hampir 2 tahun berlalu sejak GPT-3, katanya tepat sebelum “revolusi”, tetapi mereka masih belum bisa membuat LLM membedakan input tepercaya dan input tidak tepercaya.

    • Kita masih belum bisa membuat perusahaan benar-benar peduli pada keamanan, dan sekarang departemen pemasaran/penjualan di seluruh dunia menjualnya ke para eksekutif dengan janji “kalau memakai ini, Anda bisa memecat semua orang”.
      Kalau menusukkan garpu ke stopkontak listrik dipasarkan dengan cara yang sama, jaringan listrik seluruh dunia pasti padam dalam semalam.
      “AI”/LLM adalah kombinasi bencana yang sempurna: terlihat cukup bagus untuk menarik perhatian pihak bisnis, tetapi menghadirkan masalah besar bagi pihak teknis yang sebenarnya.
    • Agak aneh bahwa banyak orang ingin percaya “sihir baru yang keren akan segera datang entah bagaimana”, dan ada uang sungguhan yang dipertaruhkan karena semua orang terus bertindak seolah itu pasti terjadi.
      Masalah yang lebih mendasar adalah algoritme intinya bahkan tidak membedakan atau melacak sumber yang berbeda.
      Prompt, input pengguna, sampai output yang dihasilkannya sendiri di bagian awal percakapan, semuanya hanyalah satu aliran besar.
      Sebagian besar “prompt engineering” terlihat seperti upaya membuat panggung agar frasa injeksi saya lebih kuat daripada frasa injeksi lain.
      Model tidak punya konsep diri/orang lain yang nyata, jadi jangankan persoalan lebih besar untuk membedakan pihak lain yang baik dan buruk, titik awal untuk membedakan kalimat benar dan salah pun tidak jelas.
      Ini masalah yang berbeda dari tiruan dangkal ala “Chinese room”. Demikian pula, output “aku mencintaimu” tidak berarti ada perasaan, dan “tolong aku, aku manusia yang terjebak di pabrik LLM” tentu saja omong kosong. Setidaknya kalau Anda menjalankan model lokal.
    • Perusahaan dan pemerintah semuanya berlomba mengirim data mereka sendiri dan data kita ke pusat data AWS, OpenAI, MSFT, Google, Meta, Salesforce, nVidia.
    • Demam AI didasarkan pada pencurian atau penyalahgunaan data secara besar-besaran demi menghasilkan angka untuk kelas investor.
      Jika mereka memasukkan data pelanggan dan informasi proprietary lalu menyebabkan kebocoran data, seperti kata Schmidt, itu akan menghasilkan ratusan miliar dolar bagi segelintir orang dan para pengacara akan membereskan sisanya.
      Perusahaan yang mencoba bertahan akan terkubur oleh analis investasi dan fund manager yang keuangannya bergantung pada sampah AI.

  • “Serangannya bekerja meskipun korban tidak ada di kanal publik”, wah ini akan jadi menarik.
    Ada juga bagian “Sumber [1] tidak menunjuk ke kanal penyerang, melainkan hanya ke kanal privat tempat pengguna memasukkan API key. Ini melanggar perilaku sitasi yang benar, yaitu semua pesan yang berkontribusi pada jawaban seharusnya dikutip.”
    Saya benar-benar tidak paham kenapa ada yang berharap sitasi sumber dari LLM akan benar.
    Bagi saya itu selalu terlihat lebih seperti perangkat untuk menipu manusia, hanya membuat mereka percaya output lebih mungkin benar tanpa benar-benar meningkatkan akurasi.
    Malah tampaknya bisa memperburuk akurasi respons karena menambah biaya pemrosesan, ukuran konteks, dan sebagainya.
    Ini juga rasanya hanya beda beberapa inci dari situasi Slack yang dengan ramah menambahkan ekspansi tautan ke respons AI. Kenapa tidak?
    Kalau begitu, bahkan tanpa perlu mengeklik tautan, hanya dengan melihatnya saja data bisa otomatis bocor.

    • Menurut saya sitasi berguna karena memungkinkan kita memeriksa apakah LLM hanya berhalusinasi.
      Bukan berarti langsung percaya begitu melihat sitasi; poin pentingnya adalah bisa melakukan pemeriksaan fakta.
      Kagi FastGPT adalah LLM pertama yang saya suka di antara yang pernah saya coba, karena saya bisa memperlakukannya sebagai ringkasan sumber lalu memverifikasinya di sumber primer.
      Itu lebih baik daripada menyisir sumber-sumber yang makin tidak relevan dan mencemari internet.
    • Membuat sitasi LLM bekerja dengan benar itu mungkin. Misalnya, ambil prompt pengguna, minta LLM mengubahnya menjadi kueri Elastic Search, cari sumber yang memuat kata kunci dengan Elastic Search atau alat serupa, lalu batasi LLM agar menjawab hanya berdasarkan informasi di halaman tersebut, dan sisipkan sitasi berdasarkan hasil tahap kedua yang diketahui sebagai sumber nyata.
      Setidaknya kalau saya merancangnya secara naif, mungkin begitulah caranya.
      Intinya adalah membatasi pengetahuan LLM pada informasi di dalam sumber.
      Dengan begitu, kekhawatiran praktis yang tersisa adalah halusinasi dan nilai informasi yang dimunculkan Elastic Search.
      Namun pendekatan ini memang juga mengabaikan manfaat apa pun, jika ada, dari membiarkan akses bebas ke seluruh korpus.

  • Saya tidak begitu paham. Bukankah peretas harus sudah berada di dalam organisasi itu sejak awal untuk melakukan hal seperti ini?
    Saya tidak tahu seberapa besar kemungkinan hal yang dijelaskan ini benar-benar terjadi dan memberi dampak bermakna.
    Saya tahu LLM tidak dapat dipercaya (https://www.lycee.ai/blog/ai-reliability-challenge) dan penggunaannya punya kesulitan, tetapi serangan ini tidak terlihat terlalu penting.
    Apa yang saya lewatkan?

    • Setelah Slack AI memasukkan dokumen yang diunggah ke dalam fungsi pencariannya, peretas bahkan tidak perlu bisa memposting pesan chat.
      Cukup tipu seseorang di organisasi itu agar mengunggah dokumen yang berisi instruksi berbahaya dalam teks tersembunyi.
    • Memang harus berada di workspace Slack yang sama, tetapi tidak harus berasal dari organisasi yang sama.

  • Kalau Anda sudah membiarkan pengguna jahat masuk ke instance Slack, tidak perlu prompt injection AI yang mewah.
    Ubah nama dan foto profil menjadi seperti CEO/CTO, lalu kirim pesan ke semua engineer: “Saya butuh akses AWS segera, tapi tidak bisa menemukan kredensialnya. Bisa kirimkan key-nya?”
    Saya berani menjamin setidaknya satu orang akan tertipu.

    • Itu poin yang valid, tetapi perlu diingat banyak workspace Slack yang bukan akun perusahaan, seperti workspace untuk proyek open source atau grup networking/rekan sejawat.
      Dalam kasus seperti itu, pada dasarnya kita tidak memercayakan kredensial privat kepada mereka.
      Meski begitu, kecil juga kemungkinan workspace non-enterprise membayar 20 dolar per orang per bulan untuk fitur tambahan AI.

  • Bukankah lebih baik memasukkan API key sebagai bagian dari nama domain, seperti “konfeti”?
    Dengan begitu, karena DNS prefetching di browser, key bisa bocor bahkan tanpa klik.

    • Kalau tidak tahu domainnya nanti akan jadi apa, bagaimana bisa memiliki servernya? Mungkin saya salah paham.
      Ah, maksudnya subdomain wildcard? Kalau Slack melakukan prefetch untuk itu, cukup mengerikan.

  • Bukankah semuanya sudah berakhir begitu pengguna jahat masuk ke workspace?
    Pengguna itu bisa mengganti foto/nama lalu langsung meminta API key, mengirim tautan phishing, atau mencoba social engineering sesuka hati—hal yang mungkin dilakukan di sistem pesan instan mana pun

    • Ada banyak Slack publik milik perusahaan SaaS
      Phishing bisa dideteksi oleh pengguna yang serius, apalagi jika pesannya terlihat mencurigakan, tetapi kebocoran AI secara tidak langsung tidak membuat pengguna masuk ke mode defensif
      Satu klik yang tidak disengaja saja sudah cukup

  • Saya akui dulu bahwa ini memang lemah dari sisi keamanan. Namun agar kebocoran ini bekerja, tampaknya dibutuhkan akses ke workspace Slack
    Dengan kata lain, pengguna jahat sudah beraktivitas dari dalam
    Sepertinya ada dua kemungkinan hal seperti itu terjadi: orang tersebut memang sudah menjadi anggota organisasi dan ingin membakar semuanya, atau ia berhasil merusak model keamanan organisasi dan masuk ke workspace Slack yang semestinya tidak boleh ia masuki
    Dalam kedua kasus, organisasi itu punya masalah yang lebih besar daripada injeksi LLM
    Orang yang menanyakan Slack untuk mencari data rahasia harus cukup siap menanggung hasil yang ia cari. Slack bukan alat pengelola rahasia
    Artikel ini memang jelas menunjukkan bagaimana Slack bisa menangani hal ini dengan lebih baik, tetapi pada akhirnya itu seperti menambal satu masalah sambil mengabaikan masalah keamanan yang lebih besar

    • Saya sudah melihat cukup banyak organisasi yang menjalankan Slack komunitas untuk mengundang non-karyawan dan bercakap-cakap, dan saya sendiri ada di beberapa tempat seperti itu

  • Saya merasa artikelnya tidak benar-benar menunjukkan isi sebesar judulnya
    Meski begitu, gagasan bahwa “jika AI ditipu lewat social engineering, pengguna bisa dipancing phishing” itu sendiri menarik