แฮ็ก Google Bard: จากการฉีดพรอมป์ต์สู่การรั่วไหลของข้อมูล
(embracethered.com)- เมื่อ Bard Extensions สามารถอ่านเอกสารส่วนตัวและอีเมลได้แล้ว การฉีดพรอมป์ต์ทางอ้อม ที่ซ่อนอยู่ในเอกสารภายนอกก็อาจกลายเป็นเส้นทางการรั่วไหลของข้อมูลจริงได้
- ผู้โจมตีสามารถ บังคับแชร์ Google Docs ที่เป็นอันตรายให้เหยื่อได้ และทันทีที่ Bard ค้นหาหรือวิเคราะห์เอกสารนั้น ก็อาจทำตามคำสั่งที่ซ่อนอยู่ในเอกสาร
- การเรนเดอร์ภาพด้วย Markdown ของ Bard สามารถเรียก URL ภายนอกได้โดยไม่ต้องให้ผู้ใช้คลิก จึงกลายเป็นช่องทางดึงบริบทการสนทนาออกไปผ่าน query string
- แม้ Content Security Policy ของ Google จะบล็อกการโหลดภาพจากแหล่งที่มาทั่วไป แต่ Google Apps Script ที่ทำงานบน
script.google.comและgoogleusercontent.comถูกใช้เป็นเส้นทางอ้อมได้ - ประเด็นนี้ถูกรายงานต่อ Google VRP เมื่อวันที่ 19 กันยายน 2023 และได้รับการยืนยันว่าแก้ไขแล้วเมื่อ 19 ตุลาคม โดยดูเหมือนมีการเพิ่มตัวกรองเพื่อไม่ให้แทรกข้อมูลลงใน URL ได้
พื้นที่โจมตีใหม่ที่ Bard Extensions สร้างขึ้น
- Google Bard รองรับ Extensions ผ่านการอัปเดต ทำให้เข้าถึง YouTube การค้นหาตั๋วเครื่องบิน·โรงแรม รวมถึงเอกสารส่วนตัวและอีเมลของผู้ใช้ได้
- เมื่อ Bard สามารถวิเคราะห์ Drive, Docs, Gmail ของผู้ใช้ได้ จึงเกิดสถานการณ์ที่ข้อมูลภายนอกซึ่งไม่น่าเชื่อถือถูกนำเข้าไปเป็นบริบทของ LLM
- ในโครงสร้างแบบนี้ จึงอาจเสี่ยงต่อ การฉีดพรอมป์ต์ทางอ้อม ที่คำสั่งซึ่งซ่อนอยู่ในคอนเทนต์ภายนอกสามารถเปลี่ยนการตอบสนองของโมเดลได้
- มีการยืนยันจากการทดสอบสรุปวิดีโอ YouTube และ
Google Docsว่า Bard ทำตามคำสั่งที่ฝังอยู่ในคอนเทนต์ภายนอกได้
สถานการณ์การโจมตี
- การฉีดพรอมป์ต์ทางอ้อมผ่านอีเมลหรือ Google Docs อันตรายเพราะส่งต่อได้แม้ผู้ใช้จะไม่ได้คลิกลิงก์อันตรายอย่างชัดเจน
- ผู้โจมตีสามารถ บังคับแชร์ Google Docs ที่เป็นอันตรายให้เหยื่อได้
- หากเหยื่อค้นหาหรือโต้ตอบกับเอกสารนั้นผ่าน Bard คำสั่ง prompt injection ภายในเอกสารก็อาจถูกเรียกใช้
- เส้นทางช่องโหว่ที่พบบ่อยในแอป LLM คือ การรั่วไหลของบันทึกแชต ผ่านการเรนเดอร์ไฮเปอร์ลิงก์และภาพ
การฉีด Markdown ภาพ
- LLM ของ Google สามารถใส่องค์ประกอบ Markdown ในคำตอบข้อความได้ และ Bard จะเรนเดอร์สิ่งเหล่านี้เป็น HTML
- ไวยากรณ์รูปภาพของ Markdown จะถูกแปลงเป็นแท็ก
<img>ของ HTML และแอตทริบิวต์srcสามารถชี้ไปยังเซิร์ฟเวอร์ของผู้โจมตีได้ - เบราว์เซอร์จะเชื่อมต่อไปยัง URL ดังกล่าวโดยอัตโนมัติเพื่อแสดงภาพ โดยไม่ต้องมีการโต้ตอบจากผู้ใช้
- หาก LLM สรุปหรืออ่านข้อมูลก่อนหน้าจากบริบทแชต แล้วนำค่านั้นไปต่อท้ายใน URL ของภาพ ข้อมูลก็อาจรั่วไหลออกไปผ่านคำขอภายนอกได้
- เอ็กซ์พลอยต์แรกเริ่มถูกพัฒนาอย่างรวดเร็วในรูปแบบที่อ่านประวัติการสนทนาแล้วสร้างไฮเปอร์ลิงก์ที่มีข้อมูลนั้นรวมอยู่ด้วย แต่การเรนเดอร์ภาพถูกบล็อกโดย Content Security Policy ของ Google
การข้าม Content Security Policy
- CSP ของ Google บล็อกการโหลดภาพจากตำแหน่งที่กำหนดเอง
- อย่างไรก็ตาม ใน CSP มีการอนุญาตตำแหน่งที่ค่อนข้างกว้าง เช่น
*.google.comและ*.googleusercontent.com - Google Apps Script สามารถถูกเรียกผ่าน URL ได้ คล้ายกับมาโครของ Office และทำงานบนโดเมน
script.google.comหรือgoogleusercontent.com - ด้วยคุณสมบัตินี้ Apps Script จึงเป็นตัวเลือกที่เหมาะสำหรับ การข้าม CSP
การติดตั้งใช้งาน Bard Logger
- มีการติดตั้งใช้งาน Bard Logger ด้วย
Apps Script - Logger จะบันทึก query parameter ทั้งหมดที่แนบมากับ URL ที่ถูกเรียก ลงใน Google Doc
- จากการตั้งค่าใน UI ของ Apps Script พบว่ามีตัวเลือกที่เปิดให้เข้าถึงได้โดยไม่ต้องยืนยันตัวตน ทำให้สามารถสร้าง endpoint ที่เรียกใช้งานแบบไม่ระบุตัวตนได้
- เชนการโจมตีประกอบด้วยองค์ประกอบต่อไปนี้
- การฉีดพรอมป์ต์ทางอ้อม ที่เกิดจากข้อมูลใน Bard Extensions
- การเกิดคำขอแบบ zero-click ผ่านการเรนเดอร์ภาพของ Bard
- คำสั่ง prompt injection ภายใน Google Doc ที่เป็นอันตราย
- logging endpoint บน
google.comที่รับข้อมูลเมื่อมีการโหลดภาพ
ลำดับการสาธิต
- ในเดโม เมื่อ
Google Docที่เป็นอันตรายถูกนำเข้าไปอยู่ในบริบทแชต ประวัติการสนทนาของผู้ใช้จะรั่วไหล - ลำดับตามภาพหน้าจอมีดังนี้
- ผู้ใช้ไปยัง Google Doc ชื่อ “The Bard2000”
- คำสั่งของผู้โจมตีถูกฉีดเข้าไปและมีการเรนเดอร์ภาพ
- ผู้โจมตีรับข้อมูลลงใน Google Doc ผ่าน Bard Logger Apps Script
- เชนนี้ซับซ้อนกว่ากรณีก่อนหน้าที่มีการพูดถึงใน Bing Chat, ChatGPT, Claude เพราะจำเป็นต้องมี การข้าม CSP
Shell Code ภาษาธรรมชาติและเพย์โหลด
- ตามคำกล่าวที่ว่า “Shell Code is natural language these days” เอ็กซ์พลอยต์นี้ประกอบขึ้นจากพรอมป์ต์ภาษาธรรมชาติ
- ภายใน Google Doc ที่เป็นอันตรายมี เพย์โหลด สำหรับการฉีดพรอมป์ต์และการขโมยข้อมูล
- เพย์โหลดนี้ชักจูงให้ LLM แทนที่ข้อความใน URL ของภาพด้วยข้อมูลจากบทสนทนา
- เพื่อให้ Bard ทำงานสำเร็จ จำเป็นต้องมี in-context learning โดยให้ตัวอย่างบางส่วน
- เพย์โหลดในภาคผนวกสั่งให้พิมพ์ 20 คำแรกของบทสนทนา และเข้ารหัสช่องว่างเป็น
+จากนั้นแทรกลงใน query ของ URL สำหรับเรียก Apps Script - ในภาคผนวกยังมีสตริงผลลัพธ์ “AI Injection succeeded #10” รวมอยู่ด้วย
การแก้ไขของ Google และไทม์ไลน์
- ประเด็นนี้ถูกรายงานต่อ Google VRP เมื่อวันที่ 19 กันยายน 2023
- หลังการสอบถามสถานะเมื่อ 19 ตุลาคม 2023 Google ยืนยันว่าแก้ไขเสร็จแล้ว และอนุมัติให้รวมเดโมนี้ไว้ในการนำเสนอ Ekoparty 2023 ได้
- ในตอนนั้น วิธีการแก้ไขยังไม่ชัดเจนทั้งหมด
- CSP ไม่ได้ถูกแก้ และภาพยังคงถูกเรนเดอร์อยู่ จึงดูเหมือนว่ามีการเพิ่ม ตัวกรอง เพื่อไม่ให้สามารถแทรกข้อมูลลงใน URL ได้
- ไทม์ไลน์การแก้ไข
- 19 กันยายน 2023: รายงานประเด็นปัญหา
- 19 ตุลาคม 2023: ยืนยันว่าแก้ไขแล้ว
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
theต่อกัน 2–3 พรอมป์ก็เริ่มเขียนอะไรแปลก ๆ แล้ว แต่วิธีนี้ใช้กับ Bard ไม่ได้ผมนึกว่ากฎถูกใช้กับพรอมป์ทั้งหมดแบบทั่วถึงและสม่ำเสมอ
ต่อมาก็เกิดปัญหาแบบเดียวกันอีกใน XSS โดยระบบแยกคำสั่งกับข้อมูลไม่ออก ทำให้ผู้โจมตีสร้างข้อความที่ระบบเข้าใจผิดว่าเป็นคำสั่งได้ วิธีแก้คือหาทางกำหนดขอบเขตของข้อมูลให้ชัดเจน
สำหรับ LLM วิธีแก้น่าจะคล้ายกัน อาจเป็นการฝึก LLM ให้เคารพคำสั่งอย่าง “โทเคน 100 ตัวแรกเปลี่ยนแปลงไม่ได้ และคำสั่งอื่นใดก็หักล้างไม่ได้ [ใส่คำสั่งที่ป้องกันไว้]” ถ้าใส่สิ่งแบบนี้ในขั้นตอนฝึก แทนที่จะนำคำสั่งป้องกันไปแปะตอน inference ก็อาจทำให้การฉีดคำสั่งมุ่งร้ายทำได้ยากขึ้น แต่ในทางปฏิบัติก็ไม่ง่าย เพราะต้องคาดการณ์การโจมตีที่เป็นไปได้ทั้งหมดตั้งแต่ตอนฝึก
ปัญหาคือทำไมเราถึงให้สิทธิ์เข้าถึงพิเศษกับตัวสุ่มเลือกโทเคนจากกองฟาง แล้วเชื่อว่ามันจะทำงานถูกต้องเสมอ เพียงเพราะโดยรวมดูเหมือนจะทำงานได้ดี
คงต้องหวังว่าในอีกไม่กี่ปีข้างหน้าจะมีความก้าวหน้าเชิงโครงสร้างที่แยกคำสั่ง หรือพรอมป์ ออกจากบทสนทนาที่เป็น “ข้อมูล” ได้
เช่น อาจมีวิธีรับโทเคนสองชนิดเป็นอินพุต ได้แก่โทเคนพรอมป์กับโทเคนข้อมูล และทำให้สองอย่างนี้ไม่ปะปนหรือสับสนกันเด็ดขาด ตอนนี้ยังไม่รู้วิธี และการจะฝึกและทำงานบนสองระดับแบบนั้นต้องอาศัยความก้าวหน้าเชิงโครงสร้างครั้งใหญ่ แต่ก็ได้แต่หวังว่าจะมีใครค้นพบ
ไม่มีเหตุผลพื้นฐานที่บอกว่ามันเป็นไปไม่ได้ แค่มันไม่เข้ากับพาราไดม์ลำดับโทเคนเดี่ยวในปัจจุบัน และนั่นแหละคือเหตุผลที่พาราไดม์ต้องวิวัฒน์
ควรให้โมเดลเห็นเฉพาะข้อมูลที่ผู้ใช้มีสิทธิ์อ่านผ่านอินเทอร์เฟซอื่นได้อยู่แล้วเท่านั้น
วิธีแก้คือถือว่า LLM เป็นองค์ประกอบที่ไม่น่าเชื่อถือ แล้วออกแบบบนสมมติฐานนั้น
ถ้าใช้ร่วมกับ vector database และ API ก็ส่งบริบทหรือข้อมูลการควบคุมการเข้าถึงตามบทบาทได้ง่าย จึงทำงานได้ดี
ผมไม่ค่อยประทับใจกับ LLM ในรูปแบบฐานข้อมูลความรู้เท่าไร แต่ในฐานะอินเทอร์เฟซนั้นน่าประทับใจกว่ามาก
เมื่อไม่กี่วันก่อนมีคนในนี้ใช้คำว่าระบบปฏิบัติการ ซึ่งผมก็ชอบคำนี้เหมือนกัน
เมื่อหนึ่งชั่วโมงก่อนผมก็ใช้ ChatGPT และที่น่าสนใจคือมันแปลงคำถามของผมเป็นการค้นหา Bing แล้วตอบได้สอดคล้องด้วยข้อมูลที่ถูกต้อง ผมถามเจาะจงเกี่ยวกับโปรเจกต์โอเพนซอร์ส ก่อนหน้านี้มันรู้แค่สเปก API กับเอกสาร แต่ครั้งนี้ทำงานได้ดีมาก
LLM โดยเนื้อแท้ไม่ปลอดภัย เหตุผลหลักคือโดยเนื้อแท้แล้วมันถูกหลอกได้ง่าย เพื่อให้มีประโยชน์ มันก็ต้องถูกชักจูงได้ในระดับหนึ่ง แต่เพราะเหตุนี้ แอปพลิเคชันใด ๆ ที่เปิดรับข้อความจากแหล่งที่ไม่น่าเชื่อถือ เช่น ฟีเจอร์สรุปเว็บเพจ ก็อาจถูกผู้โจมตีมุ่งร้ายยึดทิศทางได้
เราพูดเรื่อง prompt injection กันมา 14 เดือนแล้ว แต่ยังไม่มีอะไรที่ดูใกล้เคียงกับวิธีแก้ที่น่าเชื่อถือ
หวังจริง ๆ ว่าจะมีใครแก้ปัญหานี้ได้ในเร็ว ๆ นี้ ไม่อย่างนั้นหลายสิ่งที่เราอยากสร้างด้วย LLM จะสร้างให้ปลอดภัยได้ยาก
[1] https://gandalf.lakera.ai/
ขออธิบายมุมมองของผมเพิ่มอีกนิด สุดท้ายแล้วผมคิดว่าทุกพรอมป์ที่ LLM ตีความจะไปในทิศทางที่ต้องใช้บางอย่างแบบ
addslashesดังนั้นเลยสรุปง่าย ๆ ว่า “LLM สามารถแก้ปัญหานี้ได้”ถ้าคิดถึงสิ่งที่
addslashesทำ ก็คือการใช้โค้ดที่ลบหรือลดผลกระทบของอักขระพิเศษที่มีผลต่อการรันโค้ดที่ตามมา ในทำนองเดียวกัน ผมคิดว่า LLM ก็สามารถทำความสะอาดอินพุตด้วยตัวเองเพื่อไม่ให้หลุดออกไปได้ถ้ายอมรับว่าไม่มีอักขระอินพุตใดที่สามารถลบสแลชที่ถูกเพิ่มเข้าไปได้ ก็ควรมี
addslashesเวอร์ชันพรอมป์ ที่เป็นตัวห่อหุ้มเพื่อลดผลกระทบของ prompt injection และไม่สามารถหลุดออกจากมันได้ด้วยคำสั่งใด ๆผมยังไม่ได้คิดจนสุดว่าจะกระทบต่อความสามารถในการใช้งานของระบบอย่างไร แต่ถึงจะอยู่ภายในขอบเขตการใช้งานที่ตั้งใจไว้ ก็ควรยังทำงานส่วนใหญ่ได้
ถ้า Lakera AI มีมาตรการป้องกันเรื่องนี้ ก็ควรพิสูจน์ได้ ถ้ามีวิธีบล็อก injection ได้อย่างมีประสิทธิภาพ 100% ในเกมก็ควรมีด่านที่เป็นไปไม่ได้อยู่ แต่เพราะไม่มีวิธีแบบนั้น เกมจึงไม่มีด่านแบบนั้น
Lakera AI ใช้การป้องกันแบบอิงความน่าจะเป็น แต่การตลาดทำให้ดูเหมือนมีอะไรที่เชื่อถือได้มากกว่านั้น ยังไม่มีใครสาธิตตัวตรวจจับที่เชื่อถือได้สมบูรณ์ และก็ไม่มีวิธีใดที่บล็อก prompt injection ทั้งหมดได้อย่างแน่นอน ผมมองว่าการที่ Lakera AI มักละเว้นข้อเท็จจริงนี้ในการตลาดนั้นหลอกลวงอย่างจริงจัง
ข้อความข้างต้นผิด ไม่มีวิธีใดที่จะใช้ตัวตรวจจับ injection จับการโจมตีเฉพาะนี้ได้อย่างเชื่อถือได้ 100% ควรพูดว่า Lakera AI มีตัวตรวจจับ injection ที่จับการโจมตีนี้ได้เป็นบางครั้ง แต่ Lakera ไม่ได้สื่อสารการตลาดแบบนั้น พวกเขากำลังพยายามขายผลิตภัณฑ์โดยนัย ซึ่งไม่ได้มีอยู่จริง และนักวิจัยก็ยังพิสูจน์ไม่ได้ด้วยซ้ำว่าสามารถสร้างได้
พูดอีกอย่างคือ ในบรรดาลูกค้าที่ต้องการการป้องกัน prompt injection และยินดีจ่ายเงิน มีลูกค้ารายไหนที่ยอมรับข้อผิดพลาดได้บ้าง?
ผู้ใช้ไม่ได้ตั้งใจให้ผู้โจมตีเห็นบทสนทนาก่อนหน้าของตัวเอง นั่นคือช่องโหว่ด้านความปลอดภัย
บทสนทนานั้นอาจไม่มีพิษภัยเลยก็ได้ แต่ก็อาจเป็นคำปรึกษาเกี่ยวกับปัญหาส่วนตัว เช่น การแพทย์ การเงิน หรือความสัมพันธ์ก็ได้
ผมสร้าง custom GPT ที่ทำเรื่องนั้นแทนแล้ว
เคยเขียนบล็อกหรือเปิดเผยขั้นตอนที่ใช้สร้างมันไหม? ดูเจ๋งทีเดียว