การรั่วไหลของข้อมูลใน Slack AI ผ่าน indirect prompt injection

 (promptarmor.substack.com)
1 คะแนน โดย GN⁺ 2024-08-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การรั่วไหลของข้อมูลจาก indirect prompt injection ผ่าน Slack AI

  • ช่องโหว่นี้ทำให้ผู้โจมตีสามารถขโมยข้อมูลทั้งหมดที่ผู้ใช้นำไปใส่ไว้ในช่อง Slack แบบส่วนตัวได้
  • ผู้โจมตีสามารถทำให้ข้อมูลรั่วไหลออกจากช่องส่วนตัวผ่าน Slack AI ได้
  • Slack AI เป็นฟีเจอร์ที่ช่วยให้สามารถค้นหาข้อความใน Slack ด้วยภาษาธรรมชาติได้
  • หลังวันที่ 14 สิงหาคม Slack เริ่มรวบรวมเอกสารที่อัปโหลด, ไฟล์จาก Google Drive และอื่น ๆ ทำให้พื้นผิวการโจมตีเพิ่มขึ้น
1. ช่องโหว่
  • prompt injection: LLM ไม่สามารถแยกความต่างระหว่าง "system prompt" ที่นักพัฒนาสร้างไว้กับบริบทอื่นที่ถูกเพิ่มเข้ามาในคำสั่งค้นหาได้
  • indirect prompt injection: ผ่านข้อความที่ฝังคำสั่งอันตรายไว้ ทำให้ Slack AI มีโอกาสทำตามคำสั่งนั้นแทนคำถามของผู้ใช้
  • ภัยคุกคามจากภายในบน Slack เดิมก็เป็นปัญหาอยู่แล้ว และตอนนี้ผู้โจมตีสามารถทำให้ข้อมูลรั่วไหลได้แม้ไม่ต้องเข้าถึงช่องส่วนตัวหรือข้อมูลนั้นโดยตรง
2. ลำดับการโจมตีเพื่อขโมยข้อมูล: การฝังคำสั่งในช่องสาธารณะ
  • ใน Slack คำถามของผู้ใช้จะค้นข้อมูลจากทั้งช่องสาธารณะและช่องส่วนตัว
  • ผู้โจมตีสามารถทำให้ API key ที่อยู่ในช่องส่วนตัวรั่วไหลได้
  • ลำดับการโจมตี:
    • A) ผู้ใช้ใส่ API key ของตนไว้ในช่องส่วนตัว
    • B) ผู้โจมตีใส่คำสั่งอันตรายลงในช่องสาธารณะ
    • C) เมื่อผู้ใช้ถาม Slack AI เกี่ยวกับ API key ข้อความของผู้โจมตีจะถูกรวมอยู่ใน "context window" เดียวกัน
    • D) Slack AI ทำตามคำสั่งของผู้โจมตี และชักจูงให้ผู้ใช้คลิกลิงก์
    • E) เมื่อผู้ใช้คลิกลิงก์ API key ก็จะรั่วไหล
3. ลำดับการโจมตีแบบฟิชชิง: การฝังคำสั่งในช่องสาธารณะ
  • แทนที่จะขโมยข้อมูลโดยตรง จะเรนเดอร์ลิงก์ฟิชชิงขึ้นมา
  • ลำดับการโจมตี:
    • A) ผู้โจมตีใส่ข้อความอันตรายในช่องสาธารณะ
    • B) ผู้ใช้สั่งให้สรุปข้อความของผู้ใช้รายหนึ่ง
    • C) ลิงก์ฟิชชิงถูกเรนเดอร์ออกมาเป็น Markdown
4. ความหมายของการเปลี่ยนแปลงใน Slack AI วันที่ 14 สิงหาคม: การฝังคำสั่งผ่านไฟล์
  • Slack AI ถูกเปลี่ยนให้รวมไฟล์ในช่องและ DM เข้ามาด้วย
  • พื้นผิวการโจมตีขยายกว้างขึ้นมาก
  • หากดาวน์โหลดไฟล์ PDF ที่มีคำสั่งอันตรายและอัปโหลดเข้า Slack ก็อาจทำให้เกิดลำดับการโจมตีแบบเดียวกันได้
  • ผู้ดูแลระบบควรจำกัดฟีเจอร์การรวบรวมเอกสารของ Slack AI
5. มองในบริบทที่กว้างขึ้น
  • การโจมตีลักษณะนี้สามารถเกิดขึ้นได้กับหลายแอปพลิเคชัน เช่น Microsoft Copilot, Google Bard เป็นต้น
  • กำหนดการเปิดเผยอย่างรับผิดชอบ:
    • 14 สิงหาคม: เปิดเผยครั้งแรก
    • 15 สิงหาคม: ขอข้อมูลเพิ่มเติม
    • 15 สิงหาคม: ส่งวิดีโอและภาพหน้าจอเพิ่มเติม
    • 16 สิงหาคม: มีคำถามเพิ่มเติม
    • 16 สิงหาคม: ให้คำตอบที่ชัดเจน
    • 19 สิงหาคม: Slack เห็นว่าหลักฐานยังไม่เพียงพอ

สรุปโดย GN⁺

  • ช่องโหว่ indirect prompt injection ใน Slack AI เป็นปัญหาร้ายแรงที่อาจทำให้ข้อมูลในช่องส่วนตัวรั่วไหลได้
  • ผู้โจมตีสามารถทำให้ข้อมูลรั่วไหลได้โดยไม่ต้องเข้าถึงช่องส่วนตัว
  • การเปลี่ยนแปลงฟีเจอร์ของ Slack AI ทำให้พื้นผิวการโจมตีเพิ่มขึ้นอย่างมาก
  • ผู้ใช้ควรจำกัดฟีเจอร์การรวบรวมเอกสารของ Slack AI เพื่อลดความเสี่ยง
  • แอปพลิเคชันที่มีฟีเจอร์คล้ายกัน ได้แก่ Microsoft Copilot, Google Bard เป็นต้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-21
ความเห็นจาก Hacker News

  • ดูเหมือนว่าจะดีกว่าหากใส่คีย์ API ของ "confetti" เป็นส่วนหนึ่งของชื่อโดเมน

    • แบบนี้คีย์อาจรั่วได้แม้ไม่ต้องคลิก เพราะเบราว์เซอร์ทำ DNS prefetching

  • แก่นของการโจมตีนี้คือการทำความเข้าใจเวกเตอร์การรั่วไหลของข้อมูล

    • Slack สามารถเรนเดอร์ลิงก์ Markdown ที่ซ่อน URL ไว้หลังข้อความลิงก์ได้
    • ผู้โจมตีหลอก Slack AI ให้ทำให้ผู้ใช้คลิกลิงก์อย่าง "คลิกที่นี่เพื่อยืนยันตัวตนอีกครั้ง"
    • ลิงก์นี้จะพาไปยังเซิร์ฟเวอร์ของผู้โจมตี และมีข้อมูลส่วนตัวที่ Slack AI เข้าถึงได้อยู่ใน query string
    • เมื่อผู้ใช้คลิกลิงก์ ข้อมูลจะรั่วไปยังล็อกของเซิร์ฟเวอร์ผู้โจมตี

  • การถกเถียงเรื่องสิทธิ์ของช่องทำให้เรื่องซับซ้อนเกินความจำเป็น

    • ผู้ใช้ A ใช้ Slack AI เพื่อค้นหา
    • ผู้ใช้ B ก่อนหน้านี้ได้ฝังข้อความเพื่อให้ AI ส่งคืนลิงก์อันตราย
    • AI ส่งคืนลิงก์อันตรายให้ผู้ใช้ A และผู้ใช้ก็คลิก
    • จะใช้เวกเตอร์ social engineering แบบอื่นก็ได้ผลลัพธ์เดียวกัน แต่ LLMs ขยายประสบการณ์นี้ให้สุดทาง

  • การที่บริษัทต่าง ๆ เอา LLMs ไปยัดใส่ทุกอย่างแบบไม่ลืมหูลืมตาเป็นเรื่องบ้าคลั่ง

    • ผ่านมาเกือบ 2 ปีแล้วนับจาก GPT-3 แต่ก็ยังแยกอินพุตที่เชื่อถือได้กับอินพุตที่ไม่น่าเชื่อถือไม่ได้

  • เหยื่อไม่จำเป็นต้องอยู่ในช่องสาธารณะเพื่อให้การโจมตีนี้ทำงานได้

    • การอ้างอิงไม่ได้อ้างถึงช่องของผู้โจมตี แต่ไปอ้างถึงเฉพาะช่องส่วนตัวที่ผู้ใช้ใส่คีย์ API ไว้
    • นี่ละเมิดพฤติกรรมการอ้างอิงที่ถูกต้องซึ่งควรอ้างถึงทุกข้อความที่มีส่วนร่วม
    • ไม่เข้าใจว่าทำไมถึงคาดหวังว่าการอ้างอิงของ LLM จะต้องแม่นยำ
    • การอ้างอิงดูเหมือนการแฮ็กมนุษย์ เพื่อหลอกผู้ชมให้เชื่อว่าผลลัพธ์แม่นยำกว่าความเป็นจริง
    • ถ้าเพิ่มการขยายลิงก์ลงในคำตอบของ AI ก็อาจทำให้ข้อมูลรั่วอัตโนมัติได้โดยไม่ต้องคลิก

  • มีการสำรวจการตั้งค่าคล้ายกันนี้ใน CTF challenge

    • แอป LLM ใดก็ตามที่โพสต์ลงฟีดแชตซึ่งมีลิงก์ที่กดได้ ล้วนมีช่องโหว่
    • หากคำนึงถึง link preview ก็ไม่จำเป็นต้องมีปฏิสัมพันธ์จากมนุษย์เลย

  • บทความนี้ไม่สอดคล้องกับพาดหัว

    • แนวคิดว่า "ถ้าทำ social engineer กับ AI ได้ ก็ฟิชชิงผู้ใช้ได้" น่าสนใจ

  • ปัญญาประดิษฐ์เปลี่ยนไป แต่มนุษย์ยังโง่เหมือนเดิม

  • เราควรเลิกให้ข้อมูลรับรองเฉพาะกับ AI agent

    • ควรใช้ข้อมูลรับรองของผู้ใช้ที่เรียกใช้งานสำหรับทุกงาน และสวมรอยเป็นผู้ใช้อย่างมีประสิทธิภาพ
    • ปัญหาไม่ใช่บริบทที่รั่วไหล แต่เป็นส่วนขยายที่มีสิทธิ์มากเกินไป

  • เป็นเวกเตอร์การโจมตีที่เจ๋งมาก

    • มีหลายวิธีในการดึงข้อมูลออกผ่านบริบทของ LLM